本文目錄
短提示也重連,先把問題限定在連線鏈路
這篇文章處理 Codex App 或 CLI 發出簡單提示後,介面依序顯示 Reconnecting 1/5 到 5/5,最後出現 stream disconnected before completion 的情況。OpenAI 官方 issue #23061 記錄了同樣的錯誤路徑,說明它不一定來自提示詞、儲存庫大小或上下文長度。
Codex 的普通 HTTPS 請求成功,也不代表串流回覆一定穩定。OpenAI 網路文件說明 Codex 還會透過 wss://chatgpt.com/ 建立安全 WebSocket;應用接入代理、Clash 規則、節點出口和長連線策略中的任一環節都可能中斷回覆。
先按對照結果分組
| 現象 | 更可能的斷點 | 繼續檢查 |
|---|---|---|
| OpenAI 狀態頁同時報告故障 | 伺服器端事件 | 等待恢復後重新測試 |
| App 失敗,CLI 在同一網路可用 | 兩種介面的代理接入不同 | 比較版本與啟動方式 |
| 短回覆成功,長回覆中途重連 | WebSocket 或代理長連線被提前關閉 | 檢查 443、TLS 和超時 |
| App 與 CLI 都不出現在 Clash 連線頁 | 請求沒有進入目前代理入口 | 核對系統代理、TUN 或連接埠 |
- Codex App 或 CLI發起登入、HTTPS 與串流請求
- 系統代理、環境變數或 TUN決定請求是否進入 Clash
- Clash 規則與節點為 chatgpt.com 選擇實際出口
- OpenAI WebSocket在 443 連接埠維持模型串流連線
短請求成功而回覆中途反覆重連,常見斷點不在提示詞本身,而在應用接入代理、規則出站或 WebSocket 長連線之間。
用狀態頁和另一條網路排除共同故障
先查看 status.openai.com 是否存在正在處理的 ChatGPT 或 Codex 事件。若狀態頁有明確故障,保留錯誤時間並等待恢復;此時切換大量節點或重寫規則只會破壞原來的對照條件。
狀態頁正常時,固定同一個短提示和帳號,分別在目前 Clash 節點、另一個已知可用節點、手機熱點或不經過企業閘道的網路上測試。只要換網路立即恢復,就應繼續檢查本機代理或公司網路,而不是刪除 Codex 會話。
建立三組可復現對照
記錄準確錯誤
儲存 Reconnecting 次數、失敗 URL、發生時間、Codex App 與 CLI 版本,不公開會話內容或令牌。
固定最小請求
在新任務傳送同一句短提示,避免長上下文、工具呼叫和儲存庫掃描干擾網路判斷。
只換一次出口
先換一個確認可用的 Clash 節點,再換手機熱點;每次都觀察是否出現同一錯誤。
恢復原節點
對照完成後回到原策略群組,避免後續結果來自尚未記錄的新出口。
在 Clash 連線頁確認 Codex 真的進入代理
開啟 Clash Verge Rev 的連線頁並清空舊篩選,再從 Codex 發出一次新提示。重點尋找 chatgpt.com 及相關 OpenAI 網域,並記錄命中的規則、策略群組和實際節點;只看到瀏覽器流量不能證明 Codex App 或 CLI 使用了同一路徑。
日常仍應使用 Rule 模式。為了判斷是否是漏規則,可以短時間切到 Global 並固定同一節點重新測試;若 Global 恢復而 Rule 失敗,說明請求已進入 Clash,問題在規則或策略選擇,不必繼續修改 Codex。測試後立即切回原模式。
Codex 請求出現並走預期節點
代理入口已接通,繼續檢查 WebSocket、TLS 檢查和長連線超時。
請求出現但命中 DIRECT
短時用 Global 對照,再從連線記錄補充可解釋的規則。
完全沒有 Codex 新連線
系統代理可能未被該處理程式讀取,或 CLI 沒有繼承目前終端的代理變數。
所有網域都持續 timeout
先換節點或網路,不要把整組上游故障當成 Codex 專屬問題。
分別測試 App 與 CLI,不把兩者當成同一處理程式
Codex 官方疑難排解說明提醒,桌面 App 和 CLI 可能包含不同版本。先記錄兩邊版本,再在同一網路和節點傳送送同一句短提示;App 成功而 CLI 失敗,或反過來,都說明帳號與 OpenAI 服務不是唯一變數。
codex --version
/Applications/Codex.app/Contents/Resources/codex --version版本和結果如何解釋
| 對照 | 判斷 | 下一步 |
|---|---|---|
| App 與 CLI 版本不同 | 先更新較舊的一側再重新測試 | 保持節點與提示不變 |
| CLI 可用,App 持續重連 | App 可能沒有沿用終端環境變數 | 用 TUN 或系統代理做獨立對照 |
| App 可用,CLI 持續重連 | 目前 shell 代理變數或啟動環境異常 | 檢查變數和實際 HTTP 連接埠 |
| 兩邊都在同一階段失敗 | 更像共同節點、規則或 WebSocket 問題 | 繼續檢查網路控制 |
允許 Codex 的 WebSocket 在 443 連接埠持續連線
OpenAI 官方網路建議要求代理、防火牆或安全閘道允許 chatgpt.com 在 TCP 443 上完成標準的 Upgrade: websocket 握手。若網頁和登入可用,但回覆總在產生途中斷開,應讓網路管理員檢查 WebSocket 空閒超時、最大訊息大小以及是否提前關閉長連線。
企業網路若啟用了 TLS 檢查,還要確認它沒有替換錯誤憑證、改寫握手或只允許普通 HTTPS。最有價值的對照是在手機熱點上使用同一帳號和同一 Codex 版本;熱點穩定而公司網路失敗,才把問題交給網路策略處理。
交給管理員的最小檢查項
- 允許 chatgpt.com 的 TCP 443 與 WebSocket Upgrade
- 長連線不會被過短的 idle timeout 提前關閉
- TLS 檢查信任鏈對 HTTPS、登入與安全 WebSocket 一致
- 官方列出的 ChatGPT、OpenAI 與靜態資源網域沒有被改寫
- 手機熱點對照已排除帳號、提示詞和本機版本問題
只在目前終端測試 Clash 的 HTTP 代理入口
OpenAI Codex issue #20844 是仍未關閉的使用者報告:同一代理棧使用 SOCKS5 時出現 stream disconnected,改成顯式 HTTP_PROXY 與 HTTPS_PROXY 後恢復。它不是官方承諾的通用修復,但可以用來判斷 SOCKS 路徑和 HTTP 路徑是否表現不同。
先在 Clash Verge Rev 設定中確認 HTTP 或 Mixed 連接埠。下面的 7897 只是示例,必須換成本機實際連接埠;變數只寫入目前終端,不要先放進 shell 設定或系統環境。
export HTTP_PROXY=http://127.0.0.1:7897
export HTTPS_PROXY=http://127.0.0.1:7897
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
unset ALL_PROXY all_proxy
codex$env:HTTP_PROXY="http://127.0.0.1:7897"
$env:HTTPS_PROXY="http://127.0.0.1:7897"
Remove-Item Env:ALL_PROXY -ErrorAction SilentlyContinue
codexCLI 立即穩定,連線頁顯示 chatgpt.com
保留該終端作為臨時工作路徑,並繼續檢查 App 是否需要 TUN 接管。
HTTP 可用、SOCKS5 仍斷流
優先使用已驗證的 HTTP 或 Mixed 入口,關注對應官方 issue 的後續修復。
兩種代理都失敗,但手機熱點正常
檢查 Clash 節點、規則與 WebSocket 轉發,不要把變數永久寫入系統。
新處理程式仍不出現在連線頁
連接埠可能寫錯或命令沒有在同一終端啟動,關閉處理程式後核對設定再試。
撤銷臨時變數,再完成四項串流驗證
測試無效或準備切回系統代理時,先退出本次啟動的 Codex,再關閉目前終端即可撤銷臨時變數。若變數已寫入 shell 設定或 Windows 使用者環境,應刪除本次新增項並開啟新終端;不要同時保留舊 SOCKS、HTTP 與 TUN 三條未知路徑。
若 App 只有在 TUN 下穩定,先把它作為可還原的臨時接入方式,並保留關閉 TUN 後系統代理可恢復的基線。後續更新 Codex 或 Clash Verge Rev 後,用同一驗證清單重新測試,再決定是否繼續保留 TUN。
最終驗證清單
- App 與 CLI 各傳送一次短提示,都不再進入 Reconnecting 計數
- 連續產生一段較長回覆,未出現 stream disconnected before completion
- Clash 連線頁顯示 chatgpt.com 命中預期規則與固定節點
- 退出 Codex 並關閉臨時代理後,系統網路能恢復原狀態
