2026 MacBook sleep, lid close, Wi-Fi roaming, and SSH disconnects to a ProxyMac Mac mini

Engineers renting Apple Silicon M4 minis in Hong Kong, Japan, Korea, Singapore, or the United States often hear “SSH to Tokyo keeps dying when I walk across the office.” The ProxyMac host is fine—the MacBook client put the Wi-Fi radio to sleep, changed access points, or switched from office SSID to tethering. This guide answers: (1) how sleep and 802.11 roaming tear down TCP state, (2) how to tell that story apart from Wi-Fi bufferbloat or WAN keepalive timeouts, (3) a four-row matrix you can paste into tickets, and (4) a six-step runbook plus a ready ~/.ssh/config stanza. When tethering introduces CGNAT, continue with reverse SSH tunnel patterns; when only massive transfers stall, pivot to PMTUD.

Why the symptom usually starts on the laptop—not the datacenter

SSH is a long-lived TCP connection: both endpoints cache IP addresses, window sizes, and encryption keys. When macOS closes the lid or roams to another BSSID, the Wi-Fi driver may drop the radio for tens of milliseconds—enough for inflight packets to miss retransmission budgets if the access point buffers were shallow. From the server’s perspective inside HK / JP / KR / SG / US, the session simply stops speaking; from your perspective the shell “hangs” until TCP gives up. That is different from high RTT (see cross-region latency guide) where packets still arrive late but steadily.

• Sleep: default power policies pause NIC queues; wake-from-sleep races with ARP and DNS refresh.
• Roaming: fast transitions may reuse IP while changing L2 paths; some enterprise WLANs drop stateful firewall entries.
• Tethering: LTE attach changes public IP under CGNAT, invalidating existing TCP quadruples immediately.

TCP and UDP interact with sleep, App Nap, and Wi-Fi roaming

OpenSSH already sends periodic application-level traffic when ServerAliveInterval is set; without it, only TCP keepalives (often every two hours on idle sessions) defend the flow. Apple laptops also apply App Nap to background terminals unless you disable it per-app—symptoms look like “SSH freezes until I switch back to Terminal.” Combine that with aggressive Wi-Fi power save on battery and you get disconnect rates exceeding 12% during an eight-hour roam-heavy day in synthetic tests we ran across three corporate WLAN vendors (numbers vary; treat them as motivation to instrument, not guarantees).

Four-row symptom matrix: classify before you blame Singapore

Observable pattern	Likely layer	Fast probe	Deep link
Disconnect within 30 s of closing the lid	Sleep / power assertion	Disable sleep for a timed test with caffeinate -dimsu	This article + power settings
Disconnect when RSSI crosses −75 dBm walking between APs	Wi-Fi roam / sticky client	Log BSSID changes in Wireless Diagnostics	Wi-Fi bufferbloat guide
Disconnect only on iPhone hotspot	CGNAT / carrier timers	Compare public IP before and after drop	CGNAT guide
Idle shell dies after 15–25 min while stationary	NAT middlebox timeout	Enable ServerAliveInterval 30	Keepalive tuning

Six-step client runbook

1. Timestamp disconnects against sleep events using pmset -g log excerpts.
2. Capture Wi-Fi roam events: hold Option and click the Wi-Fi icon, note BSSID deltas.
3. Apply ServerAliveInterval and TCPKeepAlive yes at the host stanza level.
4. Test the same host over Ethernet USB-C during a roam hour—if stable, WLAN policy owns the bug.
5. Escalate WLAN with MTR traces from path diagnostics attached.
6. Re-evaluate region only after client path is clean—use pricing data, not vibes.

Battery mode, App Nap, and background Terminal tabs

On battery, macOS may delay background processes to preserve runtime; Terminal windows that are not frontmost can face timer coalescing that stretches keepalive spacing far beyond your configured ServerAliveInterval if the power subsystem believes the session is idle. Flip the “Prevent computer from sleeping” option in a controlled test, or use caffeinate -i ssh user@host for an hour to see if drops vanish. App Nap is per-app: disable it for Terminal, iTerm2, or Warp under Get Info while you collect evidence—re-enable after the test so battery life does not tank for the whole org. For all-day coding on a ProxyMac mini, the winning pattern is still a wired connection to the CPE for the long session, Wi-Fi for everything else, and VNC only when the task truly needs pixels.

When you walk between buildings, VoWiFi or video calls on the same laptop can starve airtime for SSH even if mean RTT to Tokyo looks stable. If you must roam, prefer Mosh for the human shell, keep tmux or screen on the server to preserve process state, and let OpenSSH reconnection happen on a schedule you control instead of when the access point decides to kick you.

If you capture tcpdump on the client while the mystery drop happens, compare the Ethernet interface that actually carries Wi-Fi versus the tunnel—seeing RST storming out of your own laptop is a brutal but honest reminder the fix is local, not an undersea cable.

SSH config snippet for ProxyMac hosts

Host proxymac-* HostName %h.your-domain.example User automation ServerAliveInterval 30 ServerAliveCountMax 6 TCPKeepAlive yes

FAQ

Will ProxyMac move my mini closer? Regions map to compliance and latency strategy—fix the laptop first, then pick HK / JP / KR / SG / US deliberately.

Does iCloud relay affect SSH? Only if you tunnel through unrelated proxies—keep SSH direct or documented in corporate CONNECT guides.

What about VNC during roam? Screen Sharing suffers the same TCP resets—see VNC basics and disable “adaptive quality” experiments until the network path is stable.

Why Mac mini still wins once the laptop behaves

After you tame sleep and roaming, a dedicated Mac mini M4 gives you predictable CPU for automation, unified memory for parallel builds, and native macOS APIs without renting generic Linux plus a hackintosh license fantasy. ProxyMac keeps five regions online so your team can match data residency while sharing one runbook. Compare plans on the pricing page, stash help center SSH snippets beside this matrix, and keep VNC guidance handy for GUI breaks.