SSH Drops, Database Timeouts & Flaky VPNs While Working Abroad

SSH Dying Mid-Command: Keep-Alive Settings and Mosh

Plain SSH has no built-in awareness that your WiFi hiccuped — TCP will happily sit in a half-open state waiting for a response that's never coming, which is why a session can look "frozen" for a full TCP timeout window (often 15-20 minutes with default settings) before your client finally gives up. The fix most people skip is ClientAliveInterval and ClientAliveCountMax on the server side, and ServerAliveInterval in your client's ~/.ssh/config — setting these to something like 15-30 seconds means a dead connection gets detected and dropped in under a minute instead of hanging indefinitely, which at least lets you reconnect immediately instead of staring at a frozen terminal.

For genuinely unstable connections — train WiFi, spotty rural cell coverage, congested coworking WiFi — Mosh (mobile shell) is the better tool, not a workaround. It runs over UDP with a local echo and a custom state-sync protocol instead of TCP, so it survives IP changes, sleep/wake cycles, and dropped packets without killing the session — you'll see it visibly "catch up" instead of disconnect. The tradeoff is it needs a UDP port range open on the server, which is a one-time setup we can configure remotely alongside your SSH keep-alive settings.

Database Connection Timeouts: It's Latency, Not Bandwidth

A database timeout after switching countries is rarely about your connection being too slow in the bandwidth sense — it's latency. A connection pool or query timeout configured for a server in the same region (typically 1-5ms round trip) doesn't magically fail at 50ms, but once you're routing traffic from, say, Southeast Asia to a database in US-East, you're looking at 200ms+ round trip on every single query, and connection pool settings that assume near-instant acquisition start timing out on pool checkout, not just on slow queries.

The practical fixes we handle remotely: raising connectionTimeoutMillis / statement_timeout (Postgres) or connectTimeout / wait_timeout (MySQL) to realistic values for your actual current latency rather than the values your team set when everyone was in one office, checking whether your ORM's connection pool size is starving under higher latency (fewer connections completing per second means more queued requests hitting the pool timeout), and confirming your database driver is using persistent/pooled connections rather than opening a fresh TCP+TLS handshake per query, which turns a 5ms local overhead into a 400-600ms overhead at distance.

Git Push/Pull Failures on Flaky Hotel or Cafe WiFi

Git over HTTPS is more fragile on unstable connections than most people realize — a large push over HTTP can fail partway through and, depending on your git version and the remote's configuration, sometimes leaves you with a corrupted pack or a push that "succeeded" on your end but never fully landed. Switching the remote to SSH transport (git remote set-url origin git@host:... instead of https://host/...) gives you a persistent, resumable connection that tolerates brief drops better, especially combined with git config http.postBuffer increases if you're staying on HTTPS for auth reasons.

For genuinely large pushes on bad connections, git config --global http.lowSpeedLimit and http.lowSpeedTime control when git gives up on a stalling transfer — the defaults are often too aggressive for satellite or heavily congested WiFi and abandon a push that would have completed if given another 30 seconds. We can also set up a lightweight bounce server or use git bundle for genuinely offline-first workflows when you're somewhere with no reliable connection at all.

VPN Tunnel Instability Breaking Everything Downstream

A VPN tunnel adds its own failure mode on top of the underlying connection instability — most consumer and even some corporate VPN clients don't handle a dropped WiFi handshake or an IP change (switching from WiFi to hotspot mid-session, common when working from moving transport) gracefully, and the tunnel can end up in a state where it thinks it's connected but nothing is actually routing, which is worse than being disconnected because everything just hangs instead of failing fast.

WireGuard-based VPNs handle this materially better than OpenVPN because of how the protocol re-establishes state, and it's worth checking whether your corporate VPN client supports it before assuming your only option is the default OpenVPN config IT handed you. If your dev workflow depends on VPN access to internal infrastructure, see our VPN setup guide for remote workers for the connection-stability side of this — combined with the keep-alive and timeout tuning above, this covers most "everything just hangs" scenarios.

Choosing Infrastructure Closer to Where You Actually Are

The highest-leverage fix, and the one most teams never consider until someone's actually abroad, is not tuning timeouts at all — it's putting a read replica, a caching layer, or a bastion/jump host in the region you're actually working from. A jump host in the same region as you, tunneling to the origin infrastructure over a connection that infrastructure providers optimize (rather than consumer hotel WiFi doing the long haul), turns a 250ms round trip into two shorter, more reliable hops instead of one long fragile one.

This is more setup than a keep-alive tweak, but for developers doing extended stays (months, not days) in one region, it's worth the one-time cost — we can help configure a bastion host or regional read replica as part of a session if your current infra doesn't have one, which also pairs well with a properly configured remote desktop setup if part of your workflow depends on a machine physically closer to your infrastructure.

Get Your Dev Workflow Working Again

"Just restart your router" isn't a real fix for a keep-alive misconfiguration or a timeout value tuned for the wrong region — this needs someone who actually reads the SSH config and the connection pool settings, not generic troubleshooting.