How to read a traceroute to your broker’s server
The short answer
A traceroute to your broker shows where latency begins along your transit path. Run tracert or traceroute to identify persistent delays that continue through to the final destination row. An isolated slow hop or asterisk row reflects deprioritised diagnostic checks rather than a genuine trading issue.
Four steps show where on the path your delay starts
Why it matters. Once you know where the delay starts, you know who can fix it. That may be you, your internet provider or your broker.
- 01
Find your broker’s server address
You need the server’s address, not the name in your login window. On Windows, connect your platform and note its PID in Task Manager’s Details tab. Then run
netstat -n -oand read that PID’s foreign address.Turn any proxy off first, or you will read the proxy’s address. Measure your broker delay shows three other ways.
- 02
Run the trace
On Windows, open Command Prompt and run
tracert BROKER_ADDRESS. On macOS or Linux, open Terminal and runtraceroute BROKER_ADDRESS.Leave the port off the address.
- 03
Save the output
Copy the whole result into a text file, with the date and time. Your provider will want the exact rows and when you saw them.
- 04
Run it again at another hour
One trace is one moment. Trace at the hours you trade and at a quiet one before you draw a conclusion.
Which forex session is open now lists the session hours.
Each row’s time is the whole way from your computer to that point
Each row is one router between you and your broker. On Windows the three middle columns are times, in milliseconds, from your computer to that router and back (Microsoft’s tracert reference). The last column is the router’s address, or its name when it has one.
On macOS and Linux the address comes first and the three times follow (traceroute manual). Either way, a row’s time is the whole time from your computer to that point. It is not the time between one router and the next.
So a real delay shows up in that row and in every row after it.
This invented trace shows how to read one, row by row.
| Row | Three times | How to read it |
|---|---|---|
| 1 | 1 ms 1 ms 1 ms | Usually your own router |
| 2 | 62 ms 60 ms 63 ms | Slow, but row 3 is fast. Ignore it. |
| 3 | 10 ms 11 ms 10 ms | Times rise a little from row 1 |
| 4 | * * * | No reply, but row 5 answers. Ignore it. |
| 5 | 95 ms 96 ms 94 ms | A jump |
| 6 | 96 ms 95 ms 97 ms | The last row. The jump stayed, so the delay starts at row 5 |
An illustration, not a measurement. The times are invented to show the patterns in the next table.
How your order reaches your broker explains the path itself.
Only a delay that lasts to the last row reaches your broker
Match your trace to a row below, so you don’t chase a delay that isn’t real.
| What you see | What it usually means | What to do |
|---|---|---|
| Times rise a little with each row | Distance adding up | Nothing. This is a normal trace |
| One row is slow and the rows after it are not | That router is slow to answer checks, not slow to pass traffic on | Ignore it |
| A jump that stays to the last row | Delay enters at that point. A long link or a busy one | Note the row and compare at another hour |
| Asterisks on a row, and later rows answer | That router does not reply to checks | Ignore it |
| Asterisks from one row to the end | The server, or a firewall before it, does not answer checks | Check whether your platform connects |
| Router names point away from your broker’s city, then back | An indirect path between the networks on the way | Send the trace to your internet provider |
Each reading is something to test at another hour, not a diagnosis.
A router answers checks sent to itself more slowly than it passes traffic on (Cisco’s traceroute guide). So only a pattern that lasts to the last row counts.
Your provider controls the path, so your fix is evidence you send them
Your internet provider and the networks beyond it choose the path your data takes. You cannot change it from your computer.
- Send your provider the saved traces, and name the row where the delay starts, so they know exactly where to look.
- Run the same trace from another connection, such as a phone hotspot. This shows whether the delay follows you or stays with one provider.
- If the second trace is clean, the delay is on the first provider’s path.
Our server recovers lost data inside your broker’s city instead of changing your provider’s path
Traders Proxy works with any platform that has a proxy setting, including MetaTrader 4, MetaTrader 5, TradingView Desktop and Optuma. Each platform’s maker decides which of its connections use that setting.
Our server opens its own connection to your broker and recovers lost data inside your broker’s city. Trading ports go first when our server is busy.
That helps only on the connection between our server and your broker. Your platform still reaches our server over your own internet. Data lost there is sent again between you and us.
Only the trading app you set up uses Traders Proxy, so a traceroute always shows your direct path, without us. It can’t measure the connection between our server and your broker.
To see what we change, time your platform itself.
Ping measures the round-trip time data takes to reach your broker and return. We do not promise lower ping because physical distance sets the floor. If your broker prohibits proxies, do not use one.
A backtest runs on your own machine, so no internet link can lose a piece of data during a news release. In live trading, one lost piece holds up every price update and order behind it. Everything waits while your computer sends it again across the world.
You cannot paste four values into your platform while your chart is already frozen in a live trade. Set it up today while the market is calm. Then time it on your own screen during the next release.
Next steps
- Find your broker’s server cityTurn the address into a city.
- Check your delay hour by hourA busy hour against a quiet one.
Common questions about traceroutes
Frequently asked questions
How many routers is normal on the way to a broker?
There is no normal count. It depends on the networks between you and your broker, and Windows stops at 30 rows by default. Read the times, not the count.
Why does the trace stop before my broker’s server?
The server, or a firewall in front of it, may not answer checks. The traceroute manual says firewalls are in widespread use. Check whether your platform connects before you call it a fault.
Should I trace at a busy hour or a quiet one?
Both. A jump that shows at one hour and not the other points to a busy link. A jump that is there at every hour points to the path itself.
Can a proxy fix my internet provider’s path?
No. We help only on the connection between our server and your broker, where lost data is recovered inside your broker’s city. The connection from you to our server stays with your provider.
Field reports · Verified forum threads
Real forum reports, what our system does, and where it stops.
Every quote below links to the forum thread or vendor guide where it appeared. Underneath each quote, see which parts of our system work together on it and where our server stops.
MQL5 VPS location can't be chosen and its ping 'jumped'
“Please don't mix up your concepts. 2ms may be for the Ping response time, or in other words, the latency of the network communication. However, there is much more that the server has to do besides the network response”
How local trading avoids it. Pick a server city in your dashboard and switch whenever you like.
- City switchingPrimary
Where it stops. Pick a server city in your dashboard and paste the new server value into your platform. Switching city changes the address your broker sees.
'Old tick' lines in the Journal
“<old Tick> in itself shouldn't be a problem but can be a pointer to break/s in communication with the broker server Check your internet connection for speed (both ways) and packet loss statistics”
Why a proxy does not change this. Traders Proxy changes the route your platform uses to reach your broker. It doesn't change quotes, fills or what your Journal says.
Where it stops. MetaQuotes staff confirm that Old tick journal entries are filtered out by the terminal and logged for information only.
Windows Server update reboots a rented VPS while a position is open
“Hoster can conduct technical maintenance of the servers during weekends (Saturday and Sunday according to EET time zone) for a total of up to 4 hours a day and, if necessary, during weekdays for a total of up to 15 minutes a day.”
Why a proxy does not change this. Security updates install daily. When a server needs a reboot, it happens at the weekend, with each server at its own time.
- Daily security updates, weekend restartsBoundary
Where it stops. Security updates install daily. When one of our servers needs a restart, it happens at the weekend, and a restart drops live connections.
Hotel / public Wi-Fi is flaky, slow or sits behind a login page
“You should not deal with any software requiring some security on a public network.”
Why a proxy does not change this. No claim about Wi-Fi quality. We can't improve a weak or crowded network.
Where it stops. A captive-portal login must be completed in a browser first. Public networks are still public.