騰訊雲認證帳號購買 騰訊雲 TKE 集群 Pod 訪問外網特定 IP 丟包/連不上排查

一、先把問題說清楚：不是所有外網都不能訪問

在騰訊雲 TKE 裡，最容易讓人誤判的，就是把「訪問某個特定 IP 不通」直接當成整個集群出網故障。實際上，很多案例都不是全局性問題，而是某一段路徑、某一條策略、某一個目標端限制，剛好只影響了這個 IP。換句話說，Pod 能正常訪問大部分網站，卻對某個外部 IP 出現丟包、連不上、偶發超時，通常代表問題已經很接近真相了。

這類故障常見的表現有幾種：第一，能 ping 通但 TCP 連不上，說明 ICMP 和業務端口的處理不一樣，問題可能在防火牆、白名單或端口策略；第二，小包正常，大包不通，往往與 MTU、分片或回程路徑有關；第三，同一個節點上的別的 Pod 正常，只有某個 Pod 不行，更偏向 Pod 網路、策略或容器內配置；第四，只在高併發時失敗，就要看 conntrack、源端口耗盡、NAT 壓力或對端限流。

所以排查時不要急著改配置，先把問題縮小到具體層級，這樣才不會在路由、安全組、CNI、NAT 之間來回跳，最後什麼都碰了，卻沒有真正找到原因。

二、先做最小化驗證：從 Pod、Node、對端三個位置看差異

判斷這是不是 TKE 出網問題，最好的方法不是靠猜，而是做對照。至少要從三個位置分別測一次：Pod 內、節點上、外部對端。如果這三個位置的結果不一樣，問題邊界就很清楚了。

1. 先在 Pod 內測試

進到出問題的 Pod，對目標 IP 做最基礎的連通測試。不要一開始就只看 ping，因為 ping 只能說明 ICMP 這條路，不能代表業務協議可用。

kubectl exec -it your-pod -- sh
ping -c 4 203.0.113.10
nc -vz 203.0.113.10 443
curl -v --connect-timeout 5 http://203.0.113.10:8080/

如果 ping 通，但 nc 或 curl 不通，先把方向放在 TCP 端口、白名單、對端防火牆和中間設備上；如果 ping 都不穩，則優先看路由、MTU、丟包和上游網關。

2. 再在 Node 上測試

同一個目標 IP，也在宿主機上試一次。如果 Node 能通，Pod 不通，往往說明問題出在 Pod 到 Node 的轉發、CNI、策略或 Pod 級別的出網方式；如果 Node 也不通，那就更像是節點到外部網路這一段有問題，例如安全組、路由、NAT、對端封禁，或者雲上網關沒有正確放行。

curl -v --connect-timeout 5 http://203.0.113.10:8080/
ping -c 4 203.0.113.10
ip route
tc qdisc show

這一步的價值很高，因為它能把問題分成「Pod 特有」和「節點也受影響」兩大類。很多人一上來就在容器裡改參數，最後才發現節點都出不去，白忙一場。

3. 最好再看一下對端視角

如果能聯繫目標 IP 的管理方，讓對方看日誌、防火牆或抓包，往往能一下子確認源地址、目的端口、是否收到 SYN、是否回了 RST。因為外部對端看到的源 IP，未必就是你以為的 Pod IP，可能已經經過 SNAT，變成節點 IP 或 NAT 網關 IP。只要源地址判斷錯了，後面的排查就會跑偏。

三、TKE 裡最容易被忽略的四個出口點

騰訊雲認證帳號購買 Pod 訪問外網，表面上只是一次請求，實際上要經過好幾層。TKE 裡只要其中任意一層不一致，就可能出現只對某個 IP 異常的情況。

1. Pod 到節點的轉發是否正常

如果 Pod 的網路不是最直接的 VPC 路徑，而是經過額外的轉發或封裝，那麼 CNI、橋接、路由和 iptables 規則都可能影響到最終結果。某些問題不是完全斷，而是表現成隨機丟包，因為轉發鏈路上的某個節點狀態不穩，或者規則命中順序有偏差。

可以先看 Pod 所在節點的網路狀態，重點觀察是否有異常的轉發規則、是否有明顯的丟包統計、是否存在接口錯誤。

ip addr
ip route
iptables -t nat -nvL
iptables -nvL
ss -s

2. 出口是否經過 SNAT

騰訊雲認證帳號購買 很多外部 IP 其實並不接受 Pod 網段來源，尤其是企業內網、合作方白名單系統、舊防火牆設備，常常只認節點 IP 或固定 NAT IP。這時如果 Pod 直接用自己的地址出去，對端就會丟棄，表現成「有時候能通，有時候不通」，或者「別的工作負載能通，這個 Pod 不行」。

要確認目標端看到的源 IP，到底是 Pod IP、Node IP，還是 NAT 網關 IP。這一步非常關鍵。很多所謂的「特定 IP 丟包」，真正原因其實是對端只允許某個出口地址，卻沒有把新的 Pod 網段加進去。

3. 安全組與網絡 ACL 是否放行

在雲環境裡，安全組和網絡 ACL 常常是最先被忽略、但最常造成誤判的地方。尤其是只對某個外部 IP 出現問題時，最應該先看這個目標是否在放行範圍內，出方向規則是否完整，回方向是否被限制。

有些團隊只加了入方向，忘了出方向；有些只開了 ICMP，卻沒開業務端口；還有些是對端有白名單，但白名單更新只加了節點 IP，沒有加 NAT 出口 IP。這些都會造成「表面像網路故障，實際上是策略沒配全」。

4. 路由與回程是否對稱

網路問題最怕不對稱。你的請求可能從 A 路徑出去，回包卻從 B 路徑回來，中間任何一層只要沒有配合好，就會出現亂序、丟包或直接失聯。尤其是跨 VPC、跨可用區、經 NAT 網關、或目標 IP 本身在另一個安全域時，回程路由經常比去程更容易出問題。

如果能抓包，會很直觀地看到請求發出去了，但回包沒有到達 Pod 或 Node。這種情況不要只盯著應用層，先看三層路由和四層會話是否閉環。

四、只對某個 IP 掉包，MTU 與分片問題很常見

很多人遇到的現象是：小流量測試沒事，一旦請求稍微大一點，或者某個協議握手階段傳輸的報文偏大，就開始超時。這時第一個要懷疑的不是應用，而是 MTU。

在雲上網路裡，經過封裝、隧道、跨網段轉發後，可用 MTU 會比你想像的小。當報文超過路徑能承受的大小，理論上會分片，但如果中間設備禁掉了分片，或者 PMTUD 失效，結果就會變成「看起來像卡住了」，實際上是大包根本回不來。

可以用不同大小的 ping 去測：

ping -c 4 203.0.113.10
ping -c 4 -s 1400 203.0.113.10
ping -c 4 -M do -s 1472 203.0.113.10

如果小包通，大包不通，基本就要往 MTU、MSS、隧道封裝和路徑上的分片策略查。對於容器集群來說，最實用的修復方式通常不是盲目加大 MTU，而是先確認鏈路的真實上限，再考慮在節點或 CNI 上做合適的調整，必要時對 TCP 做 MSS clamp，避免報文超限。

這一類問題的特點是很迷惑：表面上像偶發網路抖動，實際上是穩定復現，只是你測的包太小，看不到而已。

五、當它只在高併發下失敗，要查 conntrack、端口和併發上限

如果訪問某個外部 IP 並不是完全不通，而是流量一大就丟包，或者高峰期連不上，問題很可能不是鏈路本身，而是節點狀態。最常見的就是 conntrack 表壓力過大、臨時端口耗盡，或者對端限制了單來源的並發數。

節點上的 conntrack 會記錄大量連線狀態。當短連接非常多、連線建立和釋放太頻繁時，表項容易逼近上限。一旦上限到了，新連線就會失敗，表現為部分請求超時、握手失敗、偶爾成功偶爾失敗。

conntrack -S
cat /proc/sys/net/netfilter/nf_conntrack_max
ss -antp | head
ss -s
dmesg | tail

如果發現丟包只發生在某幾台節點上，而不是整個集群，那就要重點看這些節點是否有資源壓力、conntrack 是否異常、是否有大量 TIME_WAIT、是否存在大量短連接打爆出口的情況。對外部某個固定 IP 的訪問，若所有 Pod 都集中打向同一目的地，也可能把對端的連接跟踪、限速策略或防火牆策略觸發。

這時候的解法通常不是單純加大重試，而是要把連線複用做起來，控制併發，降低短連接密度，必要時調整節點網路參數，讓出網行為更平穩。

六、別忽略對端：白名單、防火牆、限速和業務策略

很多排查走到最後，答案都在對端。尤其是訪問某個固定 IP，這個 IP 背後很可能不是單純的一台主機，而是一套防火牆、反向代理、負載均衡、IPS 或安全策略。你以為是在訪問一個服務，其實是在跟一整套安全設備打交道。

如果對端只接受部分來源，或者對同一來源 IP 的連接數有限制，Pod 數一多就會被誤判成惡意流量。還有些系統會對異常 User-Agent、特定端口、過高速率直接做丟棄，不回應、不拒絕，只是默默超時，這也是為什麼很多人會覺得「像丟包」，但抓不到明確錯誤碼。

判斷對端問題時，可以觀察幾個特徵：

• 只有某一個端口不通，其他端口正常。
• 從少量來源訪問正常，一旦並發升高就失敗。
• 固定時間段內失敗率明顯升高，像是被限流。
• 目標地址回包不穩，或者只回 SYN-ACK，後續業務數據沒了。

如果具備條件，讓對端同步開抓包或看防火牆日誌，是最快的方式。很多看似複雜的雲網問題，只要對端確認「請求根本沒到」或「收到了但被丟了」，整個排查方向就會立刻收斂。

七、建議的排查順序：先分層，再動手

面對 TKE Pod 訪問外網特定 IP 丟包或連不上，最怕的就是同時改太多項，最後不知道是哪一項真正起作用。比較穩妥的順序是先定位，再修復。

1. 確認是不是只有某個 IP 異常，還是整體出網都有問題。
2. 在 Pod、Node、對端三個位置分別測試，劃出故障邊界。
3. 看目標端口是否通，不要只看 ping。
4. 確認源地址到底是 Pod IP、Node IP 還是 NAT IP。
5. 檢查安全組、ACL、路由、回程路徑是否完整。
6. 若小包正常大包失敗，優先查 MTU、分片與 MSS。
7. 騰訊雲認證帳號購買 若高併發時失敗，再查 conntrack、端口和對端限流。
8. 最後再回頭看應用層配置，避免把網路問題誤判成程序問題。

這個順序的好處，是能把看起來很亂的故障拆成一層一層的小問題。只要你能回答三個關鍵問題：包有沒有從 Pod 出去、中間哪一段丟了、對端有沒有收到，大多數 TKE 出網故障都能很快縮小範圍。

騰訊雲認證帳號購買 八、總結：特定 IP 不通，通常不是「雲壞了」，而是某一層不對

Pod 訪問外網特定 IP 丟包或連不上，真正的排查思路不是「把所有網路配置翻一遍」，而是從現象反推路徑。先看是否只影響單一 IP，再看 Pod 與 Node 的差異，接著確認 SNAT、路由、安全組和對端策略，最後才是 MTU、conntrack 與高併發問題。這樣查，效率最高，也最不容易把簡單問題搞複雜。

如果你在 TKE 裡遇到這類故障，記住一句話就夠了：不要只問能不能通，要問是哪一段路徑、哪一個條件、哪一類報文出了問題。把問題拆細，答案通常就很快出來了。