How to Choose Clash Nodes: Understanding Latency, Multipliers, Regions, and Protocols

Define what you need node selection to solve first

After importing a subscription into Clash, the “Proxy” page may list dozens or even hundreds of nodes. Names can include a country or region, route abbreviation, traffic multiplier, protocol, and number—for example, “Japan IEPL 01 | 0.8x” or “Singapore Hysteria2 | 1.0x.” These details are not a simple speed ranking: latency reflects interactive responsiveness, the multiplier affects traffic usage, the region determines routing and content availability, and the protocol changes how connections are established and how much transport overhead they incur.

Start by defining the use case. Web browsing and remote terminals prioritize low latency and stability; large downloads and cloud-drive syncing need sustained throughput and a favorable multiplier; region-restricted content requires choosing the right region before comparing routes. On mobile networks with frequent handoffs, also consider how the protocol handles packet loss and roaming. Relying only on “high-speed” in a node name or on a single latency test rarely produces a reliable result.

How subscription nodes, proxy groups, and actual egress relate

A subscription provides a node list and may include rules. Proxy groups determine which nodes are available for selection, while proxy rules decide whether a request enters a particular group. For example, if video services are assigned to a “Streaming” group and web traffic to a “Proxy Selection” group, changing the node in “Proxy Selection” may not change the egress used by a video app.

• Node: A single proxy entry containing a server address, port, protocol, and authentication parameters.
• Proxy group: A collection of nodes used for manual selection, automatic latency testing, failover, or load balancing.
• Rule: A rule that routes a connection to a specified proxy group or direct connection based on its domain, IP, process, or rule set.
• Egress: The server a request ultimately passes through, which can be verified with an IP lookup page or application logs.

Before testing, open “Proxy” → the target proxy group and confirm that you selected a specific node rather than another nested group. If the client shows the current route, check that its endpoint is actually in the expected region. During troubleshooting, temporarily pin one node so an automatic group cannot switch the egress while testing.

Metric 1: Read latency, jitter, and packet loss correctly

Latency tests in Clash GUI clients are usually not ICMP pings. The client sends an HTTP request through the node to a test URL and records the connection and response time. A common test endpoint is a lightweight page that returns HTTP 204. This number combines your local network, the route to the proxy server, the proxy handshake, and the test site's response; it is not the download speed the node can deliver.

A single low-latency result does not prove long-term stability

Suppose three nodes measure 68 ms, 92 ms, and 145 ms at the same moment. The 68 ms node appears fastest. But after five consecutive tests, if its results are 68, 310, 75, timeout, and 240 ms, while the 92 ms node stays between 88 and 105 ms, the latter is better for video, meetings, and remote work. The first node's average and peak are both high, suggesting congestion, packet loss, or route instability.

To compare nodes in the same region, use this method: pause any large downloads, run five consecutive tests on the same network at roughly 10-second intervals, remove one obvious outlier caused by a local connection drop, and record the median, maximum, and number of timeouts. Nodes with a lower median, a maximum close to the median, and no timeouts should rank higher.

These ranges are only for initial screening on the same network environment. The baseline for a mainland China user connecting to Japan differs from that of a European user connecting to Japan; home broadband, campus networks, corporate networks, and cellular networks are not directly comparable either. Test for your own real-world connection rather than chasing a fixed number detached from the environment.

Why low latency can still mean slow downloads

• The test request is tiny, so it cannot reveal the server's bandwidth ceiling or sustained long-connection throughput.
• The node entrance is nearby, but the transit route or the path to the target website is congested.
• Too many concurrent connections on the server: short requests work, while high-volume transfers are throttled.
• Weak local Wi-Fi, a heavily loaded router, or evening congestion at the ISP.
• Rules assigned the latency test and download request to different proxy groups.

After initial screening, choose a fixed 50 MB to 200 MB test file and download it for 30 to 60 seconds from each candidate, watching whether the speed remains stable. Use the same server for every test to avoid differences between target sites. Bandwidth tests consume real traffic, and multiplier nodes deduct traffic accordingly, so there is no need to run large-file tests on hundreds of nodes.

Metric 2: The multiplier determines how traffic is deducted

Values such as 0.5x, 1x, 1.5x, or 2x in a node name usually indicate the subscription's traffic billing multiplier. Transferring 1 GB of data may deduct 0.5 GB from a plan on a 0.5x node, or 2 GB on a 2x node. The subscription provider defines the multiplier; it is not a performance score calculated by Clash or Mihomo and does not directly indicate node speed.

Use actual usage to judge whether a multiplier fits

Assume a 100 GB monthly plan and 3 GB of actual video traffic per day. Using a 1x node continuously would consume about 90 GB in 30 days; a 1.5x node would consume about 135 GB and exceed the plan; a 0.5x node would use about 45 GB. The difference may be negligible for occasional browsing, but system updates, cloud backups, and high-bitrate video make the multiplier worth considering before speed.

1. Check how the subscription panel defines the multiplier and whether both uploads and downloads count.
2. Estimate actual daily transferred data rather than looking only at playback time.
3. Multiply actual usage by the node multiplier and compare it with the traffic remaining in the plan.
4. Use high-multiplier nodes only when they offer a genuine routing advantage; do not treat the multiplier as a quality guarantee.

Low-multiplier nodes can still become congested at peak hours, while high-multiplier nodes may simply use more expensive routes. Consider two groups: use stable 0.5x or 1x nodes for everyday traffic, and reserve high-multiplier nodes with genuinely low jitter or specific regional access for meetings, livestreams, or temporary tasks. This makes usage easier to control than staying on one high-multiplier node all the time.

Metric 3: Region affects routing, egress, and content availability

A node's region has at least two meanings: the location of the server entrance and the region associated with the egress IP seen by websites. They usually match, but transit routes, cross-region egress, or inaccurate naming can make them differ. When a specific regional egress matters, use the actual IP geolocation and the target service's result rather than relying only on a flag or abbreviation in the node name.

For everyday browsing, prefer a geographically nearby region

When other conditions are similar, a shorter distance usually means a shorter physical path and lower round-trip time. In East Asian networks, nodes in Japan, Singapore, and South Korea are often used for low-latency browsing; for services within Europe, Frankfurt, Amsterdam, or London egresses may provide better routes to the destination. ISP routing and congestion ultimately determine the experience; geography is only a first-pass filter.

Start by selecting three to five nodes in the target region, then run consecutive latency tests. Do not place Tokyo, Los Angeles, and London in one list and simply choose the lowest number, because the task may require a specific egress. For region-restricted content, use this order: “Is the region correct? → Is the service available? → Are latency and speed acceptable?”

Why access results can change

• The IP database's registered location does not match the region labeled for the node.
• The target service applies different policies to different IP ranges in the same region.
• DNS requests use local resolution while the application connection uses the proxy, creating conflicting region signals.
• The browser has retained old cookies, account-region data, or location permissions.
• Rules proxy only some domains, so login, media, and API requests use different egresses.

When a region is identified incorrectly, first pin the node in “Proxy,” then open “Connections” to confirm the matching rule and proxy group for the target domain. Clear the target site's data and sign in again. If TUN mode is enabled, check that DNS and routing are both handled by the current configuration; if only the system proxy is enabled, confirm that the application actually honors the system proxy settings.

Metric 4: Protocol affects how connections work, but does not determine speed alone

Common subscription protocols include Shadowsocks, Trojan, VMess, and Mihomo-supported VLESS, Hysteria2, and TUIC. They differ in handshakes, encryption, transport layers, and UDP support, but speed still depends on server performance, route quality, bandwidth limits, the local network, and the client core. Seeing a protocol name is not enough to conclude that it will “always be faster.”

What to look for in common protocols

Hysteria2 and TUIC are primarily based on UDP. When UDP is allowed and the route is suitable, they may maintain good throughput on high-latency networks with light packet loss. However, corporate networks, campus networks, and some mobile networks may restrict UDP, causing connection failures, handshake timeouts, or unstable speeds. In that case, first switch to a TCP-based node in the same region for comparison instead of immediately changing every DNS and rule setting.

Protocol compatibility also depends on the core. Clash Nyanpasu can work with the Mihomo core, but every field in the subscription must be recognized by the current core version. If a class of nodes still fails after updating the core, check the logs for messages such as “unsupported,” “authentication failed,” “TLS handshake,” or “timeout.” Unsupported protocols, authentication errors, and route timeouts are different problems and require different fixes.

TUN mode does not make nodes faster automatically

TUN mode uses a virtual network interface to capture traffic from more applications. It is useful for terminal programs, game launchers, and some desktop apps that ignore system proxy settings. It changes how traffic enters Clash; it does not increase the proxy server's bandwidth. If speeds drop after enabling TUN, check for double proxying, an unsuitable MTU, DNS bypassing, or interference from security software.

In common desktop layouts, open “Settings” → “Clash Settings” → “TUN Mode” to check its status; node switching is under “Proxy” → proxy group → node name. Wording may vary slightly by version. Keep the mode consistent during comparisons: do not use the system proxy for node A and switch to TUN for node B, or the results will also reflect a change in traffic capture method.

A repeatable workflow for choosing nodes

When you have many nodes, you do not need to run a full test on every one. Narrow the candidates by use case, region, and multiplier, remove obvious outliers with short tests, and let real applications provide the final validation. This workflow can usually identify a primary everyday node and a backup from dozens of candidates in about ten minutes.

1. Define the use case: State whether you need web browsing, video, downloads, remote access, or a service in a specific region.
2. Limit the region: Keep 5 to 10 nodes from regions that meet the egress requirement.
3. Check the multiplier: Exclude high-multiplier nodes that are unsuitable for long-term use based on your remaining plan allowance.
4. Run repeated latency tests: Test each candidate 5 times and record the median, peak, and timeouts.
5. Run a short throughput test: Test the remaining 2 to 3 nodes with the same file for 30 to 60 seconds.
6. Validate with real applications: Open the target website, play a video, or establish a remote connection.
7. Keep a backup: Ideally, the primary and backup nodes should use different servers or routes.

How to configure an automatic proxy group

If the subscription allows local configuration overrides, use url-test to periodically select the lowest-latency node from a group of candidates. The example below tests every 300 seconds with a 50 ms tolerance; when several nodes are close, the tolerance reduces frequent switching. Replace the node names with names that actually exist in your configuration.

proxy-groups:
  - name: Daily automatic selection
    type: url-test
    proxies:
      - Japan-01
      - Japan-02
      - Singapore-01
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

url-test selects nodes mainly by the response time of the test URL; it does not account for multipliers, regional access, or large-file throughput. Filter the candidate list beforehand rather than mixing every region and multiplier together. When availability is the priority, consider fallback, but it also cannot replace validation with real workloads.

Common misconceptions and troubleshooting

Latency test times out, but websites still open

The test URL may be temporarily unreachable, restricted by the target network, or subject to an overly short client timeout, while the node can still proxy other websites. First replace the test address with a stable lightweight page, then use real connections and logs to investigate. If every node times out at once, check the local network, subscription status, core process, and firewall before deleting nodes individually.

The egress does not change after selecting a node

The most common cause is switching the wrong proxy group. Open “Connections” to see the rule, proxy group, and node route matched by the target request. If a rule sends the request to “Streaming” while the user changes only “Proxy Selection,” the egress naturally stays the same. Also check whether the browser has an independent proxy extension and whether the terminal defines the HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY environment variables.

Automatic selection keeps bouncing between a few nodes

When latency differs by only 10 to 30 ms, minor network fluctuations can change the ranking. Set the test interval to 300 to 600 seconds and use a tolerance of about 50 ms to avoid switches with no meaningful benefit. For remote terminals, meetings, or long-lived connections, manually pinning a stable node is often better than constantly chasing the lowest latency.

Nodes labeled with the same region perform very differently

Being in Japan or Singapore does not mean nodes use the same ISP, entry point, international route, or server capacity. A node number is not a quality grade. Record stable performers in a dedicated proxy group and keep a different route as a backup; retesting during peak hours often reflects long-term performance better than a single daytime test.

Make the decision using four recorded metrics

Summarize node selection in a simple record: latency as the median and maximum, multiplier as the actual deduction rule, region as the real egress and target-service result, and protocol as connection stability on the current network. For example, “Japan-02: 86 ms median, 112 ms maximum, 1x, Japan egress, Trojan, stable for a 60-second download” is easier to compare later than “the Japan node is fast.”

Your everyday primary node does not need to rank first on every metric. A node that is stable, has an acceptable multiplier, uses the right egress, and remains reliable in real applications is the more practical choice. Network conditions change with ISP routing, server load, and time of day, so rerun a short test when noticeable stuttering appears instead of switching nodes repeatedly every day.