现象判断：重置发生在哪条路径

任务执行到一半时终端抛出 Claude Code ECONNRESET，长任务输出随之中断。这种报错比单纯“连不上”更难处理：网页可以打开，curl 也能返回结果，但真实请求却被反复重置。问题可能源自项目配置中残留的代理地址，也可能来自路由器无线链路故障，还可能只是 MTU 与链路不匹配。

排查前需先判断重置发生在哪条路径上，不同现象对应不同优先方向：

  • curl 访问官方地址正常、Claude Code 必然失败：优先核对生效代理与配置，差异可能来自代理配置、TLS 客户端、协议或请求大小。
  • 原网络必失败、手机热点正常：多属链路层问题，进入 MTU 与无线分支。
  • 大请求更易失败、小请求正常：考虑分片或缓冲问题，走 MTU 分支并用原失败请求复测。
  • 同一长上下文反复重置：可能是客户端无效重试循环，核对已完成动作后尝试 ESC 续接。
  • 大面积用户同时报错：多为服务端或上游事故，保留现场等待恢复并查看官方状态页。

关键认知：网页能打开、curl 能返回，只证明某个地址可达，不能证明 Claude Code 实际走的那条路径健康，两条路径不能混为一谈。

五类成因与可控性对照

将成因按可控性排列，配置项最容易核对，应从中入手；路径差异明确时，再检验 MTU、无线等分支。

  • 配置残留代理指向死端口：项目 settings.json 写入 localhost 代理而服务未运行，/status 显示的代理与预期不符。可控性高，删错项重启验证即可。
  • MTU 与链路不匹配：某条路径稳定失败、另一条正常，大 TLS 握手更易触发。可控性中等，临时调低 MTU 可作对照。
  • 无线网卡或路由器故障：换有线或 2.4GHz 后大任务恢复。可控性中等，需查固件与硬件。
  • IPv6 路径异常：失败时 IPv6 路由丢失或 RA 异常。可控性中等，有路由证据才处理。
  • 上游或出口问题：换账号换设备都失败，热点正常且 MTU 无差异。可控性低，交官方或做出口对照。

按路径分流的六步排查

六步需按顺序执行，每步末尾的判定决定走向：进入下一步、转入对应分支，或回查客户端与服务端。

步骤一：核对实际生效的代理

  1. 在 Claude Code 内运行 /status 查看当前代理。
  2. 依次核对启动环境、用户设置与项目 .claude/settings.json 中的代理项，大小写都要查。官方文档规定的优先级为 https_proxy→HTTPS_PROXY→http_proxy→HTTP_PROXY，旧小写值可能盖过新大写值。
  3. 确认 NO_PROXY 没有把 API 目标排除。
  4. 端口必须是 HTTP 代理入口，不要把 SOCKS 端口当 HTTP 代理端口，官方当前不支持 SOCKS。

改完环境变量要保存任务并重启 Claude Code 进程，新进程才会读取；终端会话与桌面端托管连接作用域不同，桌面端按官方支持的 managed/user 配置核对，不默认任意 project 配置生效。判定标准：/status 显示预期代理、同一账号同一任务（含长任务）可完成才算通过；只得到 HTTP 400/401 不能证明模型调用成功。

步骤二：路径对照

固定设备、版本、账号与相似任务，分别走原网络与手机热点，重复并记录成败。判定：得到可重复的路径差异则进入 MTU 分支；两路一致失败则回查客户端与服务端。

步骤三：MTU 对照

记录当前活动网卡 MTU 原值（不要默认 1500），macOS 在系统设置的网络详细信息中查看，受管理设备交管理员处理。对实际承载请求的接口临时调低 MTU 试一轮，案例值不是通用处方，别改错扩展坞有线口与 WiFi。用原失败请求连续复测，无改善即恢复原值。需保留反例：有作者反馈同网络其他设备在原 MTU 下完全正常。MTU 步骤是 macOS 个案的界面与操作，Windows 方式不同，不要照抄界面与命令。判定：同任务结果稳定随 MTU 变化并通过真实请求才算数。

步骤四：无线链路排查

同设备同账号同任务，改有线或 2.4GHz 观察大任务。判定：持续恢复再查路由器固件与硬件；另一网络也失败则回到其他分支。不要由单个案例泛化“5GHz 不适合 Claude”。

步骤五：无效重试循环的临时续接

有作者反馈自动重试全部失败后，ESC 输入 continue 可立即继续。操作前核对已完成的工具动作（部署、支付、写入类尤其要确认），停止当前重试，明确要求从上个完成点继续。判定：这是个案反馈的临时恢复，不说明 keep-alive 就是根因，更不算根治。

步骤六：IPv6 分支

仅在有路由证据时处理：比对失败时的实际地址族与路由日志，必要时经稳定 IPv4 路径做可恢复对照。不要把全机关闭 IPv6 写成第一步；部分运行时下的相关环境变量并不控制实际连接，不能当通用命令。

路径对照：把出口作为最后一个变量

Claude Code 长任务可能包含多次 API 请求及流式响应，连接可在建立、发送请求或接收响应时失败，不同运行时会把失败映射为不同提示。ECONNRESET 要结合日志中的失败阶段判断，不能凭报错字符串认定收到 TCP RST。

有作者把 API 目的地址经一条加密通道转发后，200 余次握手探测无重置，随后数百个流式响应基本无错误。这条路径同时改变了路由、MTU 与出口地址，差异可能还涉及地址族与中间设备：既不能反推原 IP 被封，也不能简化成“出口信誉”单一因素。

证据指向路径时，固定账号、任务与其他条件，换一条固定归属线路做受控对照：原请求多次完成才算该分支恢复。换线路只是对照手段，修不了配置残留、无线故障或上游缺陷；对照后问题仍在，应回到日志继续定位。需要固定归属出口资源的开发者，可访问 https://www.ipxss.com/ 了解。

常见问题

  • ECONNRESET 是 IP 被封了吗？不能据此判断。重置发生在 TCP 层，配置残留、MTU 不匹配、无线故障都会产生同样的报错。完成路径对照后仍指向出口时，才轮到评估 IP 因素。
  • MTU 应该直接改成某个低值吗？不要直接抄。先记录原值、临时调低、用原失败请求复测、无改善即恢复。有作者反馈调低有效，也有调整无效的反例，案例值不是通用处方。
  • curl 能通 api.anthropic.com，为什么 Claude 还报 ECONNRESET？curl 返回成功不证明 Claude 的真实模型请求正常。两者可能使用不同代理，也可能走同一路径但使用不同 TLS 运行时、连接复用或请求大小。核对双方实际配置，再用接近失败场景的请求做对照，验收以原失败任务的实际结果为准。
  • ESC 后 continue 能当常规操作吗？不能。它是无效重试循环下的单人反馈临时恢复，续接前要核对已完成的工具动作，避免重复副作用。
  • 换了网络就好了，说明原网络有问题吗？说明存在路径差异，但差异来自 MTU、无线、出口地址与中间设备中的哪一个仍需定位。换路径成功是诊断线索，不是修复结论。

总结

Claude Code ECONNRESET 的排查主线是：用 /status 核对生效代理与配置残留，做可重复的路径对照，差异明确后按 MTU、无线、IPv6 分支逐个验证，每个分支都有适用条件与反例。出口是最后一个变量，固定归属与可用性保障值得逐条验收，需要对照资源的开发者可注册 IPxSS 海外 AI 网络（https://www.ipxss.com/）。