Codex 很慢但 ChatGPT 网页正常？代理、重连与 TLS 报错排查

ChatGPT 网页能正常对话，Google 也很快，Codex 却迟迟不响应，或者反复出现 Reconnecting。遇到这种情况，先看 Codex 的连接错误，再决定是否换节点、调整代理或等待模型。

网页正常，只证明浏览器当前的访问路径可用，不能证明 Codex 的请求经过相同代理，也不能证明它的持续连接正常。 如果日志里已经出现 tls handshake eof、连接重置或连续重连，等待时间就不能全部算在模型推理上。

这篇文章针对伴随连接异常的 Codex 卡顿。排查顺序是：确认是否在重连 → 确认实际代理路径 → 检查 TLS 和普通 HTTPS → 再验证 WebSocket 或流式连接。

下面的判断使用了一次 Mac 本机实测：Tailscale 下三次真实 Codex 调用完成，保存的 AnyTLS 节点在隔离重建中出现 TLS EOF，并且连 Google HTTPS 也失败。这没有完整复现此前“网页快、只有 Codex 慢”的状态，不能当作历史故障的唯一根因。 它能帮助我们判断，遇到不同证据时应先查哪一层。

Codex 很慢，是模型在思考，还是一直在重连？

先找当前请求对应的错误，不要只看界面停留了多久。

你看到的现象或错误	接下来先检查什么
`Reconnecting...`，同时出现 `tls handshake eof`	代理路径、TLS 建连与目标转发
`stream disconnected before completion`	查看后面的具体错误；这句本身不能确定原因
WebSocket 建立后中断、关闭码 1006	对应连接的关闭时间、持续时间及中间链路
HTTP 400，明确提示模型需要更新版本	客户端版本；不要先归为网络故障
没有连接错误，只是长时间等待结果	先保留判断，不能仅凭慢就认定网络断开

本轮用同一模型、同一推理档位，只要求 Codex 返回固定文本 NETWORK_PROBE_OK：

路径	真实调用结果
Tailscale，三次独立短会话	全部完成，整次 CLI 进程耗时分别为 11.551、13.945、14.877 秒
本地 HTTP CONNECT，出站沿 Tailscale	完成，整次进程耗时 11.634 秒
本地 HTTP CONNECT，使用保存的 AnyTLS 节点	反复重连，45 秒观察窗口内没有完成

失败调用里出现了这些日志：

Reconnecting... 2/5 (... tls handshake eof)
Reconnecting... 3/5 (... tls handshake eof)
Reconnecting... 4/5 (... tls handshake eof)
Reconnecting... 5/5 (... tls handshake eof)
Reconnecting... waiting for network

这时，继续等待并不等于模型正在持续生成答案。请求正在经历连接失败与重试，应先排查连接。

表里的时间包含进程启动、认证、推理与传输，不是首字延迟，也不是纯网络耗时。45 秒是测试程序的终止上限，不能当作代理的平均响应时间。

ChatGPT 网页正常，为什么 Codex 仍可能连不上？

排查时需要分别确认浏览器、桌面端和 CLI 的实际连接。浏览器代理插件、系统代理、TUN、进程分流和终端代理环境变量，可能覆盖不同范围；不能从一个程序正常，直接推定另一个程序也走了同一条路。

在 Clash Verge 下，先检查这三件事：

Codex 发起请求时，Clash 的连接记录里是否出现对应流量。 终端里设置了变量，还不算验证请求已经经过代理。
命中的规则和出口是否符合预期。 检查当前请求，而不是只看节点选择界面。
比较的是同一个使用位置。 CLI 测通，不等于桌面端所有后台连接都测通；网页能对话，也不能代替桌面端的连接测试。

本轮真实 CLI 代理测试中，隔离代理的连接记录出现了 chatgpt.com，因此能够确认请求进入了这个代理入口。另做的 HTTP CONNECT 正对照能完成真实请求，说明这套客户端在本轮可以通过该入口工作。

但桌面日志里报错的 durable/app-server 通道，要单独分析。OpenAI 的文档也分别列出了 SSE、WebSocket 请求与事件等观测类别，不能把不同通道的成功与失败合成一个“Codex 网络正常”的结论。Codex 连接遥测事件分类

如果浏览器正常，而 Codex 的对应流量没有出现在预期代理里，优先纠正这条请求的代理路径。此时反复更换节点，可能根本没有改变出问题的连接。

Codex 报 tls handshake eof，应该先查什么？

tls handshake eof 指向 TLS 握手过程中的提前结束。它不是“WebSocket 已经正常建立，后来空闲超时”的同义词。先确认普通 HTTPS 能否经过同一代理，再研究应用层的持续连接。

检查同一代理能否完成普通 HTTPS

用一个简单的 HTTPS 地址，分别经过当前系统网络和明确指定的本地代理。本地代理端口应以正在运行的客户端为准；只测浏览器里的同一个网址，仍然无法确认 Codex 使用的路径。

下面是可替换端口的命令示例。7897 只是示例值，要改成你当前的 Clash HTTP 或 mixed 端口；本次实验实际使用的是脚本分配的临时端口。

# 不显式使用 HTTP 代理，沿当前系统路由访问。
# 如果开着 TUN 或 Tailscale，这不等于绕过它们。
curl --noproxy '*' --connect-timeout 10 --max-time 25 \
  -o /dev/null -sS -w 'HTTP=%{http_code} total=%{time_total}s\n' \
  https://www.google.com/generate_204

# 明确经过本地 HTTP/mixed 代理入口。
curl --proxy http://127.0.0.1:7897 --noproxy '' \
  --connect-timeout 10 --max-time 25 \
  -o /dev/null -sS -w 'HTTP=%{http_code} total=%{time_total}s\n' \
  https://www.google.com/generate_204

如果先报本地端口无法连接，先确认 Clash 正在运行、端口填写正确；这还没有测到远端节点。若进入 TLS 阶段才失败，再检查节点及目标转发。两个命令都成功，也只能说明短 HTTPS 可用，还要继续验证 Codex。

本轮对每个目标、每条路径各测了三次：

测试目标	Tailscale 路径	保存节点的隔离代理路径
Google `generate_204`	三次均为 HTTP 204	三次均为 curl 35，没有 HTTP 响应
ChatGPT 首页	三次均为 HTTP 403	三次均为 curl 35，没有 HTTP 响应
Codex responses 地址的未认证 GET	三次均为 HTTP 405	三次均为 curl 35，没有 HTTP 响应

curl 35 属于 SSL/TLS 建连错误，本轮信息是 SSL_ERROR_SYSCALL。curl 错误码说明

这里的 403、405 不能算作 ChatGPT 或 Codex 功能正常，只说明探测取得了 HTTP 响应；未认证 GET 更不能替代合法的模型调用。真正的应用验证是上一节返回固定标记的请求。

不过，代理路径连 Google HTTPS 也失败，足以改变排查顺序：先恢复通用 HTTPS 转发，而不是先把故障锁定为 Codex 的 WebSocket。

节点能连上，不代表能替你连接 OpenAI

如果代理入口可以连接，接下来仍要检查认证、协议兼容性与目标转发。

本轮绕过代理客户端，用原生 socket 绑定物理网卡，分别连接节点解析出的四个 IPv4 入口。四个入口的 TCP 建连都成功，用时约 4–7 ms；带证书校验的 TLS 握手也都成功，总耗时约 248–553 ms。

这只能说明入口可达。代理链路还包含后续步骤：

本机 → 代理入口 TCP/TLS → 认证、协议处理与转发 → 目标服务

入口 TLS 成功，与经代理访问目标站的 TLS 成功，是两项不同的验证。 前者不能证明 AnyTLS 认证通过，也不能证明节点能够访问 Google 或 OpenAI。

本轮将节点域名固定成一个解析出的 IP 后，Google HTTPS 仍然失败；相同实现的本地 HTTP CONNECT 入口改为 DIRECT、沿 Tailscale 出站，则能返回 Google 204。这些对照将关注点推向节点协议与客户端兼容性、认证及转发状态、服务端出站记录，但还不足以选定唯一根因。

如果你的结果与此相同，下一步应取得这些环节的错误记录，而不是用“ping 很低”或“服务器端口能连接”结束排查。

Codex 一直 Reconnecting，需要关闭 WebSocket 吗？

先区分两件事：Codex 应用使用的 WebSocket，以及代理节点使用的传输协议。

本轮保存的选中节点是 AnyTLS，并不是配置里的 VLESS/WS 节点。因此，“这个节点套了 WS，导致 Codex 很慢”的猜想，与当前保存的节点类型不符。但 Codex 自己的 WebSocket 经过它时，仍然可能失败。

是否需要检查 WebSocket，要看连接已经进行到哪一步：

已有证据	排查重点
普通 HTTPS 也无法完成 TLS 握手	先修复代理建连和转发
普通 HTTPS 正常，但 WS 握手失败	检查对应连接的握手、代理路径与访问策略
WS 已建立，持续使用或空闲后断开	记录断开时机，检查连接保持与中间链路

本轮用 Postman 的公开 WSS Echo 服务验证了持续连接：Tailscale 下先交换五条消息，关闭测试客户端的主动定时 ping，空闲 90 秒，再交换五条，十条回显全部匹配。关闭主动 ping 不等于消除了 TCP 保活或服务端可能发送的帧。Postman Echo 说明

另一个 HTTP CONNECT/DIRECT 正对照也能完成 WSS 握手和回显。它说明这个本地代理入口能够承载 WSS，不能推广为所有代理节点都正常；公开 Echo 服务也不能代替 Codex 的具体端点。

历史桌面日志中，明确找到 10 条 websocket_error 和 15 条 reconnect_started 事件，涉及 durable 通道。这些是事件记录，不等于 25 次独立故障；同一个错误还可能传播到多条状态日志中。

关闭码 1006 也只表示异常关闭，不能仅凭它判断是谁中断了连接。WebSocket 异常关闭码的 RFC 定义

因此，出现 Reconnecting 后，不应直接套用“关闭 WS”的配置。本轮失败在 TLS 阶段就已出现，尚无证据把修改 WebSocket 空闲超时当作对应修复。

换 Tailscale 能解决 Codex 卡顿吗？

对这台 Mac 的本轮短请求测试，Tailscale 是已经验证可用的路径；它不是普遍更快的保证。 三次真实 Codex 调用和 90 秒空闲回显，比单纯测速更能支持当前是否继续使用它的选择。

Tailscale 使用 WireGuard，能直连时通过 UDP 传输，无法直连时可能使用中继。Codex 的 WebSocket 可以运行在它的隧道里；切换 Tailscale 并不等于关闭了 WebSocket。Tailscale 连接说明

本轮 Tailscale 的 20 次发现探测里，成功 17 次、超时 3 次，成功样本的 RTT 中位数为 188 ms。这不能直接当作业务流量的长期丢包率，却也说明“能用”不等于“零延迟、零异常”。

同样，dig 不能证明 163 骨干网拥塞。本轮 ChatGPT 域名的三次 A 查询都成功，用时 185–233 ms；它们测的是 DNS 查询，不能替代 TCP、TLS 和实际应用请求。本轮没有取得足以确认 163 骨干网拥塞的路径证据。

如果切换出口后 Codex 恢复，能够确认的是“更换路径改变了结果”。要进一步归因于某个运营商、共享节点负载或代理协议，还需要与该判断对应的证据。

怎样确认 Codex 已恢复，而不是网页刚好能打开？

在出现问题的那个客户端里验证，而不是只回到浏览器刷新首页。

发一个不调用工具的短请求。 保持同一模型与推理档位，确认能收到完整结果，避免把工具执行时间混入连接测试。
确认对应请求的代理规则、出口和错误记录。 检查是否仍有重连；设置了代理不等于请求已经经过它。
再验证原先会失败的工作流。 短请求成功不能代替长任务、空闲恢复或桌面后台通道的验证。本轮只完成了短模型请求，没有证明长工作流已恢复。

桌面端可以直接发送“不要读取文件或调用工具，只回复 NETWORK_PROBE_OK”。CLI 用户可参考下面的短请求示例；它会实际调用模型，并非离线检查：

codex exec --ephemeral --skip-git-repo-check --sandbox read-only \
  '不要读取文件或调用工具，只回复 NETWORK_PROBE_OK'

用你实际出问题的版本和设置验证，并记录错误与完成情况。不要因为另一套 CLI 能回答，就宣布桌面端也恢复了。

客户端明确提示模型需要更新版本时，应先解决版本兼容性。本轮首次测试就遇到了这个情况：独立 CLI 0.151.0 返回 HTTP 400；随后使用应用内附的 0.164.0-alpha.11.1 重测。前一次没有算作网络失败。

针对当前结果，可执行的选择是：继续使用已经完成真实调用的 Tailscale；排查这套代理时，先恢复普通 HTTPS，再验证 Codex 的具体连接。若要解释此前“网页正常、只有 Codex 慢”的故障，还需要在那个条件重现时同步记录连接与出口。

测试范围： 本文数据来自 2026 年 10 月 27 日凌晨的 Mac 本机测试。代理实验读取保存的 AnyTLS 节点参数，在独立 mihomo 进程中重建，没有启动原 Clash GUI/TUN，也没有切换系统代理或 Tailscale 出口。虽然配置了物理网卡绑定，nettop 未捕获该 AnyTLS 进程可确认的上游接口，不能声称两条完整物理路径已完全独立验证。CLI、桌面 durable 通道及公开 Echo 的结果均分别记录；原始数据、脚本和详细条件保存在配套实验材料中。