阿里雲帳號認證開通 阿裡雲 ECS 實例 SSH 提示 Connection refused/timeout 連線超時排查指南
先分清是 refused 還是 timeout
看到 SSH 連不上時，很多人第一反應是「伺服器壞了」，其實不一定。Connection refused 和 timeout 代表的問題層級不同，排查方向也完全不同。前者通常是你已經打到主機了，但目標埠沒有服務在聽，或被系統主動拒絕；後者則多半是網路鏈路被攔住了，封包根本沒有順利到達 sshd。
簡單說，refused 更像是「門口有人回你，這裡沒開門」，timeout 則像是「你一直敲門，但連門在哪裡都沒摸到」。如果一開始就把兩者混在一起，很容易把時間浪費在錯的方向。
在阿里雲 ECS 的場景裡，這兩類問題最常見的來源包括安全組未放行、系統防火牆限制、sshd 服務異常、埠號改動、來源 IP 被封、實例沒有公網入口，以及本地網路或跳板機路由問題。排查時要先確認自己是從哪裡連、連的是公網還是內網、使用的埠是不是 22，再一層層往下看。
先做最小化確認
不要一上來就改配置。先確認幾個最基本的事：你連的是不是正確的公網 IP，帳號是不是正確，SSH 埠是不是被改過，實例是否真的在運行。很多看似複雜的故障，最後只是把 IP 複製錯了，或者把端口號記成了舊值。
如果你手上有 ECS 控制台，先看實例狀態是否是「運行中」。再看網卡是否綁定了正確的彈性公網 IP，或者是否通過 NAT、負載均衡、堡壘機轉發。若你本來就該走內網，卻拿外網地址測試，結果就會被誤判成超時。
接著本地執行一條最直接的測試命令：ssh -p 22 root@你的IP。如果你不是 22 埠，就把埠號換成實際值。這一步的目的不是解決問題，而是拿到更準確的錯誤現象，因為錯誤訊息本身就是排查線索。
Connection refused 的重點排查
阿里雲帳號認證開通 Connection refused 大多說明 TCP 已經到了目標主機，但目標埠沒有對外提供服務。這類問題最常見的原因是 sshd 沒有啟動、監聽埠不是 22、只綁定在本地迴圈位址，或被本機防火牆直接拒絕。
檢查 sshd 是否正常
先到 ECS 控制台使用 VNC、串列連接或雲助手登入系統，然後查看 SSH 服務狀態。常見命令是：systemctl status sshd。如果服務沒有啟動，可以先嘗試：systemctl start sshd。如果啟動失敗，要立刻看日誌，而不是盲目重啟。
在 Linux 上，sshd 的配置檔通常在 /etc/ssh/sshd_config。你要特別留意這幾項：Port、ListenAddress、PermitRootLogin、PasswordAuthentication。如果把 Port 改了，外部連線也要同步改；如果 ListenAddress 只寫了 127.0.0.1，那遠端當然連不上。
如果你曾經做過安全加固，尤其要小心把 SSH 改到非標準埠之後，忘了同步更新安全組和防火牆。很多 refused 問題，表面看起來像連不進去，實際上是服務在另一個埠上正常工作。
檢查本機是否真的在監聽
用 ss -lntp | grep ssh 或 netstat -lntp | grep ssh 看看 sshd 是否在監聽對應埠。若根本沒有監聽，說明服務沒起來或配置有誤；若只監聽 127.0.0.1，表示外部流量進不來；若監聽的是非預期埠，就要確認你的連線命令是否同步修改。
這裡的判斷很重要：只要服務沒有在正確埠上監聽，安全組放得再開也沒用。反過來，如果服務監聽正常，但你仍收到 refused，則要進一步查看防火牆與訪問控制策略。
看系統日誌找啟動失敗原因
sshd 啟動失敗的原因通常很直接：配置語法錯誤、主機金鑰損壞、端口衝突、權限不正確。可以查看 journalctl -u sshd，或直接看 /var/log/auth.log、/var/log/secure。如果你最近改過配置，尤其要留意是否多打了一個空格、少了一個參數，導致 sshd 無法載入。
不少人修改 sshd_config 後沒有先做語法檢查就直接重啟，結果把自己鎖在外面。正確做法是先執行 sshd -t 驗證配置，確認沒有錯誤再重啟服務。這個動作很小，卻能少掉很多返工。
timeout 的重點排查
timeout 一般比 refused 更偏向網路層。它表示你的請求沒有在合理時間內收到回應，常見原因包括安全組沒有放行、公網路由不通、系統防火牆丟包、來源 IP 被封、埠被上游設備攔截，或者你其實連到的不是那台機器。
先看阿里雲安全組
阿里雲 ECS 最常見的第一道門檻就是安全組。只要安全組沒有放行對應埠與來源 IP，外部就會一直超時。檢查時要確認入方向規則是否存在，協議類型是否是 TCP，端口範圍是否正確，來源是否寫成你的辦公網段、家裡 IP 或 0.0.0.0/0。如果你用的是非標準埠，也要在安全組裡同步添加該埠。
很多人以為「我已經放行 22 埠了」，結果實際上放的是出方向規則，或只加了內網段，沒有加自己的來源地址。還有人用了臨時 IP 上網，結果安全組白名單只寫了舊地址，連線自然超時。
再看系統防火牆
即使安全組放行了，主機內部的防火牆也可能把流量擋住。常見的有 firewalld、iptables、ufw。你要確認對應埠已經允許進站，並且規則沒有被更高優先級的策略覆蓋。對 Linux 來說，安全組解決的是雲上邊界，防火牆解決的是主機自身；兩層都要通過，SSH 才能真正到達服務。
如果你不確定是否是防火牆問題，可以暫時在控制台用 VNC 進入後查看規則，再對照 SSH 埠是否開放。但不要把長期關閉防火牆當成解法，這只能用來定位問題，不能作為最終方案。
阿里雲帳號認證開通 檢查來源與路由
阿里雲帳號認證開通 超時不一定是伺服器端故障，也可能是你所在網路環境對 SSH 連線有限制。例如公司出口封鎖了 22 埠，校園網或公共網路攔截了部分對外連線，或者你所在地區到雲主機的某段路由不穩。這時可以換一個網路環境測試，例如手機熱點、另一條寬頻，或者通過跳板機、堡壘機嘗試連接。
如果換網路後立刻恢復正常，說明問題不在 ECS 本身，而在本地網路策略。這種情況下，與其反覆重裝服務，不如先把本地出口限制搞清楚。
把常見誤區一次講清楚
第一個誤區是只看安全組，不看主機。安全組開了不代表系統一定正常，sshd 停掉、埠改掉、主機防火牆拒絕，照樣連不上。
第二個誤區是只看 22 埠。很多人出於安全考量把 SSH 改到其他埠，結果控制台、文檔、終端命令三處不同步，最後自己都不知道應該連哪個埠。改埠可以降低掃描噪音，但一定要同步更新安全組、防火牆和連線工具。
第三個誤區是把超時當成密碼錯誤。密碼錯誤通常會在建立連線後直接報認證失敗，不會長時間卡住。若是超時，優先查網路層與安全策略，而不是反覆修改帳密。
第四個誤區是忽略來源 IP。很多企業環境會做 IP 白名單，外出辦公、切換網路、使用 VPN 後，出口地址可能變了。這時你明明輸入的是正確主機和正確密碼，卻因為來源不在白名單裡而一直超時。
建議的排查順序
實際處理時，最有效的方法不是靠直覺，而是按順序排：先確認實例運行與 IP 正確，再測試本地網路可達性，接著看安全組入方向規則，然後查看主機防火牆，最後檢查 sshd 服務與監聽埠。這條路徑從外到內，最容易迅速縮小範圍。
如果是 timeout，優先看安全組、路由和防火牆；如果是 refused，優先看 sshd、埠監聽和本機拒絕策略。這樣分流，效率最高。
推薦的檢查清單
1. ECS 實例是否為運行中狀態。
2. 連接的是正確的公網 IP 或內網 IP。
3. SSH 埠是否仍是 22，或是否已改成其他埠。
4. 安全組入方向是否放行對應埠與來源地址。
5. 主機防火牆是否允許該埠進站。
6. sshd 服務是否啟動，且確實在正確埠上監聽。
7. 本地網路或公司出口是否封鎖了 SSH。
8. 最近是否修改過 sshd_config、密鑰、白名單或路由規則。
如果已經連不進去，怎麼自救
當你已經無法透過 SSH 登入時，不要繼續在本地反覆重試。先改用阿里雲控制台的 VNC、遠程連接、雲助手、救援模式或快照回滾等手段進入系統。重點是拿到一個可操作入口，再去修復配置，而不是死磕原通道。
如果你懷疑是配置改壞了，可以直接在控制台修復 sshd_config，或把最近的變更回退。若是防火牆規則誤改，先臨時放通管理端口，再逐步收斂策略。若是密鑰或帳號問題，確認是否還保留至少一個可登入的管理帳號，避免把唯一入口也關掉。
對於重要生產實例，建議平時就保留至少兩種登入方式，例如密碼加密鑰雙方案、堡壘機接入、控制台救援通道、備份帳號與快照。這不是多餘，而是避免一次錯誤把整台機器鎖死。
把問題變成可預防的流程
SSH 連不上不是一個單點故障，而是「入口、網路、服務、權限」四層之間有一層出了問題。真正成熟的處理方式，不是每次出事才臨時排查，而是把常見配置固化成標準流程：改埠前先同步安全組，改防火牆前先保留遠程通道，修改 sshd 後先做語法檢查，調整白名單後先記錄來源 IP，正式變更前先在測試機驗證。
只要把排查思路理順，Connection refused 和 timeout 其實都不難。前者看服務是否真的在聽，後者看流量是否真的能到。從這兩個方向入手，通常都能很快找到答案。對 ECS 來說，最怕的不是故障本身，而是沒有順序地亂查。把層次拆開，問題就會清楚很多。
