What Are Gaming Proxies? An Honest Latency Breakdown

Nothing in any protocol makes a proxy a "gaming proxy." The phrase is a product label attached to a normal HTTP or SOCKS5 proxy, usually with three claims stacked on it: low latency to popular game regions, an IP that does not read as a datacenter, and UDP support. The first is a hosting decision, the second is a registration decision, and the third is a software feature that most commercial pools do not actually ship.

Two very different things get sold under the same name, and confusing them is the source of most disappointment:

• A forward proxy sits between your client and the game. Your traffic leaves from the proxy's IP. This is what almost every gaming proxy listing means, and it is the thing that adds latency.
• A relay or reverse proxy sits in front of a server you control, absorbing attack traffic and hiding the origin address. This one is genuinely useful, but it protects the host, not the player, and it is a different product. If that distinction is new, our explainer on what a reverse proxy is covers the mechanics.

There is a third category worth naming because it competes directly with anything you would buy: publishers already run relay networks. Valve's Steam Datagram Relay, the transport documented in Valve's open-source GameNetworkingSockets library, carries game traffic across Valve's own backbone between ingress and egress points near the player and the server, and it hides server IPs from clients as a side effect. Riot operates Riot Direct, a private network with peering into consumer ISPs. Those systems can beat the public internet route because they own the middle of it. A rented proxy does not own anything in the middle. It just adds a stop.

Light in single-mode fiber moves at roughly 200 km per millisecond. A round trip covers the distance twice, so every 100 km of physical path adds about 1 ms of ping before any router touches the packet. Real routes are not straight lines, so the practical figure is closer to 1 ms per 70 to 80 km of great-circle distance.

Now insert a proxy. Your packet no longer goes player to server. It goes player to proxy to server, and back the same way. Unless the proxy sits exactly on the direct path, you are paying for a triangle.

Worked example. A player in Frankfurt connects to a Frankfurt game server:

That New York row is not exotic. It is what happens when someone buys a US exit and then connects to the European server anyway, or when a pool quietly assigns an exit outside the advertised region.

The best case is a proxy sitting on your direct path, which adds only process overhead: roughly 0.3 to 2 ms for a well-run TCP proxy under light load. That is the ceiling. A forward proxy cannot make a route shorter than the shortest route, so the honest range runs from slightly worse to unplayable, with nothing above zero.

The exception people cite is a bad ISP route. If your provider hairpins traffic through a distant peering point, a proxy that reaches the destination over a better-peered network can beat the default path. This does happen, mostly on congested residential links in regions with thin peering. It is worth measuring, and the route testing section below shows how. Just do not assume it. In the large majority of measurements, the direct path wins.

Where those numbers come from

The table is not a vendor estimate. It is arithmetic on two published constants and one public dataset, and you can redo it in about a minute.

Proxied round-trip time is RTT(client to proxy) + RTT(proxy to server) + proxy processing. Nothing in that sum can be negative.

Start with the glass. Single-mode fiber built to ITU-T G.652 has a group index near 1.468 at 1550 nm, so a signal travels at roughly 204,000 km/s: 4.9 microseconds per kilometre one way, 9.8 microseconds per kilometre of round trip. That works out to 1 ms per 102 km of round-trip path in a perfectly straight line. Cable does not run straight. It follows rights of way, duct, and sea floor, and measured paths typically run 1.3 to 1.6 times the great-circle distance. Divide 102 km by that inflation factor and you get the practical 1 ms per 70 to 80 km used above.

Now rebuild the New York row from scratch. Frankfurt to New York is about 6,200 km great circle, so the physical floor is 61 ms round trip. Published inter-region latency between Frankfurt and northern Virginia sits around 85 to 90 ms, an inflation factor near 1.4. A proxy in New York makes a Frankfurt player pay that leg twice: 2 x 88 ms is 176 ms, plus a millisecond or two of proxy processing. That is the 175 to 195 ms in the table, and every other row is built the same way.

Two things follow. First, any advertised figure below the great-circle floor for a city pair is wrong, not impressive. Second, you can verify a specific vendor claim without buying anything: run a RIPE Atlas measurement from a probe in the proxy's city to the game server, add the RTT from your own machine to that city, and compare the sum against your current direct ping. The mtr -T baseline further down does the same job once you have shell access on the exit.

What the detour costs in game terms

Milliseconds are abstract. Server ticks are not. Divide the added round-trip time by the tick interval and you get the number of simulation steps you are behind everyone who took the direct path:

Rollback implementations generally hold 4 to 8 frames of delay, 66 to 133 ms at 60 fps, before the correction becomes visible as a teleport. The Amsterdam row fits inside that window. The New York row does not, and no rollback buffer is deep enough to hide it.

The uncomfortable line is the first one. A 16 ms detour is the best realistic case for a European player using a European exit, and it still costs two Valorant ticks. That budget was already being spent on your last mile.

Stable high ping is playable. Unstable ping is not. Game netcode interpolates and extrapolates around a predictable delay, so a steady 90 ms feels far better than an average of 45 ms that spikes to 200 ms twice a minute.

RFC 3550, the RTP specification, gives the standard definition and it is worth borrowing: interarrival jitter is a smoothed running mean of how much consecutive packet spacings differ, updated as J += (|D(i-1,i)| - J) / 16. The detail that matters for games is that the metric is deliberately tail-sensitive. One 200 ms straggler moves it, and one straggler is also what rolls your position back through a wall.

Proxies are jitter factories for reasons that have nothing to do with distance:

• Shared tenancy. A proxy exit handling hundreds of concurrent sessions schedules your packets against everyone else's. Queue depth varies. Your delay varies with it.
• Bufferbloat. Oversized buffers on the proxy host or its uplink hold packets rather than dropping them. Latency under load climbs by tens or hundreds of milliseconds, exactly the failure mode games hate most.
• Rotation. Rotating pools change your exit IP on a timer or per connection. A mid-session exit change looks to the game server like a new source address, which at best resets the connection and at worst trips a security check.
• Residential and mobile paths. These exits ride consumer connections with asymmetric upload and, for mobile, carrier NAT plus radio scheduling. Added RTT of 30 to 150 ms is normal for residential exits, and 50 to 300 ms with heavy variance for mobile.

One configuration is worse than every other: a rotating residential proxy on a live game connection. Highest jitter, plus a path that changes underneath an authenticated session.

This is the part most gaming proxy listings quietly skip.

An HTTP proxy carries HTTP requests. For encrypted or arbitrary traffic it uses the CONNECT method, which opens a TCP tunnel. TCP only. There is no mechanism in the HTTP proxy specification for relaying a UDP datagram. Point a game that speaks UDP at an HTTP proxy and the game traffic does not degrade, it simply never arrives.

Which games care? Roughly:

SOCKS5 does have a UDP path. RFC 1928, published in March 1996 and never revised, defines the UDP ASSOCIATE command: the client opens a TCP control connection, asks the proxy to allocate a UDP relay port, and then sends datagrams to that port wrapped in a small header. The header layout for IPv4:

Ten bytes for IPv4, twenty-two for IPv6. That overhead comes out of your MTU. On a standard 1500-byte path, usable UDP payload drops from 1472 to 1462 bytes, and a game that sizes packets near the MTU starts fragmenting. The FRAG field exists to reassemble oversized datagrams, and in practice almost nothing implements it, so many proxies just drop fragments.

Three more constraints make SOCKS5 UDP fragile in the field:

1. The UDP association is bound to the TCP control connection. Drop the control socket and the relay tears down mid-match.
2. The vast majority of commercial proxy pools disable UDP ASSOCIATE entirely. It is expensive to run and trivially abusable for reflection attacks.
3. The client has to implement it. Games do not offer a SOCKS5 field, so you end up running a system-wide redirector, which pulls in every other application on the machine.

You can test whether a given endpoint actually supports UDP rather than trusting the product page:

import socket, struct

def socks5_udp_supported(host, port, user=None, pwd=None, timeout=5):
    s = socket.create_connection((host, port), timeout)
    # greeting: version 5, methods = no-auth (0) and user/pass (2)
    s.sendall(b"\x05\x02\x00\x02")
    ver, method = s.recv(2)
    if method == 0x02:
        auth = (b"\x01" + bytes([len(user)]) + user.encode()
                + bytes([len(pwd)]) + pwd.encode())
        s.sendall(auth)
        if s.recv(2)[1] != 0x00:
            raise RuntimeError("SOCKS5 auth rejected")
    elif method != 0x00:
        raise RuntimeError("no acceptable auth method")

    # CMD 0x03 = UDP ASSOCIATE, ask the proxy to pick the relay port
    s.sendall(b"\x05\x03\x00\x01" + socket.inet_aton("0.0.0.0") + struct.pack("!H", 0))
    reply = s.recv(10)
    rep = reply[1]
    if rep != 0x00:
        return False, "proxy refused UDP ASSOCIATE (REP=0x%02x)" % rep
    relay_ip = socket.inet_ntoa(reply[4:8])
    relay_port = struct.unpack("!H", reply[8:10])[0]
    return True, "relay at %s:%d" % (relay_ip, relay_port)

print(socks5_udp_supported("proxy.sparkproxy.io", 1080, "USER", "PASS"))

A REP byte of 0x07 means "command not supported," which is the answer you will get from most pools.

A clean REP=0x00 is not proof of anything yet, and this is the part that catches people out. Some pools accept the association, hand back a relay address, and then discard every datagram sent to it. From inside a game that failure is indistinguishable from 100% packet loss, so it gets blamed on the ISP. Finish the test by pushing a real datagram through the relay and checking that an answer comes back. A DNS query is the cheapest probe available: small, stateless, and the transaction ID makes the reply self-verifying.

def dns_query(name=b"sparkproxy.io", txid=0x1234):
    q = struct.pack("!HHHHHH", txid, 0x0100, 1, 0, 0, 0)
    for label in name.split(b"."):
        q += bytes([len(label)]) + label
    return q + b"\x00" + struct.pack("!HH", 1, 1)   # QTYPE=A, QCLASS=IN

def socks5_udp_forwards(ctrl, relay_ip, relay_port, proxy_host,
                        dst="1.1.1.1", dport=53, timeout=5):
    # keep `ctrl`, the TCP control socket, open: the association dies with it
    if relay_ip == "0.0.0.0":
        relay_ip = socket.gethostbyname(proxy_host)   # wildcard reply is common
    payload = dns_query()
    header = b"\x00\x00\x00\x01" + socket.inet_aton(dst) + struct.pack("!H", dport)
    u = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    u.settimeout(timeout)
    try:
        u.sendto(header + payload, (relay_ip, relay_port))
        data, _ = u.recvfrom(4096)
    except socket.timeout:
        return False, "ASSOCIATE accepted, datagrams silently dropped"
    finally:
        u.close()
    body = data[10:]                    # strip the 10-byte IPv4 reply header
    return body[:2] == payload[:2], "relay returned %d bytes" % len(body)

Three outcomes, one of which is a usable endpoint. REP=0x07 means the pool never shipped UDP. A timeout after REP=0x00 means the control plane says yes while the data plane says no, which is the failure worth catching before a match rather than during one. A matching transaction ID means the relay genuinely forwards, and only then is it worth spending time on what it does to your jitter. Our comparison of SOCKS5 versus HTTP proxies covers the rest of the protocol differences.

Stated once, plainly, then the article moves on to the useful part.

Using a proxy to evade a game ban, to spoof your region for cheaper regional pricing, or to get around a publisher's access controls violates the terms of service of every major platform, and in the pricing case it can be fraud. Steam's Subscriber Agreement prohibits circumventing regional restrictions, Valve requires the payment method to match the account's store region, and region changes are rate-limited. Declaring a country you do not live in to a payment processor in order to pay a lower price is a misrepresentation in a financial transaction, not a clever trick. Publishers reverse those purchases, revoke the licences, and close the accounts, and the account usually holds a decade of unrelated purchases.

Ban evasion deserves its own note because the technology does not even work. IP is a weak signal and modern anti-cheat barely leans on it. Riot's Vanguard runs as a kernel driver and has required TPM 2.0 and Secure Boot for Valorant on Windows 11 since 2021. Easy Anti-Cheat and BattlEye fingerprint hardware, drivers, and process behaviour. Platforms link accounts by payment instrument, device identifier, and login graph. Changing your exit IP changes one low-weight feature in a model with dozens, and the attempt itself is a fresh terms violation on a fresh account.

There is also a detection problem. Many titles block traffic from known hosting networks, so a datacenter exit usually earns a connection refusal rather than an advantage. Our piece on what a datacenter ASN is explains that lookup.

None of this makes proxies off limits around gaming. It makes the live gameplay connection the wrong place to put one. Everything below is the right place.

Five workloads, all of them HTTPS rather than game traffic, all of them jobs where a proxy is the correct tool:

1. Regional store and pricing research. Storefronts serve different catalogues, prices, currencies, and release dates by country. Publishers, analysts, and competitors need that matrix. Reading a public price page from a given country is exactly what geo-targeted exits are for.
2. Route and ping-route testing. Before you commit a community server to a region, measure the real path from the regions your players live in. Proxies give you vantage points.
3. DDoS-shielded relaying for a server you host. A relay in front of your own game server hides the origin and absorbs volumetric traffic. This is infrastructure you run, not a rented exit you connect through.
4. Market and leaderboard data collection. Player counts, esports standings, item economies, patch notes, review sentiment, and streaming metrics all live behind rate limits enforced per IP.
5. Publisher-side anti-cheat and bot detection research. If you build the defence, you need to see your service from a proxied, geo-shifted, datacenter-registered client, which means holding the same tools attackers hold.

This is the highest-value gaming use of a proxy, and it does not touch a game connection at all. A store page rendered from a Japanese exit and the same page from a Brazilian exit are different documents, and the difference is the dataset.

SparkProxy's Scraping API handles the exit selection, the rendering, and the extraction in one request. The base URL is https://scrape.sparkproxy.io/api/v1, authenticated with an X-API-Key header.

A single country, rendered, with structured extraction:

curl -X POST "https://scrape.sparkproxy.io/api/v1" \
  -H "X-API-Key: sk-YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://store.example-game.io/app/12345",
    "render_js": true,
    "country_code": "JP",
    "format": "json",
    "extract_rules": {
      "title": "h1.app_title",
      "price": ".game_purchase_price",
      "release_date": ".release_date .date"
    }
  }'

Now the same page across a country matrix, which is the shape most pricing studies actually need:

import os, requests, csv

API = "https://scrape.sparkproxy.io/api/v1"
KEY = os.environ["SPARKPROXY_API_KEY"]
COUNTRIES = ["US", "GB", "DE", "JP", "BR", "IN", "TR", "AU", "PL", "MX"]
TITLE_URL = "https://store.example-game.io/app/12345"

rows = []
for cc in COUNTRIES:
    r = requests.post(
        API,
        headers={"X-API-Key": KEY, "Content-Type": "application/json"},
        json={
            "url": TITLE_URL,
            "render_js": True,
            "country_code": cc,
            "premium_proxy": True,
            "format": "json",
            "session_id": "pricing-" + cc,
            "extract_rules": {
                "price": ".game_purchase_price",
                "currency": "meta[itemprop=priceCurrency]::attr(content)",
                "discount": ".discount_pct",
            },
        },
        timeout=90,
    )
    if r.status_code == 429:
        print(cc, "rate limited, retry after", r.json().get("retry_after_seconds"))
        continue
    if r.status_code != 200:
        print(cc, "failed", r.status_code)
        continue
    data = r.json()
    ext = data.get("extracted", {})
    rows.append({
        "country": cc,
        "price": ext.get("price"),
        "currency": ext.get("currency"),
        "discount": ext.get("discount"),
        "credits": data.get("credits_used"),
    })

with open("regional_prices.csv", "w", newline="") as f:
    w = csv.DictWriter(f, fieldnames=["country", "price", "currency", "discount", "credits"])
    w.writeheader()
    w.writerows(rows)

Two notes that save credits. The API allows 60 requests per minute with 3 concurrent requests, and a 429 carries retry_after_seconds, so honour it. For flat pages that need no JavaScript, such as patch-note archives, batch mode takes comma-separated URLs in one url parameter with render_js false, and the whole batch costs a single credit:

notes = ",".join("https://patchnotes.example-game.io/v%d" % n for n in range(140, 160))
r = requests.get(
    API,
    headers={"X-API-Key": KEY},
    params={"url": notes, "render_js": "false", "format": "md"},
    timeout=120,
)
for item in r.json()["results"]:
    print(item["url"], item["status"], len(item.get("content", "")))

For long-running collections, pass a callback_url and the API returns 202 with a job_id immediately, then POSTs the finished result to your webhook. That keeps a nightly leaderboard sweep off your concurrency budget. If you are pulling Steam specifically, our walkthrough on scraping Steam game data covers the endpoint layout in detail, and scraping Twitch data covers the streaming side of the same market picture.

If you want to know whether a proxied path could beat your direct path, measure it. Not a marketing page, and not a single ping.

ICMP is deprioritised on plenty of routers, so measure at the TCP layer against the port the game actually uses:

# Baseline: direct path, 100 samples
mtr -T -P 27015 -c 100 --report game-eu.example-game.io

# Same target, run from a shell on the proxy host, to see the second leg alone
mtr -T -P 27015 -c 100 --report game-eu.example-game.io

Then compare handshake times directly. The number that matters is not the mean, it is the spread between the median and the 95th percentile, because that spread is your jitter:

import socket, time, statistics

def tcp_rtt(host, port, samples=50):
    out = []
    for _ in range(samples):
        s = socket.socket()
        s.settimeout(3)
        t0 = time.perf_counter()
        try:
            s.connect((host, port))
            out.append((time.perf_counter() - t0) * 1000)
        except OSError:
            pass
        finally:
            s.close()
        time.sleep(0.1)
    return out

r = sorted(tcp_rtt("game-eu.example-game.io", 27015))
med = statistics.median(r)
p95 = r[int(len(r) * 0.95)]
print("n=%d median=%.1fms p95=%.1fms spread=%.1fms" % (len(r), med, p95, p95 - med))

Run both paths for at least ten minutes at your normal play hours, not at 04:00 when every link is idle. A proxy that wins on a quiet Tuesday afternoon and loses at 21:00 on a Saturday is a proxy that loses.

Here the word proxy is technically right and the product is completely different. You run a community server for Minecraft, Rust, or a Source-engine title. Its IP is visible to every player who joins, and one annoyed player with a booter subscription can take it offline.

The fix is to terminate connections on a scrubbing provider or a cheap relay host and forward clean traffic to an origin whose address is never published. The origin firewall then accepts traffic only from the relay. For a TCP-based game, an nginx stream block is enough:

stream {
    upstream origin {
        server 10.0.0.12:25565;
    }
    server {
        listen 25565;
        proxy_pass origin;
        proxy_protocol on;          # preserves the real client IP for your logs
        proxy_connect_timeout 3s;
        proxy_timeout 10m;
    }
}

For UDP games, the same block with listen 25565 udp; and proxy_responses 1; relays datagrams, though you lose PROXY protocol unless the game server supports the UDP variant.

Three rules decide whether this works:

• Put the relay near the origin, not near the players. The relay-to-origin leg should be short, because the player-to-relay leg is the one you cannot control.
• Change the origin IP after you deploy the relay. If the old address ever appeared in a server list, a DNS history record, or a player's connection log, it is still attackable.
• Lock the origin firewall to the relay's addresses. A relay in front of a server that still accepts traffic from everywhere protects nothing.

Budget 5 to 25 ms of added RTT for a well-placed relay, and treat that as the price of staying online.

If you operate the game, the question inverts: which connections are proxied, and do you care? Corporate networks, university dorms, and carrier-grade NAT all produce shared addresses belonging to legitimate players.

Useful signals, in rough order of how much weight they deserve:

1. ASN classification. Look up the connecting IP's autonomous system and check whether it belongs to a hosting provider, a consumer ISP, or a mobile carrier. A hosting ASN on a client connection is the strongest single signal.
2. RTT versus claimed geography. A client that geolocates to Singapore but shows a 12 ms RTT to your Frankfurt server is not in Singapore. Physics does not negotiate.
3. Address density. Many accounts, one address, uncorrelated play patterns. Distinguish this from CGNAT by checking whether the ASN is a residential ISP.
4. Handshake fingerprint. A client whose TLS or protocol handshake does not match the client build it claims to be running.
5. Route consistency within a session. A source address that changes mid-session on a connection that should be stable.

A minimal ASN pass over a day of connection logs:

import csv, subprocess, collections

def asn_of(ip):
    # whois against Team Cymru's IP-to-ASN service
    out = subprocess.run(
        ["whois", "-h", "whois.cymru.com", " -v " + ip],
        capture_output=True, text=True, timeout=10
    ).stdout.splitlines()
    return out[1].split("|")[-1].strip() if len(out) > 1 else "unknown"

counts = collections.Counter()
with open("connections.csv") as f:
    for row in csv.DictReader(f):
        counts[asn_of(row["ip"])] += 1

for asn, n in counts.most_common(25):
    print("%6d  %s" % (n, asn))

Sort the output and the hosting providers stand out immediately. Rate-limit or challenge on this signal, do not hard-ban on it alone. Plenty of legitimate players sit behind a VPN for reasons that have nothing to do with your game, and the difference between a proxy and a VPN matters here: our proxy versus VPN comparison covers how each one shows up in your logs.

The pattern is clean once you see it. Anything that is a request for a document belongs on a proxy. Anything that is a live, stateful, latency-budgeted session belongs on the shortest path you have.