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

Define the task before reading speed-test numbers

When choosing Clash nodes, the lowest latency does not always deliver the best experience. Web browsing, video buffering, remote meetings, file downloads, and gaming connections each place different demands on a route. Before testing, decide whether the priority is responsiveness, sustained bandwidth, an exit region, or data usage.

For example, the same subscription may include a Hong Kong node at 48 ms and a Japan node at 82 ms. The former will usually load webpages faster, but if it suffers noticeable packet loss during peak hours, video playback may be less stable than on the latter. A US node listed at 160 ms is not suited to low-latency interaction, yet it may be the right choice for accessing content restricted to the United States.

Priority metrics by common use case

• Everyday browsing: Prioritize latency, connection success rate, and peak-hour stability. A geographically closer region is usually preferable.
• High-definition video: Prioritize sustained download speed and jitter. A route with a high burst speed but frequent slowdowns is not ideal.
• Voice meetings: Focus on round-trip latency, jitter, and packet loss. A steady 80 ms connection is generally easier to use than one fluctuating between 35 and 180 ms.
• Large downloads: Look at sustained throughput, the traffic multiplier, and remaining quota instead of chasing the lowest latency alone.
• Region-specific content: Confirm the required exit country or region first, then compare stability among nodes that meet that requirement.
• Unreliable mobile connections: Compare protocol behavior, reconnection speed, and whether UDP is available.

How to read latency test results

Latency tests in Clash graphical clients usually request a very small test URL and record the time from initiating the connection to receiving a response. Different clients, profiles, and proxy providers may use different test URLs, so results from two applications are not directly comparable.

Latency is also affected by DNS resolution, the TLS handshake, the test server’s location, local Wi-Fi, and the node’s current load. A one-time result of 42 ms only means that a small request completed quickly at that moment; it does not prove that the node can sustain high download speeds.

Practical latency ranges

These ranges are not fixed standards. From mainland China to nodes in Hong Kong, Japan, or Singapore, results commonly fall between 35 and 120 ms; European or North American nodes often measure 140–260 ms. The carrier, city, access route, and cross-border routing can all change the result.

Test at least three times in a row

1. Close active large downloads, cloud-drive sync, and system updates.
2. Test each candidate node 3–5 times in a row, with about 5 seconds between tests.
3. Record the minimum, maximum, and number of timeouts instead of keeping only the best result.
4. Run one round during the day and another from 8:00–11:00 p.m. to compare peak-hour performance.
5. Narrow the list to two or three candidates, then play a 1080p video or download a test file of about 200 MB.

Suppose node A returns 46, 49, 51, 48, and 50 ms, while node B returns 32, 37, 145, a timeout, and 41 ms. Although node B has the lower minimum, node A varies by only 5 ms and will often feel more stable for browsing and meetings. Node A should be the preferred choice here.

Latency, jitter, packet loss, and speed explained

Latency determines how long a request waits

Latency mainly affects short connections and frequent interactions. When opening a page with many small resources, every connection and request waits for a network round trip. Remote terminals, online documents, and voice calls are also latency-sensitive. When latency rises from 50 ms to 180 ms, operations feel noticeably slower even if download bandwidth stays the same.

Jitter shows whether latency is stable

Jitter can be understood as the variation between repeated latency measurements. Consecutive results of 70, 73, and 76 ms are generally more stable than 40, 160, and 55 ms. Voice and real-time video must receive data continuously in sequence; excessive jitter can cause choppy audio, frozen frames, or brief dropouts.

Packet loss triggers retransmissions or quality drops

TCP traffic usually retransmits lost packets, reducing download speed; UDP applications may simply lose portions of data, making real-time voice and gaming more sensitive. Interference on home Wi-Fi, local-carrier congestion, an overloaded node entrance, and remote routes can all cause packet loss.

Bandwidth sets the sustained transfer ceiling

A node with 95 ms latency and a sustained download rate of 80 Mbps may outperform one with 45 ms latency that can maintain only 6 Mbps during peak hours when playing high-bitrate video. Watch a speed test for at least 30–60 seconds to distinguish a brief peak from sustained speed. 8 Mbps corresponds to roughly 1 MB per second in theory; protocol overhead reduces the actual rate.

If the client’s latency test is normal but the browser remains slow, first switch to another test URL, then check DNS, rule matching, and the system proxy. After enabling TUN mode, also confirm that traffic is actually entering Clash rather than bypassing it through another network interface.

How node multipliers affect subscription usage

A multiplier is usually a billing attribute set by the proxy provider, not a feature of the Clash protocol itself. A label of “0.5×” may mean that using 1 GB of actual traffic deducts about 0.5 GB from the quota; “2×” may deduct about 2 GB. Follow the subscription panel for the exact accounting rules, since providers may differ on whether uploads, downloads, and protocol overhead are counted.

A low-multiplier node is not necessarily slower, and a high-multiplier node does not guarantee lower latency. The multiplier may reflect route costs, access quality, regional resources, or provider policy. Treat it as the subscription cost per unit of usage, not as a performance grade.

Work backward from monthly quota to an acceptable multiplier

Suppose a plan includes 200 GB per month and everyday video and downloads are expected to use 120 GB in reality. If everything runs through 1.5× nodes, the theoretical billed usage is about 180 GB, leaving only 20 GB. If 80 GB instead uses 0.5× nodes and the remaining 40 GB uses 1.5× nodes, the example billed usage is about 100 GB. For high-volume tasks, a dedicated low-multiplier policy group is usually clearer than switching nodes manually.

You can create three policy groups in the configuration: “Everyday,” “Downloads,” and “Regional services.” Use stable 1× nodes in the Everyday group, add low-multiplier nodes to Downloads, and place only nodes meeting the required exit region in Regional services. Rules can send traffic for different domains or applications to the appropriate group, making node management easier.

Region selection depends on the exit point and route

Hong Kong, Japan, Singapore, or the United States in a node name usually describes the proxy server’s exit location, but the name may not reveal the full access and transit route. Two nodes both labeled Japan may use different carriers and transit paths, resulting in very different latency and peak-hour performance.

A shorter distance is only a starting point

• Hong Kong: Geographically close and often useful for everyday webpages and low-wait interactions, though peak-hour performance depends on the access route.
• Japan: Often offers moderate latency and suits content requiring a Japanese exit; it can also be an everyday option for East Asia.
• Singapore: Useful for services in Southeast Asia, with some southern mainland networks connecting particularly well.
• United States: Suitable for services requiring a US exit, but physical distance usually means higher baseline latency than East Asian nodes.
• Europe: Mainly useful for region-specific access. Everyday interaction latency is usually higher, so route stability deserves priority.

For region-restricted content, the region assigned to the exit IP matters more than the node name. After connecting, use a familiar IP lookup page to confirm the country, region, and network operator. If the exit appears correct but the content is still unavailable, the cause may be the account registration region, billing details, browser location, DNS results, or an outdated IP database maintained by the service.

Limit the candidate range in automatic groups

A Clash url-test policy group can periodically test candidate nodes and choose one with lower latency. If all regions are placed in the same group, however, automatic selection may switch from a US node to a Hong Kong node and change the exit region. When the region must remain fixed, create separate groups such as “Japan automatic” and “US automatic.”

proxy-groups:
  - name: Japan automatic
    type: url-test
    include-all: true
    filter: "(?i)日本|JP|Japan"
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: Everyday manual
    type: select
    proxies:
      - Japan automatic
      - DIRECT

This example tests nodes matching Japan in their names every 300 seconds. tolerance: 50 helps prevent frequent switching caused by small latency changes. Support for configuration fields varies across Clash Meta (mihomo) versions and clients, so check the current core documentation and generated subscription output before importing.

Protocol differences are more visible on unreliable networks

Subscription nodes may use protocols such as Shadowsocks, Trojan, VLESS, VMess, WireGuard, Hysteria2, or TUIC. The specific protocols and transport combinations supported by Clash Meta (mihomo) depend on the core version. Protocol choice alone does not determine speed; server performance, access bandwidth, route quality, and parameter settings are usually just as important.

TCP-based transports: reliable compatibility, but packet loss can reduce speed

Trojan and some VLESS or VMess nodes commonly run over TCP and TLS. TCP works across most networks and generally behaves predictably, but packet loss causes the underlying TCP connection to retransmit and reduce its sending rate. When the traffic inside the proxy tunnel is also TCP, severe loss can compound speed reductions and latency.

Shadowsocks: mature implementation, route-dependent performance

Shadowsocks usually has manageable overhead and is widely implemented on both clients and servers. On ordinary broadband, its experience depends more on the encryption method, server load, and network path. When you see SS, Trojan, or VLESS labels, do not assume a fixed performance ranking based on protocol name alone.

Hysteria2 and TUIC: UDP/QUIC-based transport

Hysteria2 and TUIC use UDP/QUIC and can provide smoother throughput on some high-latency routes with moderate packet loss through congestion control and connection migration. However, some campus networks, corporate networks, public Wi-Fi, and mobile networks restrict UDP. Symptoms may include failed connections, handshake timeouts, or sudden speed drops.

WireGuard: suited to stable tunnel scenarios

WireGuard uses UDP and has a compact protocol design, making it common for full network tunnels. It is sensitive to system time, MTU, and UDP reachability. If webpages load but some sites stall, check the MTU; common values to test include 1280, 1380, and 1420, but the final value should come from testing the actual link rather than being copied blindly.

Weak-network testing should include network changes

1. Test the same node on home Wi-Fi, a phone hotspot, and a mobile network.
2. Play a video for 10 minutes and watch for frequent rebuffering.
3. Lock the screen for 2 minutes, then resume and check whether the connection rebuilds quickly.
4. Switch from Wi-Fi to a mobile network and record how long access takes to recover.
5. If a UDP protocol repeatedly times out, test a TCP-based node to determine whether the network is restricting UDP.

When using VpnService on Android or enabling TUN mode on desktop, a network change may require the system to rebuild the default route. A brief interruption does not necessarily indicate a node failure. Wait 5–10 seconds first, then check client logs for timeouts, DNS errors, or interface-rebuild events.

Use policy groups to reduce manual node selection

When a subscription contains dozens of nodes, testing them one by one is inefficient. A more practical approach is to create groups by purpose: region groups restrict the exit, automatic groups compare latency, manual groups preserve final control, and fallback groups switch to a backup when the primary node is unavailable.

Where four policy-group types fit

• select: Manually choose a node or another policy group. Suitable for region-specific content and accounts that require a fixed exit.
• url-test: Test periodically and favor lower-latency nodes. Suitable for everyday browsing.
• fallback: Use available nodes in order and switch to a backup route when the primary fails.
• load-balance: Distribute connections across multiple nodes according to the configured strategy. Not suitable for login sessions that require a fixed exit IP.

Automatic test intervals also need control. A 10-second interval generates frequent probe requests and may cause nodes to switch repeatedly; 300–600 seconds is more suitable for general use. tolerance helps prevent constant switching when two nodes differ by only 5–20 ms. Use a fixed node or fixed-region policy group for logins, shopping carts, and risk-sensitive services.

Node names may change after a subscription update. When filtering regions with a regular expression, cover Chinese names, English abbreviations, and common provider naming—for example, Japan nodes may match “日本,” “JP,” or “Japan.” If the filter returns nothing, inspect the actual node names first and then update the expression; do not send rules directly to an empty policy group.

A repeatable node-selection workflow

1. Define the task: Decide whether the goal is everyday browsing, downloads, meetings, region-specific content, or mobile use on an unreliable network.
2. Filter by region: Keep nodes that meet the exit requirement and verify the actual region through the exit IP.
3. Check the multiplier: Use the remaining quota to rule out high-multiplier nodes that are unsuitable for long-term use.
4. Measure latency repeatedly: Run 3–5 tests and record variation, timeouts, and peak-hour results.
5. Test real traffic: Test at least one of webpages, video, or downloads instead of relying only on URL Test.
6. Compare protocols: Test both TCP-based and UDP/QUIC-based nodes on the current network.
7. Create policy groups: Put the final candidates into manual, automatic, or fallback groups.
8. Keep a backup: Prepare at least one backup node using a different access route or protocol.

The final choice can be summarized as follows: get the region right, ensure a stable connection, confirm that the multiplier is acceptable, and only then optimize for lower latency. For everyday webpages, a nearby node that stays around 60–100 ms is usually sufficient; for high-definition video, verify sustained bandwidth first; for region-specific content, keep the exit unchanged; and on unreliable networks, test reconnection and jitter resistance through real network changes.

Node quality changes over time. Route adjustments, peak-hour load, carrier routing, and server maintenance can turn last week’s best node into an ordinary one today. Retest candidate groups every one or two weeks, and when performance noticeably drops, switch to a backup before checking the local network, DNS, rules, and TUN capture status. This can reduce unproductive troubleshooting.