AWS帳號代開 AWS EC2 實例狀態檢查通過但 Ping 不通？路由表與安全組深度排查
先確認：狀態檢查通過，代表什麼，不代表什麼
很多人看到 EC2 的系統狀態檢查與實例狀態檢查都顯示通過，就以為主機一定正常。其實這只代表 AWS 觀察到的基礎健康度沒有異常，像是宿主機、虛擬化層、作業系統啟動等沒有明顯問題，並不等於外部一定能連得上。Ping 不通，最常見的情況就是網路路徑被某一層擋住了，而這一層往往不在狀態檢查的範圍內。
換句話說，狀態檢查是健康燈號，不是通路證明。它告訴你這台機器大致活著，但不保證封包能順利進來，也不保證回包能順利出去。當你面對的是 Ping 不通，思路不能停在主機是否開機，而要往外看整條路徑：來源是否正確、路由是否送對方向、安全組是否放行、網路 ACL 是否攔截、系統防火牆是否封鎖，最後再確認是否其實連的是私有位址，卻期待它像公網主機一樣回應。
第一輪排查：先確認你到底在 Ping 什麼
排查 Ping 問題時，第一步不是改規則，而是先把目標講清楚。你是從公司電腦、家裡網路，還是另一台 EC2 去 Ping？你 Ping 的是公有 IP、彈性 IP，還是私有 IP？這三種情境的答案完全不同。最容易出錯的地方，就是把私有子網裡的實例，當成互聯網主機去測試。
如果你從外網 Ping 公有 IP，前提是這台 EC2 必須真的有公有地址，且所屬子網的路由表已經把預設路由送到 Internet Gateway。若只有私有 IP，就算安全組全開，外部也根本沒有路徑走進來。反過來，如果你是在同一個 VPC 內 Ping 私有 IP，則不需要經過 Internet Gateway，但仍要看路由表、安全組與 NACL 是否允許同網段封包通過。
- 從外部 Ping 公有 IP：先看公有 IP、路由表、IGW、安全組。
- 從 VPC 內部 Ping 私有 IP：先看 VPC 路由、本地規則、安全組、NACL。
- 從 EC2 自己 Ping 自己：通常測不到外部網路問題，參考價值有限。
第二輪排查：路由表是不是把封包送對地方
路由表是很多人第一個忽略、卻最常出問題的地方。安全組放行，只代表門開了；路由表正確，才代表門外真的有路可以走。若子網沒有綁對路由表，或預設路由沒有指向正確的出口，Ping 再怎麼調也沒用。最典型的錯誤，是把本來應該是公有子網的 EC2 放進了沒有預設路由的私有子網。
公有子網與私有子網的差別
公有子網通常會有一條 0.0.0.0/0 指向 Internet Gateway 的路由，這意味著去往公網的封包有出口。私有子網則通常沒有直接到 IGW 的路由，而是透過 NAT Gateway 做出站上網，或者完全不具備對外入口。這裡要特別注意，NAT Gateway 只適合讓私有實例主動發起連線，並不會讓外部直接 Ping 到私有實例。
所以，如果你要讓外部 Ping 到 EC2，這台實例必須位於有 IGW 預設路由的子網，並且已經分配公有 IP 或彈性 IP。只要其中一個條件缺失，外網就不可能直接到達。很多人只檢查安全組，卻忽略子網到底屬於哪一種，最後花半天時間找不到原因，其實問題就在路由表。
最常見的三種路由錯誤
- 0.0.0.0/0 沒有指向 Internet Gateway，導致公網無法進入。
- 實例放在私有子網，卻誤以為它可以像公有主機一樣被 Ping。
- 路由表綁錯子網，配置看起來正確，實際上沒有套用到該實例所在子網。
排查路由時，不要只看路由表內容，還要確認子網是否真的關聯到那張表。AWS 介面上最容易出現的錯覺，就是你修改了某張路由表，卻忘了那不是實例實際使用的那張。結果表面上所有規則都對，實際流量卻根本沒走那條路。
第三輪排查：安全組不能只看入站，出站也要一起看
安全組是狀態式的，這點很重要。很多人以為 Ping 不通一定是入站規則沒開，其實不一定。對外部主機來說，Ping 是先送出 ICMP Echo Request，EC2 收到後回 ICMP Echo Reply。安全組如果只放行了入站，卻把出站收得很緊，回包一樣出不去，最終表現仍然是 Ping 失敗。
另一個常見誤解，是以為允許所有流量就一定沒問題。實務上，安全組裡即便寫了看似寬鬆的規則，也要確認方向是否正確、來源是否正確、套用的安全組是否真的掛在該實例上。有時候你改了新建的安全組，卻沒有把它附加到實例，舊規則仍在生效，這種錯誤很隱蔽。
ICMP 要放行哪一種
Ping 用的是 ICMP，不是 TCP，也不是 UDP。若要讓外部 Ping 進來，入站規則至少要允許 ICMP Echo Request。若是從 AWS 介面設定，通常可以直接放行 ICMP，來源可先暫時測試用 0.0.0.0/0，確認通路後再收斂到特定來源。對內部測試而言，可以只放特定 CIDR 或特定安全組，避免開得太大。
但請記住，安全組是有狀態的，回包通常會自動放行，因此在多數情況下，不需要另外為 ICMP Echo Reply 寫對應規則。真正要小心的，是出站規則被嚴格限制時，連回包都可能出不去。若你做的是高安全性環境，建議直接檢查目前的出站預設值，不要想當然地認為它一定是全開。
AWS帳號代開 回包能不能出去同樣重要
如果你從外部 Ping EC2，封包流程其實是兩段：先進來，再回去。入站開了只代表第一段有機會成功，第二段若被擋，外部工具看到的結果仍然是超時。這也是為什麼很多人改完入站規則後，還是覺得沒效，最後才發現出站規則被鎖住了。尤其在複雜環境中，安全組不一定保留預設的全部放行，這時就必須逐條核對。
如果是 EC2 主動向外 Ping 外部地址，出站規則更關鍵。你需要確認安全組允許 ICMP 出站，並且路由表能把流量送到正確出口。沒有路由，再寬的出站規則也是空談；有路由，沒有出站規則，封包仍然卡在本機。這兩者一定要一起看。
第四輪排查：網路 ACL 與作業系統防火牆
很多人只盯著安全組，卻忘了子網上還有一層網路 ACL。NACL 是無狀態的，意思是入站與出站都要各自放行，不能期待它像安全組一樣自動記住連線。對 Ping 來說，至少要允許 ICMP 相關流量雙向通過；若你做更複雜的測試，還要注意其他協定的配套規則。
NACL 還有一個特點，就是規則有順序，數字越小優先級越高。這代表你不能只看有沒有一條允許規則，還要看前面是否已經有拒絕規則先把它攔掉。很多環境在做安全加固時，會先放一條較寬的拒絕，再逐步補白名單，結果新加入的實例剛好被上層拒絕規則蓋住，Ping 當然不通。
再往下一層，就是作業系統防火牆。Linux 可能是 firewalld、ufw 或 iptables，Windows 則是內建防火牆。即使 AWS 層全部放行，OS 層如果把 ICMP Echo Request 擋掉，外部一樣看不到回應。這類問題尤其常見在使用加固鏡像、企業模板、或曾經被手工調整過的主機上。
判斷方法很直接：如果在同 VPC 內某些主機能 Ping，外部卻不行，而且路由與安全組看起來都正常，就要高度懷疑 OS 防火牆。這時候可以暫時關閉相關防火牆做驗證，但正式環境不要忘了改回正確策略，避免為了排障而留下長期風險。
如果你 Ping 的是私有 IP 或跨 VPC，思路要改
很多人問，明明 EC2 狀態檢查通過，為什麼在另一個 VPC 或公司網路裡 Ping 不到它的私有 IP。答案通常不是故障，而是你本來就沒有打通路徑。私有 IP 只在 VPC 內有意義，離開那個網路邊界，就必須依賴 VPN、Direct Connect、VPC Peering、Transit Gateway 或跳板機等機制來建立可達性。
如果兩個 VPC 已經做了對等連線，還要檢查路由是否雙向配置、CIDR 是否有重疊、安全組是否允許對等網段、NACL 是否放行。很多人只在一邊加路由，另一邊忘了回程，結果封包出得去回不來。網路問題最怕的就是單邊思維，因為任何跨邊界通訊，本質上都需要回程路由完整成立。
若你只是想遠端管理這台主機，不一定非得執著於 Ping。很多環境會刻意禁 Ping 來降低噪音與掃描風險，但仍然可以透過 SSH、RDP、SSM Session Manager 或應用層健康檢查來驗證可用性。也就是說，Ping 不通不一定等於服務壞了，但如果你的業務真的依賴 ICMP，那就必須把前面每一層都查透。
實戰案例：看起來都放行，卻還是 Ping 不通
最常見的實戰場景有四種。第一種，安全組入站已經放行 ICMP，但出站被限制，回包被擋住，所以外部看到超時。第二種，實例放在私有子網，路由表根本沒有到 IGW 的預設路由，外網無法進入。第三種，NACL 有拒絕規則搶先命中，封包在子網邊界就被攔下。第四種，AWS 層都沒問題，真正擋住的是主機上的防火牆。
還有一種很容易被忽略的情況，是你以為自己打的是公有 IP，實際上已經換過彈性 IP，或是實例重啟後公有 IP 改變了。這時候如果 DNS 還指向舊位址，Ping 當然沒有回應。雖然這看起來像網路故障，但本質上是目標位址錯了。排障時一定要先確認現在連的就是當前正在使用的地址。
如果環境很複雜，建議把排查順序固定下來，不要來回跳。先看地址，再看路由，再看安全組，接著查 NACL，最後查 OS 防火牆。這樣做的好處是，你能快速排除上層大方向問題，不會一開始就陷入細節，結果在錯誤方向上修半天。AWS 網路問題最大的敵人不是難，而是層次太多，容易讓人猜錯。
一張可以直接照著走的排查清單
- 確認 Ping 的是公有 IP、彈性 IP，還是私有 IP。
- 確認實例是否真的在可對外的子網，且是否已分配公有地址。
- AWS帳號代開 確認子網路由表是否有 0.0.0.0/0 指向 Internet Gateway。
- 確認安全組入站是否允許 ICMP，來源是否正確。
- 確認安全組出站是否過度限制，回包能否出去。
- 確認網路 ACL 入站與出站是否都放行，且沒有被前置拒絕規則攔截。
- 確認作業系統防火牆是否阻擋 ICMP。
- 確認路由與安全組是否真的套用在實例所在的子網與網卡上。
- 必要時用流量分析工具與 AWS 的可達性檢查功能交叉驗證。
如果你習慣用排除法，這份清單幾乎就夠用了。多數 Ping 不通的問題，其實都能在前五步找到答案。真正棘手的案例，不是規則太少，而是規則太多、層數太多、變更太頻繁，最後沒有人知道哪一層才是最新狀態。這時候最有用的不是猜，而是回到最基本的封包流向，一步一步看它卡在哪。
AWS帳號代開 結語：別把狀態檢查當成網路可達的保證
EC2 狀態檢查通過，只代表主機活著，不代表外部一定能 Ping 到。真正要看的，是整條路徑是否完整：路由表是否把封包送到正確出口，安全組是否允許 ICMP 進出，NACL 是否沒有無聲攔截，作業系統防火牆是否阻擋回應。只要你把這幾層拆開看，很多看似神祕的問題，其實很快就能定位。
下次再遇到 Ping 不通，不要急著懷疑 AWS 壞了，也不要一口氣亂改設定。先確認目標地址，再從路由表、安全組、NACL、OS 防火牆一路往下查。你會發現，網路故障雖然看起來複雜，但只要排查順序對了，答案往往並不難找。
