How to Choose Proxy Nodes: Latency, Traffic Multipliers, Regions, and Protocols

Choose by use case first, then compare latency

Choose nodes in this order: first, confirm which egress region the target site requires; then check that it works; finally, compare reliability, traffic multipliers, and speed. The millisecond figure in ClashX or another client's node list is just one test result, not an overall score. A node showing 45 ms but dropping frequently is usually less suitable for a meeting than one that consistently stays around 110 ms.

Subscription services often label combinations of ingress, egress, and protocols as “Hong Kong 01,” “Japan relay,” or “US dedicated line.” These labels are supplied by the provider; they are not proof of a route verified by the client. “Dedicated line” does not guarantee fixed bandwidth, low packet loss, or streaming access. When getting started, keep three candidates: a low-multiplier node for everyday use, one in the region you need, and a backup on a different route.

What latency tests measure: not download speed or the whole experience

Know the difference between ICMP, TCP, and URL probes

The system ping command typically sends ICMP packets. A client's “latency test” often makes a proxied request to a specific URL and may include connection setup, the TLS handshake, and an HTTP response; exactly what gets timed depends on the client and its core. The two tests may use different routes, protocols, and endpoints, so their results are not directly comparable.

For example, probing https://www.gstatic.com/generate_204 only shows how that node performs when accessing that URL. It doesn't prove that the same node will be just as fast for code hosting, video platforms, or meeting servers. The url-test proxy group also selects nodes based on its configured test URL; it won't automatically know which region your current task requires.

Test repeatedly and compare the median and variability

1. Stick to the same Wi-Fi or wired network, and pause system updates and large downloads.
2. Use the same test URL and timeout for every candidate; for example, set the timeout to 5000 ms.
3. Test each node five times, about 10 seconds apart. Record the number of successful tests, the median, and the maximum.
4. Run another round during your usual usage hours, such as 8–11 p.m. Don't make a long-term choice based only on results from the middle of the night.

These sample figures illustrate how to assess results; they are not measurements of this site's routes. Node A returned 45, 48, 46, and 620 ms, plus one timeout. Node B returned 105, 108, 110, 112, and 109 ms. A has the lower minimum, but B is more consistent. For meetings, remote terminals, and interactive websites, B is usually the better one to try first. Five tests are only an initial screening, not a measure of long-term availability.

How traffic multipliers work: calculate your quota, then check the plan's units

A traffic multiplier usually indicates how much quota is deducted. Under the provider's billing method, a node with a 2× multiplier typically deducts 20 GB from your plan for 10 GB of billable traffic; a 0.5× multiplier typically deducts 5 GB. A multiplier does not increase speed, and a higher-multiplier node is not necessarily faster.

Estimated quota used = billable traffic × node multiplier
10 GB × 0.5 = 5 GB
10 GB × 1.0 = 10 GB
10 GB × 2.0 = 20 GB

60 GB of quota remaining; use only 2× multiplier nodes:
Usable billable traffic is about 60 ÷ 2 = 30 GB

“Billable traffic” doesn't necessarily match the download size shown by your browser. Providers may count uploads and downloads together, display capacity in different units, or update usage with a delay. The client's connection-page traffic counter may also use different accounting boundaries from the server. For actual deductions, check the provider's published billing rules and your account usage.

• Large downloads: Try a low-multiplier node for a short period first. If it can sustain the speed you need, there's no reason to switch to a higher-multiplier node just to shave off a few milliseconds.
• Occasional access to a specific region: Save high-multiplier nodes in that region for the tasks that need them instead of routing all your traffic through the same costly egress.
• Multiplier not listed: A node's name doesn't tell you everything about billing. Check the provider's node list and plan details; don't assume the multiplier is 1×.

At an average of 8 Mb/s, two hours of video uses about 7.2 GB of media data alone, before other requests and transfer overhead. At a 2× multiplier, that would use about 14.4 GB of quota. Note that lowercase b means bits, while uppercase B means bytes: 8 Mb/s is about 1 MB/s.

Choosing a region: distinguish ingress location, egress IP, and content region

The region in a node's name usually refers to its intended egress, not necessarily where your client first connects. A relayed route may connect to a nearby ingress first, then pass through another link before exiting in a different country or region. So a “Japan node” doesn't necessarily connect your device directly to a server in Japan, and a shorter geographic distance doesn't guarantee a shorter route.

Websites generally see the egress IP

Web services typically use the egress IP's registered location, account region, payment details, and other signals to determine content or access. Switching to a US egress doesn't necessarily change your account region, store region, and content catalog all at once. IP geolocation databases may also disagree: a lookup site might show one region, while the target platform identifies the same IP as being elsewhere or as a data-center proxy.

1. Select a candidate node manually in the client so an automatic proxy group doesn't switch it during testing.
2. Open the service you're targeting and check that the specific page, video, or API you need works—not just the home page.
3. Check the corresponding domain, matched rule, and actual proxy chain on the client's “Connections” page. Make sure the request isn't going direct or through another proxy group.
4. Keep your account's usual region relatively consistent. If switching egress triggers verification, follow the platform's process instead of repeatedly logging in from different regions.

Streaming access can change over time. Different egress IPs in the same region may produce different results, and a provider may change a node's egress at any time. Successful playback once only reflects that test at that moment; it isn't a long-term guarantee. Test the actual resolution and continuous playback you need, not just whether the title page opens.

Choosing a protocol: check core support first, then network conditions

Protocol names describe transport and authentication methods, not a speed ranking. Whether protocols such as Shadowsocks, Trojan, VMess, VLESS, Hysteria2, and TUIC work depends on the client's core version and supported configuration fields. Capabilities vary across ClashX forks; for clients using the mihomo core, check the actual version on the About or core information page. Being able to import a subscription doesn't mean every node field is supported correctly.

Hysteria2 and TUIC use QUIC and depend on UDP being available. Some hotel, campus, and workplace networks restrict UDP, so these nodes may fail to connect even if they work well on home broadband. Conversely, a proxy node using TCP does not necessarily carry UDP traffic for every application; check the protocol's capabilities, server settings, and client configuration.

A repeatable node testing process

Step 1: Fix the egress and test conditions

On the client's “Proxies” or “Proxy Groups” page, select a manual-selection group and pin one candidate node. Menu names vary by client; the key is to prevent url-test or fallback from switching nodes automatically during the test. Stop other speed tests and confirm the configured local port. The commands below assume the HTTP or mixed port is 7890.

curl --proxy http://127.0.0.1:7890 \
  --output /dev/null \
  --silent --show-error \
  --max-time 15 \
  --write-out 'status=%{http_code} first_byte=%{time_starttransfer}s total=%{time_total}s\n' \
  https://www.gstatic.com/generate_204

This command works in macOS, Linux, and other command-line environments with curl installed. first_byte is the time from the start of the request until the first byte arrives. It includes steps such as connecting through the proxy and waiting for the destination response, so it isn't a pure network RTT. A 204 response means this test endpoint responded as expected; it doesn't mean other sites will work. The command sends the request through the local proxy, but the client rules still determine the egress, so check the connection log as well.

Step 2: Verify throughput with real-world tasks

After the latency test passes, check sustained speed using a file you're authorized to access or a video you actually watch. Download for 30–60 seconds and note the steady-state speed, not just a momentary peak. Speed tests use plan traffic: downloading 100 MB from each of 10 nodes adds up to nearly 1 GB before multipliers. Screen candidates with light tests first, then test just two or three.

Step 3: Note failure conditions and keep a backup on a separate route

Record the date, network connection, node name, egress region, multiplier, median probe result, and real-world outcome. If a node only slows down during evening peak hours, congestion may be the cause. If every node fails on the same Wi-Fi, check the local network, DNS, and client settings before replacing your subscription. Two nodes with different names may share an ingress, so choose a backup on a different ingress or route where possible.

Everyday setup: use a reliable node and limit automatic switching

For everyday browsing, put low-multiplier nodes with high success rates in the same candidate group. Use a separate proxy group for services that need a fixed region, rather than mixing egress nodes from several countries into an automatic test group. Rules are matched in order, so direct each service's domain to the right group. See the rule-based routing guide for configuration details.

• For interactive tasks: Choose a node with consistent results and reliable requests, not the lowest latency from a single test.
• For video: Confirm the content is available first, then check sustained throughput and your multiplier budget.
• For meetings: Check UDP support and traffic capture. Keep the same egress for the duration of a meeting where possible.
• For account stability: Stick to your usual region and avoid unnecessary automatic switches between regions.

You don't need to keep a long list of nodes. One reliable everyday node, one for a specific service, and one independent backup are usually easier to manage than dozens of untested candidates. Retest under the same conditions when your network, egress IP, or plan changes so the results remain comparable.