前言:為什麼 Codex CLI 需要穩定的代理環境?
OpenAI Codex CLI 是面向開發者的終端工具,可以在命令列中讀取專案檔案、分析程式碼、協助編寫功能、執行測試,並根據自然語言指令完成多種開發工作。對習慣使用 Terminal、PowerShell 或各類 IDE 終端機的使用者來說,它比單純打開網頁聊天更貼近實際的編程流程。
然而,國內使用者在安裝 Codex CLI、完成 OpenAI 帳戶登入、呼叫 API 以及下載版本更新時,可能會遇到連線逾時、登入頁面無法載入、驗證回調失敗或套件下載速度不穩定等情況。這些問題不一定代表 Codex CLI 本身故障,很多時候是因為終端程式沒有繼承圖形化 Clash 客戶端的代理設定。
Clash 的作用是接管並分流網絡請求,而不是提供 OpenAI 帳戶或 API 服務。你仍然需要合法可用的 OpenAI 帳戶、有效的 API 金鑰及符合服務條款的網絡環境。本文以 Windows、macOS 和 Linux 桌面環境為例,從客戶端選擇、訂閱導入,到終端代理變數、TUN 模式及 YAML 分流規則,逐步完成一套適合新手的配置。
本文配置目標
讓瀏覽器登入、Codex CLI 命令、Node.js 或 Python 開發工具使用一致的代理路徑,同時保留國內網站與區域服務的直連速度。
1選擇 Clash 客戶端並導入訂閱
在桌面端,建議優先選擇仍在維護、支援 Mihomo 內核並提供圖形化操作介面的 Clash 客戶端,例如 Clash Verge Rev。不同客戶端的按鈕名稱可能略有差異,但訂閱管理、代理模式、系統代理及 TUN 模式等核心概念基本一致。手機端雖然也能使用 Clash 類工具,但 Codex CLI 主要運行在電腦上,因此本文先聚焦桌面配置。
安裝前的檢查
- 確認平台:Windows 選擇 x64 或 ARM64 安裝包;Apple Silicon Mac 選擇 ARM64 版本;Intel Mac 選擇 x64 版本。
- 確認核心:在客戶端設定中查看是否使用 Mihomo。若客戶端只提供過時核心,可能無法完整支援新的代理協議或 TUN 功能。
- 確認來源:只從可信任的官方發布頁或專案頁下載,避免使用來歷不明的修改版,以免訂閱連結、API 金鑰及終端資料被竊取。
- 確認服務:Clash 不會自動生成節點。你需要向可信任的服務商取得訂閱 URL,並自行確認服務的穩定性、流量限制與使用規範。
導入訂閱並測試節點
- 開啟 Clash 客戶端,進入「配置」或「Profiles」頁面。
- 將服務商提供的訂閱 URL 貼入輸入框,點擊導入、下載或更新。
- 選擇剛下載的 YAML 配置,確認代理組、節點列表及規則已正常顯示。
- 進入「代理」頁面,先選擇一個延遲較低且連線穩定的節點,不要一開始就依賴自動切換。
- 在瀏覽器中測試 OpenAI 登入頁及一般網站,確認代理可以正常工作後,再進行終端配置。
小撇步
第一次測試時,建議固定使用同一個地區的節點。頻繁切換不同國家或地區的 IP,可能導致登入驗證增加,亦不利於排查問題。
節點延遲並不是唯一標準。對 Codex CLI 而言,長連線穩定性、TLS 握手成功率、晚高峰可用性及出口 IP 品質同樣重要。即使某個節點顯示延遲很低,只要經常在登入或下載時中斷,也不適合作為日常開發節點。
2讓終端機繼承 Clash 代理
很多新手會發現瀏覽器已經可以打開外部網站,但在終端執行 Codex CLI 時仍然出現 network error。最常見的原因是:瀏覽器使用了系統代理或擴充功能,而 Terminal、PowerShell、npm、Git 或 Python 並沒有自動使用相同的代理。
確認 Clash 的本地監聽端口
在 Clash 的「設定」或「一般」頁面查看 HTTP、SOCKS 或混合代理端口。常見的本地地址是 127.0.0.1,端口可能是 7890、7897 或其他自訂數值。請以客戶端實際顯示的端口為準,不要直接複製他人的配置。
如果客戶端提供「系統代理」開關,可以先開啟它,讓支援系統代理的應用程式直接使用 Clash。但終端工具是否跟隨系統設定,取決於程式本身,因此仍建議明確設定 HTTP_PROXY、HTTPS_PROXY 及 ALL_PROXY。
設定 Shell 代理變數
以下示例假設 Clash 的混合端口為 7890。如果你的端口不同,請替換最後的數值。HTTP 與 HTTPS 請求可以使用 HTTP 代理;若需要 SOCKS5,則應確認客戶端的 SOCKS 端口並相應修改。
若希望每次開啟終端都自動載入,可以將上述 export 行加入 ~/.zshrc、~/.bashrc 或你正在使用的 Shell 設定檔,儲存後執行 source ~/.zshrc。不過,對需要同時使用國內套件鏡像或內網服務的開發者來說,長期全局設定可能造成不必要的連線問題,因此建議先以臨時設定驗證。
設定完成後,請在同一個終端視窗執行 Codex CLI。若你從 IDE 內建終端執行,必須確認 IDE 是在設定代理變數之後啟動,部分應用程式不會即時讀取外部環境的變更。
3安裝 Codex CLI、登入與 API 呼叫
Codex CLI 的安裝方式可能會隨版本更新而變動,請以 OpenAI 官方文件公布的命令為準。不要從不明來源複製安裝腳本,也不要將 API 金鑰貼到公開的 Issue、聊天群組或 Shell 歷史記錄中。安裝前可以先確認 Node.js、npm 或官方要求的執行環境版本,避免因版本過舊造成套件解析失敗。
安裝與版本檢查
- 先確認 Clash 已啟動,並在代理頁面選定穩定節點。
- 在已設定代理變數的終端中,按照官方文件執行 Codex CLI 安裝命令。
- 安裝完成後執行版本檢查命令,確認執行檔已加入系統的 PATH。
- 若安裝器下載套件時逾時,先用
curl測試相同網絡,再檢查 npm 或其他套件管理器的代理設定。
瀏覽器登入流程
如果 Codex CLI 提供瀏覽器登入流程,執行登入命令後通常會開啟瀏覽器,或在終端顯示一個登入網址。請確保瀏覽器與終端使用同一個 Clash 節點,並完整完成授權與回調流程。若瀏覽器可以登入但終端等待回調,可能是本機回調端口被防火牆攔截,也可能是終端程序沒有正確保留登入狀態。
安全提醒
不要把登入網址中的一次性代碼、授權回調網址或 API 金鑰發給他人。若你曾經在公開環境洩露金鑰,應立即到帳戶控制台撤銷並重新生成。
使用 API 金鑰時的注意事項
若工作流程需要 API 金鑰,建議使用環境變數或受保護的密鑰管理工具,不要直接寫入 Git 儲存庫、專案設定檔或命令列參數。命令列參數可能被 Shell 歷史或系統程序列表記錄。團隊開發時,還應在 .gitignore 中排除本地環境檔案,並為不同專案設定最小必要權限與合理的費用限制。
4啟用 TUN 模式與配置分流規則
單純設定系統代理,通常足以處理支援 HTTP(S) 代理的命令。但某些登入程式、更新器、DNS 請求或使用自訂網絡庫的工具,可能不讀取環境變數。此時可以考慮啟用 TUN 模式,讓 Clash 透過虛擬網卡接管更底層的流量。
TUN 模式的開啟方法
- 在 Clash 客戶端中確認核心為 Mihomo,然後進入「設定」或「系統」頁面。
- 開啟 TUN 模式;Windows 可能需要允許安裝服務或授予管理員權限,Linux 可能需要相應的網絡權限。
- 啟用後重新測試瀏覽器、終端及 Codex CLI,觀察是否有應用程式無法連線。
- 若出現本地網絡、虛擬機或公司內網異常,先關閉 TUN,確認是否為路由衝突,再調整排除規則。
TUN 並不是「開啟後所有問題都會消失」。它可能與其他 VPN、Docker、虛擬機、企業安全軟體或系統防火牆發生衝突。啟用前應記錄原有設定,並保留快速停用的方法。
OpenAI 相關域名的分流
為了讓 Codex CLI、登入頁面及靜態資源使用一致路徑,可以在自訂規則或覆寫配置中加入相關域名。規則的具體位置取決於客戶端及訂閱格式;若服務商使用遠端規則集,請不要直接修改每次更新都會被覆蓋的原始檔案。
上面的 OpenAI 必須對應你配置中實際存在的策略組名稱。如果你的策略組叫作 PROXY、外部服務 或其他名稱,請替換成正確值。規則通常按照從上到下的順序匹配,因此 OpenAI 專用規則應放在較寬泛的 MATCH 或通用規則之前。
DNS 與分流排查
DNS 配置錯誤可能造成域名解析失敗、解析到不適合的地址或出現瀏覽器與終端結果不一致。可以在 Clash 中使用具備合理快取與遠端解析能力的設定,並避免同時運行多個會攔截 DNS 的軟體。修改 DNS 後,清除系統 DNS 快取,再重新啟動 Clash 與終端程序。
小撇步
排查時不要一次修改節點、TUN、DNS 和規則。一次只改一項,然後執行相同測試,才能知道真正有效的變更。
5常見問題與排查順序
完成配置後,建議按照「Clash 是否連線、瀏覽器是否正常、終端是否能訪問、Codex CLI 是否能完成登入或請求」的順序逐層測試。不要一看到錯誤就立刻更換大量設定,否則很難判斷故障來源。
- 瀏覽器正常、終端失敗:檢查環境變數是否在目前 Shell 生效,並確認命令是在同一個終端視窗中執行。
- 終端能下載、登入回調失敗:檢查瀏覽器與 CLI 是否使用相同節點,並查看本機防火牆是否阻擋回調端口。
- 所有程式都無法連線:確認 Clash 已啟動、配置已啟用、節點未過期,並查看系統代理端口是否被其他軟體佔用。
- 只有更新時失敗:檢查 npm、Git 或系統套件管理器是否有獨立的代理設定,並確認憑證與時間同步正常。
- 登入反覆要求驗證:固定使用穩定節點,不要短時間內跨地區切換 IP;同時確認帳戶與服務所在區域符合官方要求。
你也可以在 Clash 的連線記錄中搜尋 openai、chatgpt 或相關域名,查看請求究竟命中了哪條規則、使用了哪個策略組。如果記錄中完全沒有對應請求,表示程序可能繞過了 Clash,應優先檢查 TUN 或代理變數,而不是先更換節點。
FAQ:Codex CLI 與 Clash 常見疑問
為什麼瀏覽器可以登入,Codex CLI 卻顯示網絡錯誤?
最常見原因是瀏覽器使用了系統代理或獨立擴充功能,而終端沒有設定 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY。先確認環境變數、Clash 監聽端口及目前 Shell,再使用 curl 測試,最後重新啟動 CLI。
HTTP 代理和 SOCKS5 代理應該選哪一個?
如果工具明確支援 HTTP 代理,優先使用 Clash 的 HTTP 或混合端口,兼容性通常較好。需要 SOCKS5 的程序則使用 SOCKS 端口。不要把 HTTP 端口和 SOCKS5 協議混用,否則可能出現連線被重置或握手失敗。
使用 Codex CLI 一定要開 TUN 模式嗎?
不一定。若 CLI 能正確讀取代理變數並完成所有請求,系統代理或 Shell 代理已經足夠。當某些子程序、登入回調、DNS 請求或更新器不遵循代理設定時,再考慮啟用 TUN。TUN 啟用後若影響內網或虛擬機,應調整路由或暫時關閉。
如何避免 API 金鑰在使用過程中洩露?
將金鑰放在環境變數或專用密鑰管理工具中,避免寫入 Git、截圖、公開日誌及命令列歷史。完成測試後檢查專案檔案與 CI 日誌;若懷疑洩露,立即撤銷舊金鑰並設定新的使用限制與費用上限。
只要先確定 Clash 節點可用,再讓瀏覽器、終端與 Codex CLI 使用一致的代理路徑,絕大多數登入與連線問題都能更容易定位。建議從最簡配置開始,確認基本功能後再加入 TUN、DNS 及自訂分流,並定期更新客戶端與配置檔案。