騰訊雲帳號認證充值 騰訊雲 NAT 網關併發連接數達到上限，導致外網訪問超時排查
騰訊雲帳號認證充值 現象與背景
一個平常穩定跑的業務，在高峰時段開始出現外網訪問超時：拉取第三方接口偶發失敗，容器鏡像拉取變慢，偶爾還伴隨任務堆積。內網服務互調正常，訪問雲上自建的入站服務也沒問題，唯獨出網去公網的請求時好時壞。這類現象在使用騰訊雲 NAT 網關做出網 SNAT 的架構裡並不罕見。本次記錄一次從故障現象到確認 NAT 網關併發連接數達到上限的完整排查過程，並總結可落地的處理與預防策略。
典型場景是：VPC 內的私有子網沒有綁外網 IP，出網路由指向 NAT 網關。NAT 綁定一個或多個彈性 IP，通過 SNAT 將內部私網地址轉換為 EIP 出口，對外建立連接。當併發連接數、連接建立速率、或單個 EIP 可用端口資源接近上限，新的連接可能被丟棄或延遲，應用側最終表現為超時或重試放大。
快速判斷思路
先確認範圍
第一步搞清楚影響面。只在出網對外時超時，內網互訪沒問題，入站也正常，基本可以聚焦在出網鏈路：實例網卡、路由表、NAT 網關、EIP、上游網絡。若只有某些子網或某些服務受影響，優先檢查它們共享的 NAT 規則與 EIP。
排除 DNS 與上游故障
嘗試直接訪問目標 IP 與端口，避開域名解析；測試多個互聯網目標位址，若均不穩定，NAT 出口問題的可能性更高。反之，若僅某個第三方目標出現大量超時，需同時排查對方限流或黑洞。
對比內外網與入站
使用相同業務在內網的對等調用做比對。若僅外網出現 SYN 重傳而內網一切正常，且入站受 CLB 或公網 IP 承載的服務響應良好，基本可鎖定出網側鏈路資源緊張或策略限制。
在主機側觀察 TCP 行為
tcpdump 抓包判斷
在出現問題的 CVM 或容器節點上抓包：
tcpdump -nn -i eth0 tcp and host 目標IP and port 目標端口
騰訊雲帳號認證充值 常見現象是連續發出 SYN，對端無回包，幾秒後重傳，最終超時。若偶發能連通，抓包會看到少量連接握手成功，多數超時。這種沒有任何回包的超時，除了對方黑洞，也很像 NAT 出口在新建連接時丟棄了流量。
ss 與 netstat 觀察
使用以下命令觀察內核連接狀態與重傳情況：
ss -s ss -ant state syn-sent netstat -s | egrep 'retransmit|failed|listen'
如果 SYN-SENT 堆積、重傳次數增多，而 ESTAB 並不高，結合應用日誌出現大量連接超時，說明問題多集中在建立連接階段，這與 NAT 連接表滿、端口資源緊張高度吻合。
在雲端側核查 NAT 網關
監控指標
打開雲監控查看 NAT 網關相關指標，關注三個面向：
一是 SNAT 併發連接數。當曲線逼近規格上限或長時間維持高位，新的連接很難被即時接納。
二是新建連接速率。突發高 CPS 容易瞬間打滿連接表或 EIP 端口池，導致短時丟棄。
三是丟棄或失敗計數。如果平台提供丟棄統計，持續攀升幾乎可以坐實瓶頸在 NAT。
同時查看每個綁定 EIP 的使用情況。如果只有單個 EIP 承擔了大部分流量，它的可用端口可能更早耗盡。
騰訊雲帳號認證充值 流日誌與丟棄判斷
開啟 VPC 流日誌，對受影響子網或關鍵節點采集五元組流量記錄，落盤到日誌服務。雖然無法直接看到 NAT 轉換後的端口映射，但可以觀察到大量未建立成功的出向流與重試，與應用時序做對齊，輔助定位為出網側擁塞而非目標站限流。
併發連接達上限的成因剖析
EIP 端口資源與連接表
NAT SNAT 的本質是將內部多源地址映射到有限的 EIP 與端口池。單個 EIP 可用的出站端口數量有限，連接表對每條五元組建立映射與狀態維護。當併發多、目標多、連接短且頻繁新建時，端口與表項會被迅速佔滿，新連接就會被丟棄。
連接空閒與 TIME_WAIT
一個常被忽略的細節是關閉連接後的保留時間。對短連接洪峰，雖然應用已斷開，但 NAT 端的映射條目還會保留一段時間，以處理遲到報文與重傳。這段時間在高並發場景會導致端口實際可用數滯後回收，峰值更容易觸頂。應用層若沒有連接復用，等同於不斷創造新的消耗。
UDP 場景差異
UDP 沒有握手，映射建立與回收僅依賴報文活動與空閒超時。如果短時間大量 DNS 或打點流量經 NAT 出口，亦可能觸發映射數上限，對其他關鍵業務造成爭搶。
故障復盤：一次真實排查
現象
某日早高峰，業務監控報告外呼接口超時率攀升，容器鏡像拉取偶發卡住。內網調用與入站訪問一切正常。團隊初判是對外出網通道擁塞。
騰訊雲帳號認證充值 定位
在業務節點上用 curl 測試多個公網站點，均有延遲明顯增加甚至超時。tcpdump 顯示 SYN 多次重傳無回包，時間點與高峰吻合。登錄雲監控，發現 NAT 網關 SNAT 併發連接數在高峰接近規格上限，新建連接速率吊頂，丟棄曲線抬頭。進一步核查綁定 EIP，只有一個 EIP 承擔了大部分流量。把應用側統計對上去，發現是新上的某個微服務在高併發場景禁用了 HTTP keepalive，單請求單連接，導致瞬時連接暴增。
緊急止血
先做容量側止血：給 NAT 綁定第二個 EIP，調整 SNAT 規則讓受影響子網出網使用 EIP 池自動分擔。生效後，併發連接數下降到安全區間，丟棄歸零，超時率快速回落。為避免回退，臨時把該微服務的併發限流下調，配合重試退避策略減少瞬時衝擊。
根因與修復
根因是應用端未做連接復用，且在高併發下短連接洪峰打滿 NAT 併發與 EIP 端口。開發團隊當天修復配置：開啟 keepalive，設置連接池與每目標最大空閒連接數，啟用 HTTP2 或 gRPC 的復用能力，並將批量任務改為分批。次日觀察，高峰期 SNAT 併發與新建速率曲線平滑許多。
治標與治本的處理方案
擴容與橫向分擔
短期最直接的是增加資源餘量：
- 提升 NAT 網關規格，使併發連接上限與新建速率上限更高。
- 綁定多個 EIP 並啟用共享 SNAT，讓出口分擔到多個 EIP 的端口池。
- 按子網或源地址劃分多個 NAT 出口，將不同業務的出網流量隔離，避免互相爭搶。
擴容是止血，真正讓曲線長久平滑還要從源頭減少無謂的連接建立。
應用端連接優化
- 開啟 HTTP keepalive，為每個目標設置合理的最大空閒連接與存活時間，避免閒置過多或太快回收。
- 使用連接池與請求併發控制，限制每目標的最大新建速率，遇到溢出採用排隊或快速失敗。
- 優先使用能復用底層連接的協議與客戶端，HTTP2、gRPC、長連接的消息協議都有幫助。
- 調整重試與超時策略，使用指數退避，避免瞬時重試雪崩再次衝擊出口。
架構層面繞開 NAT
- 能內網訪問的雲服務，盡量走內網域名或私有連接，繞開公網出口。
- 對第三方高頻依賴，考慮與對方建立專線或就近接入，降低經 NAT 出網的請求量。
- 靜態資源下載、鏡像倉庫拉取，優先選擇提供內網節點或加速的方案。
系統與超時策略
- 謹慎調整系統的出站端口回收與重用參數，避免過早回收導致連接誤傷，也避免保留過長造成端口長期占用。
- 應用層合理設定連接與請求超時，拉齊上下游的期望，縮短掛起時間，加快失敗暴露與恢復速度。
預防與運維規範
告警閾值
針對 NAT 網關設置告警：併發連接使用率超過 70%、85%、95% 分級告警，新建連接速率的突增告警，丟棄計數非零及持續升高告警。對單個 EIP 的使用也應有可視化，避免某個 EIP 成為瓶頸。
壓測與容量評估
上線前用接近真實的併發與請求模式做壓測，重點觀察短連接洪峰與重試風暴下的指標行為。預估峰值連接數與新建速率，結合 NAT 規格與 EIP 數量，給出冗餘係數，避免逼近邊界運行。
變更風險控制
任何可能放大出網請求的變更，都要有灰度與開關，包括重試策略、併發度、批處理批次大小、協議切換等。對外部依賴建立白名單與速率限制，避免單目標成為全局的風暴源。
排查清單與命令速查
現場排查可按清單執行：
- 確認影響面：僅出網超時，內網與入站正常。
- 多目標測試：不同公網目標是否一致超時。
- 主機側抓包：觀察 SYN 重傳與握手是否完成。
- 內核統計：查看 SYN-SENT 堆積與重傳次數。
- 雲監控：查看 NAT 併發、新建速率、丟棄曲線。
- EIP 分佈：是否存在單 EIP 流量過載。
- 臨時擴容：增加 EIP 或提升規格觀察是否緩解。
- 應用側：檢查 keepalive、連接池、重試策略。
常用命令：
curl -v --connect-timeout 3 http://目標 ping -c 3 目標IP traceroute 目標IP ss -s ss -ant state syn-sent | head netstat -s | egrep 'retransmit|failed' tcpdump -nn -i eth0 tcp and host 目標IP and port 目標端口
常見誤區與細節
- 以為擴大主機的臨時端口範圍就能解決。實際上 NAT 使用的是 EIP 端口池與網關連接表，主機側參數幫助有限。
- 騰訊雲帳號認證充值 以為關閉 keepalive 能省連接。對短請求高併發場景，關閉復用只會放大新建連接，反而更容易頂爆 NAT。
- 忽略重試風險。無節制的重試會在出口擁塞時形成雪崩，應用層需要退避與併發限制。
- 只看平均值，不看峰值與分位。NAT 連接資源的瓶頸常發生在秒級尖峰上，平均值無法反映真實風險。
收尾與建議
這類問題的本質是多租共享的有限出口資源與瞬時請求模式之間的矛盾。定位時以端到端的事實為準：主機側 TCP 行為、雲端 NAT 指標、EIP 分佈與丟棄趨勢交叉驗證；處置時先止血擴容，後優化應用與架構，最後用監控與規範把關，讓問題在告警線被發現而不是在業務崩點暴露。形成標準化的排查清單與發版准入檢查，將會大幅降低類似故障的重演概率。
