騰訊雲企業帳號開通 騰訊雲 CVM 綁定 EIP 後，內部 ping 不通外網 IP 排查
騰訊雲企業帳號開通 一、先搞清楚：綁了 EIP，不代表一定能 ping 通外網
很多人一看到 CVM 綁定了 EIP，就會直覺認為這台機器已經具備完整的外網能力。實際上，EIP 只是把公網地址和雲主機做了映射，讓主機具備對外通信的條件，但真正能不能 ping 通，還要看路由、安全組、系統防火牆、回包路徑，以及對端是否允許 ICMP 回應。
騰訊雲企業帳號開通 所以，遇到「EIP 已綁定，機器內部還是 ping 不通外網 IP」時，不要一上來就懷疑雲廠商有問題。正確做法是把整條鏈路拆開看：請求有沒有發出去，回包有沒有回來，雲上策略有沒有放行，主機本身有沒有攔截。只要順著這個思路排查，通常很快就能定位。
先說結論：這類問題最常見的原因，通常不是 EIP 本身失效，而是下面幾種情況之一：安全組出方向限制、子網網關或路由異常、系統防火牆攔截 ICMP、主機有多網卡導致回程路徑錯亂，或者對端主機本來就不回 ping。
二、排查順序要對：先雲上，再主機，最後看對端
排查網路問題最怕亂試。今天改一下安全組，明天重啟防火牆，後天又改路由，最後問題沒解掉，還把線索弄亂了。建議按照這個順序來：
- 騰訊雲企業帳號開通 先確認 EIP 是否真的處於正常綁定狀態。
- 再確認雲上出方向策略是否放行。
- 再看主機系統內部的路由和防火牆。
- 最後驗證目標外網 IP 是否允許 ICMP。
只要按這個順序走，基本不會漏掉核心問題。
騰訊雲企業帳號開通 1. 先確認 EIP 是否真的綁成功
有時候控制台顯示已經綁定，但實際上狀態還在變更中，或者綁到了不是當前業務使用的網卡上。尤其是有多網卡、多 ENI、或者多主機切換場景時，最容易出現這種誤判。
你要先看兩件事：第一，EIP 在控制台上的狀態是否正常；第二，這個 EIP 到底綁在了哪台 CVM、哪個網卡上。如果綁定對象不對，即使控制台顯示有公網地址，實際流量也未必走得到那張卡。
如果條件允許，直接在主機上做最簡單的外網連通性測試，例如：
ping -c 4 114.114.114.114
ping -c 4 8.8.8.8如果所有外網 IP 都不通，問題大概率在本機、雲上策略或出站路由；如果只有個別 IP 不通，先別急著懷疑 EIP，可能是對端主機屏蔽了 ICMP。
2. 看主機路由：默認路由走沒走對
很多人忽略了一點：主機能不能上網，和系統裡的默認路由有很大關係。尤其是 Linux 機器，當有多塊網卡、手工改過網路配置、或者做過容器網路調整時，默認路由很容易出問題。
先看網卡和路由表：
ip addr
ip route正常情況下，應該能看到一條默認路由，並且下一跳和當前子網一致。如果沒有默認路由，或者默認路由指向了錯誤的介面，那麼包根本發不出去。這種情況下，EIP 綁得再正確也沒用。
如果機器有多張網卡，還要特別注意源地址選擇問題。很多業務主機同時掛了內網卡和公網相關配置，系統可能從另一張卡出包，導致雲上回程路徑異常。表面看是 ping 不通，實際上是回包被送到了錯誤的方向。
3. 安全組出方向別只看入方向
這是最容易被忽略的一步。很多人只檢查了入方向，認為既然是主機主動 ping 外網，入方向不重要。其實不對。安全組如果把出方向限制得太死，ICMP 請求本身就發不出去。
你要確認安全組出方向至少允許：
- 目標為 0.0.0.0/0 的出站流量。
- 協議類型包含 ICMP，或者直接放行全部協議做驗證。
- 如果有多層安全策略，確保沒有更高優先級的拒絕規則。
排查時最實用的方法，不是猜，而是直接臨時放開一條最寬的出方向規則做驗證。如果一放開就通了，說明問題就在安全組或網路 ACL 上。等定位完，再回收為精細化規則。
另外，如果你用了子網級別的網路 ACL，也要一起看。安全組和 ACL 是兩層邏輯，任意一層拒絕都會讓流量過不去。
4. 系統防火牆可能攔住了 ICMP
雲上策略放行了，不代表主機就沒問題。Linux 上的 iptables、nftables、firewalld，都有可能把 ICMP 包攔掉。雖然很多情況下防火牆更常攔入站，但如果規則配置得比較嚴，出站也會受影響。
你可以先看當前防火牆狀態：
iptables -S
firewall-cmd --state
firewall-cmd --list-all如果主機上做過安全加固，還要留意 sysctl 裡是否把 ICMP echo 直接忽略了。這類配置雖然少見，但在基線模板或安全整改後並不少見。可以檢查：
sysctl net.ipv4.icmp_echo_ignore_all如果返回值是 1，代表主機會忽略 ping。這時候你從這台主機 ping 外網，表面看像是外網不通，其實是本機根本沒正常發出或處理 ICMP。
5. 用抓包看請求到底有沒有出去
如果前面的配置都看過了，還是沒頭緒，最直接的辦法就是抓包。抓包不是給高手炫技用的，它的價值在於把問題從猜測變成證據。
tcpdump -nn icmp然後在另一個窗口執行 ping。根據抓包結果，你會看到三種典型情況：
- 根本看不到 echo request，說明包沒有從主機層發出去，優先查本機防火牆、路由和網卡配置。
- 看到 request 發出去了，但沒有 reply，說明出站基本正常，問題可能在回包路徑、雲上策略，或者對端不回 ping。
- request 和 reply 都能看到，但 ping 仍顯示失敗，通常是主機本地協議棧或防火牆對回包有處理問題。
抓包這一步很重要，因為它能快速把問題從「雲上問題」和「主機問題」兩大類中分離出來。
三、最常見的幾個根因
1. 只綁了 EIP，卻沒有真正走到正確網卡
這種情況在多網卡機器上很常見。控制台看起來 EIP 正常，但業務流量實際從另一張網卡出去。結果就是，雖然有公網映射，卻沒有走到正確的出站路徑。特別是做了手工網路配置、系統遷移、或容器網路接管後，這個問題更容易出現。
2. 安全組策略太保守
有些團隊習慣把安全組當成單向白名單，只放入站，不放出站，或者只放 TCP，不放 ICMP。平時業務訪問似乎沒問題，但一到排查 ping，就會發現外網完全不通。這不是 EIP 的問題，而是策略本身把探測包攔住了。
3. 系統防火牆做了過度收斂
主機安全加固沒錯，但收得太死就會把正常的網路探測一起擋掉。尤其是在一些歷史較久的伺服器上，iptables 規則可能積累得很亂，最後只剩下少數幾條能記得的人才知道它在做什麼。這種情況下，與其一條條猜，不如先臨時清晰化規則，再逐步收緊。
4. 對端外網 IP 本來就不回 ICMP
這是最容易誤判的一類。很多公網服務器、雲廠商節點、IDC 邊界設備，會主動丟棄 ping 請求。你 ping 不通，不代表網路不通，只代表對方不回應 ICMP。這時候更合適的驗證方式是測試 TCP 端口，例如 80、443、22，或者使用 curl、telnet、nc 做業務層驗證。
所以，當你只對某一個外網 IP ping 不通時，不要急著給自己的 CVM 下結論。先換幾個公共地址測試，確認是不是目標側屏蔽了 ICMP。
四、建議的實戰排查流程
如果你現在就要處理現場問題，可以按下面這個流程走，效率最高：
- 在主機上執行 `ping -c 4 114.114.114.114`，確認是不是所有外網都不通。
- 執行 `ip addr` 和 `ip route`，看默認路由是否正常。
- 檢查安全組出方向，臨時放開全部出站做對照實驗。
- 檢查子網 ACL 是否存在拒絕規則。
- 查看主機防火牆和 ICMP 相關系統參數。
- 使用 `tcpdump -nn icmp` 觀察請求和回包。
- 如果只是不通某個特定 IP，改用 TCP 測試，排除對端屏蔽 ICMP 的情況。
這套流程的好處在於，每一步都能把問題範圍縮小一半。排到第三步，通常就已經能知道問題是雲上還是雲下。到了抓包這一步，基本可以定位到具體層面。
五、幾個容易踩坑的細節
第一，不要把「EIP 已綁定」等同於「所有外網能力都正常」。綁定只是前提，不是結果。
第二，不要只看入方向。很多人檢查半天安全組，結果出方向根本沒看，最後白忙一場。
第三，不要拿 ping 當唯一標準。ping 只是 ICMP 探測，不能代表所有協議。很多業務環境裡，ping 不通但網站、API、SSH 都正常，這是完全可能的。
第四，注意多網卡、多路由、多策略路由的場景。這類問題表面很像雲網故障，實際上是主機路由表把包送錯了地方。
六、總結
騰訊雲 CVM 綁定 EIP 之後，內部 ping 不通外網 IP，通常不是單點故障，而是多層鏈路中的某一層出了問題。真正有效的排查方法，不是憑感覺改配置，而是按照固定順序逐層驗證：先看 EIP 狀態，再看路由和網卡，再看安全組與 ACL，接著查主機防火牆，最後用抓包確認請求和回包是否完整。
只要把這幾步走順，絕大多數問題都能在短時間內定位。對運維和雲上排障來說，最重要的不是記住多少命令，而是建立一條清晰的判斷鏈：包有沒有出去，回包有沒有回來，哪一層最先把它攔住。這才是解決這類問題最快的方法。
