First connection: checks in order

Enable the configuration first, choose a proxy next, and then enable traffic routing. Clash Meta’s mihomo core parses the configuration, matches rules, and establishes outbound connections; the client interface handles subscription management and toggles. “Subscription imported” only means the configuration was retrieved—it doesn’t mean browser traffic is going through a proxy.

  1. Confirm the configuration is enabled: Select the subscription you just imported and check the core logs for errors such as YAML parsing failures or references to nonexistent policy groups.
  2. Switch to Rule mode: Look for the “Rule” option in the interface. For your first test, keep the subscription’s existing rules and avoid changing DNS, rule sets, and TUN settings at the same time.
  3. Choose an available outbound: Open the Proxies or policy groups page, find the group used by the site you want to test, and select an available proxy.
  4. Enable one traffic routing method: For your first browser test, use the system proxy. Test TUN mode separately if you need to route apps that ignore system proxy settings.
  5. Make a new request: Check the connection log, matched rule, and exit IP to verify the result. Don’t rely on the toggle’s color alone.

Which proxy should you choose in a policy group?

A policy group provides a selection layer between rules and outbound connections. For example, a rule can send a site to PROXY, and that group can point to a proxy or another policy group. Group names are set by the configuration author. A group might be called “Proxy Selection,” “International Sites,” or something else, so don’t assume its purpose from the name alone.

Follow the rule to the final outbound

  1. Open the proxy list in your client and expand the manual selection group. In the configuration, this is usually a select group.
  2. Avoid DIRECT and REJECT: the former connects directly, while the latter blocks the connection. Neither is a remote proxy.
  3. If you selected another policy group, expand it and confirm that it ultimately points to a specific proxy rather than another direct connection.
  4. After selecting a proxy, revisit the site and check the connection log to see which group and outbound handled the request.

For your first connection, choose a proxy manually and keep it fixed. An automatic latency-testing group, url-test, selects an outbound based on its configured test URL, interval, and tolerance. A failover group, fallback, generally picks an available member in order. Neither means “fastest download speed.” Fixing the proxy first helps prevent automatic switching from affecting your tests.

Proxy names aren’t proof of where they connect

Region, multiplier, and route details in proxy names come from the subscription provider; they aren’t facts measured by the core. A proxy labeled with one region may show an exit IP associated with another, and geolocation databases can lag behind. For your first connection, confirm that the proxy works and the rules are correct, then compare locations and stability based on the service you need to access.

In Rule mode, a common configuration sends sites in mainland China directly and sites outside mainland China through a proxy. So opening a site that the rules route directly doesn’t prove that your selected proxy is carrying traffic.

Latency test results and timeouts

Latency tests in a client usually aren’t ICMP pings. mihomo commonly sends an HTTP or HTTPS probe through the selected proxy to a specified URL, then reports how long it took. The test URL, connection reuse, DNS, TLS handshake, and target server response can all affect the result. Don’t directly compare numbers from different clients or test URLs.

Test the same URL three times

For example, if your client lets you set a test URL, use https://www.gstatic.com/generate_204 consistently and set the timeout to 5000 ms. This is a commonly used probe target, but it may not be reachable on every network or through every proxy. If your subscription already specifies a health-check URL, note its current value first so you don’t mistake a probe failure for a proxy failure.

  • Low latency: This probe completed quickly. It doesn’t mean video will stream at a high bitrate or that the site you need will be reachable.
  • Large fluctuations: Wireless connectivity, cross-network routing, proxy congestion, or the test server’s response may be responsible. Retest under the same conditions.
  • Timeout: The probe didn’t complete before the deadline. The proxy may be unreachable, or the test URL may be blocked, fail to resolve, or require authentication the proxy couldn’t complete.
  • Blank or not tested: Run a test first; a blank result doesn’t mean the proxy is down.

Suppose three readings are 86 ms, 92 ms, and 89 ms, while another proxy returns 45 ms, times out, and then takes 610 ms. For a first connection, start by testing the first proxy. These numbers illustrate how to compare results; they weren’t measured by this site. Consistent successful requests are usually more useful than a single lowest reading.

Check the system proxy and local port

In your client settings, find the System Proxy toggle and the actual listening port. Menu paths vary by client, so check the interface and active configuration. The system proxy writes a proxy address to the operating system settings; only apps that follow those settings will use it. Command-line tools, games, and some apps with their own network stacks may ignore it.

Local proxy port vs. remote proxy port

127.0.0.1:7890 is the local proxy entry point on your device, not the remote proxy address. This mihomo configuration snippet is for illustration; 7890 is an example port, not a default for every client. It shows only the listener and mode, not usable proxies, policy groups, or rules, so don’t replace your entire subscription with it.

mixed-port: 7890
allow-lan: false
mode: rule

mixed-port accepts both HTTP and SOCKS proxy connections on the same port. If your client shows the actual port as 7897, use 7897 in the commands below. Don’t use the controller port 9090 as a traffic proxy port: the controller manages the core and doesn’t provide the HTTP proxy entry point described here.

Isolate the issue with an explicit proxy request

On macOS or Linux, run the command below. In Windows PowerShell, replace curl at the start with curl.exe to avoid parameter parsing issues caused by an alias with the same name.

curl --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://api.ipify.org

This command explicitly uses the local HTTP proxy and clears the proxy bypass list for this request. It helps distinguish whether the local proxy endpoint works from whether an app uses the system proxy. Once a request reaches mihomo, it still follows the current rules. So getting an IP in the output doesn’t necessarily mean traffic went through a remote proxy; check the connection log too.

  • Connection refused immediately: Check that the core is running, the port is correct, and no other program is using it.
  • Connection established, then timed out: Check proxy handshake, DNS, and upstream connection logs. Don’t keep toggling the system proxy.
  • Command succeeds but browser fails: Check browser extensions, custom proxy settings, PAC, and stale connections before reinstalling the client.

Cross-check your browser and exit IP

The goal is to verify a traceable path: a new request reaches mihomo, matches the expected rule, uses the expected outbound, and gets a response. The exit IP is supporting evidence; the connection log explains why a request went direct or through a proxy.

Record a baseline, then test the same destination

  1. With TUN and the system proxy turned off and no other VPN running, visit https://api.ipify.org in your browser and record your current exit IP. The lookup service will receive the public IP address used for this request.
  2. Enable the system proxy and keep the same network and test URL. Close any existing tabs before visiting it again. If needed, quit and restart your browser to reduce the chance of reusing an existing connection.
  3. Find api.ipify.org on the client’s Connections page. Note the matched rule, policy chain, and final outbound. Short-lived requests may disappear quickly, so check the logs as well.
  4. If the domain matches DIRECT, test another destination that your existing rules should proxy, or briefly use Global mode if you understand the effects.

Global mode changes routing, but you still need to select a remote proxy in the global policy group. Selecting DIRECT still connects directly. After testing, switch back to Rule mode so you don’t mistake a temporary test setting for your everyday configuration.

A changed exit IP combined with a connection log showing the selected proxy is strong evidence that routing is working. If the IP hasn’t changed, check the rule: the request may have gone direct, or the proxy may share a public IP with your original network. Conversely, the IP may have changed because of another VPN or a network switch, so don’t rely on the IP alone.

Troubleshooting common connection failures

Proxies show latency, but web pages won’t load

Start with the explicit proxy command. If it works, check whether your browser uses the system proxy. If it fails too, inspect the rule and outbound for that request. A reachable test URL doesn’t guarantee that a site you need will work. The issue could be site restrictions, DNS, protocol differences, or the proxy route; don’t assume one probe result applies to every website.

The IP changed, but command-line tools still connect directly

Browsers and terminal tools may use different routing paths. A terminal tool may need its own proxy option or the http_proxy and https_proxy environment variables. For an initial check, use the --proxy option on a single command. Once it works, consider setting environment variables for ongoing use. After changing them, make sure new processes inherit the updated values.

Web pages work, but games or UDP apps fail

A successful HTTP request only proves that the specific route works; it doesn’t prove UDP works. Check the app’s routing method, the proxy protocol, and whether the server supports UDP. TUN can route traffic from more apps, but it can’t add UDP support to a remote proxy that doesn’t have it. Before enabling TUN, check system permissions, the virtual network adapter, and routing conflicts with other VPNs.

The site still shows the old exit IP after changing proxies

Existing long-lived connections may not switch immediately. Close the site or app, and if necessary close its connections in the client, then make a new request. Closing all connections will interrupt downloads, calls, and other sessions, so check the impact first. Also confirm that the policy group you changed is actually referenced by the rule for the destination; you may have changed a group that isn’t in use.

What to record after your first connection

Keeping reproducible details locally makes future troubleshooting easier than simply noting that it “works.” Save these five items. There’s no need to share your subscription URL, authentication parameters, or full configuration.

  • Environment: Operating system version, client version, and mihomo core version shown in the interface.
  • Active configuration: Current configuration name, last updated time, and whether you’re using Rule mode or temporary Global mode.
  • Outbound selection: Policy group referenced by the rule, final proxy, and three latency results for the same destination.
  • Routing method: System proxy or TUN, actual local port, and whether another VPN is running.
  • Verification evidence: Test time, domain, matched rule, exit IP, and request result.

Finally, restore Rule mode for everyday use and keep a stable proxy selected. Test terminal tools, download apps, or games one at a time. After a subscription update, check the final outbound again if policy group names or rules have changed. Your first connection is complete not when a latency number appears, but when a new request from the target app follows the expected rule and receives a stable response.