SSH 連不上，幾乎每個用過 VPS 的人都遇過。它很少是單一原因，而是卡在四層中的某一層：本機網路、雲端安全組、伺服器內部防火牆，以及 SSH 服務與認證設定。
先給結論：若錯誤是 Connection timed out，多數情況是安全組沒放行、IP 或埠號填錯；Connection refused 多半是 sshd 沒啟動或埠沒在監聽；Permission denied 幾乎都與金鑰或目錄權限有關。依照「由外到內」的順序排查，多數人能在 10 分鐘內把問題範圍縮小到具體一層，而不是反覆重裝系統。
本文是一份可照著操作的排查流程：先教你看懂錯誤訊息，再依出現機率由高到低拆成 7 個步驟，每一步都附上可直接複製的指令；最後補上進階排查、預防措施，以及什麼情況下應該直接聯繫客服。文中指令輸出為示範格式，IP 採用文件專用保留位址（RFC 5737 的 192.0.2.0/24、198.51.100.0/24、203.0.113.0/24），實際數值請以你的環境為準。
先讀懂錯誤訊息：三種「連不上」的差別
同樣是「連不上」，錯誤訊息不同，問題的層級完全不同。先讀懂訊息，可以直接跳過一半的排查步驟。
終端機常見的回應大致分三類：完全沒有回應（timed out）、被明確拒絕（refused）、以及連上了但認證失敗（permission denied）。前者屬網路與攔截層，中者屬服務與埠層，後者屬認證與權限層。
| 終端機回應 | 代表的意思 | 第一件事先做什麼 |
|---|---|---|
| Connection timed out | 封包沒有任何回應，被攔截或路由不通 | 確認 IP／埠號，再檢查雲端安全組 |
| Connection refused | 主機有回應，但該埠沒有服務在聽 | 檢查 sshd 是否運行、是否監聽正確埠號 |
| Permission denied | 連線成功，但認證沒有通過 | 檢查金鑰內容、使用者名稱與目錄權限 |
快速排查清單：先看這 5 件事
如果你只想用最短時間恢復連線，先按這個順序檢查，這是最常出問題的五個位置：
- 目標資訊是否正確：IP、埠號、使用者名稱是否與控制台顯示一致。重建實例或搬遷機房後，IP 可能已經變更。
- 雲端安全組是否放行 SSH 埠：這是最常見的攔截點，尤其是你曾經改過 SSH 埠號卻忘了同步規則。
- 系統防火牆是否放行：安全組放行了，但伺服器內的 ufw／firewalld／iptables 沒放行，一樣會逾時。
- sshd 服務是否運行並監聽：服務沒啟動、或監聽的埠與你連線的埠不一致，會得到 refused。
- 金鑰與權限是否正確：
~/.ssh權限過寬會被 sshd 直接拒絕，即使金鑰本身沒有問題。
7 步排查：由外到內逐一排除
下面的順序刻意「由外到內」——先確認最外層的網路與雲端規則，再進到伺服器內部。這樣做的好處是：每一步都能把問題範圍砍掉一半，避免一開始就鑽進 sshd 設定檔裡繞圈。
步驟 1：確認 IP、埠號與帳號是否正確
這一步最容易被跳過，卻是最常見的原因之一。請打開控制台，逐字比對實例的 IP、SSH 埠號與預設使用者名稱。若你使用的是網域名稱，先確認解析結果指向正確的 IP：
ping -c 4 203.0.113.10
nslookup vps.example.com步驟 2：用 ping 與 traceroute 判斷網路層是否通
有回應，代表網路層可達，問題往下走到埠與服務；完全沒有回應，則先看路由與線路，再回頭檢查本機網路。
ping -c 4 203.0.113.10
traceroute -n 203.0.113.10
步驟 3：檢查雲端安全組是否放行 SSH 埠
登入雲端控制台，確認實例所屬安全組的入方向（Inbound）規則中，TCP 的 SSH 埠（預設 22）允許你的來源 IP。若你曾把 SSH 改到其他埠（例如 2222），規則也要一併更新。建議把來源限制在你的固定 IP 或公司網段，而不是對全網開放。
步驟 4：檢查系統防火牆與埠連通性
雲端安全組與系統防火牆是兩道彼此獨立的閘門，必須兩邊都放行。以下指令分別對應「從外部測試埠」與「查看本機防火牆規則」：
nc -vz 203.0.113.10 22
sudo ufw status
sudo firewall-cmd --list-ports
sudo iptables -L -n
步驟 5：檢查 sshd 服務是否運行、是否監聽
若前面都正常，卻得到 Connection refused，問題就在服務本身：
systemctl status ssh --no-pager
sudo ss -tlnp | grep ssh
sudo systemctl restart ssh請注意服務名稱在不同系統上可能不同：Ubuntu／Debian 為 ssh，部分 RHEL 系發行版為 sshd。若 ss -tlnp 顯示監聽的是 2222 而非 22，那你的連線指令也要跟著改。
步驟 6：檢查金鑰、權限與認證設定
Permission denied (publickey) 幾乎都出在權限或金鑰內容。sshd 對權限相當嚴格：只要家目錄或 ~/.ssh 開放給群組或其他人寫入，就會直接拒絕登入。
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh
sudo sshd -t # 測試設定語法後再重啟另外請確認三件事：使用者名稱正確（例如 Ubuntu 映像常是 ubuntu 而非 root）、authorized_keys 內是完整的單行公鑰、以及 sshd 設定中 PubkeyAuthentication 為 yes。需要更細節的線索時，用詳細模式連線：
ssh -vvv deploy@203.0.113.10步驟 7：檢查系統資源與登入日誌
還有一種情況是「連上了又被切斷」，這通常與資源或封鎖有關。記憶體不足導致程序被 OOM 終止、磁碟寫滿、或來源 IP 被 fail2ban 暫時封鎖，都會出現類似症狀：
sudo journalctl -u ssh -n 50 --no-pager
sudo fail2ban-client status sshd
free -m
df -h
進階排查：老手常忽略的細節
用 -vvv 逐行讀連線過程
ssh -vvv 會印出金鑰協商、認證方法與伺服器回應的完整過程。多數卡點會停在「Offering public key」或「Authentications that can continue」這幾行，從那裡往回推就能確定是金鑰不被接受，還是使用者名稱不對。
換一個網路來源測試
用行動網路熱點或另一台主機再連一次。如果換了來源就正常，問題多半在原本的來源 IP（被防火牆或防護機制限縮）或該條線路，而不是伺服器本身。
能連上但連線很快卡住
若握手成功卻在登入後卡住，可留意 MTU／MSS 與路徑上的封包分片問題，也可檢查伺服器是否載入過高、磁碟是否處於 I/O 等待。這類狀況通常需要搭配系統監控一起判讀。
主機金鑰變更的提醒
重建實例或更換系統後，可能出現 Host key verification failed。這是安全機制在提醒你「主機指紋變了」，請先確認變更是你自己造成的，再清除 ~/.ssh/known_hosts 中的舊記錄，不要習慣性地跳過警告。
線路與晚高峰的影響
若你的伺服器在海外節點、而你從中國大陸連線，晚間高峰時段出現延遲升高或連線中斷，往往與跨境路由品質有關，而非伺服器故障。這類情況可先看線路與路由資料，再判斷是否需要調整節點或改用對大陸優化的線路。
如何避免下次再被鎖在門外
排查完只是救火，真正省時間的是事前準備。以下幾件事建議在部署當天就做完：
- 保留一組備援登入方式：例如第二組金鑰或另一個管理帳號，並熟悉控制台提供的 VNC／救援模式，避免改設定時把自己鎖在門外。
- 改動 SSH 埠要同步兩處規則：sshd 設定、雲端安全組與系統防火牆必須一致。
- 改用金鑰登入並關閉密碼登入：可大幅降低被暴力嘗試的機率，必要時再搭配 fail2ban 與來源 IP 白名單。
- 備份關鍵設定：
/etc/ssh/sshd_config與授權金鑰建議納入定期備份，重建時能省下大量時間。 - 監控磁碟與記憶體：避免因資源耗盡導致服務中斷，讓「連不上」變成常態。
相關的系統維護與安全設定，可延伸閱讀本站的 VPS 安全防護與備份完整教學 2026 與 VPS 長期運行維護經驗。
什麼情況該聯繫 LuckVM 客服
如果以下情況成立，建議直接提交工單或透過即時客服聯繫，會比自己摸索更快：
- 控制台顯示實例「運行中」，但 ping 完全沒有回應，且更換網路來源後依然如此。
- 安全組與系統防火牆都已確認放行，仍然得到
Connection refused，且服務狀態異常無法啟動。 - 需要重裝系統、進入救援模式，或需要核對實例所在節點與線路狀態。
- 懷疑是機房或上游線路層面的問題，而非你自身設定。
提交時請一併附上：實例 ID、來源 IP、完整的錯誤訊息、問題發生的時間點，以及 traceroute 的逐跳結果。這些資訊能讓技術人員在第一次回覆就縮小範圍。可透過 支援中心、Line 或 Telegram 客服聯繫我們。
常見問題
SSH 連不上，但 ping 得通，問題出在哪裡？
ping 通代表網路層可達，問題通常不在線路，而在埠與服務層：雲端安全組沒有放行 SSH 埠、系統防火牆擋住、sshd 服務沒有運行，或你連到了錯誤的埠號與使用者名稱。請依序檢查安全組、ufw／firewalld，以及 ss -tlnp 的監聽狀態。
Connection refused 和 Connection timed out 有什麼差別？
Connection refused 表示連線已被目標主機回應但遭到拒絕，多半是 sshd 沒有啟動、埠未被監聽，或連到了沒有服務的埠號；Connection timed out 表示封包沒有得到任何回應，通常是被安全組或防火牆攔截、IP／埠號填錯，或路由不通。
改了 SSH 埠號之後就連不上，該怎麼處理？
改埠後必須同時更新兩處規則：雲端控制台安全組的入方向規則，以及伺服器上的系統防火牆（ufw／firewalld／iptables）。若只改了 sshd_config 而沒有放行新埠，就會直接逾時。改設定前建議先確認仍有一組可用的登入方式。
金鑰明明正確，為什麼還是 Permission denied (publickey)？
最常見的原因是權限設定過寬或使用者名稱不符。請確認 ~/.ssh 為 700、authorized_keys 為 600、家目錄不開放群組或其他人寫入，並確認 authorized_keys 內是完整的公鑰單行內容、登入的使用者名稱與金鑰所屬使用者一致。
會不會是我的 IP 被伺服器封鎖了？
有可能。若日誌中出現大量 Failed password，fail2ban 之類的工具可能已把你暫時封鎖；部分雲端平台的基本 DDoS 防護也會在異常流量時限縮來源。可檢查 fail2ban-client status sshd，或改用另一組網路（例如手機熱點）測試，以確認是否為來源 IP 被攔。
本文由 LuckVM 技術團隊整理，指令與判讀方式以 Ubuntu 24.04／Debian 12 搭配 OpenSSH 9.x 為參考環境；不同發行版、面板或安全模組的實際輸出名稱可能略有差異。
