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 的結果均分別紀錄；原始數據、腳本和詳細條件保存在配套實驗材料中。