OpenAI Codex CLI搭配Clash Verge：內地連線設定攻略

為什麼 Codex CLI 需要單獨處理連線

OpenAI Codex CLI 把程式碼理解、檔案修改、指令執行與帳戶驗證集中在終端機裡。它不像瀏覽器那樣會把載入中的資源、重新導向與錯誤提示完整呈現，因此只要其中一段連線沒有走到合適的出口，使用者通常只會看到登入等待、更新失敗、API 逾時，或終端游標長時間沒有回應。對身處內地、需要透過代理連線到相關服務的開發者來說，這種問題尤其容易被誤判為 Codex CLI 本身故障。

一次完整的 Codex CLI 工作流程，可能同時包含安裝或更新套件、登入授權、瀏覽器回呼、API 請求、版本檢查，以及終端機發出的長連線資料交換。這些請求不一定使用同一個主機名，也不一定都由瀏覽器完成。即使你可以在瀏覽器開啟某個頁面，也不代表 npm、Codex CLI 或目前使用的 shell 程式已經正確繼承代理設定。Clash Verge 的作用不是單純「把所有流量送到代理」，而是讓不同類型的流量按照清楚、可觀察的規則分流。

本文以 Clash Verge 與 Mihomo 核心的常見操作邏輯為基礎，說明如何準備代理、確認混合埠、選擇規則模式，並用較穩妥的方式測試 Codex CLI。文章不提供任何繞過服務條款或所在地網路政策的方法；請在合法授權、服務提供者條款，以及公司或學校網路規範允許的範圍內使用相關工具。

開始前：確認 Clash Verge 與代理環境

開啟 Clash Verge 後，先在主畫面確認目前使用的設定檔已經成功載入，並且 Mihomo 核心處於執行狀態。若設定檔旁邊出現解析錯誤、節點數量為零，或策略組完全沒有可選項目，請先處理訂閱內容與 YAML 格式，不要直接開始調整 Codex CLI。設定檔沒有正常運作時，後續所有測試都沒有參考價值。

接著檢查代理埠。Clash Verge 常見會提供 mixed-port，同時接受 HTTP 與 SOCKS5 流量，例如本機的 127.0.0.1:7890。實際埠號必須以你的設定檔和客戶端介面為準，不要直接假設所有安裝都使用 7890。若電腦同時開著其他代理軟體、舊版 Clash 客戶端、VPN 或下載工具，可能發生埠號衝突；這時應先關閉競爭程式，或把其中一個服務改用不同埠。

系統代理與 TUN 模式是兩種不同的接管方式。系統代理主要影響遵循作業系統代理設定的應用程式；TUN 則透過虛擬網路介面接管更多不主動讀取代理變數的程式。Codex CLI 的實際行為會受到執行環境、Node.js 或其他網路函式庫影響，因此不要把「瀏覽器可以上網」當成終端測試已經完成。若你只是初次設定，建議先使用系統代理或明確的終端環境變數，等基本流程確認後再評估 TUN。

選擇規則、全域與直連模式

Clash Verge 通常提供規則、全域與直連等模式。規則模式適合日常使用，流量會依照設定檔中的規則分配到代理、直連或拒絕策略；全域模式則會把大部分可接管的流量交給你選定的代理組，適合用來做短時間的故障定位；直連模式可用來確認問題是否確實與代理路徑有關。三種模式不是誰永遠最好，而是對應不同的測試目的。

初次設定 Codex CLI 時，可以先暫時選擇一個穩定的代理節點，並使用全域模式完成登入與基本 API 測試。如果全域模式能成功、規則模式卻失敗，通常表示規則沒有涵蓋實際連線的主機，或某個重新導向、授權與更新服務被錯誤送往直連。完成定位後，應回到規則模式建立較精準的分流，而不是長期讓所有本機流量都走同一條線。

規則設計上，建議把 Codex CLI 相關流量分成幾個概念桶：第一是帳戶登入與授權流程，第二是 API 或控制平面，第三是套件、版本更新與文件資源，第四是本機回呼和公司內部服務。不要只憑一個產品名稱猜測所有網域，也不要把整個頂級網域一律交給代理。實際主機名應以官方文件、客戶端連線日誌及你所使用的版本為準。

動手設定：讓終端機使用 Clash Verge

完成 Clash Verge 的節點與策略選擇後，先記下介面顯示的本機代理位址與埠號。以下示例假設混合埠是 127.0.0.1:7890；如果你的介面顯示其他數字，請替換成實際值。Windows PowerShell、macOS、Linux shell 的環境變數寫法不同，設定前要先確認自己使用的終端類型。

1. 確認代理監聽：在 Clash Verge 的設定或概覽頁查看 mixed port，並確認核心沒有出現 bind failed、port already in use 等錯誤。
2. 設定目前終端：在支援 HTTP 代理變數的環境中，將 HTTP_PROXY 與 HTTPS_PROXY 指向本機代理；若工具明確要求 SOCKS5，則使用對應的 ALL_PROXY 或工具自身參數。
3. 保留本機直連：把 localhost、127.0.0.1、::1 以及你的內部開發網域放入 NO_PROXY，避免 OAuth 回呼或本機服務被送進遠端節點。
4. 重新開啟終端：環境變數通常只會套用到新啟動的程序。設定完成後重新開啟 PowerShell、Terminal 或 VS Code 內建終端，再執行 Codex CLI。
5. 分段測試：先測試一般 HTTPS 連線，再測試套件安裝或版本檢查，最後才進行登入與模型請求，這樣比較容易把問題定位到正確鏈路。

不同版本的 Codex CLI 對代理變數的支援方式可能不同。有些工具會讀取標準環境變數，有些則依賴 Node.js 的網路函式庫或自己的設定檔。如果 Clash Verge 日誌完全沒有出現終端機的請求，但 CLI 已經顯示連線失敗，問題可能在於該程序沒有讀取代理變數，或被其他環境設定覆蓋。此時可以先使用 Clash Verge 的 TUN 模式做對照測試；如果 TUN 能接到流量，再回頭檢查 CLI 的代理支援，而不是盲目更換節點。

Windows 使用者也要留意 PowerShell 與傳統命令提示字元的環境變數語法不同。macOS 或 Linux 使用者則要確認變數是否只存在於目前 shell、是否被 shell profile 覆蓋，以及 VS Code 是否從另一個環境啟動。若公司電腦有代理自動設定、端點防護或群組原則，請把這些因素一併記錄，否則你可能在本機測試成功，換到 IDE 終端又得到完全不同的結果。

用日誌與 DNS 找出真正的失敗點

Clash Verge 的連線日誌比單純測速更有價值。執行 Codex CLI 時，觀察是否出現新的主機名、連線使用的策略組、連線結果與錯誤類型。若日誌顯示請求命中 MATCH 且走直連，而你的需求是代理，應先修正規則；若命中代理後仍然逾時，再檢查節點品質、TLS 握手、遠端服務狀態與本機防火牆。不要只看到一個 timeout 就認定「節點速度不夠快」，因為 DNS 或授權回呼同樣會造成等待。

DNS 模式也可能影響 CLI。使用 fake-ip、redir-host、TUN 與嗅探時，應確認目前核心版本與設定檔互相支援。若日誌中的主機名與你預期不同，可能是重新導向、CDN 或嗅探結果造成；若出現解析不到、憑證主機名不匹配，則應優先檢查 DNS 配置，而不是增加更多寬泛的 DOMAIN-SUFFIX 規則。規則越寬，越容易把不需要代理的內地服務、公司系統或套件鏡像一併帶走。

建議每次只改一個變數：先固定節點觀察規則，再固定規則比較兩個節點，最後才測試 TUN 或 DNS 模式。把測試時間、Clash Verge 核心版本、Codex CLI 版本、命中規則與錯誤訊息記下來，通常比連續切換十個節點更快找到原因。完成設定後，也要用一個不需要代理的網站或內部服務確認直連規則沒有被意外破壞。

常見失敗情境與修正方法

登入頁開啟但終端沒有完成

這類情況常見於瀏覽器已經完成授權，但 CLI 等不到本機回呼，或授權交換階段的另一個主機沒有命中相同策略。先確認瀏覽器與終端是否在同一台電腦，檢查本機回呼埠是否被其他程式占用，並將 localhost 保留直連。若瀏覽器跳轉途中被企業安全軟體攔截，Clash 規則正確也無法取代端點防護的允許設定。

安裝或更新卡在下載階段

若 Codex CLI 尚未能完成安裝，先不要排查模型 API。套件管理器可能需要連線到 registry、套件 tarball CDN、版本資訊服務或簽章來源；其中一個主機直連失敗，就可能只呈現「下載中」或簡短的網路錯誤。請查看連線日誌，把實際出現的主機納入有版本管理的規則，而不是直接把所有 CDN 網域交給同一代理。

已登入但指令執行逾時

這時應先判斷是每次請求都失敗，還是只有較長的串流回應中斷。短請求穩定、長回應中斷，可能涉及節點品質、連線重置、代理核心超時或網路設備對長連線的處理；完全沒有日誌，則更像程序沒有經過 Clash。把 CLI 版本、核心日誌和終端錯誤放在同一時間軸上，才能避免把 API 服務狀態、規則錯誤與本機代理問題混成一件事。

排查原則：先確認「有沒有進入 Clash」，再確認「命中哪條規則」，最後才比較「哪個節點較穩」。順序顛倒時，最容易把配置問題誤認為節點問題。

建立可維護的日常使用流程

一套能長期使用的配置，不應只在某天成功登入一次。建議為 Codex CLI 建立獨立且命名清楚的策略組，例如把授權、API 與更新鏈交給同一個可手動切換的代理組，再為本機與內地常用服務保留直連。這樣遇到某一個服務異常時，可以只切換相關策略，不必影響所有瀏覽器、遊戲或辦公室流量。

規則檔和本機覆寫也要分開管理。若訂閱更新會完整覆蓋設定檔，手動新增的規則可能下一次更新就消失；若客戶端支援覆寫或本地配置，應把自訂內容放在明確的覆寫層，並為檔案保留備份。每次更新後重新檢查策略組名稱、規則順序和核心是否成功重載，尤其要注意自訂規則是否被一條過寬的 MATCH 提前截斷。

最後，定期清理不再使用的節點、重複規則與失效的環境變數。代理不是越多越好，規則也不是越長越穩；對 Codex CLI 而言，能看懂、能回滾、能從日誌驗證的配置，通常比堆滿來源不明規則集的配置更可靠。若工具升級後突然出現新主機名，先記錄變更，再針對新增鏈路補規則，避免為了短期成功而把整個網路改成全域代理。

相較於只依賴瀏覽器擴充功能的方案，瀏覽器代理往往無法完整覆蓋 npm 安裝、shell 子程序與 CLI 長連線；而部分簡化型 VPN 客戶端又缺少規則命中日誌、策略組切換與 DNS 細節，出了問題時很難知道流量去了哪裡。Clash Verge 能把混合埠、規則分流、TUN 對照與連線日誌集中在同一個介面，對需要穩定使用 OpenAI Codex CLI 的開發者更容易維護。若你已確認使用場景符合相關規範，可前往下載 Clash V.CORE，再依本文的分段測試方式建立自己的 Codex CLI 連線配置。