Claude Code 輸出到一半突然停掉，是網路問題還是 API 限流？

Claude Code 走的是 SSE（Server-Sent Events）串流長連接。如果服務端已經成功回傳了前幾個 token、中途突然中斷，一般不是限流（限流通常會直接回傳 429），而是鏈路層面的問題——可能是 DNS 解析被攔截、MTU 不匹配導致分片丟失、中轉出口抖動、或者本地代理用戶端的連接維持時間過短。建議先排查鏈路穩定性，再懷疑帳號或配額問題。

接了代理後 Claude Code 能啟動但回答特別慢，怎麼加速？

慢通常有三層原因：一是 DNS 解析沒走代理——本地 DNS 把 api.anthropic.com 解析到了遠距離節點、增加首包延遲；二是代理出口到 Anthropic 的中間鏈路跳數多、延遲高（有些機房 IP 的中轉段超過 15 跳）；三是本地 MTU 過大導致 TCP 分片重傳。最快見效的優化是把 DNS 改為遠端解析、並確保出口 IP 距離 Anthropic 服務節點較近（美西最好）。

Claude Code 和 claude.ai 網頁端的網路問題一樣嗎？

不一樣。網頁端 claude.ai 的驗證偏風控訊號（IP 歸屬類型、帳號地區一致性），斷連少見；Claude Code 走的是 api.anthropic.com 的 API 閘道，對長連接穩定性要求高得多。一個很常見的情況是網頁端正常但 CLI 各種斷——這說明 IP 本身沒被標記，但通往 Anthropic API 的中轉鏈路品質不好。解決方案是用美國住宅 IP（最短路徑、低跳數）替代機房中轉。

怎麼確認是本地環境還是代理的問題？

一個簡單的方法：在代理環境下執行 curl -v https://api.anthropic.com/v1/messages，觀察 TLS 握手是否順暢（有 SSL connection using TLS 字樣則 OK）；然後去掉代理、用本地網路直連一遍對比。如果代理環境下 TLS 握手耗時明顯長（>800ms）或反覆 reset，說明問題出在代理鏈路。另外可以 ping api.anthropic.com 看丟包率——丟包超過 5% 就值得換出口了。

換成住宅 IP 之後 Claude Code 還會斷嗎？

住宅 IP 解決的是 IP 歸屬類型和地區一致性問題，這是基礎。但即使是住宅 IP，如果從中國大陸到美國住宅的中轉鏈路品質差、或者本地 DNS 沒配好，仍然可能出現延遲高和偶發斷流。最好的配置是：固定一個美國住宅 IP + 遠端 DNS + 加密隧道（WireGuard / VLESS）+ 適當調整 MTU。四層一起做好，斷連機率會降到非常低。

Claude Code · 開發者

Claude Code 頻繁斷連、SSE 中斷？終端網路環境排查指南

Claude Code 輸出到一半突然停掉、打字速度忽快忽慢、頻繁提示 connection error？你遇到的不是 AI 不穩定，而是終端網路環境沒有針對長連接做適配。

關鍵詞：Claude Code 斷連、SSE 中斷、Claude CLI 網路、Anthropic API 排查

先講結論：Claude Code（CLI 程式設計工具）走的是 api.anthropic.com 的 SSE（Server-Sent Events）長連接串流輸出，和 claude.ai 網頁端的 HTTP 短連接完全不一個量級的網路要求。網頁端能打開不代表 CLI 環境穩定。導致斷連的根因大多在 IP 類型 + DNS + 中轉鏈路 + MTU 這四層。下面從最常見到最隱蔽，一層一層排查。

第一層：確認網路環境基準（10 秒自查）

Claude Code 的 CLI 本質是一個 HTTP 用戶端，它通過你在終端或系統代理設定裡配的 HTTP(S)_PROXY 存取外部 API。第一步是確認出口 IP 的「身份」是否乾淨：

查 IP 類型：在終端執行 curl https://ipinfo.io/json，看 org 欄位。如果回傳 AS15169 Google LLC / AS14061 DigitalOcean / AS20473 Vultr 這類雲服務商 ASN，說明出口是機房 IP。Claude Code 的請求對這種出口的容忍度比網頁端更低——因為 API 閘道對請求模式的異常更敏感。
看 IP 一致性：確認 ipinfo 回傳的 country/city 和你預期的一致。如果你在美國註冊的 Claude 帳號、出口 IP 卻顯示其他國家，地區跳變會疊加風險。
檢查 TLS 握手：執行 curl -v https://api.anthropic.com/v1/messages 看 TLS 階段是否正常。如果看到 ssl handshake failed / connection reset 反覆出現，基礎連接就有問題。

如果基礎網路不通或不乾淨，後面的排查可以跳過——直接換個乾淨的美國住宅 IP 是最快見效的辦法。

第二層：DNS 配置 —— 最容易忽略的瓶頸

很多 CLI 用戶的終端繼承了系統 DNS 設定，而系統 DNS 往往走的是本地運營商。這導致 api.anthropic.com 被解析到離你很遠、甚至和出口 IP 地理矛盾的節點。對 Claude Code 的 SSE 流來說，DNS 解析慢 = 首包延遲高，而「IP 在美國、DNS 在國內」的地理矛盾也是 Anthropic 風控訊號。

排查：

連接到代理後，終端執行 nslookup api.anthropic.com —— 看回傳的 IP 是否在你出口 IP 的同一地區。
執行 dig api.anthropic.com +short @1.1.1.1 用 Cloudflare DNS 解析一次作為對照。如果本地解析快很多但 IP 不一致，說明你的 DNS 走了本地。

修復：在代理用戶端的 DNS 設定中切換為遠端解析（Remote DNS）。如果你用的是系統代理 + HTTP_PROXY 環境變數，在 ~/.zshrc 或 ~/.bashrc 裡補充 export no_proxy=localhost,127.0.0.1 避免 DNS 查詢回退本地。

第三層：中轉鏈路 —— 跳數多、抖動大

從中國大陸到 api.anthropic.com 不可能直連（GFW 會 reset）。所有請求都必須經過中轉。而中轉的品質差異極大：有些便宜機房中轉的中間跳數超過 15 跳、丟包率 5% 以上，對普通網頁瀏覽可能沒感覺，但對 SSE 長連接的破壞是致命的——每一次丟包都可能導致流中斷或重新 connect。

怎麼排查鏈路品質：

traceroute / MTR：執行 mtr -r api.anthropic.com 看中間經過多少跳，重點看第 3-5 跳的延遲和丟包率。如果中國到香港段就 80ms+ 且波動大，鏈路品質不好。
ping 丟包率：執行 ping -c 50 api.anthropic.com 測 50 個包，丟包超過 5% 說明鏈路不可靠。
測首包延遲：在代理下 curl API 時看 -w "%{time_connect} / %{time_starttransfer}"，TLS 握手 > 800ms 就已經偏慢了。

如果鏈路品質差到丟包明顯、延遲高且波動大，你需要在「鏈路更穩的中轉」和「換一個更近的出口」之間選擇。一般情況下，經香港中轉的美國住宅 IP 對大陸用戶的鏈路最均衡（HK 段短 + 美國段直連 Anthropic）。

第四層：MTU 與本地網路棧

MTU（最大傳輸單元）是特別隱蔽的一個坑。如果你的本地網路 MTU 偏大（比如 1500），但中轉加密隧道有額外報頭佔用，產生的包超過鏈路最大尺寸，就會被中間路由器靜默丟棄——你的 SSH/CLI 不報錯，但 Claude Code 的輸出就是會突然停住。

排查：

在代理下執行 ping -M do -s 1472 -c 3 api.anthropic.com 看是否需要分片。
如果 ping 大包失敗或延遲異常增大，在你的代理用戶端或 WireGuard 配置裡把 MTU 降低到 1300-1400。
用 clash/stash/sing-box 的用戶：檢查 global-client-fingerprint 和 utls 設定，部分指紋模擬會導致額外的 TLS record 分層，增加 MTU 壓力。

第五層：代理用戶端的連接保持

Claude Code 的 SSE 長連接在「思考」和「生成」兩階段都可能持續幾十秒甚至幾分鐘。如果你的代理用戶端或系統防火牆把長連接判定為「空閒連接」並自動切斷，就會出現「明明 API 沒問題但 Claude Code 說 connection closed」的情況。

排查：

確認代理用戶端有沒有 keepalive / timeout / idle timeout 配置。有的話調到 300 秒以上。
macOS 用戶：系統預設的 TCP keepalive 較短。執行 sysctl net.inet.tcp.keepidle 看當前值（預設 7200000=2小時，通常是夠的——但如果被改過就可能不對）。
如果你用的代理加密隧道（WireGuard / VLESS）是 UDP 承載的，確認 UDP 會話沒有被 NAT 或路由器逾時丟棄。

動手順序：一個拿到就做、越做越排查的路

先去 AI IP 檢測頁看 IP 類型和 DNS
用 curl -v https://api.anthropic.com/v1/messages 做 TLS 基準
接上代理後重複 TLS 檢測，對比延遲和成功率
改 DNS 為遠端解析
測 MTR / ping 丟包，判斷鏈路是否需要更換
調 MTU 到 1300-1400
確保代理用戶端 keepalive ≥ 300s

如果前三點做完已有明顯改善，後面可以先不做。反之，越往下走越接近真因。

大多數 Claude Code 的「不穩定」，本質是機房 IP + 本地 DNS + 劣質中轉鏈路三者疊加。解決這三個，剩下的調 MTU / keepalive 屬於錦上添花。第一步——確認出口 IP 是乾淨的住宅 IP——是所有優化的前提。

檢測當前 IP 純淨度查看住宅 IP 套餐