作者： SSH Connection refused 與 timed out 怎麼判斷？
「Connection refused」表示伺服器已回應但沒有 SSH 服務監聽；「Connection timed out」則代表沒有任何對象回應。了解應執行的測試，以及測試位置。
SSH 中「Connection refused」與「Connection timed out」的含義
SSH 連線遭拒與 SSH 連線逾時是相反的錯誤，因此其中一種錯誤的修正方法，通常無法解決另一種。遭拒表示封包已抵達伺服器，而伺服器的核心回應「此處沒有任何服務正在監聽」。逾時表示封包沒有抵達任何會回應的對象，因此用戶端等待後放棄。遭拒是伺服器上的服務問題。逾時則是伺服器前方的網路路徑問題。
請閱讀用戶端輸出的確切行，因為錯誤訊息的措辭本身就是完整的診斷線索。
ssh: connect to host 203.0.113.10 port 22: Connection refused
ssh: connect to host 203.0.113.10 port 22: Connection timed out時間也是第二個線索。遭拒會立即回傳，所需時間約等於一次往返的時間。逾時則會停留數秒才輸出，因為用戶端會持續重傳，直到放棄為止。macOS 對相同狀況會輸出 Operation timed out。如果你還不熟悉此通訊協定，SSH 的運作方式與 sshd 的功能 是本指南預設的背景知識。
「Connection refused」其實是好消息
拒絕連線代表 TCP（傳輸控制協定）重設。用戶端會將 SYN 封包傳送至 22 埠。封包穿過網際網路後抵達伺服器的網路堆疊，核心發現該埠沒有 socket 正在監聽，因此回覆 RST（重設）封包。SSH 用戶端會將這個 RST 轉換為 Connection refused。
這個返回的封包能證明許多事項。位址正確。主機已開機，且路由正常。路徑上的設備沒有靜默丟棄傳往該埠的流量，因為遠端主機確實回覆了封包。因此，剩下的可能原因都在伺服器本身。
sshd未執行，因為啟動失敗，或從未設定為啟用。sshd正在監聽其他埠，通常是強化安全設定後造成。sshd綁定至單一位址，例如ListenAddress 127.0.0.1，因此只有伺服器本身能連線。- 防火牆設定為 reject，而不是 drop，因此由防火牆代表主機傳送 RST。ufw 的
reject動作，以及以reject with tcp reset結尾的 nftables 規則，都會採用這種方式。
還有一種情況看起來相同，但實際上並不是：你輸入的位址屬於另一台正在運作的主機。該主機會回覆你的 SYN，但 22 埠沒有 SSH，因此禮貌地拒絕連線。確認位址後，再開始針對錯誤的伺服器排查。了解 Linux 上監聽中的埠實際代表什麼，能讓你更快理解本節內容。
如何修復 Connection refused
您無法透過 SSH 修復此問題，因為故障的正是 SSH。請開啟服務供應商的 Web console 或 serial console，從該處登入後，依序執行以下命令。
systemctl status ssh
sudo ss -tlnp
sudo sshd -T | grep -Ei '^(port|listenaddress|addressfamily)'systemctl status ssh 在 Ubuntu 和 Debian 上使用 unit name。在 RHEL 及其重建版本（例如 AlmaLinux）上，unit 是 sshd。ss -tlnp 會列出所有處於 listening 狀態的 TCP socket，以及擁有該 socket 的程序。這是實際狀態的依據：如果沒有任何列提到 sshd，就表示沒有程序正在 listening，無論設定檔宣告了什麼。sshd -T 會在合併所有 Include 檔案後，輸出實際生效的設定；如果有人忘記在 /etc/ssh/sshd_config.d/ 中設定 port，通常會在這裡看出來。
請仔細查看 address 欄位。0.0.0.0:22 表示主機上的所有 IPv4 位址。[::]:22 表示主機上的所有 IPv6 位址。127.0.0.1:22 表示僅限 loopback，因此所有遠端連線都會遭到拒絕，但本機的 ssh localhost 仍可正常運作。
如果沒有任何程序正在 listening，請啟動服務，並在服務無法啟動時查看錯誤訊息。
sudo sshd -t
sudo systemctl enable --now ssh
sudo journalctl -u ssh -n 50 --no-pagersshd -t 會解析設定檔，並輸出錯誤指令所在的檔案與行號，不會影響執行中的服務。每次重新啟動前都應先執行此命令，因為設定檔遭拒時，sshd 會在啟動時結束，下一次連線就會遭到拒絕。
Ubuntu 上的 socket activation 陷阱
Ubuntu 24.04 隨附 OpenSSH 的 systemd socket unit。啟用該 unit 時，systemd 會持有 listening port，並依每個連線啟動 sshd，因此在 sshd_config 中修改 Port 2222 不會產生任何作用，主機仍會在舊的 port 回應。編輯前，先確認目前使用哪種模式。
systemctl is-enabled ssh.socket
systemctl status ssh.socket如果 socket 已啟用，請在 socket unit 中設定 port，而不是在 sshd_config 中設定。
sudo systemctl edit ssh.socket[Socket]
ListenStream=
ListenStream=2222空白的 ListenStream= 行是必要的，因為 systemd 的清單設定會附加到現有設定。省略這一行時，伺服器會同時監聽兩個 port。使用 sudo systemctl daemon-reload 和 sudo systemctl restart ssh.socket 套用變更，然後以 sudo ss -tlnp 確認目前持有的是新 port。變更 port 是 強化 VPS 上 SSH 安全性 的正常步驟，也是最常導致使用者被鎖在伺服器外的步驟。
為何「Connection timed out」代表沒有任何回應
逾時表示沒有回應。用戶端傳送 SYN 後，在一兩分鐘內重試數次，卻始終沒有收到任何封包。這無法證明伺服器的任何狀態，因為從未收到伺服器傳回的資料。
DROP 規則正是會產生這種無聲丟棄的結果，而且丟棄是刻意的。拒絕連線會讓掃描者知道主機存在，因此 ufw 和各家雲端服務供應商的網路防火牆會丟棄不需要的封包，不傳回任何內容。你的逾時通常表示防火牆正在對你想開放的埠執行預期的防護行為。
- 位址錯誤：DNS 記錄仍指向你重建前的伺服器，或是拼字錯誤，導向沒有人使用的位址。
- 主機尚未運作：可能已關機，或正處於重新開機程序中。供應商因帳務問題暫停服務，從外部看起來也完全相同。
- 主機防火牆丟棄 port 22，最常見的原因是先執行了
ufw enable，當時尚未建立任何允許規則。 - 執行個體前方的供應商防火牆丟棄封包，作業系統完全收不到該封包。
- 你自己的網路封鎖對外連出的 port 22，辦公室與飯店網路很常見這種情況。
從連線的正確一側執行測試
這是最浪費時間的錯誤。無法從封包未抵達的主機內部診斷封包遭丟棄的原因。如果你能登入該主機來執行命令，就不會遇到這個問題。本節中的所有命令都在你自己的電腦上執行。
getent hosts vps.example.com
ssh -G vps.example.com | grep -Ei '^(hostname|port|user)'
ssh -vvv -o ConnectTimeout=10 user@vps.example.com
nc -vz -w 5 203.0.113.10 22getent hosts 顯示電腦實際使用的位址，可在數秒內找出過期的 DNS 記錄。ssh -G 會列出用戶端讀取 ~/.ssh/config 後套用的設定，因此可找出過時的 Host 區塊；該區塊可能在未顯示明顯錯誤的情況下改寫主機名稱、連接埠或使用者。ssh -vvv 顯示連線嘗試進行到哪個階段：若最後一行顯示正在連線至該位址，接著長時間沒有回應，表示發生逾時；若某一行顯示遠端 OpenSSH 版本，表示 TCP 已經連線成功，實際問題在驗證。在 Windows 上，PowerShell 中的 Test-NetConnection 203.0.113.10 -Port 22 可取代 nc。
測試連接埠，不要只測試主機。ping 失敗並不能證明任何事情，因為許多供應商會在網路邊界過濾 ICMP（internet control message protocol）。ping 成功也不能證明任何事情，因為它不會提供連接埠 22 的資訊。
接著變更任何命令都無法替你變更的單一變數：網路。改用手機熱點重新測試。如果透過熱點可以連線，但使用辦公桌上的網路不行，表示封鎖發生在你這一側的網際網路，或是你的辦公室位址已遭伺服器封鎖。
無法從伺服器查看的供應商防火牆
大多數 VPS 控制面板都提供網路防火牆，有時稱為 security group 或 cloud firewall。它在執行個體的上游運作，並維護獨立的規則清單。ufw status 在伺服器上無法查看這份清單，因此「但我已經允許 22 埠了」才會成為常見說法。在伺服器上修改任何規則前，先開啟控制面板並查看這份清單。
只要執行一個命令即可確認問題，但必須具備主控台存取權。先在伺服器上執行命令，再於命令執行期間從筆電嘗試連線。
sudo tcpdump -ni any tcp port 22如果用戶端嘗試連線時沒有任何封包出現，表示封包在抵達作業系統前就被丟棄。因此，問題出在供應商防火牆或通往主機的路由。如果 SYN 封包已抵達，但沒有回覆封包送出，表示封包是在本機被丟棄，問題屬於 ufw 或 nftables。這項單一測試可將逾時問題分成兩類，因此值得透過主控台進行檢查。
ufw 規則順序、IPv6，以及自行封鎖的 IP
ufw 的規則順序錯誤，是這裡最容易造成大量使用者無法連線的問題。sudo ufw enable 會立即套用預設的拒絕輸入流量政策。因此，如果尚未建立 SSH 規則，現有工作階段仍可依靠已建立的連線狀態維持，但所有新連線都會逾時。先允許連線，再啟用 ufw。
sudo ufw allow OpenSSH
sudo ufw status verboseOpenSSH 應用程式設定檔只涵蓋連接埠 22。如果計畫將 SSH 移至 2222，應使用 sudo ufw allow 2222/tcp 規則，並在變更連接埠之前加入，而不是之後才加入。更完整的規則集請參閱 VPS 的 ufw 防火牆基本設定；正確的操作順序則列於 新 VPS 啟用後前 10 分鐘應完成的事項。
IPv6 會產生看似異常的逾時。如果主機名稱具有 AAAA 記錄，客戶端會優先嘗試 IPv6。因此，當伺服器缺少 IPv6 規則時，連線會停滯，但直接使用 IPv4 嘗試即可成功。請手動分別測試兩者。
ssh -4 user@vps.example.com
ssh -6 user@vps.example.com如果 -4 可以連線，而 -6 不行，問題就在伺服器的 IPv6 規則。在 ufw 中為 IPv6 開放相同連接埠會逐步說明修正方式。
您也可能封鎖了自己。fail2ban 會監控驗證日誌，並針對反覆驗證失敗的位址加入防火牆規則。因此，錯誤的金鑰或背景中持續重試的指令碼，都可能使整個辦公室共用的位址無法連線。遭到丟棄的封鎖會呈現為逾時；遭到拒絕的封鎖則會回傳 No route to host。請從主控台執行：
sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 198.51.100.24將自己的位址加入 ignoreip，是 在 Ubuntu 24.04 上建立可正常運作的 fail2ban 設定的一部分。
拒絕或逾時以外的錯誤
No route to host 表示收到 ICMP unreachable 訊息。可能是本機沒有通往該網路的路由，也可能是路徑上的某個設備回覆了管理性拒絕；iptables 的 REJECT 規則就會傳送這類回覆。
Network is unreachable 表示由本機回覆。指定的 address family 完全沒有可用路由。當主機名稱只解析到 IPv6 位址，但連線僅支援 IPv4 時，通常會出現這個結果。
kex_exchange_identification: Connection closed by remote host 表示 TCP 已建立連線，但伺服器在 key exchange 完成前中斷連線。連接埠已開啟，sshd 也正在執行，因此請檢查伺服器負載、MaxStartups，或確認你連線期間是否遭到封鎖。
Permission denied (publickey) 表示已進入驗證階段，但驗證失敗。網路與防火牆均正常，因此本指南不適用。請改閱 修正 SSH 上的 Permission denied (publickey)。
如何重新取得存取權，以及如何避免再次被鎖在外面
所有正式的 VPS 主機商都會提供不依賴客體網路的主控台：可能是 serial console，或以瀏覽器為基礎的 VNC 畫面。這個主控台是本指南兩個分支的復原途徑，因為即使 sshd 已停止，或防火牆規則捨棄所有流量，它仍能運作。請在主機商面板中找到主控台，以 root 或一般使用者身分登入，然後執行上述檢查。如果從未設定 root 密碼，多數面板可以代為重設。
如果沒有主控台，替代方式是使用主機商的 rescue mode。它會啟動精簡的復原系統並掛載磁碟，因此你可以離線編輯 /etc/ssh/sshd_config 或刪除防火牆規則，然後重新開機。
養成兩個習慣即可避免下一次被鎖在外面。每次編輯 sshd 或防火牆時，都應保留第二個 SSH 工作階段，因為該工作階段會依靠已建立的連線狀態繼續運作，讓你測試新的連線。進行有風險的防火牆變更前，也應先設定自動復原。
sudo systemd-run --unit=ufw-rollback --on-active=10min /usr/sbin/ufw disable
sudo systemctl stop ufw-rollback.timer第一行會排程讓 ufw 在 10 分鐘後自動關閉。套用新規則後，開啟新的 SSH 工作階段確認規則正常，再執行第二行取消復原排程。如果因此把自己鎖在外面，等待 10 分鐘後防火牆就會自行停用。此時主機會持續處於未受防火牆過濾的狀態，直到你再次啟用 ufw，因此請只在你能直接操作鍵盤時使用，不要將其作為永久設定。
工作順序
- 讀取錯誤文字，並注意錯誤出現所需的時間。
- 出現「Refused」：前往主控台，檢查
sudo ss -tlnp是否有 listening socket、其連接埠，以及它繫結的位址。 - 發生逾時：從自己的電腦確認位址，接著在控制面板檢查供應商防火牆，最後檢查該主機上的主機防火牆。
- 都沒有出現這兩個字串：表示你已建立 TCP 連線，因此應將問題視為驗證或伺服器負載問題，而不是網路問題。
FAQ
為什麼 sshd 正在執行時，SSH 仍顯示「Connection refused」？
因為拒絕連線的是 socket，而不是服務本身；即使 sshd 正在執行，仍可能拒絕連線。開啟供應商主控台並執行 sudo ss -tlnp。監聽於 127.0.0.1:22 的 socket 只繫結至 loopback，因此會拒絕所有遠端用戶端。若 socket 使用其他埠，仍使用 22 的用戶端都會遭到拒絕。若使用 systemd socket activation，連接埠來自 ssh.socket，而不是 sshd_config，因此也要檢查 systemctl is-enabled ssh.socket。ufw 的 reject 規則也可能代替主機拒絕連線，因此在下結論前先查看 sudo ufw status verbose。
為什麼 ufw 已允許連接埠 22，SSH 仍會逾時？
因為逾時表示沒有收到回應，而 ufw 不是路徑上的唯一防火牆。大多數 VPS 控制面板會在 instance 前方執行網路防火牆，而該防火牆丟棄的封包不會到達作業系統。從主控台執行 sudo tcpdump -ni any tcp port 22，並在執行期間從筆記型電腦嘗試連線。完全沒有封包抵達，表示封包是在上游的控制面板中遭到丟棄。封包已抵達但沒有回應送出，表示封包是在本機的 ufw 或 nftables 中遭到丟棄。
ping 失敗是否表示我的 VPS 已離線？
不是。許多供應商會在網路邊界過濾 ICMP，因此正常提供網路流量的伺服器也可能忽略所有 ping。反過來說，ping 成功同樣無法充分證明服務正常，因為這不代表連接埠 22 已開放。請在自己的電腦上使用 nc -vz -w 5 203.0.113.10 22 測試該連接埠，或在 Windows 的 PowerShell 中使用 Test-NetConnection 203.0.113.10 -Port 22。
我變更了 SSH 連接埠，現在完全無法連線。出了什麼問題？
有兩種順序錯誤會造成這種情況。若防火牆從未加入新連接埠的規則，連往新連接埠的嘗試會逾時，而連往連接埠 22 則會遭到拒絕。因此，sudo ufw allow 2222/tcp 應在變更連接埠前執行，而不是之後。若主機使用 systemd socket activation 提供 SSH 服務，sshd_config 中的 Port 2222 會遭到忽略，systemd 會繼續保留舊連接埠；你可以使用 systemctl is-enabled ssh.socket 確認這點。透過供應商主控台復原，修正適用的問題，然後在 sudo ss -tlnp 顯示新的 socket 後，使用 ssh -p 2222 user@203.0.113.10 連線。