satmux keeps 12 connections open on the ground so airplane Wi-Fi stops paying for handshakes

Airplane Wi-Fi over a geostationary satellite is slow in a very specific way. A signal climbs 35,786 km up, comes back down, and a round trip lands around 620 ms. Opening one new HTTPS connection takes several of those trips, and a web page opens connections to a lot of places.

The satmux README calls the project a “TCP multiplexer and 1-RTT HTTP/TLS relay for geostationary (GEO) inflight Wi-Fi.” The mechanism is a pool: satmux “Keeps 12 pre-warmed TCP connections open to a Linux VM near the satellite ground station.” Your requests ride those warm connections instead of each paying for DNS, TCP and TLS over the sky.

The setup is DIY. You “Rent a small Linux VM ($0.01–$0.03/h, Python 3.9+, open TCP port 8444),” and the code is “Pure Python 3 stdlib, zero external dependencies.” A local proxy on the laptop talks to that VM. The README lists a macOS routing script and a disable script that restores your Wi-Fi proxy and tool settings, and it says to destroy the VM afterward. A flight with a $0.03 an hour server is about the cheapest networking project you’ll run this month.

There are two ways through. In tunnel mode, the laptop keeps its own end-to-end TLS. The README says the local endpoint answers right away and sends the open request and the TLS hello in the same burst, which saves one satellite round trip per new connection. In ground-fetch mode, the laptop sends one encrypted request to the VM. The VM does the DNS, the TLS and the redirects over fiber, compresses the reply with zlib, and sends it up once.

The README says the cabin network fights back. As I read it, the gateway intercepts DNS and runs a transparent proxy on port 443 that drops connections under load, which is why satmux talks to the VM on port 8444 instead.

The numbers come from one flight. The README says they were “Measured inflight over Inmarsat GX Ka-band (~620 ms RTT, SITA AS206433 Amsterdam ground station).” Its headline test fetched six sites at once: “6-Origin Burst: 19.13s (3/6 failed) → 5.35s (0/6 failed) [3.6× faster · -76% TTFB].” Three of the six requests died on the bare cabin connection. With satmux, none did.

The per-site rows tell the same story. Raw Wi-Fi timed out on the GitHub repo page and a second site, and reset the connection on the GitHub API. satmux got those through in 4.66, 2.66 and 2.28 seconds. MDN went from 12.01 seconds to 2.30. Cloudflare went from 2.97 seconds to 1.40.

The limits are in the README too. “Speed-of-light propagation to geostationary orbit (35,786 km) does not change.” “Cabin routers police total bandwidth per client lease.” And “Uses your authenticated cabin Wi-Fi lease; it does not bypass captive portals,” so you still pay for the airline’s Wi-Fi first. One tip: “Pause UDP VPNs (Tailscale/WireGuard) inflight—blocked UDP retry traffic competes for cabin airtime.”

Everything above comes from the maker’s own README, and that’s the one source. It doesn’t give the flight date, the number of runs or the airline. Another flight on another aircraft could look different.

The README’s gateway complaints read like a to-do list for the airline’s own network. Until somebody works through it, the cheap fix is a rented server and a script. Expect more passenger-side tools like this one, since the people with the most time to tinker are the ones stuck in a seat.

Seat 14C, tunnel open.