目錄
  1. 一、 第一層：Codex 根本沒有走上本機的代理埠
  2. 1. 查詢本機真實的代理監聽埠
  3. 2. 在 Codex 設定檔中注入代理參數
  4. 二、 第二層：設定後仍報 TLS unexpected-eof？將代理升級為 SOCKS5H
  5. 解決方案：使用 SOCKS5H 協議接管並開啟遠端 DNS 解析
  6. 三、 終極保底：開啟代理軟體的 TUN 虛擬網卡模式

Codex 持續 Reconnecting 怎麼解決？從本地代理、SOCKS5H 到 TUN 模式徹底搞定 TLS 斷流

日常在做 VibeCoding 時，很多開發者最抓狂的場景莫過於：正讓 Codex 進行多檔案重構或生成複雜模組，介面頂部或右下角突然開始瘋狂彈出 Reconnecting...，終端甚至直接拋出底層斷流報錯：

stream disconnected before completion:
IO error: peer closed connection without sending TLS close_notify

Codex 持續 Reconnecting 與 TLS unexpected-eof 報錯實錄

很多人的第一反應通常是：「是不是節點崩了？趕緊換個節點試試。」但往往切了一圈節點，發現 Codex 依舊頻繁斷連、掉線、重新連線。

其實，這種頻繁重連的根因極少是節點本身癱瘓，90% 以上都出在本地代理埠繫結與 TLS 長連線握手策略上。根據我的實測排錯經驗，問題通常分為兩層，順著排查，不用換節點就能徹底解決。

一、 第一層：Codex 根本沒有走上本機的代理埠

Codex 在國內網路環境下呼叫雲端模型 API 時，必須依賴本機的本地代理。如果你只是打開了梯子/代理用戶端，但沒有給 Codex 設定正確的環境變數，用戶端可能在不斷嘗試直連，最終觸發連線超時重連。

1. 查詢本機真實的代理監聽埠

切忌主觀臆測代理埠（比如盲目假設埠一定是 7890）。代理用戶端（Clash、Mihomo、Surge、v2ray 等）在不同系統或版本上的 mixed-port 可能完全不同。

Windows 檢查命令：

在 PowerShell 或 CMD 中排查：

netstat -ano | findstr "LISTEN"

或者在工作管理員中檢視 Clash/Mihomo 的設定詳情，確認 mixed-port 或 http-port 的真實數值。

macOS 檢查命令：

在 Terminal 中執行：

# 查看系统代理设置
scutil --proxy

# 或直接过滤监听代理端口的进程
lsof -nP -iTCP -sTCP:LISTEN | grep -Ei "clash|mihomo|surge|v2ray|xray"

重點確認實際監聽的 mixed-port 埠（記為 <PORT>，例如 Clash 常見的 7890）。

2. 在 Codex 設定檔中注入代理參數

Codex 允許在使用者目錄下的設定檔中宣告網路代理環境：

  • 設定檔路徑：
    • Windows：%USERPROFILE%\.codex\.env
    • macOS / Linux：~/.codex/.env

編輯（若不存在則新建）該檔案，追加以下標準代理參數（請將 <PORT> 替換為您在上一步查得的真實埠）：

HTTP_PROXY="http://127.0.0.1:<PORT>"
HTTPS_PROXY="http://127.0.0.1:<PORT>"
NO_PROXY="localhost,127.0.0.1,::1"

儲存後徹底重啟 Codex 用戶端：

  • Windows：從系統托盤徹底退出，並在工作管理員確認程序結束；
  • macOS：按下 Cmd + Q 完全退出應用後重新開啟。

二、 第二層：設定後仍報 TLS unexpected-eof？將代理升級為 SOCKS5H

如果加上了上述設定，Codex 依然斷流，且報錯變成： IO error: peer closed connection without sending TLS close_notify

這說明 Codex 已經走上了你的本地代理，但 HTTP CONNECT 隧道在傳輸長資料流時，被代理中介軟體或鏈路提前掐斷了。更關鍵的是，預設的 http:// 代理在發起請求前，DNS 解析通常仍然發生在本機系統，容易受到汙染或鏈路阻斷。

解決方案：使用 SOCKS5H 協議接管並開啟遠端 DNS 解析

如果你的代理用戶端支援 SOCKS5（Clash 的 mixed-port 原生同時支援 HTTP 和 SOCKS5），直接將應用層協議切換為 socks5h：

修改 ~/.codex/.env 檔案為：

HTTP_PROXY="http://127.0.0.1:<PORT>"
HTTPS_PROXY="socks5h://127.0.0.1:<PORT>"
ALL_PROXY="socks5h://127.0.0.1:<PORT>"
NO_PROXY="localhost,127.0.0.1,::1"

注意其中的 socks5h:// 標識： socks5:// 會在本機做 DNS 解析後再發請求；而 socks5h:// 會把網域原封不動交給遠端代理伺服器去解析 DNS，徹底消除本機 DNS 汙染和握手被中間重置的頑疾。

設定完成後再次徹底重啟 Codex 程序。

Codex 本機長連線代理演進與斷流排查架構

三、 終極保底：開啟代理軟體的 TUN 虛擬網卡模式

在極少數情況下，Codex 用戶端內部依賴的某些原生二進位制依賴或子程序可能不尊重 .env 裡的環境變數。

如果你改了 socks5h 依然偶爾遇到流斷裂，最穩定、最一勞永逸的做法是：開啟代理軟體的 TUN 虛擬網卡接管模式。

  1. 進入你的代理用戶端設定（如 Clash Verge、Mihomo Party、Surge 等）；
  2. 開啟 TUN Mode（虛擬網卡接管）；
  3. 清空 ~/.codex/.env 中的 HTTP_PROXY / HTTPS_PROXY / ALL_PROXY 宣告。

此時，作業系統的所有底層網路資料包（包括 Codex 產生的所有 TCP/UDP 連線）都會由虛擬網卡驅動直接接管分流，應用層無需再設定任何繁瑣的環境變數，從根本上杜絕了長連線斷流和 TLS 異常斷開的問題。