How to Choose Proxy Nodes: Latency, Traffic Multipliers, Location & Protocols

Check availability first, then compare latency and cost

Choose nodes in this order: confirm they can reach the services you need, check connection stability, make sure traffic costs are acceptable, and only then look for the lowest latency. The milliseconds shown in a Clash node list reflect a single probe; they don't tell you download speed, exit region, or whether a service will work. Everyday browsing, video streaming, and remote terminals also have different network requirements.

Before comparing nodes, check which core your client uses. The original Clash and Clash Meta (now mihomo) support different protocols. If your subscription includes Hysteria2 or VLESS nodes with REALITY parameters, you'll need a core that supports those protocols. A node that fails to import points to a compatibility or configuration issue—not necessarily a poor connection.

1. Define the task: For web browsing, check page load and response times; for video, sustained throughput; for SSH and other interactive connections, latency variation and disconnects.
2. Keep conditions consistent: Test on the same device and Wi-Fi or wired network, and pause cloud sync and background updates.
3. Verify routing: Make sure the request is actually using the node you're testing—not going DIRECT under a rule or being routed through another policy group.
4. Keep a backup: Alongside your primary node, keep one on a different route or server so both don't share the same point of failure.

1. Latency tests: Check the test URL, repeat results, and real requests

Milliseconds aren't download speed—and they aren't the same as an ICMP ping

mihomo's URL test sends a request through the selected proxy and measures the time for an HTTP probe. The result depends on the connection from your client to the node, the proxy handshake, the route from the node to the test server, and the endpoint's response. Results can also differ between a new connection and a reused one, so the number in the node list isn't a pure network round-trip time.

For example, if the test URL is https://www.gstatic.com/generate_204, the result shows how that node performs when reaching this endpoint. A successful test doesn't mean another website, video service, or API will also work. A timeout doesn't necessarily mean the node is offline: the test site may be blocked, DNS may fail, or the connection may be temporarily congested.

• Use the same test URL and timeout settings for every node.
• Test each node five times in a row. Record how often it succeeds, typical latency, and the slowest result—not just the best one.
• Test once during the day and again on a weekday evening. A node that performs well only under light load may not be suitable for evening streaming.
• If the interface shows timeout, first try accessing the actual service through that node. Then determine whether the issue is the test endpoint or the route.

For example, one node might return 80, 82, 85, 83, and 900 ms across five tests, while another returns 110, 112, 109, 115, and 111 ms. The first node has the lowest result, but also a clear spike. For interactive connections, check whether spikes recur instead of ranking nodes by the 80 ms result alone.

Use curl to check which local port handles the request

The command below explicitly connects to the local HTTP proxy at 127.0.0.1:7890. This assumes your client provides an HTTP or mixed-port service at that address; change the port if your configuration uses a different one. In Rule mode, requests sent through the local proxy are still matched against your rules. Check the client's connection list to confirm which outbound policy was actually used.

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

This is the macOS and Linux syntax. On Windows, use curl.exe and replace /dev/null with NUL; leave the other arguments unchanged. This test endpoint normally returns HTTP 204. time_starttransfer measures the time until the first byte arrives, while time_total measures the full request duration. Neither is a standalone “node ping.”

A 204 response has a tiny body, so it's useful for checking whether a request completes—not for measuring throughput. To test download speed, use a reputable source and a file of known size that you're allowed to download for testing; keep the file and test duration consistent. Use the same units: 1 MB/s is about 8 Mbps. Don't compare the numbers directly across these units.

2. Traffic multipliers: Calculate usage before choosing a use case

A traffic multiplier is a provider's billing rule, not a protocol setting or a speed multiplier. A node marked 2x isn't twice as fast as a standard node. A common billing formula is “billable traffic × multiplier,” but check the provider's terms for whether uploads count, how GB and GiB are defined, and whether rates vary by time of day.

Convert your remaining quota into usable traffic

With 60 GB of quota remaining, a 2x node would allow about 30 GB of billable traffic under the model described here. At 0.5x, that would be about 120 GB. This estimate helps you plan costs, but doesn't change the plan's expiration date, speed limits, or other terms.

• Web browsing and messaging: Response time and reliability often matter most, so a higher multiplier may be worth it for a dependable route.
• Video and large downloads: Check the multiplier before running a sustained throughput test; speed tests can use up quota too.
• Background backups: Check whether they need to use the proxy. Avoid routing large uploads over a high-multiplier node by accident.

3. Choosing a region: Distinguish the node's entry point, exit IP, and destination service

Choose a region based on the destination service's requirements, not just the nearest point on a map. “Japan” in a subscription name may refer to the exit region; it doesn't mean your client connects directly to a server in Japan. A relay route may enter locally before exiting overseas. Even a nearby node can be slower than a more distant one if the carrier's routing takes a detour.

First, confirm the exit region the destination service sees

1. Select the node you want to test in the current policy group, then open the target website to create a new connection.
2. Check the client's connection list to see which rule and proxy chain handled the request. Make sure it didn't use another policy.
3. Use a trusted IP lookup service to check the exit address and region, then confirm that the destination service provides the content you expect.
4. If an existing long-lived connection is still using the old exit, close and reopen the relevant app. Some clients also let you close existing connections directly.

IP databases and destination services may identify an IP's region differently. A lookup page showing Japan doesn't mean every streaming service, payment provider, or account system will treat it as Japanese. Services may also consider your account region, payment details, device location, login history, and IP reputation. Simply switching countries won't guarantee access.

Keep nodes in different regions for different tasks

• Remote work: Follow your organization's access policies and keep your exit region relatively stable to avoid verification prompts triggered by frequent cross-region logins.
• Region-specific content: Test the content you need on the destination service; don't stop at checking whether its homepage loads.
• Everyday browsing: Compare performance during busy hours among nodes that work. Treat the region label as a secondary factor.
• Gaming: First confirm that game traffic is actually being proxied and that the node and rules support the required UDP traffic. A working browser connection doesn't mean the game's route will work.

If your browser and command line show different exit IPs, check browser proxy extensions, the system proxy, TUN routing, and the app's own proxy settings. Don't keep switching nodes before verifying the route; otherwise, you're comparing different traffic paths, not the nodes themselves.

4. Transport protocols: Choosing between Trojan, VLESS, and Hysteria2

A protocol defines how a connection is established and carries traffic, but it can't make up for a poor route. The same protocol can run on entirely different servers and networks, and one server can offer several protocol endpoints. First check client compatibility, then compare connection success, sustained throughput, and recovery after disconnects on your own network.

Trojan and VLESS: Look beyond the protocol name

Trojan nodes often use TCP with TLS. With VLESS, check the security layer and transport settings as well. REALITY is a security-layer option, not a “speed tier.” Transports such as WebSocket and gRPC also affect connection behavior. The fact that VLESS is newer than Trojan doesn't mean it will be faster on your network.

If you see a TLS or handshake error after importing a node, check the system clock, server address, port, SNI, authentication details, and whether the subscription is complete. With REALITY, the relevant parameters must also match the server's requirements. Don't disable certificate validation just to hide the error; first fix any mismatch in the address, certificate, or parameters.

Hysteria2: Check UDP connectivity before testing throughput

Hysteria2 can deliver good throughput on some high-latency or lossy networks, but results depend on the network and server configuration. If a campus network, corporate network, or public Wi-Fi restricts UDP, TCP-based nodes may work while Hysteria2 fails to connect. Try another network and keep a working TCP-based node as a backup.

Higher bandwidth settings aren't always better. Set them according to your actual connection and the server's limits; values that are too high can increase congestion. Start with the provider's valid settings, and adjust them only if you understand the relevant congestion-control options. Don't copy “high-speed settings” that aren't suited to your connection.

Put all four checks into a repeatable node-selection process

You don't need to run a full-speed test on every node in your subscription during the first round. Start with a small shortlist, complete basic checks, then test the services you actually use. This process works for manual node selection and for checking whether an automatic selection group meets your needs.

1. Pick three candidates: Choose nodes that meet your region requirements, have acceptable multipliers, and are supported by your core. Include different routes where possible.
2. Verify the rules: Check the rule and exit used for your request. If you temporarily switch to Global mode to compare nodes, restore Rule mode when you're done.
3. Repeat a small request: Test each node five times with the same URL and record failures and variation.
4. Test real-world use: Open a website you use, play the same video, or keep a remote terminal session open. Watch for interruptions and reconnects.
5. Retest during peak hours: Run another round during the time you usually use the service. Don't treat daytime results as an all-day guarantee.
6. Keep a primary and a backup: The primary should meet your stability and cost requirements; the backup should handle the same tasks if the primary fails.

An automatic selection group isn't necessarily best for your destination service

mihomo's url-test group selects nodes based on configured conditions such as the test URL, interval, and tolerance. It optimizes for probe results; it doesn't account for streaming regions, traffic multipliers, or account login patterns. Mixing nodes with different multipliers and exit regions in one group can make your exit and costs change whenever the group switches nodes.

A safer approach is to shortlist nodes by use case first, then let an automatic selection group compare only those candidates. For example, keep nodes in the same region for a region-specific service, and choose nodes with acceptable billing for high-volume tasks. See Advanced Setup for configuration fields, or Getting Started for your first import and proxy mode.

Your final notes don't need a complicated scorecard. Record the network, test time, destination service, success rate, latency variation, and multiplier. A node that reliably handles your usual tasks at a predictable cost is a better everyday exit than one that occasionally posts the lowest latency.

Technical references and verification resources

Button labels may vary between clients. For protocol support and test behavior, refer first to the documentation for the core you're using. These references cover URL test settings, proxy protocol configuration, and Hysteria2 bandwidth options; they don't endorse the quality of any node.

• mihomo docs: url-test groups—check the test URL, interval, and tolerance.
• mihomo docs: outbound proxies—check the fields and support for Trojan, VLESS, and Hysteria2.
• Hysteria 2 docs: full client configuration—learn about QUIC and bandwidth settings. The native client configuration format can't be pasted directly into mihomo YAML.