npm 走企業鏡像時規則怎麼寫？

將實際使用的鏡像主機名寫入 DOMAIN-SUFFIX，不要用死的 registry.npmjs.org 複製到根本不會被解析到的環境；其餘 OpenAI API 仍可依日誌補齊。

Codex CLI 總逾時？Clash 分流 OpenAI 與 npm（2026）

1. 為什麼 Codex CLI 會和 npm 搶同一條出站路徑

Codex CLI在終端裡除了對話，還會觸發檔案操作、LSP、外掛或腳本；這些子行程往往和父 Shell 一樣，預設走作業系統解析出的路由與 DNS。一邊要向 OpenAI端點送可能帶串流、重試與較長逾時門檻的請求，另一邊同一個工作目錄又跑了 npm install去拉 registry 中繼資料與 tarball。兩條流量若一條直連、一條進代理，或都進代理卻落在不同策略組、不同出口 ASN，終端機就會呈現「上一輪還行、這一輪整窗都在轉圈圈」的體感。

價值在於可觀測性：mihomo 能把「應該走哪個策略組」變成規則順序＋日誌上的策略名稱，而不是每次逾時只能靠換節點猜。它無法替代API key、組織權限或 OpenAI 狀態頁上的事故，但能消掉大量規則落點錯誤造成的假逾時。

2. 典型症狀：OpenAI API 與 registry 同時不穩

你可能看到：Codex 在終端裡長時間沒有 token 回報、或錯誤字串含 timeout、ECONNRESET、ETIMEDOUT；幾乎同一時段 npm install卡在fetch metadata或某個 tarball。若瀏覽器開 ChatGPT 網頁「看起來還行」，卻只有 CLI 不穩，優先懷疑行程沒共用 TUN／系統代理、或 HTTP/3（QUIC）與 TCP 走不同路徑。與 Cursor 開發者網域相比，本篇收窄到 OpenAI 主幹與 npm registry，避免規則表膨脹到難以維護。

若你同時在玩 MCP、GitHub 發行版與 npx，可以把套件生態規則合併成一組策略出口；本篇範例刻意保留Codex-npm命名，方便你在訂閱更新後單點覆寫、單點關閉除錯。

3. 建議優先覆蓋的網域（以日誌為準）

下列是2026 年實務常見的起手式；正式環境仍應以你本機 mihomo 連線日誌與 CLI 的 verbose 輸出為準，出現新主機名就補 DOMAIN-SUFFIX，不要死背清單。

OpenAI API 與入口：api.openai.com、openai.com；若日誌出現 chatgpt.com、platform.openai.com或身分驗證相關子域，請一併納入。
npm 公有註冊表：registry.npmjs.org； tarball 網址常由套件版本解析而來，仍多回落到此網域或受其重導。
連帶主機：若安裝流程會打 GitHub release、S3、或其他 CDN，請從日誌補規則；可與 MCP 專文共用同一策略組以免重複維護。

若問題核心是網頁顯示地區限制、帳號層級不可用，應先對照 ChatGPT 網域與帳號語境；本篇假設你已能接通服務，但要處理的是終端路徑一致性與間歇逾時。

4. mihomo 規則與策略組範例

目標是把 OpenAI與 npm registry收斂到同一策略組，並把所有 DOMAIN-SUFFIX 放在大範圍 GEOIP 直連或「整段國內直連」之前。請將節點名稱替換為訂閱內實際存在的代理；YAML 註解請用英文以利版本控管。

① 策略組（建議可手動鎖定低切換）

proxy-groups:
  - name: Codex-npm
    type: select
    proxies:
      - LOW-LATENCY-A
      - LOW-LATENCY-B
      - DIRECT

② 規則（置於寬鬆直連之前）

rules:
  - DOMAIN-SUFFIX,api.openai.com,Codex-npm
  - DOMAIN-SUFFIX,openai.com,Codex-npm
  - DOMAIN-SUFFIX,chatgpt.com,Codex-npm
  - DOMAIN-SUFFIX,registry.npmjs.org,Codex-npm
  # Append hosts from logs (CDN, auth, telemetry) without over-widening
  # ... GEOIP and MATCH below

若策略組用 url-test且頻繁切換出口，長連線或串流式回應可能被遠端重置。需要穩定對話時，可改手動固定節點或參考 url-test／fallback調整間隔與容錯。

5. 終端機代理：TUN、系統代理與環境變數

規則寫對了，若 node／npm子行程沒有把封包送進 Clash，日誌裡仍會「什麼都沒發生」。實務上TUN 模式最能覆蓋粗心的子行程；若退而求其次使用系統 Proxy，請確認 Shell 內 HTTP_PROXY、HTTPS_PROXY與 mixed-port一致，且 NO_PROXY沒有把 openai.com或 registry 主機誤設成直連。

在 Windows 若要國內鏡像直連、海外 API 走代理，環境變數與規則要兩層一起校；可交叉閱讀 Windows npm／pnpm 與分流。本篇先假設你希望官方 registry 與 OpenAI 同一穩定出口，把「先能穩定跑起來」當第一優先。

6. DNS、Fake-IP 與「看得到卻命不中規則」

Fake-IP讓核心先用假位址接流，再依網域名稱做策略決策；但若 dns 區段的 fake-ip-filter、nameserver、fallback與你寫的 rules脫鉤，會出現解析成功、規則卻像失效的錯覺。建議通讀 fake-ip 與 redir-host，每次只改一個變因，並用同一組 OpenAI／npm 請求對照日誌。

瀏覽器若開了安全 DNS（DoH）或企業 VPN 做分裂隧道，可能與終端機解析各走各路；除錯時可暫關對照，確認是否雙重解析造成了策略組漂移。

想把規則觀念一次補齊，可從高級規則分流對照條件類型與順序意義；它不是 Codex 專用，但能解釋「為什麼 npm 以為該走代理，Packet 卻被另一條規則早一步截走」。

7. 實測驗證與清單

建議流程：①開啟連線日誌或除錯級別，重現一次逾時；②確認 api.openai.com與 registry.npmjs.org是否落在同一策略組名稱；③暫停瀏覽器 DoH／多餘 VPN 分流，排除解析分裂；④必要時關閉 HTTP/3 做 A／B，檢查 UDP 路徑與 TCP 代理是否一致。

簡短清單

OpenAI／npm 相關 DOMAIN-SUFFIX 是否位於寬鬆直連規則之前。
終端父行程與子行程是否都在 TUN 或同一組代理環境變數下。
日誌是否出現預期網域；若沒有，代表規則漏字或流量未進核心。
訂閱覆寫混亂時，可依訂閱匯入教學重建基底後再合併本篇前段規則。

8. 常見問題

Codex CLI 逾時一定是節點問題嗎？

不一定。終端未走代理、規則落在寬鬆直連之後、DNS／Fake-IP 與分流決策不一致，都會長得像節點故障。先用日誌確認網域命中哪個策略組，再決定是否換出口。

需要和 ChatGPT 網頁同一組規則嗎？

主幹網域可共用，但瀏覽器與 CLI 的路徑不同；CLI 更重視長連線與 npm tarball。建議把 registry 與 OpenAI 一併收斂，必要時拆成兩個策略組做 A／B。

npm 用企業鏡像時怎麼寫？

以 npm config get registry 看到的主機名為準寫 DOMAIN-SUFFIX，不要複製別人的 registry 清單；OpenAI 端仍依日誌補齊即可。

寫在最後

Codex CLI把OpenAI 推論與本機套件生態壓在同一個反覆迭代裡，網路層若不透明，就只會剩下「換節點、重開終端機、再試一次」的疲勞戰。Clash／mihomo的強項是讓每條連線可紀錄、可固定、可回滾。相較介面停滯、除錯資訊稀少、或只能靠單一「加速模式」硬切的老舊代理工具，現代用戶端配合清楚規則，通常能更快判斷問題在路徑還是在服務本身。

若你希望用同一份用戶端完成訂閱匯入、TUN／系統代理切換與規則覆寫，可從本站下載頁取得適合的版本並完成初配；當 Codex 與 npm 都命中預期策略組，終端 AI 工作流會更接近可預期的開發節奏。

準備好對照日誌收斂規則時，可從這裡開始：→ 立即免費下載 Clash，開啟流暢上網新體驗。