How to Choose a Clash Proxy Node

Choose by use case first, then compare latency

Node names, latency, and traffic multipliers in Clash answer different questions. The region affects your exit location and which services you can access. The multiplier affects how quickly you use up your subscription allowance. The protocol determines compatibility with your core and transport requirements. Latency reflects only the response during a particular test. Sorting every node by milliseconds won’t tell you which one best suits your task.

First, make sure the active Profile is enabled in your client, then open the Proxies or Proxy Groups page. Labels vary by client, so check the proxy group name, group type, and connection log to confirm what’s actually happening. Before switching nodes, make sure the group you’re changing is referenced by the rules for your target site—not an unused fallback group.

1. Define the use case: Web browsing, video streaming, remote terminals, and large file transfers have different requirements.
2. Choose an exit region: Keep only regions supported by the target service. If there are no regional restrictions, compare latency and stability next.
3. Check the cost: Review your provider’s notes on traffic multipliers and billing before ruling out nodes that aren’t practical for extended use.
4. Verify the transport: Make sure your current core supports the protocol. If your app needs UDP, test the entire UDP path as well.
5. Compare real-world connections: Retest on the same network, against the same target, and around the same time. Keep one primary and one backup exit.

What a latency test actually measures

HTTP probe times aren’t just network round-trip time

Clash and mihomo latency tests commonly send a request to a test URL through the selected proxy. This differs from sending an ICMP ping directly to the node server. Results reflect the combined effects of your route to the proxy entry, the proxy handshake, the route from the exit to the test site, and the endpoint’s response. Whether DNS, TLS, or connection reuse is involved depends on the core implementation and the state of the connection.

For example, readings of 80 ms and 160 ms are comparable only when the test URL, network conditions, and test method are the same. These figures illustrate how to compare results; they aren’t measurements from this site. An exit closer to the test site may win that test without being closer to the server you actually need to reach.

Retest under consistent conditions; don’t judge by a single result

Test only a few candidate nodes per round to avoid saturating your local connection with concurrent probes. On the same network, record results across three rounds, about 30 seconds apart. These are suggested test settings, not a performance guarantee. Compare typical results and timeout frequency, not just the lowest reading. To assess evening performance, retest during your usual hours.

Pause large file syncs during testing and keep the test URL unchanged. If every node times out, check your local network, the test site, and your subscription status first. If only one node keeps failing, check its protocol settings and service status. Avoid changing DNS, TUN, and all your rules at once after a single timeout, or you won’t know what caused the change.

How traffic multipliers affect your subscription allowance

A traffic multiplier is usually a billing rule set by your subscription provider, not a Clash protocol field. Labels such as “0.5x,” “1x,” or “2x” in node names may simply be text added by the provider; the client doesn’t determine billing based on the name alone. Check your provider’s documentation and account statement for the actual multiplier, whether uploads and downloads both count, how usage is measured, and when the rate takes effect.

A higher multiplier doesn’t mean lower latency or more bandwidth. It may reflect the cost of a particular route or regional resources, so test the connection yourself. For system images, photo sync, or long video sessions, look for a low-multiplier node that meets your needs. For remote work, responsiveness and stability may matter more, so choose a better-fitting route if your budget allows.

• When trying a node with a new multiplier, note your remaining allowance first. Run a controlled transfer, wait for the provider’s usage figures to update, then compare.
• Don’t treat the per-session traffic shown in the client’s connection page as a substitute for your provider’s bill; they may measure usage at different points.
• If your subscription is shared across devices, account for their usage too. Otherwise, a single comparison can lead to the wrong conclusion.

Check the node’s exit region, not just its name

The region in a node name is usually entered by the subscription provider and may refer to the entry point, exit point, or route group. If a connection enters through Hong Kong and exits through Japan to reach a website, the site will generally see a Japanese exit IP. Shorter physical distance doesn’t guarantee a shorter route; peering between carriers and routing through intermediaries also affect performance.

Cross-check the region in three ways

1. Confirm the connection route: Find the target domain on the client’s Connections page and check its matched rule, proxy group, and final node.
2. Check the exit IP: In the same browser, visit a trusted IP lookup service and note the public IP and region it reports. Make sure the lookup request isn’t routed through DIRECT.
3. Test the target service: Check availability on the service you actually need. IP databases may be outdated, and services can identify regions differently.

If the lookup site reports the expected region but the target service still shows a regional restriction, check your account region, payment details, existing sessions, and the service’s own policies. Switching to a node with the same region label may not fix the restriction. A node name also doesn’t prove the IP type, access to a particular service, or whether using the account this way complies with its terms.

For services where you stay signed in, keep the exit region as consistent as possible. Frequent region changes may trigger extra verification. Existing TCP connections generally won’t move to a new node when you switch; reconnect to verify the new exit. Whether to close old connections depends on whether your current downloads, calls, or remote sessions can be interrupted.

Choose a protocol based on compatibility and UDP support

Shadowsocks, Trojan, VMess, VLESS, Hysteria2, and TUIC are names for different proxy protocols or transport systems—not speed tiers. Supported protocols depend on the client’s core and its version. Clients built on the Clash Meta (mihomo) core don’t support exactly the same things as the discontinued legacy Clash clients.

If importing a configuration produces an unsupported proxy type, a parse error, or a handshake error, first check the actual core in the client’s About page or core information. Then compare it with the configuration requirements. Don’t rely on the app’s name alone, and don’t change type, network, SNI, or TLS options without understanding what they do.

Hysteria2 and TUIC use QUIC-based transports, which require UDP to be reachable underneath. Some networks restrict UDP, so a connection may fail even when the protocol is supported. Likewise, a node that can proxy web traffic over TCP isn’t necessarily able to carry UDP traffic for games or voice calls.

System proxy settings don’t usually route every app’s UDP traffic automatically. If an app ignores the system proxy, check whether TUN mode or the app’s own proxy settings cover that traffic. Even with udp: true in the node configuration, the server must support UDP, and the client must capture and route the traffic correctly. Don’t disable certificate verification to troubleshoot ordinary network fluctuations.

How to combine manual selection with automatic testing

Use select for a fixed exit and manual choice; use url-test to automatically select among similar candidates based on probe results. The latter won’t assess subscription multipliers, account region requirements, or whether the target service is accessible. Mixing high- and low-multiplier nodes or incompatible regions in one auto group can lead to a switch that looks better on paper but doesn’t suit your needs.

This is a mihomo proxy group snippet to merge into an existing Profile, not a complete configuration. Replace 日常-A and 日常-B with node names that actually exist in your configuration, and first confirm that both meet the same multiplier and exit-region requirements. The core sends requests to the test URL, so choose an endpoint that’s reliably reachable over both your current network and proxy route.

proxy-groups:
  - name: Daily Auto
    type: url-test
    proxies:
      - Daily-A
      - Daily-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: Daily Select
    type: select
    proxies:
      - Daily Auto
      - Daily-A
      - Daily-B

interval: 300 sets the automatic probe interval to 300 seconds; tolerance: 50 sets a 50 ms switching threshold to reduce unnecessary switches when latency is similar. It isn’t the maximum allowed latency. This group won’t capture all traffic automatically: existing rules must reference 日常选择 for connections to use it.

For example, the rule DOMAIN-SUFFIX,example.com,日常选择 sends connections matching that domain suffix to this proxy group. Rules are generally evaluated in order; if an earlier rule matches, later rules won’t handle that connection. See the proxy group configuration guide for more syntax details.

Run a final check for your use case

Browsing and remote work: prioritize responsiveness

For everyday browsing, start with a low-multiplier node that responds consistently across repeated probes. SSH, remote desktop, and admin dashboards depend more on responsiveness and session continuity; consider using a fixed manual exit to avoid automatic switches complicating troubleshooting. If the node tests successfully but your terminal disconnects, also check the destination server, firewall, and idle connection timeout.

Video and downloads: prioritize sustained transfer and cost

For video, first confirm that the target service plays properly, then check that playback continues without buffering. For large downloads, compare sustained transfers from the same source rather than the initial burst speed. A speed test site’s throughput doesn’t represent every download source, and repeated tests can use up a substantial amount of your subscription allowance.

Gaming and voice calls: verify the UDP route separately

First confirm that the game or voice app is actually routed through the proxy, then check its own latency, jitter, and packet loss indicators. A successful web probe is only an initial check. If switching nodes makes no difference, check whether the rule still routes through DIRECT and whether the app is reusing an old connection before trying more protocols.

1. Save one stable primary node and one tested backup, and note each node’s region and multiplier.
2. Connect to the target service and confirm the actual exit in the client—not just the highlighted option in the group.
3. Check performance during a real task, then confirm that your account allowance changed as expected.
4. When troubleshooting, change one thing at a time: the node, routing mode, rule, or DNS. Retest after each change.

Choose in this order: meet the use case and region requirements, accept the multiplier, confirm protocol and traffic-routing compatibility, then compare latency and real-world stability. Use milliseconds to narrow down the candidates, not as the sole basis for choosing a node for every situation.