Claude 回答到一半停住不动，是模型问题还是网络问题？

先看停住的方式。逐字输出突然定格且刷新后对话记录完整，多为流式连接被网络侧掐断，常见诱因是节点自动切换或链路抖动；如果是明确的错误提示（如容量、限额类），则是服务侧问题。网络侧断流通过固定节点、关闭自动切换可明显减少。

Claude Code 跑长任务为什么比网页对话更容易受断流影响？

网页对话断流损失的只是当前这条回答，点重试即可；Claude Code 的一次任务可能包含连续的多轮 API 调用与工具执行，中途断流可能导致整个任务链失败重来，时间成本高得多，所以对出口稳定性的要求也高一个量级。

重度用户值得。把 Claude/Anthropic 相关域名通过规则固定到一个稳定、低负载的专用节点，日常浏览走其他节点，既避免了浏览行为占用长连接链路，也保证了出口 IP 长期一致，对减少断流和风控验证都有帮助。

如果说普通网页浏览对网络的要求是”能通”，那么 Claude 对网络的要求是”一直通着别动”。Claude 的流式输出、长会话，以及 Claude Code 动辄几十分钟的连续任务，都建立在长连接持续存活的前提上——这正是许多用户”网速明明很快却总断流”的原因所在。

Claude 的回答通过流式连接逐字推送，一条回答对应一条持续数秒到数分钟的连接。会话越长、上下文越大，单次响应时间越长，连接暴露在”被打断”风险中的时间窗口也越长。

Claude Code 的一次任务往往是连续的多轮模型调用加本地工具执行，整个过程可能持续几十分钟。任何一次调用因断流失败，轻则自动重试拖慢进度，重则整个任务中断。API 集成场景同理：超时与连接重置直接转化为业务错误。

一句话对比：网页断流损失一条回答，Claude Code 断流可能损失一整个任务。

出现这些症状时，网络侧嫌疑远大于服务侧。

按嫌疑从大到小排查：

更完整的长连接排查方法论（含负载均衡、QoS 等因素）见《长时间任务出现连接中断的排查思路》，本文不再重复。

固定节点：为 Claude 手动指定一个稳定节点，坚决不用”自动选择”。出口固定除了减少断流，还能避免 IP 变化触发的风控验证，原理见《AI 工具使用固定出口地址的作用》；
规则模式确保相关域名走代理：把 claude.ai、anthropic.com 及相关 API 域名通过分流规则指向该固定节点。重点是成套覆盖——主站走了代理而 API 域名走直连（或相反），会出现登录正常但对话异常等割裂现象；
关闭自动测速切换：或将测速间隔调大，至少保证长任务期间不发生切换。

重度用户的进阶做法

为 AI 工具单独指定一个专用节点分组：Claude、ChatGPT 等域名固定走这一组，浏览下载走另一组。AI 流量与大流量行为隔离后，长连接更稳，出口 IP 也长期一致。

优先级排序：稳定性 > 负载 > 延迟。走专线、用户少的新加坡或日本节点是常见选择；延迟高一些只影响首字速度，链路抖动才影响任务成败。具体表现因环境而异，以实测为准。与 ChatGPT 的选择逻辑基本一致，差异细节见《ChatGPT 网络环境需要注意什么》。

Claude 场景的网络优化只有一个中心思想：让那条长连接从头到尾走同一条稳定的路。固定节点、规则分流成套覆盖、关闭自动切换三步做完，绝大多数断流问题会消失；剩下的少数随机断流，按长连接排查文的方法定位到线路或节点层即可。