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

SELECTION BASELINE

Define your node-selection goals first

When choosing Clash nodes, the lowest latency does not necessarily deliver the best real-world experience. Whether a node fits your current task depends on connection stability, available bandwidth, network path, target region, traffic multiplier, and client support. Web browsing, video streaming, large downloads, real-time calls, and remote development all place different demands on a route, so relying on a single latency reading can easily lead to the wrong conclusion.

Regular web access depends mainly on connection setup time and stability. Video streaming needs sustained bandwidth; an occasional latency spike usually will not affect playback after buffering, but short bursts of packet loss and noticeable jitter can reduce quality. Voice calls, meetings, and gaming depend more on low jitter, low packet loss, and consistent round-trip times. For large downloads, focus on sustained throughput while accounting for traffic consumed by the node multiplier.

Before screening nodes, divide your needs into three categories: an everyday default node, nodes for specific regions, and temporary high-bandwidth nodes. Everyday nodes should prioritize stability and serve as the main proxy exit for most rule-based traffic. Region-specific nodes are for services with location-dependent behavior. High-bandwidth nodes are useful for updates, synchronization, or downloads, but may not be suitable for holding long-running connections. This classification is more reliable than trying to find one “fastest node” for every situation.

LATENCY TEST

Understand Clash latency tests correctly

Latency tests in the Clash client are usually not the same as ICMP Ping from a system command. A common implementation requests a test URL through the proxy node and records the time needed to establish a connection and receive a response. The result is closer to HTTP or HTTPS connectivity through the proxy path, but it is still only a small-request test and cannot directly represent sustained download speed.

Repeated tests on the same node can produce different results. Causes include local Wi-Fi fluctuations, carrier congestion, proxy-server load, changing international routes, DNS resolution time, and the response speed of the test target. The first test may also include DNS lookup, TCP connection setup, or the TLS handshake; later tests may reuse cached data, so their readings are often lower. Judge the range across multiple tests rather than keeping only the minimum value.

How to read latency figures

• Stable readings: Results stay close together. Even if the node is not the lowest on the list, it is usually a good choice for everyday use.
• Large fluctuations: If adjacent tests differ by hundreds of milliseconds, for example, the route or load is unstable and needs further observation.
• Timeouts: The node may be unavailable, or the test URL may be unreachable through it. Do not remove a configuration based on a single timeout.
• Low latency but slow downloads: A small request can respond quickly without the server having enough outbound bandwidth or maintaining throughput during peak hours.
• High latency but stable playback: Video that has already buffered can continue smoothly if sustained bandwidth is sufficient and packet loss remains low.

A more practical approach is to run three to five consecutive tests and record the median and the spread. For example, two nodes may have median latencies of 80 ms and 110 ms, but if the first often jumps to 600 ms while the second consistently stays between 100 and 130 ms, the latter is usually better for meetings, remote terminals, and continuous browsing.

If every node times out at once, first check whether the subscription has been updated, the configuration loaded successfully, the device network is working, and the Clash core is running. If only one proxy group times out, verify that its member nodes are valid. Enabling TUN mode does not automatically reduce node latency; TUN only changes how traffic enters the proxy core. Actual route quality still depends on the local network, node server, and destination network.

REGION AND ROUTE

Choose by region and actual network path

A region label indicates where the node server or entry point is located, but geographic distance is only one factor affecting latency. The carriers used by packets, detours in the route, and whether the entry and exit points are separate can all change the actual result. A nearby node may have higher latency because of poor peering, while a distant node may deliver lower jitter over a stable route.

When screening everyday nodes, start by testing regions geographically close to you, then keep one or two different regions as backups. Do not put every candidate in the same region: regional outages, server maintenance, or evening congestion can affect many nodes at once. A backup node is not meant to sit unused forever; it should allow a quick switch when the primary node repeatedly times out or slows down.

Common regional selection criteria

The region in a node name does not always fully describe the network path. Some services use relay entry points: the name identifies the exit region, while your device first connects elsewhere. Other names include route codes or carrier abbreviations. When the path is unclear, rely on actual testing and the node details provided by the service.

Also distinguish the target service’s region from the proxy node’s region. When visiting a site deployed on a global CDN, the node may be assigned to an edge server near the exit, so the exit region can affect content delivery. For everyday access without regional requirements, prioritize a stable node with a short route; treat exit location as the primary factor only when the target service clearly depends on it.

TRAFFIC RATE

Assess multipliers and real traffic costs

A node multiplier is usually a traffic-billing coefficient used by the subscription service, not an attribute of the Clash protocol itself. A 1× node generally counts 1 GB of usage as 1 GB against the plan; at 2×, the same transfer may count as 2 GB. The subscription service’s documentation defines the exact scope and calculation method. The Clash client simply uses the configured nodes and does not standardize multiplier rules.

A higher multiplier does not necessarily mean higher speed. It may correspond to a more expensive route, a less congested entry point, or resources in a specific region, but the node’s current load can still change. Conversely, a low-multiplier node may provide enough speed outside peak hours. Treat the multiplier as a cost metric and evaluate it separately from latency, stability, and throughput.

Assign multipliers by task

1. For everyday browsing and instant messaging, prioritize stable nodes with standard multipliers to reduce frequent manual switching.
2. System images, game updates, and cloud synchronization can use substantial traffic. Check your remaining quota first, then compare the sustained speed of low-multiplier nodes.
3. For temporary tasks with specific regional or route requirements, use a higher-multiplier node and switch back to the default policy afterward.
4. Speed tests consume traffic too. Repeated large-file tests can quickly increase usage and are not suitable for every node.

PROTOCOL REVIEW

Compare common proxy protocols and client support

A subscription may include Shadowsocks, VMess, VLESS, Trojan, Hysteria2, TUIC, and other nodes at the same time. The protocol determines how the connection and transport work, but its name alone does not prove that a node is faster. Server location, route bandwidth, congestion, transport-layer settings, and the client core version often matter more.

Shadowsocks

Shadowsocks configurations are relatively straightforward, and common Clash cores support multiple encryption methods. Actual usability depends on whether the client core supports the specified cipher or plugin format. If imported nodes report errors involving cipher, plugin, or unsupported features, check core compatibility first instead of repeatedly testing latency.

VMess and VLESS

VMess and VLESS are often combined with transport settings such as TCP, WebSocket, gRPC, and TLS. VLESS does not imply a fixed level of route quality, and the core must correctly support Reality, TLS, or other secure transport parameters. Older Clash cores may differ from cores based on Clash Meta, now known as mihomo, in protocol and extension support. When a subscription introduces new fields, use a client and core that still support the corresponding configuration format.

Trojan

Trojan typically runs over a TLS connection, with settings for the server name, certificate verification, and transport layer. An incorrect device clock, DNS resolution problems, or server certificate issues can all cause the handshake to fail. These problems usually appear as an inability to establish a connection and should not be mistaken for simple high latency.

Hysteria2 and TUIC

Hysteria2 and TUIC use UDP-based transport designs and may deliver better throughput on some high-latency or mildly lossy networks, provided that the local network, router, and carrier path can carry UDP properly. Some corporate networks, public Wi-Fi networks, and firewalls restrict UDP. In that case, the node may time out, and switching to a TCP-based candidate makes the source of the problem easier to identify.

Choose protocols with compatibility first: confirm that the client core can parse the configuration and establish a connection, then compare the experience. If nodes using different protocols share the same entry point and similar routes, the real-world difference may be small. There is no need to make a newer-sounding protocol the default, and subscription-generated protocol parameters should not be changed casually without relevant error logs.

PROXY GROUPS

Use Clash proxy groups for automatic selection

When there are many nodes, proxy groups can reduce manual switching. Common groups in Clash and mihomo configurations include select, url-test, fallback, and load-balance. Each solves a different problem, so behavior cannot be inferred from the group name alone.

• select: The user manually chooses a node or nested proxy group; suitable for the default exit and region-specific choices.
• url-test: Periodically tests candidate nodes and selects a low-latency node that meets the configured conditions.
• fallback: Checks candidates in order and switches to the next node when the preceding one is unavailable.
• load-balance: Distributes different connections across multiple nodes according to the configured strategy; it does not simply add together the bandwidth of a single download connection.

A simplified automatic test group can be organized as shown below. Actual field support depends on the core version in use, and node names must match the proxy entries in the configuration.

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

interval controls the testing interval; setting it too low increases request frequency and resource usage. tolerance helps prevent frequent switching when latency differences are small. Implementations of switching conditions and health-check fields may vary between core versions, so consult the configuration documentation for the current core before making changes.

Automatic selection works best when candidate nodes have similar quality and the same regional purpose. If nodes with different regions, multipliers, and use cases are all placed in one url-test group, the lowest-latency node may not meet the regional requirement and may incur higher traffic costs. A better structure is to group nodes by region or purpose first, test automatically within each group, and use select at the top level for “Automatic,” “Specific region,” or “Manual selection.”

Rule mode sends connections to designated proxy groups based on domains, IPs, processes, or other rules. Node selection only determines which exit the proxy group ultimately uses; it does not change the basic top-to-bottom rule matching logic, where matching stops after the first hit. If a website is not using the expected node, check both the matched rule and the group’s current selection rather than simply changing nodes.

TEST PROCESS

Build a repeatable node-selection process

Reliable screening should take place under similar local network conditions and at similar times. When testing over Wi-Fi, first confirm that the device signal is stable, then pause background large-file downloads, cloud synchronization, and system updates. Mobile and fixed broadband networks use different routes, so a node that performs best on one network may not remain the best after switching networks.

1. Update the subscription: Make sure the client has loaded the current configuration so you do not keep testing nodes that have been removed or had their parameters changed.
2. Run one connectivity test for the entire group: Eliminate nodes that consistently time out, fail the handshake, or use unsupported configurations.
3. Keep a small candidate set: Retain three to five nodes from the target region with relatively low and stable latency.
4. Repeat the tests: Test several times at intervals of a few dozen seconds and observe the median latency, maximum value, and number of timeouts.
5. Validate with real tasks: Open a commonly used website, play a video, or run a short download, and observe loading, throughput, and reconnections.
6. Check the multiplier and quota: When the experience is similar, prefer the node with an acceptable traffic cost.
7. Keep backup nodes: Choose candidates on different servers or in different regions so you do not have to screen the entire list again when the primary node fails.

It is best to record test results by time of day. If a node is stable in the morning but slows noticeably in the evening, peak-hour load or network peering has probably changed. A single speed test at midnight cannot represent normal usage hours. For work, run short tests in the morning, afternoon, and evening, observe the results for one or two days, and then choose a default node.

After switching nodes, existing connections do not necessarily migrate immediately. Browser connection pools, download tasks, video sessions, and long-lived terminal connections may continue using the original exit until they close or time out. When verifying a new node, reopen the test page or restart the relevant connection. If system proxy or TUN is enabled, also confirm that the target app’s traffic is actually entering Clash; selecting a node in the client interface does not mean every app is using it.

ERROR CHECK

Common misjudgments and how to handle them

Choosing only the lowest-latency node

The minimum may come from an isolated test or reflect only the response of the test URL. Increase the number of repetitions and verify with commonly used services. If the lowest-latency node disconnects frequently, a stable but slightly slower node is a better default exit.

Assuming a failed speed test means the subscription is invalid

A failure on one node is different from an invalid subscription as a whole. First check whether other nodes connect, then review client logs for DNS, handshake, timeout, unsupported-protocol, or unreachable-network messages. Only when all nodes fail at once should you investigate subscription updates, configuration loading, and the local proxy state.

Still unable to access a service after switching nodes

The problem may be in the rules rather than the node. Check whether the current mode is Rule, Global, or Direct, and confirm which proxy group handled the target connection. DNS caching, existing browser connections, and an outage at the target service can also prevent an immediate recovery after switching. Close the original connection first, then run a comparison test with another website known to be reachable.

Treating TUN mode as a speed-boost option

TUN mode takes over more traffic that does not follow system proxy settings, which can provide broader coverage for games, command-line programs, or specific apps, but it does not increase proxy-server bandwidth. Changes after enabling it usually result from a different traffic path or DNS handling method. If problems occur, check TUN permissions, routing, DNS, and app compatibility instead of increasing the testing frequency.

Using too much traffic on a single large-file test

Large files can measure sustained throughput, but they do not need to be tested on every node. First narrow the candidates with small requests, then run short real downloads on two or three nodes. Stop the task promptly after testing and compare usage with the client’s traffic statistics and the subscription dashboard.