How to Choose a Clash Proxy Node: Latency, Traffic Multipliers, Location & Protocols

Check the Route First: Make Sure the Node Selection Takes Effect

Before choosing a node, confirm that the target connection actually passes through the policy group you’re changing. Clash rule mode evaluates rules from top to bottom. If a browser request matches DIRECT, changing proxy nodes won’t affect its route. A streaming rule may also point to a separate policy group, unrelated to the default proxy group shown on the home screen.

1. Open «Configuration» or «Profiles» in the client and confirm which subscription profile is active. Updating a different profile isn’t enough.
2. In «Proxies», find the policy group referenced by the rule and select a node manually.
3. Visit the target site, then open «Connections» to check the target domain, matched rule, and outbound route. Menu names vary by client; the key is to verify these three fields.
4. After switching nodes, establish a new connection before testing. Existing long-lived TCP connections usually won’t migrate automatically; stop the original task and reconnect if needed.

Judge Latency by Consistency, Not a Single Low Reading

The latency shown by a client usually comes from probing a test URL through the node. It isn’t simply the ICMP latency between your device and the node server, nor is it download speed. Results depend on the test URL, DNS, connection setup, protocol handshake, connection reuse, and the core implementation. Compare nodes on the same network and against the same test URL for meaningful results.

Screen Candidates with Five Test Rounds

Choose three candidate nodes and test them five times, about 30 seconds apart. Avoid running large downloads at the same time, and keep timeout results instead of recording only the lowest successful reading. The example below illustrates how to assess results; it isn’t data measured by this site for any service.

In this example, try A first for everyday browsing rather than choosing B just because it once hit 25 ms. If C meets the location requirements of your target service, it may be a better fit than unstable B. A probe timeout alone doesn’t prove packet loss; use network diagnostics and real connection behavior to assess that.

Test a Real Task Again During the Evening Peak

• Browsing: Open five frequently used pages in a row and watch for repeated delays loading the page, images, or scripts.
• Video: Use the same video and resolution, then monitor buffering for three minutes—not just how quickly playback starts.
• Downloads: Use the same legitimate test file and record both the initial speed and performance over 60 seconds. Avoid competing tasks that consume bandwidth.

If performance is fine during the day but drops noticeably in the evening, the route or server may be under heavier load. Changing protocols may not help; compare another route and retest during your usual usage hours.

Traffic Multipliers: Estimate Usage Before Comparing Speed

Labels such as «0.5x», «1x», or «2x» in node names usually indicate how a subscription service bills traffic; they aren’t universal rate limits built into the Clash core. A node named «2x» won’t make downloads twice as fast. Check the provider’s terms and your account’s usage records for the actual billing rules. Some services account for uploads, downloads, or specific time periods separately.

Estimate Account Usage in Consistent Units

Suppose a service bills usage as metered traffic × multiplier and a task transfers 2 GiB: a 0.5x node would use about 1 GiB of quota, 1x about 2 GiB, and 2x about 4 GiB. This is only an example. Protocol overhead, billing in both directions, and the difference between GB and GiB can all make account records differ from local file sizes.

• Web browsing and messaging: Prioritize consistency; treat the multiplier as a secondary factor.
• Video and large files: Estimate monthly usage first, then choose a low-multiplier node that can reliably meet your needs.
• Time-sensitive tasks: A higher-multiplier but more reliable candidate may be worth using. Switch back to your everyday node when the task is done.

Choosing a Location: Consider the Exit and Target Service, Not Just Distance

A location in a node’s name may indicate its exit location or simply be a route label used by the provider. The entry server, relay route, and final exit can all be in different places. Being physically close to a region doesn’t guarantee the node there will be fastest; ISP peering, detours, and peak-time congestion all affect performance.

Everyday Websites and Streaming Need Different Checks

For everyday browsing, start with a stable route in a nearby region, then compare how pages actually load. For streaming, first check the service’s requirements for account region, exit IP, content rights, and terms of service. An exit IP identified as belonging to a particular country or region doesn’t guarantee access to all content there.

1. Select a candidate node manually and confirm the target domain matches the expected policy group.
2. Check the exit IP and location through that outbound route, then verify playback on the service itself.
3. Play at a fixed resolution for at least three minutes. Check for repeated buffering, quality drops, or location notices.
4. If the page and playback results don’t agree, check whether a different rule is routing media domains elsewhere before assuming the node has failed.

For development, test the actual task. Code hosts, package repositories, and container registries may use different CDNs, so a fast homepage doesn’t mean dependencies will download quickly. For services that rely on persistent login sessions, keep the exit region consistent where possible; avoid automatic groups that frequently switch between regions.

Choosing a Protocol: Check Compatibility First, Then UDP and Network Conditions

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and TUIC are different proxy protocols or implementations, not speed tiers. The same protocol can perform very differently on different routes. First confirm that the client’s core supports the protocol and its parameters; older Clash versions and Clash Meta (mihomo) don’t support the same set of options.

Hysteria2 and TUIC are based on QUIC and rely on a working UDP route. Some networks restrict UDP, which can prevent connections or cause unstable performance. Common TCP-based proxy transports are also affected by congestion and route quality. Protocol names can’t replace real-world testing, and they don’t support a universal ranking of the «fastest protocol».

If web browsing works but voice or games don’t, check UDP, TUN traffic capture, and routing rules. If the client reports an unsupported proxy type, address core compatibility first; disabling certificate verification isn’t a general fix. Subscription credentials, server addresses, and transport parameters must match the server configuration.

Policy Groups: Automate Everyday Selection, Pin Nodes for Critical Tasks

url-test can automatically select a candidate based on test results, but it doesn’t check traffic multipliers, video access, or whether a development task succeeds. Mixing every region and multiplier into one automatic group may produce a low probe latency without meeting your actual needs.

mihomo Configuration Snippet

The example below shows only the proxy-groups section. It assumes the current configuration already has two nodes named exactly JP-A and SG-A under proxies. Replace these with your actual node names and merge the snippet into the existing configuration. Don’t add a second top-level proxy-groups key to the same YAML file.

proxy-groups:
  - name: Daily
    type: select
    proxies:
      - Auto
      - JP-A
      - SG-A

  - name: Auto
    type: url-test
    proxies:
      - JP-A
      - SG-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

• type: select: Manually select a node. Use Auto for everyday browsing; pin a specific node for long downloads or tasks where maintaining a login session matters.
• interval: 300: Run automatic probes every 300 seconds. This is not the subscription update interval.
• tolerance: 50: The switching tolerance in milliseconds helps avoid switching over small latency differences. It isn’t a speed limit or timeout threshold.
• url: Choose a lightweight HTTPS test URL that’s reliably accessible. Results from before and after changing the URL aren’t directly comparable.

These fields follow common mihomo configuration guidance; check the relevant documentation for other cores. Rules must also reference Daily for the group to affect target traffic. Creating a policy group alone doesn’t change routing. See the policy group field reference to verify the structure, and the rule field reference to check how it’s used.

Wrap Up by Keeping a Primary and a Backup Node

Keep one primary node and one backup on a different route. Record the test date, network, task, multiplier, and results. If something goes wrong, retry the same task through the backup route. If all nodes degrade at the same time, check your local network, traffic capture mode, DNS, and current configuration before adding more candidates.

The selection process boils down to this: first confirm traffic uses the right policy group, then screen for consistency. If the service requires a specific region, verify access before comparing latency; for high-volume tasks, calculate the multiplier; only then compare compatible protocols.