How TradersProxy Works

The the network path.

When a retail trader opens a position, the order travels a path that most traders never think about:

Without a proxy, your order travels from your device through your ISP's network, across multiple public internet exchange points, to the broker's server. Every hop on that public path adds latency, and during peak hours — London-NY overlap, news releases — the backbone links between major internet exchange points become congested. Variable congestion creates variable latency, which creates jitter.

With TradersProxy, your order still starts on your device. But instead of routing through the public internet to the broker, MT4/MT5/cTrader connects to the TradersProxy relay node first. The relay is inside the same Equinix datacenter facility as the broker's server. The final hop from relay to broker is 2–5ms on a datacenter-internal link — not a public internet route. That hop does not get congested by general internet traffic.

The SOCKS5 protocol.

SOCKS5 is the protocol MT4, MT5, and cTrader use to connect through a relay. It works like this:

1. You enter the TradersProxy node address, port, username, and password in the platform's connection settings.
2. When the platform starts, it opens a TCP connection to the relay node and performs a SOCKS5 authentication handshake.
3. The relay verifies your credentials and establishes a forwarding tunnel to your broker's server hostname.
4. All subsequent communication between your platform and the broker flows through this tunnel — tick data arriving, order instructions leaving.
5. The relay forwards the encrypted TCP stream in both directions without decrypting it.

From the platform's perspective, it is connected to the broker normally. From the broker's perspective, the connection is arriving from the relay node's IP inside the Equinix facility. From TradersProxy's relay's perspective, it is moving encrypted TCP packets between two endpoints.

Engineering decisions that make it trading-specific.

A generic SOCKS5 relay would reduce latency by virtue of co-location alone. TradersProxy adds several engineering layers on top of basic relay functionality:

Congestion algorithm selection per connection. Not all trading connections have the same packet profile. Order sends are small, latency-sensitive packets. Data downloads (history, tick archive) are bulk transfers. Each TCP session gets the congestion control algorithm that suits its packet characteristics.

Packet classification at 512 bytes. Traffic below 512 bytes — order sends, keepalives, tick data — gets interactive-class TCP buffer handling. Traffic above gets bulk handling. This split runs at the kernel level on every relay connection, ensuring small trading packets are never queued behind large data transfers.

Three-band priority queue on order-flow ports. MT4 ports 443 and 455, MT5 port 443 are given dedicated queue lanes. Order traffic does not compete with bulk traffic in the relay queue.

Primary plus backup node assignment. Both nodes are assigned when the account is provisioned — not on demand after the primary fails. Route quality is monitored with a 15-minute EWMA. Failover to the backup node is automatic.

DNS pre-warming. Broker hostnames are cached at the node level before the session is established, eliminating DNS lookup time from the initial connection.

Read the full technical argument ?