Claude 长回答中途断掉：连接被谁掐断的，以及怎么测出来
普通网页请求两秒就结束，掉线你根本察觉不到。Claude 的一次长回答要连着几十秒，线路上任何一次抖动都会变成肉眼可见的失败。
同样一条线路，刷网页毫无问题，用 Claude 却总在回答到一半时停住。这不是错觉，原因在连接要维持多久这一件事上：
| 场景 | 单次连接持续时间 | 中途抖动的后果 |
|---|---|---|
| 打开一个普通网页 | 一两秒 | 几乎察觉不到，浏览器会自动重试 |
| 看流媒体 | 长，但有缓冲 | 缓冲吸收掉，最多画质降一档 |
| Claude 一次长回答 | 几十秒，无缓冲 | 直接中断，已生成的内容可能丢失 |
没有缓冲这一点是关键。 流媒体可以提前缓存几十秒的数据来抵消抖动，流式输出的文本是实时产生的，缓不了。链路上任何一次持续超过重试窗口的中断，都会变成你眼前那个停住的光标。
中断的四种表现，各自指向哪一层
先分清楚你遇到的是哪一种，四种的处理方向完全不同。
| 你看到的现象 | 最可能的原因 | 往哪查 |
|---|---|---|
| 停在随机位置，间隔不规律 | 线路抖动或丢包 | 线路侧，见下面两节 |
| 每次都停在差不多的时间点 | 某处的固定超时设置 | 客户端或中转侧 |
| 停住的同时其他网页也卡 | 整条链路拥塞 | 时段问题，换节点或错峰 |
| 只在切换网络、唤醒设备后发生 | 本地连接重建 | 本机环境，与机场无关 |
第二行和第一行最容易被混淆。 线路抖动造成的中断是随机的——有时十秒有时三分钟；卡在同一个时间点则说明链路上某一环到点就主动断开，属于配置问题而不是质量问题。记录三五次中断发生的时间点，一眼就能分辨。
第四行经常被误判成机场的问题。 Wi-Fi 切蜂窝、笔记本休眠唤醒、路由器重连、手机息屏后限制后台网络，这几种情况都会让本地地址变化，正在进行的连接必然重建。换多少次机场都不会有改善。
一次长回答对线路提出了什么要求
把要求说具体，才知道该测什么。
要求一：连续几十秒不出现超过重试窗口的中断。 注意这里说的不是「不丢包」——偶尔丢一两个包 TCP 会自己补上，你察觉不到。真正致命的是连续丢包或链路短暂不可达，哪怕只有一两秒。
要求二：抖动要小。 抖动是延迟的波动幅度。抖动大意味着这条链路上有排队竞争，而排队到一定程度就会表现为超时。这也是为什么延迟低不等于适合 Claude——香港节点延迟最低，但它也是最拥挤的方向，晚高峰的抖动往往最大。
要求三：不能中途换节点。 客户端的自动选择、负载均衡、故障转移这些功能，在长连接场景下都是负面因素——它们切换节点时会直接掐断当前连接。这一条是最容易被忽略的，后面单独讲。
怎么测一条线路能不能扛住长连接
不用专业工具，两个办法就够。
办法一：看延迟的波动幅度，不看平均值。 在客户端里对同一个节点做连续的延迟测试，或者用系统自带的连通性测试跑几分钟。记录最大值和最小值的差，这个差值比平均延迟更能预测中断。一条平均 150 毫秒但波动在 140 到 160 之间的线，比一条平均 80 毫秒但在 40 到 400 之间跳的线更适合长回答。
办法二：在你真正要用的时段测，而不是白天。 线路问题几乎都集中在晚高峰，白天测出来的结果没有参考价值。连续一周在你常用的时间段各测一次，形成一条曲线，这比任何一次测速都有用。
一个更贴近实际的验证：让 Claude 生成一段足够长的内容（比如让它详细展开某个话题），连续做三次，记录有没有中断、中断在第几秒。这直接测的就是你要用的东西，比任何间接指标都准。
超时与连接中断的通用排查方法见节点连接超时怎么排查。
客户端设置里三个会主动掐断连接的地方
这一节是最容易见效的部分，因为它不需要换机场。
第一，自动选择 / 自动切换节点。 多数客户端默认按延迟自动挑节点，并且会定期重测、重选。重选发生在你正在等回答的时候，连接就断了。给 Claude 相关域名配一条固定指向单个节点的规则，不要让它走自动选择组。Clash 系客户端的规则配置见 Clash Verge 使用教程。
第二，负载均衡组。 负载均衡会把不同请求分散到多个节点上，对并发下载是好事，对单条长连接是灾难——同一个会话的请求可能被分到不同出口，直接失败。把 AI 相关域名从负载均衡组里摘出来。
第三，空闲超时与连接寿命设置。 部分客户端有可配置的超时项，默认值对普通浏览足够，对长连接偏短。如果你的中断时间点很规律，优先检查这里。
做完这三项之后再复测。很多被归咎于「机场不行」的中断，实际上是这三个设置造成的。
专线和中转在这件事上的实际差别
这是少数几个专线标注真正有意义的场景。
| 线路类型 | 跨境那一段的容量 | 对长连接的影响 |
|---|---|---|
| IEPL / IPLC 专线 | 预先租定，不与公网流量竞争 | 抖动小，时段差异小，更适合 |
| 中转 | 走公共国际链路，与所有人竞争 | 白天可能更快，晚高峰抖动明显 |
| 直连 | 同样走公网，不绕中转 | 峰值高，但受国际出口拥塞影响最大 |
中转在白天可能比专线更快——公共链路空闲时可用带宽很大。但长回答关心的不是峰值，是会不会在这几十秒里塌一下，而这正是专线的优势所在。
所以这是一个少见的情况：为 Claude 选线路时，专线标注值得多付一点钱。 但要提醒两点：一是「专线」这个词在机场宣传里被滥用得很厉害，标注不等于事实；二是本站收录的机场都没有逐节点公开线路类型，你买之前无法知道订阅里哪个节点走专线。验证方法还是测抖动——真专线的抖动应明显小于中转，而且白天和晚上的差异不大。两类线路的技术差别见 IEPL 和 IPLC 有什么区别。
短期内能做的四件事
按见效速度从快到慢：
- 给 Claude 的域名配固定节点规则，摘出自动选择和负载均衡。不花钱，最快见效。
- 换掉香港节点。 它延迟最低但也最拥挤，晚高峰抖动通常最大。改用日本或美国方向，具体权衡见 Claude 访问指南里的地区一节。
- 避开你自己观察到的高峰时段。 如果中断集中在某几个小时，这本身就是线路拥塞的证据。
- 测完之后再决定要不要换机场。 如果订阅里所有节点在晚高峰都抖得厉害，那才是线路资源的问题。
不要做的两件事：把 Claude 域名放行到直连（连不上），以及叠加多层代理（每多一跳就多一个可能中断的点）。
更多 Claude 相关的访问要求与报错处理见 Claude 专题。