AI 長連線（SSE/WebSocket）頻繁斷流？延遲與丟包的根因排查與優化

用 ChatGPT/Claude/Gemini 時輸出到一半突然停住、過幾秒又蹦出一段、或者乾脆報 network error——這不是 AI 故障，是你的網絡環境沒針對長連線做適配。

關鍵詞：SSE 斷流、AI 長連線優化、Claude 網絡中斷、WebSocket 延遲、MTU TCP 排查

第一層：出口 IP —— 地基不牢一切白搭

出口 IP 的「身份」是 AI 長連線的第一道關：

• 資料中心 IP：ASN 歸屬雲端服務商（AWS/GCP/DO/Vultr 等）。AI 服務商的風控模型對這類 IP 的「連線保持信任度」較低——即使首包通過了，後續的持續連線也可能被中間審查節點掐斷。
• 共用 IP / 輪換 IP：如果同一個 IP 同時有多個使用者在做 AI 請求（常見於公共節點的出口），AI 服務端可能因並發數異常而主動限速或中斷。
• 住宅 IP：ISP 分配的獨享 IP。ASN 不在「資料中心」名單裡，AI 服務對它的長連線信任度最高，不容易被中途掐斷。

第一層不是讓你規避網絡限制，是讓你的出口在 AI 服務的判斷裡看起來像一個正常的、合法的個人使用者。

第二層：DNS 解析 —— 延遲的第一責任人

DNS 是對延遲影響最大、卻最容易被忽略的一層。

核心矛盾：如果你的代理客戶端的 DNS 設定是「本機解析」（Local DNS），系統會用你大陸電信業者的 DNS 去解析 api.anthropic.com / api.openai.com。這些域名的 CDN/Anycast 會根據 DNS 來源返回離中國大陸最近的節點——但這個節點往往不在你代理出口的同一地區。結果：出口 IP 在美國，但 DNS 把域名解析到新加坡或日本的 IP——延遲憑空多了幾十毫秒，且地區不一致是附加風控訊號。

解法：把代理客戶端的 DNS 策略從「本機解析」改為「遠端解析」（Remote DNS / DNS over Proxy）。出口在哪裡，DNS 就在哪裡解析——做到 IP 和 DNS 在同一地區。

驗證方法：

• 在代理下執行 curl -v https://api.anthropic.com/v1/messages 2>&1 | grep "TLS" 看握手時間。
• 對比關代理直連和開代理的 TLS 握手耗時——開代理後應該 ≤800ms（美國西海岸正常延遲）。

第三層：中轉鏈路 —— 長連線的隱形殺手

從中國大陸無法直連到美國的 AI 服務（會被 TCP Reset 掐斷）。所有請求必須經過中轉。中轉鏈路的品質用三個指標衡量：

• 跳數（Hops）：用 mtr -r api.anthropic.com 數中間經過多少跳。如果是中→港→美三段，期望 10-15 跳。超過 18 跳說明路由很差。
• 丟包率（Packet Loss）：用 ping -c 50 api.anthropic.com 測。丟包 >5% 意味著每 20 秒左右就可能有一個包丟失，對應 AI 串流輸出的大約每 20 秒一次「卡住」。
• 抖動（Jitter）：延遲的變化幅度。用 mtr -r 看每跳的 Avg 和 Max 差值。Max - Avg > 40ms 說明這跳不穩定。

鏈路選擇建議：

• 電信用戶 → 走 CN2 GIA 或 4837 中美直連（延遲最優）
• 聯通用戶 → 走 9929 中美直連或經香港中轉
• 移動用戶 → 走 CMIN2 或經香港中轉
• 三網通用最穩方案 → 經香港中轉的美國住宅 IP（HK 段就近 + 直連美國住宅，延遲均衡在 190-220ms）

第四層：MTU 與 TCP MSS —— 最隱蔽的坑

MTU（Maximum Transmission Unit，最大傳輸單元）決定了每個 IP 包的上限。如果你的網絡環境和 AI 服務端之間的 MTU 不匹配，大的 TCP 包會被中間路由器靜默丟棄——不報錯、不通知、就像什麼都沒發生。TCP 會嘗試重傳，但同樣大小的包還是被丟，結果就是連線卡住不動。

為什麼加密隧道會讓情況更糟：

• 隧道加密頭（VLESS/XTLS ~40 位元組、WireGuard ~60 位元組、OpenVPN ~40-80 位元組）佔用 MTU 的空間
• 你的本機 MTU 可能是 1500，但隧道路徑上的鏈路 MTU 可能只有 1460 或更低
• TCP 三次握手時協商的 MSS（最大段大小）不包含隧道頭，協商出來的是錯的
• 結果：發出去的包 > 真實 MTU → 被扔 → 連線卡住

排查方法：

1. 用 ping -M do -s 1472 -c 3 api.anthropic.com 發大包測試，如果有分片告警，MTU 有問題。
2. 從 1400 開始逐漸加大，找到剛好能過不需要分片的最大值。
3. 在代理客戶端或網絡方案配置裡設這個值。

建議值：用 WireGuard 的設 MTU=1380；用 VLESS/Vision 的設全域 MTU 1300-1400；用 Clash/Stash 的檢查 tun.mtu 設定。

第五層：Keepalive 與逾時 —— 「思考」時間的長連線

AI 從收到你的問題到開始輸出 token 的「思考」階段，可能持續 5-30 秒（複雜的推理任務甚至更長）。這段時間長連線是開啟的但沒有資料在傳輸。

如果中間有 NAT 設備或防火牆，它的「閒置連線逾時」預設可能在 60-120 秒——超過這個時間沒資料就自動切斷。對於網頁瀏覽來說這個時間完全夠（一個請求 < 2 秒），但對 AI 的長時間思考就不夠。

解法：

• 確認代理客戶端的連線保持時長 ≥ 300 秒（5 分鐘）
• 如果你用的是 UDP 承載的隧道（WireGuard / Hysteria），確認 UDP 會話的逾時足夠長
• macOS 使用者確認 sysctl net.inet.tcp.keepidle 沒被改小（預設 7200000=2小時沒問題）

五層檢查清單（照著做）

遇到 AI 長連線斷流/卡住，按這個順序排查，每一步都有明確的驗證方法：

1. ☐ IP 類型：curl ipinfo.io/json → org 不是雲端服務商 → 住宅 IP ✅
2. ☐ DNS 遠端解析：代理客戶端 DNS 策略 = Remote → 同一地區 ✅
3. ☐ TLS 基準：curl -v API → TLS 握手 ≤800ms → 正常 ✅
4. ☐ 鏈路跳數：mtr API → 跳數 ≤18 跳 → 正常 ✅
5. ☐ 丟包率：ping -c 50 API → 丟包 ≤3% → 正常 ✅
6. ☐ MTU：ping -M do 大包檢查 → 無分片告警 → 正常 ✅
7. ☐ Keepalive：代理客戶端連線保持 ≥ 300s → 正常 ✅

前 3 項是前提，修好前 3 項 80% 的斷流都解決。後 4 項屬於深度優化，每多修一項，穩定性再提一檔。