{"id":1496,"date":"2026-10-26T22:15:36","date_gmt":"2026-10-26T22:15:36","guid":{"rendered":"https:\/\/bestdedicatedwebhostingserver.com\/blog\/?p=1496"},"modified":"2026-10-26T22:15:36","modified_gmt":"2026-10-26T22:15:36","slug":"proxy-protocol-real-ip-game-node-haproxy","status":"publish","type":"post","link":"https:\/\/bestdedicatedwebhostingserver.com\/blog\/proxy-protocol-real-ip-game-node-haproxy\/","title":{"rendered":"PROXY Protocol on a Game Front-End: Recovering Real Player IPs Behind HAProxy"},"content":{"rendered":"
\n

Putting HAProxy in front of a game node is the standard way to hide origin IPs and absorb floods, and it works until you look at the server log and every player connects from 10.0.0.14<\/code>. That single line breaks per-IP bans, connection rate limits, geo rules, and any abuse forensics you had. The cause is structural: a TCP proxy terminates the client connection and opens a new one to the backend, so the backend’s view of the peer is the proxy, not the player. PROXY protocol exists to fix exactly that, but only if both ends speak it.<\/p>\n

Why Plain TCP Forwarding Destroys Source IPs<\/h2>\n

HAProxy in mode tcp<\/code> is a bidirectional byte pump. It accepts the client’s socket, establishes a separate socket to the backend, and copies bytes. The backend sees the proxy’s source address and a new ephemeral port. There is no field in a raw TCP stream to carry the original address, and no amount of header inspection will recover it after the fact.<\/p>\n

The usual workarounds all fail for game traffic. Reading X-Forwarded-For<\/code> does not apply \u2014 game protocols are binary UDP or TCP, not HTTP. Trusting the proxy to rewrite connection metadata works only for protocols with in-band identity, which most game handshakes do not have. Logging a session identifier and joining it with HAProxy logs is possible but gives you the mapping minutes late and not at all for UDP.<\/p>\n

PROXY Protocol: v1 and v2<\/h2>\n

PROXY protocol prepends a single header to the connection before any game bytes. The backend parses it, learns the real source, then continues reading the normal stream. Two versions exist, and the choice matters operationally.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Aspect<\/th>\nv1<\/th>\nv2<\/th>\n<\/tr>\n<\/thead>\n
Format<\/td>\nText line<\/td>\nBinary, 16-byte signature<\/td>\n<\/tr>\n
Signature<\/td>\nPROXY TCP4 ...<\/code><\/td>\n0D 0A 0D 0A 00 0D 0A 51 55 49 54 0A<\/code><\/td>\n<\/tr>\n
Address families<\/td>\nTCP4 \/ TCP6 only<\/td>\nTCP\/UDP, IPv4\/IPv6, UNIX<\/td>\n<\/tr>\n
UDP support<\/td>\nNo<\/td>\nYes (with datagram framing)<\/td>\n<\/tr>\n
TLV extensions<\/td>\nNo<\/td>\nYes<\/td>\n<\/tr>\n
Overhead<\/td>\n~40-80 bytes<\/td>\n16 + 4 + length<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Game traffic is UDP in almost every modern title, so v2 is the version you need. v1 is fine for a Minecraft TCP front-end and is easier to debug because you can see it in a hex dump as plain text.<\/p>\n

# HAProxy front-end sending PROXY v2 to the backend\nfrontend game_in\n  bind *:25565\n  mode tcp\n  default_backend mc_nodes\n\nbackend mc_nodes\n  mode tcp\n  server node1 10.0.0.14:25566 send-proxy-v2 check\n  server node2 10.0.0.15:25566 send-proxy-v2 check backup<\/code><\/pre>\n
One rule that catches everyone: the backend listener must either expect PROXY headers on every connection or on none. Mixing causes the backend to interpret a PROXY header as game data, and you get protocol errors or a parser crash on the first packet.<\/p>\n
Which Game Servers Read It Natively<\/h2>\n
Native support is thinner than the web world, where every reverse proxy speaks it.<\/p>\n