以为是 Claude 不行，其实是网络断了：四个最容易误判的场景

用 Claude 用久了的人大概都有过这种时刻：长回答写到一半突然停住，或者上传一份文件让它帮忙分析，进度条卡在那儿不动了。第一反应往往是怀疑自己：是不是提示词写得不对，或者这个任务 Claude 本来就应付不了。但把这些现象拆开一看，大多数情况跟模型能力没关系，是连接在中途掉链了，只是表现得像是 Claude 自己停下来了。

这篇不讲节点怎么选或客户端怎么配，只把四个最容易被误判成「Claude 不行」的场景拆开，每个都给出真实原因和自己能验证的方法。

四个最容易被误会成「Claude 不行」的场景

长回答写到一半突然停住，看起来像“放弃”了

真实原因：Claude 网页端靠 HTTP/2 长连接一口气把回答流式推送完，中途一旦丢包或连接被 NAT 回收，输出会直接断在那一秒，页面上看不到任何报错提示，看起来就像模型自己不想继续写了。验证方法：断掉那次，刷新页面重新进入同一个对话，要是历史记录里回答确实只写到一半就没了，而不是模型自己加了个结尾，那就是连接断了，不是模型停笔。

上传文件卡住不动，以为 Claude 处理不了这类文件

真实原因：文件上传走的是另一条上传链路，对中间链路的上行带宽和连续性要求比普通文本对话高得多。文件越大，中途断一次重传的概率越高，进度条卡住往往不是文件本身解析失败，而是传输还没完成。验证方法：换一个小得多的文件（比如一页 PDF）重试，要是小文件秒传、大文件卡死，基本就是上行链路的问题，跟 Claude 能不能读懂文件内容无关。

Claude Code 任务跑到一半没反应，以为是推理能力不够

真实原因：终端里跑的 agent 任务往往要多轮调用工具、多次往返 API，任何一次请求超时都可能被本地代理或终端静静地否了，界面上不报错、也不提示，看起来就像模型卡在思考里出不来。验证方法：把任务拆小，换一个只需要一次调用就能完成的简单指令试试，要是简单指令也同样无声无息，基本定位到终端到 API 这段链路，而不是任务本身太难。

首字出现很慢，以为模型在“思考”

真实原因：从发送问题到收到第一个字符，中间隔着一段网络往返时延（TTFB），跟模型的推理速度关系不大。验证方法：同一个问题在不同时段（比如深夜和晚上高峰）各问一次，要是高峰期明显慢、凌晨很快，那就是链路拥塞，不是模型本身变慢了。

一张自查表：网络问题 vs 真的是能力局限

确认是网络问题之后，怎么办

先看一个最简单的指标：TCP 重传率。连续 100 个 ping 包看丢包情况，这个数据超过 2% ，基本就能解释前面那四种现象为什么反复出现。其次是看链路能不能把连接保住——普通代理模式对长会话、大文件传输这类长时长会话连接很容易中途被回收，内核层接管的 TUN 模式因为直接接管虚拟网卡层的流量，保活机制比走系统代理稳不少，长对话、大文件、Claude Code 长任务这类场景下差异会比较明显。TonBoVPN 的客户端默认走内核级 TUN 接管，且多端配置云同步，电脑上设好的分流规则换手机登录同一账号也会自动继承。

常见问题

怎么确定自己遇到的就是这四种情况之一，而不是其他原因？

最简单的方法是把同一个操作在不同网络环境下重复一遍，比如换个 WiFi 或切到手机热点。要是现象跟着网络环境走，基本就能确认是链路问题，而不是模型本身的问题。

Claude Code 在终端里一直连不上，和网页端能连上是同一个问题吗？

不完全是。终端不一定继承系统代理设置，即便浏览器能正常打开 claude.ai，终端里的 Claude Code 也可能因为没走代理而连不上。需要显式配置 HTTP_PROXY / HTTPS_PROXY 环境变量，或者直接用客户端的 TUN 模式从系统层接管，终端请求不用单独配。

为什么有时候重试一次就好了，这也算网络问题吗？

算。重试能好说明那一次失败是偶发性丢包或瞬时拥塞，而不是持续性故障。真正需要警惕的是同一类操作反复失败，那才说明链路本身有系统性问题，而不是偶然抖一下。

手机上用 Claude 也会遇到同样的误判吗？

会，而且手机上更容易发生，因为信号在 WiFi 和蓝牙、蓝牙与蓀流之间切换时本来就容易瞬断。判断方法一样：看现象是否跟网络环境切换同步出现，而不是固定发生在某个特定问题上。

这四种情况都排除了，依旧卡，怎么办？

那就真的可能是任务本身超出了当前上下文或者描述不够清晰，这时候回到提示词本身去优化才是对的方向。先把网络这层排除干净，剩下的问题才值得花时间去改提示词。