"Waiting for update." Greyed prices. Red "No connection." Your platform just told you the real problem — and it isn't your broker.
Those are MT4 and MT5's signals that the network layer failed. The price stalled. The order went wide. The chart froze at the worst moment.
This is not a strategy problem. It is not a broker problem. It is the connection path — the network path your order packet travels from your screen to the matching engine. You've been paying for it in pips every session. Nobody handed you the bill. The market did.
MT4 · · · · in under 5 minutes Or see the plans →
MT4 and MT5 slippage and requotes are caused by network jitter — the latency spikes that delay your order packet at exactly the moments (news, opens, high volume) when price moves fastest. The broker timestamps your fill against the market price at packet arrival, not at click time. A delayed packet means a worse fill.
MT4 shows this as a requote (the trade rejects and reprices). MT5 shows it as the fill price drifting from the ticket price. Same root cause: your order hit the matching engine late.
The fix is at the network layer. A purpose-built relay — not a VPN, not a VPS — routes your order packets with priority queuing and jitter absorption between your platform and the broker's server. Chapters 03–05 explain exactly how that works. Chapter 06 shows you how to diagnose your own connection first.
The spread moved. Your fill didn't match the quote.
You know the moment. The price on the chart says one thing. The fill confirmation says another. The delta is small — sometimes half a pip, sometimes two, sometimes more during a news spike. But it's always in the wrong direction. You got in wider than the quote you clicked.
This is called negative slippage. On MT4 you see it as a requote — the trade rejects and comes back with a new (worse) price. On MT5 you see it as the fill price simply drifting away from what the ticket showed. Same cause. Different surface.
Most traders blame the broker first. That's natural. The broker is the one who sent the fill confirmation. But negative slippage asymmetry — the pattern where your fills land worse more often than they land better — exists across brokers, across account types, and across execution models. Switching brokers three times and still getting slipped is the data that tells you it isn't the broker.
The asymmetry part is worth understanding precisely. When the market moves against your order during the round-trip delay, you get filled at the worse price. When the market moves in your favour during the same delay, many brokers fill you at your original requested price rather than the improved one. The rule is not symmetric. Your losses get expanded. Your wins get capped at the edge.
Regulators have fined brokers for this. FCA, ASIC, and others have issued enforcement actions specifically on asymmetric slippage handling. The enforcement happened because the practice is real. But the enforcement doesn't fix the window. If your order arrives at the matching engine 200ms after you clicked, the market has already moved. A narrower window means less room for the asymmetry to work against you.
The window is controlled by the network — not the broker's policy.
During quiet hours on a liquid pair, negative slippage is rare. The order round-trip is fast. The price has barely moved. But during the London Open, during NFP, during FOMC, during low-liquidity overnight hours — the same network that handled your order fine yesterday starts behaving differently. That pattern has a name. It's explained in the next chapter.
Broker, spread, network — which one is lying?
When fills go wrong, there are three things to blame. Traders rotate through all three and rarely reach the third.
Candidate one: the broker. The broker controls the execution model — whether it's STP, ECN, or market-maker. It controls how quickly its matching engine processes your order and how it handles the slippage in its favour. These are real variables. A book-based broker with wide spreads and a B-book conflict of interest is a real problem. But you can test this. Run the same strategy with the same network through two different brokers. If slippage follows you, the broker is not the primary variable.
Candidate two: the spread. Spread widening during news is structural — it reflects real liquidity thinning at the top of the order book. Nothing you do changes it. When GBP/USD spreads from 0.2 pips to 2.5 pips at the London Open, that's the market structure. The spread is not lying. It is telling you what liquidity costs right now.
Candidate three: the network. This is the one that gets skipped. The network path from your machine through your ISP, across backbone hops, to your broker's datacentre is invisible. It doesn't show up in MetaTrader's interface. There's no column in your trade history labelled "milliseconds lost to jitter." You can't see it. You can only feel it in the fill.
The diagnostic is simple. Run a continuous ping to your broker's server during a live session. Do it during quiet hours. Do it during news. Watch the numbers. A stable 80ms round-trip that stays stable is fine. A 35ms round-trip that swings to 380ms during the London Open — that's jitter, and jitter is the network failing you exactly when you need it to work.
The broker operates on the assumption that your order arrived quickly. The matching engine timestamps the fill against the current market price at the moment of arrival. If your packet arrived late because your ISP's router was busy queuing your neighbour's video call, you are filled at the price the market was at when you were late — not when you clicked.
This is the Third Layer. Your trading setup has three infrastructure layers: the platform (MT4, MT5, cTrader — free), the ideas (signals, courses, EAs — real money spent), and the network path (from your machine to the broker's matching engine — $0, because nobody named it). The pros pay for all three layers. Retail pays for two. The third one is what the long-form argument on this site is built around.
How an MT4/MT5 order packet actually travels.
When you click Buy on MT4 or MT5, three things happen in rapid sequence before the fill comes back. Understanding them tells you exactly where jitter does its damage.
Step one: the authentication handshake. MT4 and MT5 maintain a persistent TCP session with the broker's server. Before your order goes anywhere, the platform verifies that session is alive. If the session has silently dropped — the TCP connection died without either end detecting it, which happens more than the platform's "connected" indicator admits — the platform must re-authenticate. That takes time. During that time, the market keeps moving.
Step two: the order packet. The actual buy or sell instruction is a small packet — 200 bytes or less for a market order. It carries the instrument, the direction, the volume, the Quote ID (on MT4) or the trade instruction (on MT5), and a timestamp. The packet exits your machine, hits your router, leaves your ISP's network, crosses backbone infrastructure, enters the broker's datacenter network, and arrives at the matching engine. Eight to fifteen hops. Each hop adds latency. Any hop with congestion adds jitter.
Step three: the keepalive cycle. While no order is in flight, MT4 and MT5 send periodic keepalive packets to hold the TCP session open. These are lightweight. But their regularity matters — if keepalives are delayed by a busy connection, the server-side timer may expire and close the session before the platform knows it's dead. The platform shows "connected" for several more seconds. Your next order goes into a dead socket.
The engineering inside TradersProxy directly addresses all three of these. Packet classification at the relay level separates small, time-sensitive packets (order submissions, keepalives) from large, bulk payloads (chart history downloads, tick data). is where that classification happens — the 512-byte boundary used to route tick vs bulk traffic into separate priority queues. Priority ports for order flow are set in so the relay knows which connections carry order packets and lifts them to the front of the queue.
The result: your 200-byte order packet does not share a queue with your platform's 2MB chart history download. On a direct ISP connection they compete. On a TradersProxy connection they do not.
Why MT4 and MT5 are especially sensitive.
MT4 and MT5 were not designed for flaky home internet connections. The protocol assumes low-jitter conditions. It assumes the TCP session stays alive. It assumes keepalive packets arrive at regular intervals. When those assumptions break, the platform's behaviour under recovery is the source of most of what traders misread as "broker lag."
Both platforms connect via a persistent TCP session. This is different from, say, a web browser, which opens a new connection for each request and handles connection failures gracefully at the application layer. MT4 and MT5 hold one connection open for the life of the session. That session carries price data, order confirmations, history downloads, and keepalives all on the same pipe.
The retry logic is the problem. When the platform detects a dropped connection, it does not immediately reconnect. It waits. It retries at intervals. The "No connection" indicator in the bottom corner appears. Then the spinner. Then the prices grey out. Then, eventually, the platform re-authenticates and the feed resumes. That sequence can take 20 to 60 seconds on a direct residential connection. Every second of that window is a second you are blind to the market.
The silent drop is worse than the visible one. If the connection drops cleanly, the platform knows and starts reconnecting. But TCP connections can die silently — the router on your end or the firewall on the broker's end closes the session, neither side sends the FIN packet, and both ends think the connection is alive until a keepalive eventually times out. MT4 and MT5 show "connected" while the session is actually dead. Your next order hits a dead socket, produces no response, and the platform begins its reconnect cycle.
Mobile MT4 and MT5 users feel this worst. Every time the phone locks, every time it switches between WiFi and cellular, every time the cellular tower hands off — the connection is stressed. The platform's reconnect cycle on mobile, without any keepalive tuning, regularly produces the 20-40 second "black screen" that mobile traders know well.
TCP keepalive tuning at the relay level changes this. The keepalive interval, the number of retries, and the retry timeout are all configurable at the kernel level. The settings at tune these parameters for trading sessions specifically — shorter probe intervals, faster dead-session detection, so the reconnect starts before the platform's own timer fires. Dead sessions surface in seconds, not tens of seconds.
This is not a feature. It is a consequence of the keepalive configuration. But the practical outcome for a mobile trader is that the 30-second reconnect after a pocket lock becomes a 3-second reconnect. That is the difference between catching the move and watching the chart refill after it already happened.
What TradersProxy does for an MT4/MT5 session specifically.
Six things change when you route MT4 or MT5 through TradersProxy. Each one traces to a specific engineering decision in the product.
Order packets are classified by size at the relay. Small packets (order submissions, keepalives) go to a priority queue. Large packets (history, tick downloads) go to a separate lane. Your order never waits behind its own chart data. .
A dedicated node configuration handles burst conditions — NFP, FOMC, CPI. The queue is smoothed at the server rather than letting spikes pass through to the broker session. .
TCP Fast Open reduces the handshake round-trips on reconnect. Pre-warmed DNS removes the lookup delay. Extended UDP conntrack holds the session state through brief cellular hand-offs. .
Keepalive tuning surfaces silent TCP drops in seconds rather than letting the platform sit connected-but-dead. The reconnect starts before MT4/MT5's own timer fires. .
Every account is provisioned with a primary and a backup node. If the primary degrades, traffic migrates to the backup automatically. No manual switch required. provisioning.go:23-24.
The relay forwards to whatever host and port your platform specifies. No whitelist. No broker list. Works with any broker your trading platform connects to.
What to try before you buy — how to diagnose your own connection.
Before spending anything, run the tests below. They take under ten minutes and will tell you whether your network is the problem or whether something else is at play.
Test one: ping your broker's server during a news event. Open a command prompt (Windows) or terminal (Mac/Linux) and run ping -t [broker-server-address]. Most MT4/MT5 brokers list their server address in the platform's login window. Start the ping 5 minutes before NFP or another high-volatility event. Watch what happens to the round-trip time at the moment the news drops. A stable 40ms that jumps to 400ms and bounces erratically for 90 seconds — that's jitter. That's the window where your fills went wide.
Test two: run tracert/traceroute to the broker's server. On Windows: tracert [broker-server-address]. This shows every hop between your machine and the broker. Look for hops where latency jumps significantly. A hop near your ISP's edge that adds 80ms is different from a hop deep in a backbone network — the ISP hop is something you can route around.
Test three: use MT5's built-in server ping. In MT5, go to View → Terminal → Trade tab. The ping time to the current server is displayed at the bottom of the window. Run this during normal hours and during news. The delta between those two numbers is your jitter exposure.
Test four: check for bufferbloat. Go to waveform.com/tools/bufferbloat and run the test while something on your network is actively downloading. An A rating means your router handles congestion well. A D or F means your order packets are competing with background traffic in a large router buffer — and losing during volume spikes.
What the results mean: If your ping is stable at 30ms and stays near that even during news, your network is fine. The slippage, if it's happening, is structural — spread widening, thin liquidity — not network jitter. A proxy won't help much. If your ping swings by 200ms or more during news, or if your bufferbloat test grades poorly, the network layer is contributing to your fill quality and TradersProxy is the right shape of fix. The latency vs jitter guide covers these diagnostics in more depth.
Run the tests first. The trial is free anyway, but knowing your baseline before you start gives you something concrete to compare after.
Platform-specific setup — MT4, MT5, cTrader.
Setup takes under five minutes on any platform. Your portal provides four values: host, port, username, and password. Enter them into the proxy field of your trading platform. Start a session. Done.
In MT4 desktop: Tools → Options → Server tab. Check "Enable proxy server." Set type to SOCKS5. Enter the host and port from your portal. Enter your proxy username and password. Click OK. Reconnect to the broker server from the same dialog.
Mobile MT4 (iOS / Android): Settings → New Account → Advanced → Proxy Settings. Same four values. The platform applies the proxy to all connections including keepalives.
In MT5 desktop: Tools → Options → Server tab. Same flow as MT4. Check "Use Proxy Server." Choose SOCKS5. Enter host, port, username, password. Reconnect.
Mobile MT5: Settings → Connect → Proxy Settings. Enter the same four values. The MT5 mobile client routes all broker traffic through the proxy including the background tick stream.
cTrader desktop: Settings (gear icon) → Connection → Advanced. Enable proxy. Select SOCKS5. Enter host, port, credentials.
cTrader Mobile routes connections through the system-level proxy on iOS or Android. Set the proxy at the device network level or use the in-app connection settings if available in your version.
The full setup walkthrough for each platform — including screenshots and common error states — is at proxies-setup.html. If you run an EA on a VPS, the setup is identical: point the VPS platform's proxy field at TradersProxy. The relay and the VPS work in the same direction. They don't conflict.
What the trial will tell you in 7 days.
Seven days is enough to cover at least one or two high-volatility sessions — an NFP, an open, a CPI. Those are the conditions where the network layer shows itself.
What to measure before you connect. Note your current ping to your broker's server during a normal session. Note it during news. Note how long your platform takes to reconnect after you lock your phone. Write it down. You need a before number to compare against.
What to look for during the trial. Your ping to the broker will likely be different — it may be higher in absolute terms, because the proxy adds a hop. But the variance will change. The 35ms-that-becomes-400ms profile should become something more stable. The reconnect after a phone lock should be noticeably faster. If you use MT5's server ping display, watch that number during a news event with the proxy on versus what you recorded before.
What counts as improvement. Your fill quality may be harder to attribute precisely — the market has its own variability. But requote frequency on MT4 is a clean signal. If you were seeing requotes on 15-20% of market orders during volatile sessions and that drops to under 3%, the network fix is working. On MT5, look at the average distance between your click price and your fill price across 20+ trades during news. If that tightens, you're feeling the jitter absorption.
What is normal variation. Not every bad fill is network jitter. Wide spreads during news are structural. A missed fill on a news spike where you entered exactly at the extreme is a liquidity problem, not a network problem. Don't count those. Count the ordinary sessions where fills were inconsistent for no visible market reason. That's the category where the proxy makes a measurable difference.
What to do if you see no improvement. If your before-ping was stable at 30ms and stayed near that during news, the network was never the bottleneck. The proxy won't help a stable connection. Cancel any time from the portal before billing starts — you are never charged. The trial is exactly the right tool for this test.
Seven days from now you will know whether the third layer was costing you what this page says it was. That is a better answer than any claim made here.
Eight questions that matter.
For most retail trading, no. The exit IP is a datacentre IP — brokers already see those from VPS users. There is one caveat. Current version uses a shared address pool. Your exit IP is stable session to session, but it is shared with other users on the same node. For prop firm accounts that audit IP uniqueness at payout, that is a risk. Dedicated IP is on the planned updates. Until it ships, prop firm challengers should wait. Standard retail discretionary trading is not affected.
Yes. TradersProxy is broker-agnostic. The relay sends traffic to whatever host and port your trading platform specifies. No whitelist. No compatibility gate. Works with any broker your trading platform connects to. If your platform reaches your broker today on a direct connection, it will reach them through TradersProxy.
MT4 uses a Quote ID model. When network jitter causes the quote to expire before the server receives it, the broker issues a requote — the trade rejects and you re-enter at a new (usually worse) price. MT5 uses exchange-style execution. There are no requotes, but the fill price is whatever the market was at when your packet arrived — if jitter delayed it, you are filled at a worse price. MT4 punishes jitter with requotes. MT5 punishes jitter with slippage. Both trace to the same root cause: inconsistent packet delivery through the network layer.
No. TradersProxy operates as a TCP relay at the network layer. It does not inspect or store the payload of your trading sessions. Your broker credentials travel encrypted inside your platform's own session — the relay forwards bytes it cannot read. The relay does log connection counts, bandwidth totals, and session lifetimes for service monitoring. It does not log trade content, account balances, or broker identity beyond the destination host.
TradersProxy nodes carry a dedicated jitter-absorption configuration for high-throughput conditions. This smooths the queue at the server level rather than letting burst traffic spike the round-trip. The node does not rate-limit order packets during news — it prioritises them. The configuration is at. The HTB burst pool that governs bandwidth allocation during news events is at.
Mobile users see the largest practical improvement. Mobile MT4 and MT5 run over cellular networks with higher baseline jitter, and the platform's persistent TCP session suffers every time the phone wakes from sleep or switches towers. TradersProxy applies TCP keepalive tuning and TCP Fast Open to make reconnects happen in seconds rather than the 20–40 seconds typical on direct cellular connections. Desktop benefits from priority queuing and jitter absorption. Mobile benefits from all of that plus the reconnect improvements.
If you already run MT4 or MT5 on a VPS, point the VPS platform's proxy field at TradersProxy instead of connecting direct. The relay adds priority routing and jitter absorption on top of the VPS's existing geographic proximity advantage. The two layers work in the same direction and do not conflict. For EA operators running 24/7 on a VPS, the reconnect improvements and dead-session detection add a meaningful layer of resilience. See the SOCKS5 vs VPN guide for more on how these tools compare and combine.
The Starter plan includes a 7-day free trial. A card is required at signup but is not charged until day 8. If the trial does not show meaningful improvement in your jitter profile or reconnect behaviour, cancel any time from the portal before billing starts and you are never charged. There are no refunds after the trial period ends — the trial is the risk-free evaluation window. Cancellation is one click from the portal. No retention calls. No forms.
Slippage and requotes are network problems. The guide above explains exactly what causes them and what a purpose-built relay does differently. Seven days of data will tell you whether the third layer was the variable.