2026 MacBook 睡眠、闔蓋、Wi‑Fi 漫遊與連向 ProxyMac Mac mini 的 SSH 中斷
在香港、日本、韓國、新加坡或美國租用 Apple 晶片 M4 mini 的工程師常反映：「走到會議室另一端連東京的 SSH 就不見。」 ProxyMac 主機多半正常——問題通常在 MacBook 客戶端：Wi‑Fi 收音機被睡眠策略收起、在基地台間漫遊，或從公司 SSID 切到手機熱點。本篇依序回答：(1) 睡眠與 802.11 漫遊如何撕裂 TCP 狀態；(2) 如何把故事與 Wi‑Fi 緩衝膨脹、廣域網路存活逾時區分開；(3) 可貼進工單的四列表矩陣；(4) 六步跑冊與可直接複製的 ~/.ssh/config。若熱點涉及電信級 NAT（CGNAT），請續讀 反向 SSH 通道模式；若只有巨量傳輸卡住，改用 PMTUD 思路。
為何症狀多半從筆電開始——而不是機房
SSH 是長連線的 TCP：兩端快取 IP、視窗與加密狀態。當 macOS 闔蓋或在另一顆 BSSID 上重新附著時，Wi‑Fi 驅動可能在毫秒級暫停無線電——若基地台緩衝淺，進行中的封包就可能錯過重傳預算。對香港／日本／韓國／新加坡／美國機房內的伺服器而言，連線只是忽然安靜；對你則像 shell「凍住」直到 TCP 放棄。那和單純高 RTT 不同：後者延遲變大但封包仍斷續到達，可參 跨區延遲指南。撰寫 RCA 時請把「客戶端鏈路事件時間線」與「伺服器端紀錄」對齊；許多工單在附上 pmset 與 Wi‑Fi 診斷後第一天就能結案。
- 睡眠：預設電源設定會暫停 NIC 佇列；醒來時與 ARP／DNS 刷新競賽。
- 漫遊：快速轉移可能保留 IP 但改寫第二層路徑；部分企業無線會刷掉狀態防火牆項目。
- 熱點：LTE／5G 重新附著會在 CGNAT 下立刻換公開 IP，現有四元組同步作廢。
若你把同一台 Mac mini 從會議桌接到有線基座後問題消失，卻仍怪東京區域，通常代表訊號鏈上「客戶端 Wi‑Fi／電源策略」尚未寫進 RCA。反向亦然：跨區 RTT 確實偏高時，請不要把睡眠議題與海洋電纜議題糊成一則敘事——財務與維運讀的是可分離的假設。
TCP／UDP 如何與睡眠、App Nap、Wi‑Fi 漫遊互動
OpenSSH 在設定 ServerAliveInterval 後會定期送出應用層存活流量；若未設定，TCP keepalive 往往在閒置約兩小時才會試探，對長駐 shell 幾乎等於不存在。Apple 筆電亦會對背景終端機套用 App Nap——表面症狀像「SSH 凍住直到我切回終端機」。再疊上用電池時較激進的 Wi‑Fi 省電，便會出現「漫遊很重的一天裡斷線率高於一成」這類統計（數字僅作為儀器化的動機，不保證每台路由器都可複製）。跨廠牌 AP 測試裡，走廊漫游時的中斷多半仍可回溯到客戶端黏著或省電而非海纜。
實務上建議同屏打開「活動監視器」的能源分頁，觀察背景 ssh 是否被標成暫停；再與 log show --predicate 'eventMessage CONTAINS "WiFi"' 的節點交叉。你的工單越能還原「哪一層先安靜」，越不會變成跨團隊的猜謎遊戲。
四列症狀矩陣：在指責新加坡前先分類
| 可觀察型態 | 可能層次 | 快速實驗 | 深入連結 |
|---|---|---|---|
| 闔蓋後 30 秒內 斷線 | 睡眠／電源宣告 | 用 caffeinate -dimsu 做計時對照 | 本文與電源設定 |
| RSSI 穿越 −75 dBm 走路換 AP 時掉線 | Wi‑Fi 漫遊／黏著客戶端 | 於無線診斷紀錄 BSSID 變化 | Wi‑Fi 緩衝指南 |
| 僅 iPhone 熱點會掉 | CGNAT／電信計時器 | 比對掉線前後公開 IP | CGNAT 指南 |
| 坐定位後閒置 15–25 分鐘 shell 才死 | NAT 中間盒逾時 | 啟用 ServerAliveInterval 30 | 存活調校 |
表格的精神在於先決定量測窗口：同一小時內不要混用「走廊漫遊」與「隔夜閒置」兩種敘事；也不要拿單次 ping 平均冒充 SSH 互動體感。把 RSSI、BSSID 變化、以及 ServerAlive 開關的 A/B 寫成可重放步驟，工程與支援才能用同一份劇本收斂。
六步客戶端跑冊
- 打時間戳：用
pmset -g log節錄睡眠事件，對齊斷線。 - 擷取漫遊：按住 Option 點選選單列 Wi‑Fi 圖示，記 BSSID 差異。
- 套用：在主機區塊設定
ServerAliveInterval與TCPKeepAlive yes。 - 對照：選一小時重度漫遊時段，同時用 USB‑C 乙太重複連線——若穩定則 WLAN 政策優先。
- 升格：附上來自 路徑診斷 的 MTR 追踪給無線團隊。
- 再評區域：客戶端路徑清白後，才用 定價 資料挑區——不靠感覺。
電池模式、App Nap 與背景終端機分頁
使用電池時，macOS 可能為續航延後背景程序；未置前的終端機分頁會碰到計時合併，使你配置的 ServerAliveInterval 實際間隔被拉長。可在受控測試開啟「防止電腦自動進入睡眠」，或以 caffeinate -i ssh user@host 維持一小時對照。對 Terminal、iTerm2、Warp 於簡介視窗暫時停用 App Nap 有助蒐證——記得測後恢復，以免全組電池壽命崩跌。長時間對 ProxyMac mini 開發時，最佳組合仍是：長連線走有線接 CPE，Wi‑Fi 給瀏覽與會議；真的需要像素再走 VNC。
若同機同時進行 VoWiFi 或視訊，會與 SSH 爭奪空口——東京 RTT 看起來仍平穩時也可能如此。若必須漫游，交互 shell 可評估 Mosh；伺服器端仍以 tmux／screen 保住進程狀態，讓重連發生在你可控的節奏。
若於客戶端側錄 tcpdump，對照真正承載 Wi‑Fi 的介面與隧道介面：若 RST 主要由你自己的筆電送出，這通常是坦率且痛苦的提醒——修正點在本地，而非海底光纜。
給 ProxyMac 主機用的 SSH 設定片段
Host proxymac-*
HostName %h.your-domain.example
User automation
ServerAliveInterval 30
ServerAliveCountMax 6
TCPKeepAlive yes
常見問題
可以把 mini 移到離我較近的機房嗎？ 區域對應法遵與延遲策略——請先把筆電側講清楚，再以資料選 香港／日本／韓國／新加坡／美國。
iCloud 轉送會影響 SSH 嗎？ 只有你經過無關代理時才可能；請維持直連或在 企業 CONNECT 指南記錄清楚的 ProxyCommand。
漫游時 VNC 呢？ 螢幕共享同樣會吃到 TCP 重設——見 VNC 說明，路徑穩定前勿開「自適應畫質」實驗。
筆電穩了之後，為何仍選 Mac mini
待睡眠與漫游可控後，專用 Mac mini M4 提供可預期的自動化 CPU、平行建置可用的統一記憶體，以及無需 Linux 加想像 macOS 的原生 API。ProxyMac 在五區維運線上服務，讓你在資料落地前提下共用一套跑冊。請於 定價頁比對方案，將 說明中心 的 SSH 片段與本矩陣並列；需要 GUI 時再讀 VNC 文件。
