How to Choose a Clash Proxy Node: Latency, Multipliers, Regions, and Protocols Explained

Set the selection order first

Node lists usually highlight the region and latency, but choosing a node by lowest latency alone is a mistake. Latency reflects responsiveness, not download bandwidth; the multiplier affects traffic usage, not line quality; the region determines the route and content availability; and the protocol affects compatibility, handshake overhead, and network resilience. Each metric answers a different question.

A more reliable order is: narrow down the region by use case, remove nodes with timeouts or high packet loss, compare peak-hour speeds, then consider the multiplier and protocol. This avoids choosing a low-latency node that downloads slowly in practice, or sticking with a high-multiplier route for a few milliseconds of advantage.

A one-minute way to choose

1. For web browsing, start by testing nearby nodes in Hong Kong, Japan, and Singapore.
2. For streaming, choose a node in the target content region first, then verify that your account and the content are available.
3. Within the same region, shortlist the three nodes with the lowest latency instead of keeping only the top result.
4. Run five consecutive tests for each node. Remove nodes that time out, fluctuate by more than 100ms, or frequently spike.
5. Use the same download source for 30 seconds and record the sustained speed, not the initial burst.
6. When speeds are close, choose the node with the lower multiplier and the protocol that best matches your current network.

For example, Hong Kong A has 42ms latency, an 18MB/s download speed, and a 1.5 multiplier. Hong Kong B has 58ms latency, a 27MB/s download speed, and a 1.0 multiplier. The response difference is barely noticeable for everyday browsing, while B is better for sustained downloads. If A maintains low jitter during peak hours but B often drops to 2MB/s, switch your primary node back to A.

How to read latency figures

Latency tests in the Clash client typically access a test URL through the proxy node and record the time needed to complete a connection or HTTP request. This is not a full bandwidth test and is not the same as a traditional ICMP ping. A node server may block ICMP while proxy connections still work; conversely, a 40ms result does not prove that large files will download quickly.

What latency, jitter, and packet loss mean

• Latency: The time required for a request to make a round trip, usually measured in ms. Lower values generally mean faster first responses and interactions.
• Jitter: Variation between repeated test results. 50ms, 52ms, and 55ms is more stable than 32ms, 180ms, and 70ms.
• Packet loss: Data packets failing to arrive successfully. Persistent packet loss causes loading pauses, choppy voice calls, and connection retransmissions.
• Throughput: The amount of data transferred per unit of time, commonly measured in Mbps or MB/s. It can only be judged by transferring actual data.

Latency can be assessed roughly by use case. 30ms to 80ms works well for most web browsing, instant messaging, and video playback; 80ms to 150ms is usually still usable, though interactions feel slower; above 200ms, initial page loads, remote terminals, and real-time actions become noticeably sluggish. These ranges are not quality guarantees, so consider jitter and packet loss as well.

Why results differ for the same node

A test request passes through your local Wi-Fi, the ISP access network, international links, the node's entry point, and the test server. Congestion anywhere along the path changes the result. When the client tests multiple nodes at once, local bandwidth and connection limits can also interfere with one another. A one-time full-list test is therefore useful only for initial filtering, not long-term evaluation.

In the client's “Proxies” page, test the full node group first, then test shortlisted nodes individually five times. With Clash Verge Rev 2.x, you can usually open “Proxies” → select a proxy group → run a latency test; button labels may appear as “Speed Test,” “Latency Test,” or “URL Test” in different builds. Pause large downloads and cloud sync, and record separate results for daytime and 20:00–23:00.

How multipliers are calculated

A multiplier is a traffic-accounting factor, not a speed multiplier. Transferring 1GB through a node with a 2.0 multiplier usually consumes 2GB from your account; a 0.5 multiplier usually consumes 0.5GB. The exact accounting method depends on the subscription service: some combine upload and download traffic, while others apply separate multipliers to specific routes.

“0.5x,” “1x,” and “2x” in node names usually indicate the multiplier, but the Clash configuration format has no standardized multiplier field. The client only displays text added to the node name by the subscription provider; it does not calculate your account balance. Check the subscription service's account page for the multiplier, plan allowance, and reset date.

When a high-multiplier node is worth using

• Low-multiplier nodes remain congested during peak hours while a high-multiplier dedicated route maintains a stable speed.
• A remote meeting, live demo, or file delivery requires a reliably stable connection.
• Only a few nodes are available in the target region, so regional access takes priority.
• Standard nodes show clear packet loss, while the high-multiplier route offers better routing and entry-point quality.

A high multiplier does not necessarily mean higher quality. Labels such as “dedicated line” and “premium” are also just route markers; sustained testing is what matters. If two nodes both maintain 50Mbps during peak hours, with latency of 62ms and 70ms and multipliers of 2.0 and 1.0, the latter is usually preferable for ordinary web and video use.

Choose regions by use case

A region name usually indicates where the proxy exit IP is located, not the complete physical route taken by the server traffic. A node labeled “Japan” may enter through a local relay, pass through other regions, and exit in Japan. Choose based on the target service, route distance, and regional restrictions rather than treating a country or region label as a fixed performance tier.

Hong Kong, Japan, and Singapore

For most networks in mainland China, Hong Kong is physically nearby, with typical latency of about 30ms to 80ms, making it suitable for web browsing, instant messaging, and general downloads. Japan commonly measures around 50ms to 120ms and may work better for software repositories, developer services, and Japan-region content. Singapore commonly measures around 70ms to 150ms, suits services aimed at Southeast Asia, and can serve as a fallback when Hong Kong or Japan routes are congested.

These figures are for initial filtering only. International gateways vary widely by carrier, and China Telecom, China Unicom, and China Mobile connections in the same city may produce completely different results. Test mobile hotspots and home broadband separately; do not apply results from one network environment directly to another.

The United States and Europe

US nodes are suitable for services that explicitly require a US exit, North American server administration, and regional content. Because of the longer distance, latency is commonly 140ms to 260ms. European nodes are often slower, with some routes exceeding 250ms. Video can still play smoothly at a stable 200ms because the player buffers, while remote desktops, SSH input, and real-time games will feel noticeably delayed.

Streaming and account regions

Streaming availability depends on more than the region. Services may also evaluate IP type, exit reputation, account registration region, payment method, and location permissions. If a node passes its speed test but content will not play, first try another exit in the same region instead of changing Clash DNS, ports, or rules. After switching, close the existing playback page and establish a new connection so the old connection is not reused.

Do protocol differences matter?

Subscription nodes may use Shadowsocks, VMess, VLESS, Trojan, Hysteria2, TUIC, and other protocols. Clash Meta, commonly powered by the mihomo core, supports many protocols and transport options; older Clash cores and earlier clients may not recognize every field. If nodes do not appear at all after importing a subscription, first check whether the client core supports the protocol instead of assuming the nodes are inactive.

What to prioritize with common protocols

• Shadowsocks: Simple to configure and broadly compatible. Real-world quality depends mainly on the cipher, server performance, and route.
• Trojan: Commonly used with TLS. An incorrect system clock, mismatched certificate domain, or faulty SNI configuration can cause the handshake to fail.
• VMess and VLESS: May be paired with WebSocket, gRPC, TLS, or Reality. All node parameters must match; copying only the address and port is not enough.
• Hysteria2 and TUIC: UDP-based transport may perform well on high-latency or lossy routes, but it is affected by the local network, router, and carrier UDP policies.

Protocol names cannot be converted directly into a speed ranking. A Shadowsocks node on a high-quality route may be faster than Hysteria2 on a congested route. Protocol differences are meaningful only under comparable route, server, and load conditions. Beginners do not need to modify settings constantly for the sake of protocol choice: start with the complete parameters supplied by the subscription, then choose based on actual connection results.

When a UDP node will not connect

If Hysteria2 or TUIC works on home broadband but times out on a mobile hotspot, the issue may be in the UDP transport layer. Switch to a TCP-based node in the same region to verify basic connectivity, then check that the client is using a mihomo core that supports the protocol. If only UDP nodes fail, repeatedly changing the system proxy port usually will not help.

TUN mode does not automatically make a node faster. TUN takes over more system traffic so applications that do not read system proxy settings can still pass through Clash. When the node is congested, exit bandwidth is insufficient, or the remote server is rate-limiting, enabling TUN cannot remove the bottleneck and instead adds another traffic-processing layer to inspect.

Use real speed tests to choose a primary node

Reliable testing requires controlled variables. All candidate nodes should use the same network, device, time period, and download source. Do not test a video site through node A and a software mirror through node B, then compare the speeds directly. Temporarily quit browser extensions, system VPNs, game boosters, and other proxy programs to prevent traffic from taking different paths.

A three-round testing process

1. Round one, connectivity: Run a latency test on every node in the proxy group and remove nodes that time out twice in a row.
2. Round two, stability: Test each remaining node five times and record the average latency, highest latency, and number of timeouts.
3. Round three, throughput: Use a fixed test file or a trusted speed-test site and test each node continuously for 30 to 60 seconds.

Suppose node A records 42, 45, 47, 44, and 46ms across five tests, with a sustained download speed of 12MB/s. Node B records 35, 38, 190, 41, and 220ms, with speeds fluctuating between 3MB/s and 25MB/s. Even though B has the lower minimum latency, A is still better as a daily primary node. Video and file transfers depend especially on sustained stability.

Do not confuse Mbps with MB/s. A speed-test page showing 100Mbps converts to about 12.5MB/s in theory; after protocol overhead and network variation, actual downloads may run at 9MB/s to 12MB/s. A browser showing 8MB/s does not mean the connection is only 8Mbps.

100 Mbps ÷ 8 = 12.5 MB/s
50 Mbps ÷ 8 = 6.25 MB/s
20 MB/s × 8 = 160 Mbps

Automatic proxy-group selection

The url-test proxy group in a configuration can test nodes periodically and automatically select a low-latency node that meets the criteria. It works best for a group of candidates in the same region with similar use cases. Do not put Hong Kong, US, streaming-only, and high-multiplier nodes into one automatic group, or the client may switch solely by test latency to an exit that does not fit the task.

proxy-groups:
  - name: HK-AUTO
    type: url-test
    proxies:
      - HK-01
      - HK-02
      - HK-03
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

interval: 300 means testing every 300 seconds, while tolerance: 50 helps prevent frequent switching over differences of only a few dozen milliseconds. The test URL must be stable, have a small response body, and be reachable through the nodes. This test still estimates response speed only; it does not measure large-file throughput.

When to switch nodes and when to change settings

Once you determine whether a problem is at the node layer or the client layer, you can avoid wasted troubleshooting. If one node times out while others in the same group work, switch nodes first. If every node fails, check the subscription, local network, client port, system proxy, DNS, or core. Do not repeatedly reinstall the client because one node is congested, and do not blindly cycle through dozens of nodes when all of them fail.

Check the port and system proxy

Many Clash configurations use the mixed port 7890, but the client may use a different port. Follow the value currently shown by the client instead of copying a fixed tutorial setting. When configuring a proxy manually in the browser, the address is usually 127.0.0.1; the port must match the Mixed Port shown under “Settings” → “Port Settings” or “Settings” → “Parameter Settings.”

If the client connection log contains no browser requests at all, the problem probably has not reached the node layer. Enable the system proxy first, then make sure no other VPN or proxy program is capturing the traffic. If the log shows the request and it times out after hitting a proxy node, continue by testing that node, the proxy group, and the remote service.

DNS cannot fix bandwidth congestion

DNS resolves domain names to addresses and participates in rule matching and connection setup. Resolution problems can stop a domain from opening, produce unexpected rule matches, or slow the first connection, but they cannot turn a congested 5Mbps route into 100Mbps. Check DNS when direct IP access works but the domain fails; when every download is slow, check node throughput and local bandwidth first.

The four-dimension conclusion

Use latency to assess responsiveness, focusing on repeated results and jitter; use the multiplier to estimate traffic consumption, not performance; choose the region based on the target service and physical distance; and assess protocol compatibility first, then how the current network handles TCP, UDP, and different transports. These four dimensions cannot replace one another.

For everyday use, shortlist three nodes in a nearby region, run five latency tests and one 30-second download test, then place the stable node in a manual proxy group. A node with low but erratic latency, high peak speed but poor sustained throughput, or a high multiplier without a quality advantage is not a good long-term default.

When something fails, switch nodes if only one node is affected; check the subscription, network, and client if every node fails; and inspect the system proxy, rules, and TUN coverage if only some apps are affected. Layer-by-layer diagnosis is faster than repeatedly changing DNS, ports, and protocol parameters.