ISP route checker for traders.
Your ISP decides the path from your computer to your broker's server. A bad routing decision can add 50–200 ms of completely unnecessary latency. This tool shows you how to check and interpret your route.
Run the route check
Open a terminal or command prompt and run the following command. Replace the hostname with your broker's MT4/MT5 server address (found in the top-right corner of MT4, or at File → Login to Trade Account).
Windows (Command Prompt):
tracert your-broker-server.com
macOS / Linux (Terminal):
traceroute your-broker-server.com
Wait for the command to complete — it typically takes 30–60 seconds. Copy the output before reading the next section.
How to read the output
Each line in the traceroute is one network hop. The format is: hop_number latency_ms hostname ip_address
Example: Good route (South Asia to London, via TradersProxy)
1 2 ms 192.168.1.1 (local router) 2 8 ms isp-gateway.local.example.com 3 12 ms isp-backbone-1.example.net 4 15 ms proxy-node.tradersproxy.com (TradersProxy LD4) 5 1 ms broker-server.equinix-ld4.net (broker, same campus) 6 2 ms your-broker-mt-server.com
Total RTT: ~17 ms. Clean route, no unexpected jumps. The proxy-to-broker segment is 1 ms (co-located at LD4).
Example: Bad route (indirect transit via US from Asia to London)
1 2 ms 192.168.1.1 2 9 ms isp-gateway.local.example.com 3 14 ms isp-backbone-1.example.net 4 180 ms us-west-transit.example.net (routed via USA — problem) 5 195 ms us-east-peering.example.net 6 220 ms europe-entry.example.net 7 245 ms your-broker-mt-server.com
Total RTT: ~245 ms. Hop 4 is the problem — ISP is routing Asia-to-London traffic via the US, adding ~180 ms of unnecessary transit latency. A proxy with a direct Asia-to-LD4 path fixes this.
What to look for
- Large jump at a single hop: If one hop adds 50+ ms when neighbouring hops are under 15 ms, that hop is a transit peering point with poor performance. This is the exact problem a proxy solves.
- Geographic misdirection: If your connection from Asia routes via the US before going to London, your ISP has indirect peering. The proxy takes a direct path.
- Many hops (15+): More hops mean more potential failure points and more accumulated latency. A clean route uses 6–12 hops maximum.
- Asterisks (*) at intermediate hops: Common on ICMP-filtering routers. Not always a problem — check whether latency resumes normally after the asterisks.
What a proxy changes in your route
TradersProxy replaces the variable ISP transit section of your route with a dedicated path from the proxy node to the broker server. The proxy node is co-located inside the same Equinix campus as your broker — the last hop latency is 1–3 ms. Your only variable is the home-to-proxy-node segment, which uses optimised routing rather than commodity ISP peering.
ISP route FAQ
A traceroute shows every network hop between your computer and a destination server, with the latency added at each hop. For trading, it reveals whether your ISP is routing your connection directly to your broker's datacenter or via indirect peering arrangements that add unnecessary latency.
6–12 hops is typical for a well-routed connection. Over 15 hops usually indicates indirect transit routing. Hops with latency spikes (one hop adding 50+ ms when adjacent hops are under 10 ms) indicate a peering handoff with poor performance — exactly where a proxy helps.
A bad ISP route typically shows: many hops (15+), a large latency jump at a transit provider handoff (e.g., hop 6 at 5 ms, hop 7 at 95 ms), routing through a geographically distant city (e.g., a Singapore-to-London connection routing via the US), or timeouts (*) at critical hops that indicate packet loss.
A proxy replaces the ISP's indirect path with a direct data-centre connection from the proxy node to the broker server. TradersProxy nodes are co-located at the same Equinix campuses as major retail brokers — LD4 for London, NY4 for US. The proxy-to-broker segment is under 2 ms. Your home-to-proxy segment is the only variable remaining.
Asterisks in traceroute output mean that intermediate router did not respond to the traceroute probe. This is common on enterprise and ISP backbone routers that filter ICMP traffic. It does not necessarily mean packet loss — only that the router chose not to respond. Look at the hops before and after to assess whether there is a real latency problem.