Codex 配置代理後仍連不上：CLI、桌面版與 Remote SSH 排查

更新於 2026-10-27 · peizhibang.com

簡答：Codex 配置代理後仍連不上，CLI 先查環境變數與 GET，桌面版查程序是否繼承系統代理，Remote SSH 則在遠端檢查 PATH、Shell 與 app-server；

定義：這裡的「Codex 配置代理」是指為 Codex CLI、桌面版或 Remote SSH 環境設定 HTTP、HTTPS 或 SOCKS5 代理，並確認實際請求是否經過預期的網路路徑。

先試這一步：三行速查判斷請求在哪裡失敗

更新於 2026 年 10 月 27 日。若瀏覽器可以開啟頁面，但 Codex 仍然登入逾時、反覆重新連線或顯示 WebSocket 錯誤，先不要急著覆蓋設定檔。先分辨請求由哪個程序和哪台機器發出：CLI 查目前終端，桌面版查應用程序與系統代理，Remote SSH 則查遠端主機。

Codex 配置代理三行速查

場景	先查什麼	結果如何判讀
CLI	`which codex`、`env \| grep -i proxy` 或 `Get-ChildItem Env: \| Where-Object Name -match 'PROXY'`	確認目前啟動 Codex 的終端是否真的有代理變數
桌面版	查看系統代理、Codex 日誌與代理客戶端連線面板	瀏覽器可用不代表桌面背景程序或 WSS 已使用相同路徑
Remote SSH	在遠端執行 `which codex`、`command -v sh`、`command -v mkdir` 和代理基線測試	SSH 可登入不代表遠端 app-server bootstrap 已成功

官方文件指出，Codex CLI 可用 RUST_LOG 設定日誌，亦可用 log_dir 產生文字日誌；可參考 Codex 安裝與日誌文件。目前官方配置入口則分為基本、進階和完整參考，見 Codex 設定文件。

HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXY 怎麼分工

Codex 的代理行為會依請求協定選擇路徑。官方目前的出站代理實作顯示，HTTPS 會優先查找 HTTPS_PROXY，Secure WebSocket 會依序查找 HTTPS_PROXY、HTTP_PROXY 和 ALL_PROXY；沒有可用代理時可能回到直連。這是目前實作的行為，升級後仍應重新核對Codex 出站代理實作。

Codex 代理變數對照

變數	作用	常見誤配
`HTTP_PROXY`	HTTP 請求的代理候選	填入 SOCKS5 連接埠，或只設定它而沒有 HTTPS 路徑
`HTTPS_PROXY`	HTTPS 請求的代理候選	把控制連接埠當成 HTTP 代理連接埠
`ALL_PROXY`	其他協定或沒有專用變數時的回退路徑	未確認支援就使用 SOCKS5 URL
`NO_PROXY`	指定不經代理、直接連線的主機或網域	漏掉本機回呼位址，或用 `*` 排除所有請求

NO_PROXY 不是關閉代理的總開關，而是例外清單。登入回呼、本機開發伺服器或控制介面通常需要檢查 localhost、127.0.0.1 和 ::1。設定過寬可能令 Codex 改為直連；完全沒有本機例外，則可能令回呼請求被送入遠端代理。實際匹配規則要以目前版本和請求庫行為為準。

先查看目前環境：

env | grep -i proxy

Windows PowerShell：

Get-ChildItem Env: | Where-Object Name -match 'PROXY'

三個系統的設定檔與環境變數差異

不要直接套用網路文章中的固定路徑。官方文件與目前實作以 CODEX_HOME 及應用程式實際環境為準；若未設定，Unix 類環境通常以使用者家目錄下的 .codex 作為工作目錄。Windows、macOS、Linux 的差異，首先要用命令確認，而不是只憑路徑猜測。

Windows、macOS、Linux 檢查方式

平台	先確認設定目錄	環境變數檢查與設定
Windows PowerShell	`$env:CODEX_HOME`；未輸出時再檢查 `$HOME\.codex`	`Get-ChildItem Env: \| Where-Object Name -match 'PROXY'` `$env:HTTP_PROXY="http://127.0.0.1:連接埠號"`
macOS	`echo $CODEX_HOME`；未設定時檢查 `$HOME/.codex`	`env \| grep -i proxy` `export HTTP_PROXY="http://127.0.0.1:連接埠號"`
Linux	`echo $CODEX_HOME`；未設定時檢查 `$HOME/.codex`	`env \| grep -i proxy` `export HTTPS_PROXY="http://127.0.0.1:連接埠號"`

這些命令只用來查看目前程序實際看到的值。桌面版、WSL、容器和 Remote SSH 可能有自己的啟動環境；在本機終端輸出的結果，不能直接代表桌面背景程序或遠端擴充套件宿主也看得到相同變數。修改前先備份設定，修改後完全退出並重新啟動相關程序。

CLI：先用進程級代理完成最小驗證

macOS 或 Linux 先在啟動 Codex 的同一個終端執行：

export HTTP_PROXY="http://127.0.0.1:連接埠號"

export HTTPS_PROXY="http://127.0.0.1:連接埠號"

export ALL_PROXY="http://127.0.0.1:連接埠號"

curl --proxy "$HTTP_PROXY" --user-agent "codex-proxy-check/1.0" --get --write-out "%{http_code}\n" --output /dev/null https://chatgpt.com/

該命令使用 GET，只能證明指定代理完成了一次 HTTPS 請求，不能單獨證明 Codex 的 WebSocket 已連通。若有狀態碼且代理面板出現對應連線，再啟動：

codex

若需要文字日誌，可使用：

codex -c log_dir=./.codex-log

tail -F ./.codex-log/codex-tui.log

Windows PowerShell 可用：

$proxy = "http://127.0.0.1:連接埠號"

$result = Invoke-WebRequest -Uri "https://chatgpt.com/" -Method Get -Proxy $proxy -UserAgent "codex-proxy-check/1.0"

$result.StatusCode

如果 GET 成功但 Codex 沒有對應代理記錄，優先檢查 Codex 是否在另一個 Shell、WSL、容器或遠端環境中執行。使用 SOCKS5 前，先確認目前客戶端與請求庫支援，再考慮 socks5h://127.0.0.1:連接埠號；不要混用 HTTP、SOCKS5 和控制連接埠。

桌面版：系統代理有效，不代表 WebSocket 已接管

目前官方 HTTP 客戶端說明指出，respect_system_proxy 會解析平台系統設定、PAC/WPAD，再處理環境變數和直連回退；這是目前版本的實作細節，不應視為所有舊版本或所有桌面元件都完全相同。參考 Codex HTTP 客戶端說明。

如果目前版本支援該功能，可在備份後測試：

[features]

respect_system_proxy = true

修改後完全退出桌面版再重新開啟，不要只關閉視窗，也不要用網路模板覆蓋整個 config.toml。若設定鍵不被目前版本識別，應撤銷變更，改用進程級環境變數或 TUN 做對照。

典型現象與下一步

現象	優先判斷	下一步
CLI 可用但桌面版失敗	桌面程序未繼承終端變數，或採用不同系統代理策略	查桌面日誌、設定開關和代理面板，完全重啟後重試
GET 成功但 WSS 超時	普通 HTTPS 路徑可用，長連線或代理認證仍可能失敗	核對 `HTTPS_PROXY`、`ALL_PROXY`、WSS 路由和 TLS 錯誤
開啟 TUN 後恢復	透明路由捕獲了原先未正確代理的連線	先記錄規則命中、DNS、IPv6 和本機回呼，再決定是否長期啟用

Remote SSH：SSH 可登入，不代表 app-server 已啟動

Remote SSH 的代理檢查必須在遠端主機進行。本機的 127.0.0.1 指向本機電腦，遠端主機中的 127.0.0.1 則指向遠端主機本身。先在遠端終端執行：

which codex

env | grep -i proxy

command -v sh

command -v mkdir

command -v chmod

echo "$PATH"

接著執行直連基線測試：

curl --user-agent "codex-proxy-check/1.0" --get --write-out "%{http_code}\n" --output /dev/null https://chatgpt.com/

這條命令刻意沒有 --proxy，只用來確認遠端主機不指定代理時的直連結果；它不能證明遠端代理已生效。若要測試遠端代理，必須先在遠端設定代理變數，或明確加入：

curl --proxy "$HTTPS_PROXY" --user-agent "codex-proxy-check/1.0" --get --write-out "%{http_code}\n" --output /dev/null https://chatgpt.com/

SSH 設定應使用具體的 Host 別名，而不是只依賴 Host *。互動式 SSH 能找到 Codex，也不代表非互動 Shell、Node/nvm 或桌面啟動命令能找到相同的 PATH。

官方問題報告記錄過特定環境：SSH 認證和 codex --version 探測成功，但 app-server bootstrap 階段因找不到 mkdir 而失敗，介面最後顯示 WebSocket code=1006。這是特定版本與環境的公開案例，不代表所有版本都會如此，詳見官方問題報告。因此應先查看桌面日誌，再修正遠端 PATH、Shell、mkdir、chmod 或 Codex 安裝位置；不要把 app-server 直接暴露到公網，也不要關閉 TLS 憑證驗證。

WebSocket、TUN 與錯誤日誌：按順序收斂問題

先記錄版本：記下 Codex CLI、桌面版、作業系統、WSL 或遠端主機，以及代理客戶端版本。升級後不要直接套用舊設定鍵。
再看代理記錄：確認目標 HTTPS 或 WSS 連線不是 DIRECT；完全沒有記錄時，先檢查實際執行端、監聽位址和連接埠。
再看 Codex 日誌：可搜尋 1006、open_timeout、connection reset、proxy_407、tls_error、invalid_proxy_config 或 resolver_error。其中部分名稱來自目前官方實作，其他則可能是應用程式或網路層訊息，應以目前版本實際日誌為準。
最後做對照：只設定必要的 HTTP_PROXY、HTTPS_PROXY 和 NO_PROXY，完全重啟 Codex，再比較錯誤是否變化。

若出現 407，檢查代理認證，不要把帳號、密碼、Cookie、令牌或完整回呼連結貼到公開日誌。若出現 TLS 或憑證錯誤，不要關閉憑證校驗，應確認代理鏈路、系統信任憑證和企業 CA。普通 GET 成功，不能代替 Codex 真實 WebSocket 驗證。

完成後至少保留四項結果：Codex 執行端、代理協定與連接埠、GET 測試結果、WebSocket 日誌及代理面板是否同時出現目標連線。這能區分代理不可用、Codex 沒有使用代理，以及普通 HTTPS 成功但長連線失敗。

FAQ：Codex 配置代理後仍連不上怎麼辦

Codex 配置代理後，為什麼瀏覽器能用但 Codex 仍連不上？瀏覽器可能使用系統代理，但 Codex 程序沒有繼承系統代理或環境變數。先確認實際執行端，再用同一環境設定 HTTP_PROXY、HTTPS_PROXY 做 GET 對照。

NO_PROXY 要怎麼設定？NO_PROXY 只用來指定直連例外，先檢查 localhost、127.0.0.1 和 ::1。設定成 * 可能令所有請求繞過代理，應按實際回呼位址逐項測試。

開啟 TUN 後 Codex 恢復，是否代表必須一直開啟？不一定。這只代表透明路由捕獲了此前未正確代理的連線；先檢查進程級變數、系統代理、WSS 規則、DNS、IPv6 和本機回呼，再決定是否保留。

SSH 可以登入，但 Remote SSH 顯示 WebSocket 1006，怎麼辦？SSH 認證成功不代表 app-server bootstrap 成功。應在遠端檢查 codex、sh、mkdir、chmod 和 PATH，再查看桌面版日誌；官方問題報告已記錄過特定環境的類似現象。

Remote SSH 的 curl 命令為什麼不加 --proxy？不加 --proxy 的命令只是直連基線，用來確認遠端主機本身的 HTTPS 結果。要驗證代理，必須先設定遠端 HTTPS_PROXY，或在命令中明確加入 --proxy "$HTTPS_PROXY"。

修改 OPENAI_BASE_URL 可以取代代理嗎？不能直接等同。代理改變連線路徑，API 位址改變請求目標；只有官方文件明確支援的 API 工作流才應設定自訂端點，未知中轉位址和認證方式未核實，不建議直接使用。

常見問題

Codex 配置代理後，為什麼瀏覽器能用但 Codex 仍連不上？

瀏覽器可能使用系統代理，但 Codex 程序沒有繼承系統代理或環境變數。先確認實際執行端，再用同一環境設定 HTTP_PROXY、HTTPS_PROXY 做 GET 對照。

NO_PROXY 要怎麼設定？

NO_PROXY 只用來指定直連例外，先檢查 localhost、127.0.0.1 和 ::1。設定成 * 可能令所有請求繞過代理，應按實際回呼位址逐項測試。

開啟 TUN 後 Codex 恢復，是否代表必須一直開啟？

不一定。這只代表透明路由捕獲了此前未正確代理的連線；先檢查進程級變數、系統代理、WSS 規則、DNS、IPv6 和本機回呼，再決定是否保留。

SSH 可以登入，但 Remote SSH 顯示 WebSocket 1006，怎麼辦？

SSH 認證成功不代表 app-server bootstrap 成功。應在遠端檢查 codex、sh、mkdir、chmod 和 PATH，再查看桌面版日誌；官方問題報告已記錄過特定環境的類似現象。

Remote SSH 的 curl 命令為什麼不加 --proxy？

不加 --proxy 的命令只是直連基線，用來確認遠端主機本身的 HTTPS 結果。要驗證代理，必須先設定遠端 HTTPS_PROXY，或在命令中明確加入 --proxy "$HTTPS_PROXY"。

修改 OPENAI_BASE_URL 可以取代代理嗎？

不能直接等同。代理改變連線路徑，API 位址改變請求目標；只有官方文件明確支援的 API 工作流才應設定自訂端點，未知中轉位址和認證方式未核實，不建議直接使用。