Speed and stability depend on node load, routing, the ISP, protocol, DNS, MTU, UDP support, and local resources. Client latency alone is not enough. If only one node is slow, switch nodes; if every node is slow, inspect local resources and the network. For games or meetings, test UDP separately.
Is one node slow, or is the entire connection unstable?
Using the same website, file, and time period, compare direct access, two nodes, and two networks while recording packet loss, reconnections, and CPU usage.
- Is only one node slow, or are all nodes slow?
- Is the speed-test target fixed and representative of the actual destination?
- Do the logs show reconnection, TLS, DNS, or UDP errors?(See DNS FAQ)
- Were TUN, DNS fake-ip, IPv6, or MTU changed recently?
Compare networks, nodes, and time periods with the same target
- Test the same target through direct access, different nodes, and different policy groups
- Disable unnecessary debug logging so log writes do not affect performance(See Profiling engine)
- Check system resources, CPU usage, and connection counts
- For games, voice, or QUIC traffic, confirm UDP support
- If needed, give the configuration provider the node name, time period, and a redacted log summary
Latency tests generally reflect only the probe URL, not the speed of every website
Do not assume a speed problem proves the client is broken
Do not publicly expose complete IP addresses, node links, or the subscription URL