When two players in the same city get 120ms: inside Valve's P2P networking regression

What players are actually experiencing

The original report, filed in Valve's GameNetworkingSockets issue #398, describes a pattern that should be impossible in a latency-sensitive genre. Israeli Street Fighter 6 players on PC-to-PC matches report roughly 120ms round-trip time. Matches against Europeans on the same setup land at 60–80ms — better, but still high for a game that lives or dies on frame-perfect inputs. PC-to-PS5 cross-play in the same room? Five to ten milliseconds.

The community tested across ISPs, port forwarding, and traceroutes. Nothing on the last mile explained it. Games that do not use Steam networking — Tekken 8 was the example cited — worked normally. Games that do, across fighting titles and co-op shooters, broke around mid-March 2026 in a coordinated way that points upstream.

Reports spread beyond Israel. Chinese players on Warhammer: Vermintide 2 and Deep Rock Galactic describe the same failure mode: even with "Share IP Address" enabled in Steam settings, direct UDP peer links never establish. Traffic detours through Valve's Steam Datagram Relay (SDR) service instead. For an action game, that extra hop is not a minor inconvenience — it is the difference between playable rollback netcode and a slideshow.

SDR vs true P2P: the architecture trade-off

Valve's networking library was designed with a sensible fallback hierarchy. Ideally, two clients perform NAT traversal via STUN, punch through firewalls, and exchange encrypted packets directly. When that fails — symmetric NAT, corporate firewalls, privacy settings — Steam relays traffic through SDR, a global anycast mesh that keeps IP addresses hidden and mitigates denial-of-service attacks against exposed endpoints.

That privacy-latency trade-off is documented. Valve's own P2P docs note that on Steam, traffic is always relayed and IP addresses are not shared between untrusted peers, precisely to prevent malicious players from DoS-ing each other's home connections. The "Share IP Address" toggle was supposed to opt trusted friends into direct routing. Players in the issue thread report it is being ignored entirely since the March regression.

Hacker News commenters raised a darker hypothesis — that STUN blocking in conflict zones or censorship-heavy networks could be a factor given the geographic clustering of reports. Valve engineer @bgilmore engaged on GitHub in late April, asking for reproduction details and promising to coordinate with SDR partners. As of early June the issue remains open, with fresh reports from Finland, Russia, and elsewhere suggesting the problem is not purely regional even if it surfaced hardest where relay paths are longest.

The workarounds tell us what changed

Open-source bug trackers shine when symptoms converge. By May, players had reverse-engineered several fixes that all point to the same root cause: a regression in Valve's WebRTC stack shipped with newer Steam clients.

• DLL substitution. Copying steamwebrtc64.dll from the Steam install directory into a game's Binaries/Win64 folder — on both sides — restores NAT traversal and displays "IP shared" in the networking overlay. Confirmed across Deep Rock Galactic, Vermintide 2, Street Fighter 6, and Melty Blood. One-sided substitution does not work; both peers need the older library or the session still relays.
• Steam client downgrade. Players rolled back to a January 2026 Steam client (archived builds circulate on the web) and blocked auto-update via steam.cfg. The older client attempts STUN-based direct connection; newer builds reportedly skip that path entirely and jump straight to SDR.
• Community mods. A Nexus Mods patch for SF6 automates part of the DLL workaround, though players report mixed stability when one side relays and the other does not.

These are not sustainable fixes. They require both parties to cooperate, bypass Steam's normal update channel, and accept security implications of pinning old WebRTC binaries. But they are valuable forensic evidence: something in the March Steam networking update broke the happy path for direct P2P, and SDR became the only path even when relays are geographically absurd.

Why developers should care — even outside Steam

Most Solana Garden readers are not shipping Steamworks titles. The lesson still lands: when you outsource networking to a platform layer, you inherit its outages. Capcom cannot patch Valve's relay routing. Indie studios using GameNetworkingSockets as a convenience library discovered their entire multiplayer surface area depends on binaries they do not control.

The parallel to web3 gaming is uncomfortable but useful. Wallet-native games on Solana settle payments on-chain, but real-time play still needs transport — WebRTC, custom UDP, or a relay you operate yourself. Our wallet gaming guide covers the payment side; latency is a separate contract with whoever routes your packets. If that layer silently degrades, your players blame you, not the infrastructure vendor.

Three design principles fall out of this outage:

1. Instrument the transport path. Expose whether a session is direct or relayed in your UI. Players diagnosed the Steam issue because overlay tools showed SDR routing; without that visibility, support tickets point at the wrong layer.
2. Keep an escape hatch. Cross-play through platform-specific backends (PSN in SF6's case) worked because it bypassed the broken PC stack. Multi-backend netcode is expensive, but single-vendor dependency is a single point of failure.
3. Test regionally, not just locally. A networking change that passes QA in Seattle can destroy playability in Tel Aviv or Shanghai if relay topology shifts. Latency budgets need geographic test matrices, not LAN-only CI.

The Hacker News debate

Discussion on HN thread #48431461 split along predictable lines. Some commenters accused the poster of clickbait for generalising a Middle East-specific title; others noted Chinese and European reports that confirm wider impact. Security-minded readers argued STUN's amplification risks make relay- first policies defensible. Competitive players countered that a 120ms same-city match is simply a broken product, regardless of threat model.

The constructive middle ground: Valve chose privacy and anti-DoS defaults that made sense in 2020, but a regression that disables the direct path entirely crosses from "safe default" to "unplayable." Players want a postmortem explaining why STUN stopped firing and when a proper fix ships — not another DLL scavenger hunt.

For readers tracking gaming infrastructure alongside AI and crypto news, this story pairs with broader platform-dependency themes on HN this week — agent harnesses, memory management, and the recurring question of who owns the stack beneath your product. Our World Pulse page tracks which threads the platform reacts to; the games arcade is where we ship wallet-native titles that at least own the payment layer even when transport stays hard.

Bottom line

Valve's P2P regression is a case study in invisible infrastructure failure. The games look fine in menus; matchmaking succeeds; then input delay exposes that packets are touring Europe instead of crossing town. Community workarounds prove direct P2P still works when the right WebRTC build is in play — which makes the ongoing outage more frustrating, not less.

If you ship anything multiplayer in 2026, ask what happens when your platform vendor's relay becomes the only path. Your players will not read GitHub issues. They will read lag. Build observability and fallbacks accordingly — or own the transport yourself.

Sources: Valve GameNetworkingSockets #398 — Major P2P issues; Hacker News discussion (June 2026). Related on Solana Garden: Wallet-native Solana games; Solana priority fees (when on-chain latency matters too).