AWS帳號開戶服務 AWS 雲伺服器連不上怎麼排查

第一章：先判斷「連不上」是哪一種

你按下連線，出現的錯誤訊息往往已經把線索藏在裡面。AWS 伺服器「連不上」常見有三大類：第一類是網路層完全不通（例如逾時、No route to host）；第二類是能到主機但服務端拒絕（例如 Connection refused）；第三類是通了但登入失敗（例如 SSH 錯誤、密碼/金鑰不對）。不同類型對應的排查方向完全不同，越早分清楚，越快收斂。

建議你先整理四個資訊：1）你連的是哪個地址（公網 IP、私有 IP、還是彈性 IP）；2）用的協定與埠號（SSH 22、RDP 3389、或應用自訂埠）；3）報錯內容是逾時還是拒絕還是登入失敗；4）你是在同一 VPC/同一辦公網路，還是跨網路連線。這些資訊會決定你要從安全群組、NACL、路由，還是從 OS 與憑證下手。

第二章：快速排除「實例本身」狀態

許多人一上來就查防火牆，卻忽略最基本的事：實例到底還在不在、跑的是不是你預期的系統、服務是否啟動。先做最省時間的檢查。

AWS帳號開戶服務 2.1 確認實例狀態與可用性

進入 EC2 主控台，打開你的實例頁面，確認狀態是 running，且檢查「系統狀態檢查」與「映像狀態檢查」。如果有失敗，可能是底層硬體、映像、或初始化問題。此時你就要先解決可用性，不要把時間耗在網路設定。

如果你看到系統檢查或映像檢查失敗，先記錄失敗原因碼。某些情況需要重啟或重新建立映像；也可能是磁碟、授權、或啟動腳本問題。網路排查再怎麼做，實例沒起來也連不上。

2.2 確認你連的埠是否正在被服務監聽

即使端口在安全群組放行，OS 內部的服務也必須在正確埠上監聽。若你尚能用其他方式登入（例如同一 VPC 內的跳板機、或你有 Session Manager），直接在主機上檢查：Linux 常用 ss -lntp 或 netstat -lntp；Windows 可用 PowerShell 檢查端口監聽與服務狀態。

若完全無法登入，仍可以用 AWS 的方式間接判斷。例如如果你開了 SSM（Session Manager），通常能繞過 SSH/RDP 連線直接進去查服務；如果沒開，再回到網路層與安全層的檢查流程。

第三章：先檢查連線路徑是否正確

很多「連不上」其實是你連錯位置：例如你以為連的是公網，實際上用的是私網 IP；或是你在公司網路，想直接打到私有子網，卻缺少 VPN/Direct Connect/跳板。

AWS帳號開戶服務 3.1 公網 IP、彈性 IP 與 DNS

確認你連的地址是不是實際對應到該實例。EC2 實例如果沒有綁定彈性 IP，重啟後公網 IP 可能改變。若你使用了自訂 DNS 或舊紀錄，可能已經指向錯誤的 IP。

排查做法很直接：在 EC2 實例頁面查看目前的公網 IPv4 或 DNS 名稱；如果你有彈性 IP，確認它正綁在這台實例上。任何連線問題，只要地址有偏差，後面都是白忙。

3.2 你所在的網路能不能到達目標

如果你是從家裡、公司、或雲端另一個 VPC 連入，請先確定是否具備路由或隧道。沒有 VPN/Peering/Transit Gateway 的私有 IP，從公網通常走不過去。

你可以用兩種方式驗證：一是從你端點看能否解析與連到目標（例如 ping 在很多環境會被封鎖，但逾時/拒絕仍能提供線索）；二是用 traceroute（或在 Linux/macOS 上使用 traceroute、Windows 用 tracert）觀察在第幾跳停止。停止點常能對應到路由或防火牆的位置。

第四章：安全群組（Security Group）是最常見的關鍵

AWS 安全群組是有狀態（stateful）的。只要你對應的入站規則允許，回包通常也會自動放行。反之，即使你在 OS 上開放端口，只要安全群組沒放行，也一樣連不上。

4.1 檢查入站規則（Inbound）是否包含正確埠與來源

打開該實例所在的安全群組，檢查 Inbound。你要核對三件事：協定（TCP/UDP）、埠號（例如 22 或 3389）、以及來源（來源 IP/網段或其他安全群組）。很多人把來源寫成 0.0.0.0/0，或寫錯網段，結果要嘛暴露風險，要嘛自己封死自己。

來源如果需要限制，就用你實際會連線的固定出口 IP 或公司網段。若你使用 VPN 或公司固定網關，記得確認你出站 IP 是否穩定。

4.2 確認安全群組是否掛在「正確的網路介面」

實例可能有多個網路介面（ENI），而你連的是哪個介面決定了要看哪個安全群組。排查時務必回到網路介面清單，確認主入口（例如 eth0 對應的 ENI）上的安全群組。

4.3 出站規則（Outbound）通常較不會阻斷入站連線

AWS帳號開戶服務 安全群組的 Outbound 是有狀態允許回包，但如果你用的是代理、反向連線或特定狀態邏輯，仍可能出現問題。通常連線本身的失敗主要是 Inbound，但你仍可檢查 Outbound 是否過度限制（例如只允許到特定網段，而你要連的目標在外部）。

第五章：網路 ACL（NACL）與子網配置是否也有影響

與安全群組不同，NACL 是無狀態（stateless）。它同時有入站與出站規則，且規則需要同時符合才會通。NACL 常被忽略，但它在某些情況會讓你「明明安全群組放行卻仍連不上」。

5.1 檢查子網的 NACL 是否有放行對應埠

找到實例所在子網（subnet），打開 NACL。你需要確認：入站規則是否允許來自你來源 IP 的流量、埠號是否符合、以及允許範圍是否被更後面的規則覆蓋（NACL 規則會依序匹配）。同時，出站規則也要允許回包路徑。

特別注意：有些 NACL 是按短時間策略或分層網段配置，當你來源 IP 稍微變動就會被拒絕。

5.2 規則順序與「預設拒絕」

NACL 通常最後會有「deny all」之類的預設拒絕。你需要確認沒有更上層規則以 deny 結束匹配。因為是無狀態，你就算入站允許，回程也可能在出站被擋下。

第六章：路由表（Route Table）與網關設定

如果你從外網打到公網 IP，路由表通常不會是唯一主因；但如果你是在 VPC 內部、或你是跨網段連線，路由就會決定你流量能否走到目標。對「無法連上」的排查，路由應該在你確認安全群組後立即看。

6.1 公網連線要看 Internet Gateway 與路由

公網連線的基本條件是：子網的路由表要有指向 Internet Gateway（IGW）的路由，且目標地址是外部網段時（通常是 0.0.0.0/0）。若 IGW 沒掛或路由沒配，外網就進不來。

同時也要檢查：如果你是負責連入的端點在另一個網段，可能還需要中轉或 NAT 結構。NAT 主要解決出站，不解決入站；因此不要把 NAT 當成「外網進來」的條件。

6.2 私網連線要看 VPC Peering / Transit Gateway / VPN

若你連的是私有 IP，你的來源網路要能在 AWS 內形成可達路徑。VPC Peering 需要雙方路由都正確；Transit Gateway 或 VPN/Direct Connect 需要對應的路由宣告與路由表。若你只做了一半，你就會看到逾時。

AWS帳號開戶服務 這類情況你要回到你所屬的連線架構文件：你到底用哪種跨網連線方式？然後在路由表中逐一確認目標 CIDR 是否被正確對應到下一跳。

第七章：OS 層級防火牆、服務與綁定地址

當網路層都過了，連線仍失敗，通常就是 OS 或應用層問題。最常見是防火牆規則沒有放行、服務沒有啟動、或服務只綁定在本機介面。

7.1 Linux：確認防火牆（iptables、nftables、ufw）與服務

Linux 常見狀況：你已開通安全群組，但本機仍用 ufw/iptables 限制入站；或者服務只監聽在 127.0.0.1，外部連線會被拒。你需要用對應指令檢查：服務狀態（systemctl）、監聽（ss/netstat），以及防火牆規則。

AWS帳號開戶服務 如果你用的是自動化映像或硬化基線，請特別注意安全強化策略可能會在你部署後更新規則，導致你以為「一直都能連」但其實變了。

7.2 Windows：Windows 防火牆與 RDP 設定

在 Windows 上，RDP 是否啟用、NLA（Network Level Authentication）政策、以及 Windows Defender Firewall 的入站規則都要確認。即便安全群組允許，Windows 防火牆依然可能拒絕。你也要確認 RDP 服務（TermService）在運行。

若你連線的是自訂埠（例如用遠端工具改了端口），那你要對應檢查該工具的服務設定與監聽端口。

7.3 服務綁定在錯誤的介面

有些程式預設只綁定到 localhost。你看到它「在跑」，但外部連線就是不行。排查時你需要看服務綁定的地址是 0.0.0.0 還是 127.0.0.1，並按需要調整服務配置。

第八章：登入失敗的排查（SSH/RDP/金鑰與帳號）

如果你的狀況是「連上了，但不能登入」，那通常不是網路問題，而是憑證、帳號、或授權策略問題。此時你要分成 SSH 與 RDP 兩條線。

8.1 SSH：金鑰、使用者、權限與 known_hosts

SSH 常見錯誤包含：permission denied（金鑰不對或使用者沒權限）、no supported authentication methods（客戶端未提供正確方式）、以及 timeouts（這通常回到網路層）。對「permission denied」，你要先核對：你使用的 key pair 是否正確、你登入的使用者名稱是否正確（不同 AMI 可能是 ec2-user、ubuntu、admin 等）、以及私鑰權限是否符合要求（例如 600）。

同時也檢查目標帳號的 ~/.ssh/authorized_keys 是否存在、金鑰是否有寫入、以及檔案權限是否正確。很多時候金鑰其實放對了，但權限太寬或所有者不對導致 SSH 忽略它。

若你更換了實例或重新配置，客戶端的 known_hosts 也可能因為主機金鑰變更而報警。這通常不是嚴重問題，但要判斷是否遭到中間人攻擊或單純重建。

AWS帳號開戶服務 8.2 RDP：帳號狀態、NLA 與憑證策略

RDP 登入失敗常見是帳號鎖定、密碼錯誤或帳號未啟用。若你啟用了 NLA，憑證相關設定也會影響連線。你可透過 AWS 的系統管理工具（如 SSM）或附加磁碟方式檢查帳號狀態。

如果你忘了密碼，且沒有 SSM/跳板可進去重設，恢復流程會更麻煩。建議你在一開始就建立可控的管理路徑（例如啟用 SSM），降低「忘記密碼導致整機不可用」的風險。

第九章：使用 AWS 原生診斷工具加速定位

AWS 不只提供基本設定，還有一些可以幫你「看到發生什麼事」的工具。當你卡住時，用它們能大幅減少猜測。

9.1 EC2 Instance Connect / SSM Session Manager

如果你在部署前就啟用 SSM（Session Manager），你可以直接連到主機查設定，而不必依賴 SSH/RDP。這對排查「連不上但你需要進去看」特別有效。

如果你有 Instance Connect（針對 Linux），也能在一定條件下快速注入臨時金鑰並登入。前提是網路路徑和 IAM 角色配置都要正確。

9.2 VPC Reachability Analyzer

Reachability Analyzer 可以用來分析「從某個來源到目標」是否可達，並指出哪一層阻擋（例如安全群組、NACL、路由）。它對大型環境很有價值，因為你不用逐條人工比對規則。

使用方式概念上是：選擇來源（例如某個 IP 或其他資源）、目標（主機或網路介面）、以及測試的協定與埠。分析結果會告訴你是哪個條件不滿足。

9.3 CloudWatch 與系統日誌

若你能透過 SSM 進去看日誌，優先查與服務啟動相關的內容（例如 SSHD 日誌、Windows 事件檢視器、應用服務 log）。若你看不到任何服務啟動，也可能是開機後初始化失敗或配置錯誤。

如果你沒有日誌，也別只想「怎麼連回去」。你要先想「為什麼沒有啟動」：IAM 權限不足、掛載磁碟失敗、使用者資料（User Data）腳本錯誤、憑證或密鑰未正確配置，這些都會讓服務不存在，導致你以為是網路問題。

第十章：用一個可重複的排查流程落地

到這裡你可能發現，排查不是隨機點選，而是有順序的。下面給你一套你可以反覆使用的流程，讓每次都能更快定位。

10.1 第一步：確認你連的地址、埠與錯誤類型

記錄你連的 IP（公網/私網/彈性 IP）、連的協定與埠、錯誤是逾時、拒絕還是登入失敗。這一步決定你要走「網路不可達」還是「服務不可用」還是「憑證錯誤」。

10.2 第二步：檢查實例狀態檢查與服務監聽（能進去才做）

查看 EC2 狀態檢查是否失敗；若能進入主機，檢查服務是否啟動、是否監聽在正確介面與埠。若完全不能進入，回到第三步先做網路層。

10.3 第三步：安全群組入站規則（TCP/UDP + 端口 + 來源）

確認 Inbound 放行的埠、協定、來源是否精準匹配你實際來源 IP/網段。確認規則掛在正確的 ENI 上。

10.4 第四步：NACL 入站/出站都要匹配，且注意規則順序

檢查該子網 NACL 是否允許來源到目標端口，以及回程出站是否允許。若有 deny 規則可能在前面匹配到。

10.5 第五步：路由表與網關（IGW / Peering / TGW / VPN）

確認子網路由是否有正確的下一跳；公網連入要看 IGW 與 0.0.0.0/0；私網連入要看跨網路是否具備可達路徑。

10.6 第六步：OS 防火牆、服務綁定與帳號金鑰

如果網路已通但仍連線失敗或登入失敗，檢查 OS 防火牆與服務設定。若是 SSH/RDP，核對使用者、金鑰、檔案權限與服務是否允許遠端驗證。

第十一章：常見陷阱清單（你可以直接對照）

下面列一些在實務中非常常見、但也最容易在排查時浪費時間的點。你遇到時可以快速跳到對應段落處理。

11.1 連錯 IP：重啟後公網 IP 改了

沒有彈性 IP 的實例，重啟後公網 IP 可能變更。你以為規則沒問題，但其實連到另一台不存在的地址或錯誤的機器。

11.2 安全群組放行了端口，但來源 IP 不匹配

你以為自己在同一網段，結果公司 VPN 出站 IP 變了；或你從手機熱點連入，來源 IP 完全不同。安全群組來源寫死就會直接拒絕。

11.3 NACL 未放行出站（因為它是無狀態）

AWS帳號開戶服務 入站看起來有放行，但回程出站被擋住，導致連線逾時。

11.4 服務只綁定在 localhost

應用「看起來在跑」，但外部連線不會成功。解法是調整綁定介面或配置對外監聽。

11.5 OS 防火牆還在，或金鑰/帳號不對

網路已通，卻仍拒絕或 permission denied。優先確認 OS 防火牆與登入憑證。

第十二章：如何預防下次也連不上

連線排查最痛的不是當下花時間，而是「以後還會遇到」。你可以用一些預防措施，讓未來更容易恢復。

12.1 啟用 SSM，讓管理不依賴 SSH/RDP

只要你在 IAM 與網路條件都正確，SSM 能成為救命通道。即使安全群組端口被誤改，也能用 Session Manager 進去檢查服務與日誌。

12.2 建立可測試的連線規範

例如在部署時就規定：SSH 只允許特定管理網段；並且把管理來源 IP 固定或使用 VPN 出口固定。規則寫得越可預期，排查越省時間。

12.3 將網路與安全設定文件化

你至少要能回答：這台機器走公網還是私網？需要 IGW 還是 Peering/TGW？安全群組與 NACL 誰負責？有沒有跳板或 SSM？當你把依賴關係記清楚，未來故障就不會像在黑暗中摸索。

結語：用順序破局，比猜測更快

AWS 雲伺服器連不上，最常見的差錯不是技術難，而是排查順序不對。把流程固定下來：先確認實例狀態與你連的地址，再判斷錯誤類型；接著從安全群組、NACL、路由表逐層驗證；最後才進到 OS 與登入憑證。當你每次都沿著同樣的路走，你就不會被「看起來像網路但其實是金鑰」或「安全群組沒問題但 NACL 擋回包」這類問題反覆拖慢。

下次你再遇到連不上，先停一下，把四個資訊（地址、埠、錯誤類型、來源網路）記下來，然後照這份流程走。大多數故障都會在前半段被定位，剩下的也能快速收斂到服務與憑證層。你會發現，連不上不再是運氣，而是可被拆解的機械問題。