Josh Huang's Engineering Notes
The Kernel Bug Hiding Inside My Own Routing Table
Selectively routing one console's streaming-app traffic through a Japan exit node, without touching its own login/matchmaking traffic — and the two independent kernel-level bugs that made it look impossible.
This article is also available in Traditional Chinese: 中文版 — same content, just a language difference.
A games console on my home network needed its streaming-app traffic (a half-dozen Japan-only video services) to exit through a Japan-based proxy, while every other kind of traffic from the exact same device — login, matchmaking, downloads, remote play — had to keep going out the normal path, untouched, with zero added latency. Not "route the whole console through a VPN." Not "run a separate SSID." Per-domain, per-connection, on one physical device, with a hard requirement that breaking the second kind of traffic was not an acceptable failure mode.
Getting the domain-matching logic right was the easy part. The actual blocker was a kernel behavior I'd never had a reason to run into before, and it hid behind a symptom that looked exactly like a proxy client bug.
Why a router-level rule or a VLAN doesn't solve this
The obvious-sounding fixes don't actually work here. A firewall rule can route by destination IP, but streaming platforms sit behind shared CDN IP ranges you can't cleanly separate from everything else on the same CDN. A separate VLAN or SSID solves device isolation, not per-domain routing — you'd still need something to actually speak the proxy protocol and decide, per connection, which of two paths to take. And a consumer mesh access point generally has no per-SSID VLAN tagging at all, so that path was closed before it started.
Unlock this article to keep reading, or subscribe for unlimited access to everything. See Pricing for details.