雲主機半夜掉線，我用三條命令先定性再動手：一次 ECS 排障筆記

凌晨兩點，手機彈出監控告警：個人項目所在的彈性雲服務器（ECS）對外服務中斷，瀏覽器只剩「連接超時」。那一刻最忌諱的，是憑感覺重啟——重啟可能掩蓋現場，也可能把一個本來可定位的問題變成「重啟後好了，但不知道為甚麼」。這篇筆記記錄我當晚的排障順序：先用三條命令定性，再按分層往下查，最後做三個取捨。

先定性的三條命令

第一，我先確認機器本身是否還活着，而不是先猜應用掛了。登入控制台看 ECS 狀態是「運行中」，CPU 沒有打滿，這排除了整機宕機和資源耗盡的第一嫌疑。

第二，我在雲主機內執行 systemctl status nginx，確認 Web 服務進程存在，但監聽端口的響應異常。進程在、端口不通，這個組合很關鍵：它把問題從「應用崩了」縮小到「服務或網絡路徑異常」。

第三，我用 curl -I http://127.0.0.1 從本機迴環地址訪問。如果本機都不通，問題大概率在服務自身或本機防火牆；如果本機通、外網不通，就要往安全組、網絡和域名方向查。當晚的結果是本機通、外網不通，於是排障方向立刻收窄。

按分層往下查，不跳步

我按「本機服務 → 本機防火牆 → 安全組 → 網絡與域名」四層走，每層只驗證一件事，驗證通過才往下一層：

1. 本機服務：確認進程、端口監聽和日誌最後幾行，排除配置剛改錯、端口被佔用。
2. 本機防火牆：檢查入方向規則是否放行了 80/443 端口，避免在安全組裏兜圈子。
3. 安全組：回到控制台核對綁定的是哪個安全組、入方向是否真的放行了來源地址。當晚的根因就在這裏：前一天調試時收緊了來源地址，測試用的地址段沒有覆蓋我當晚的出口地址，於是外網請求在安全組一層就被丟棄了。
4. 網絡與域名：確認公網 IP 沒有變、域名解析沒有指向舊地址。這一步當晚是正常的，所以沒有白白折騰 DNS。

找到根因後，修正只做一處：把安全組入方向的來源地址改回合理的範圍，重新從外網訪問，服務立即恢復。整個過程沒有重啟服務器，也沒有重啟應用，現場和日誌都保留下來了。

三個取捨，我當晚是這樣選的

第一，寧可慢一點，也不要同時改多處。一次只改安全組一處，恢復後才能確定哪個改動真正有效；同時改三處，就算恢復了，下次同類問題還是不知道從何查起。

第二，先恢復服務，再補監控。半夜的首要目標是讓服務回來，監控告警的細化和巡檢腳本可以留到白天做，而不是在故障當下邊修邊重構。

第三，不把來源地址直接放寬到全網。圖方便的「全部放行」當晚就能解決問題，卻會留下長期風險；正確做法是只放行真正需要的地址段，並把這次改動記下來。

事後補的三件小事

1. 在安全組的備註裏寫清楚每條規則的用途和負責人，半年後回看也不用猜。
2. 改安全組前先截圖或記錄原規則，改錯了可以一鍵對照還原。
3. 加一個「外網可達性」探測：每五分鐘從外部訪問一次首頁，失敗就告警，而不是等用戶反饋才知道。這個探測後來又幫我提前發現過一次域名解析異常。

結論

雲主機排障最值錢的不是命令本身，而是順序：先定性、再分層、一次只改一處。把這個順序寫成自己的檢查清單，下次半夜再收到告警，至少不會在慌亂中把現場重啟掉。