Codex CLI がタイムアウト？OpenAI と npm を Clash で分流（2026）

1. なぜ「CLI だけ」タイムアウトが目立ちやすいか

第一に、HTTPS の宛先がブラウザと CLI で別評価になりやすいことです。IDE 付属の埋め込みブラウザや拡張はシステムプロキシに従いやすいのに対し、ターミナル内の Node ランタイムは HTTP(S)_PROXY が空のまま直結するケースが残ります。Codex CLI のセッション中に npm が走ると、OpenAI 側のストリーミングは通るのに tarball 取得だけ別経路といった差が出ます。

第二に、OpenAI ドメイン空間が単一段に収まらない典型があります。プラットフォームのドキュメント・認証周辺・計測・CDN、そしてモデル応答本体の API ホストなど、ログに並ぶ名前が増えます。購読ルールだけに依存せず、一度失敗した fqdn を追記していくログドリブン運用が長期で安全です。

第三に、サービス側のガードレールとネットワーク障害は切り離して考える必要があります。429／401／課金停止メッセージが本文に見えるときは、いくら出口を変えても症状は変わりません。本稿が扱うのは名前解決・出口選択・転送レイヤの一貫性に限定し、規約順守や地域ポリシーは読者側の判断に委ねます。

2. Claude Code・Gemini CLI・Cursor 各稿との棲み分け

当サイトのClaude Code・Anthropic API と npmは、Anthropic サフィックスの束ね方が主眼です。Codex CLI は OpenAI 側のホスト集合が中心になるため、ルールの雛形は似ていても追記する suffix が置き換わる補完関係になります。

Gemini CLI と Google 系ドメインは、Google の広い CDN 面を前提にした整理です。OpenAI でも一部がサードパーティ CDN に乗る場面はありますが、まずは api.openai.com／platform.openai.com／openai.comのような公式系から束ね、ログに出た付随ホストを足すのが再現性が高いです。

Cursor 向けの記事は特定 IDE の更新・拡張マーケットが前面です。Codex CLI を別エディタで動かす場合でも、OpenAI API と npm をまとめて開発者用策略へ載せるという発想は本稿が近いです。

MCP と npm／GitHubは Model Context Protocol 周辺の tarball・API が主役です。Codex CLI で GitHub tarball が絡むときは、そちらのドメイン集合と重複があればルールを統合し、無駄な二重定義を避けてください。

3. ログでまず束ねる OpenAI／npm のホスト名

以下は切り分けの出発点であり、実際の通信はアップデートで変わり得ます。コアの接続ログに出た名前を最優先してください。

OpenAI まわりでは api.openai.com、開発者向け画面やドキュメントで platform.openai.com、ブランドドメインとして openai.com がよく登場します。OAuth やアカウント周辺で別ホストが増える場合は、そのサフィックス単位でルールを分割しておくと後からの追記が楽です。

npm では registry.npmjs.org が既定のメインレジストリです。npmjs.com 系や tarball の実体ホスト、社内ミラーの fqdn は別行で明示してください。組織で Azure Artifactory などへ向け替えている場合も、レジストリ URL が変わればルール対象も変わる点に注意します。

ルールの評価順はルールルーティングの解説どおり、具体的な DOMAIN 行を MATCH や GEOIP より上に置きます。購読テンプレートの末尾にだけ追記すると効かないことがあるため、自前の developer 向けブロックを上段に固定する運用が扱いやすいです。

4. mihomo ルール例：DOMAIN-SUFFIX と評価順

実務では 「OpenAI＋開発者パッケージ用」策略グループを一つ用意し、関連ホストをまとめて送る構成が読みやすいです。下記は構造サンプルで、プロキシ名や MATCH 行は環境に合わせて差し替えてください。

# proxy-groups: egress for Codex/OpenAI toolchain + npm
proxy-groups:
  - name: OPENAI_DEV
    type: select
    proxies:
      - LOW_LATENCY
      - NODE_STABLE
      - DIRECT

# rules: keep DOMAIN rows ahead of MATCH / GEOIP blocks
rules:
  - DOMAIN-SUFFIX,openai.com,OPENAI_DEV
  - DOMAIN-SUFFIX,api.openai.com,OPENAI_DEV
  - DOMAIN-SUFFIX,platform.openai.com,OPENAI_DEV
  - DOMAIN-SUFFIX,registry.npmjs.org,OPENAI_DEV
  - DOMAIN-SUFFIX,npmjs.org,OPENAI_DEV
  - MATCH,PROXY

api.openai.com は openai.com に包含されますが、可読性と将来の差分追跡のために明示行を残しても構いません。プロセス名で切る PROCESS-NAME ルールもありますが、OS ごとの実行ファイル名差が大きいので、まずはドメイン束ねから始めるのが安全です。

TUN と DNS の相互作用は TUN モードの解説も参照し、名前解決と実接続の策略が矛盾していないかを優先確認します。

5. 策略グループで開発者向け出口を固定する

ストリーミング応答と tarball ダウンロードで別ノードに散ると、体感レイテンシのばらつきだけでタイムアウトが増えたように見えることがあります。select でチーム共通のノード名に固定できるなら、「Codex 用」とドキュメント化して共有すると個人設定差による切り分けが減ります。

自動切替を使う場合は url-test／fallbackの評価間隔や閾値が、対話型 CLI の体感に合うかを確認してください。応答ストリームの途中で経路だけが載せ替わると、アプリ側では単なる切断エラーに見えることがあります。

HTTP/3（QUIC）を有効にしているクライアントでは、ノードの UDP 扱い次第で TCP より不安定に見える場合があります。ドメインは揃えたのに揺れるときは、トランスポートの切り分けも視野に入れます。

6. DNS／fake-ip をルールと噛み合わせる

fake-ip／redir-host など DNS enhanced-mode の選択によっては、ブラウザと CLI が別の名前解決経路を通り、DOMAIN ルール評価が直感とズレることがあります。モードごとの対照と修正順はClash Meta の DNS 比較記事にまとめてあるので、併読すると理解が早いです。

CLI がスタブリゾルバを直接叩く構成では、プロキシコアの DNS と二重化管理になる点に留意します。ログにどこで名前解決が行われたかを残せるようにし、評価された IP と実際にマッチしたルールサフィックスを突き合わせてください。

ブラウザの「安全な DNS（DoH）」が有効だと OS／Clash との設計が食い違います。Windows の Chrome／Edgeではシステム代理と DoH の校正記事も参照し、Web と CLI の見え方の差を減らします。

7. ターミナル・npm のプロキシと OS の解決経路

システムプロキシや TUN が有効でも、npm が環境変数を読まず直結する構成は珍しくありません。HTTPS_PROXY／HTTP_PROXY と NO_PROXY を社内レジストリやループバック向けに分割する手順は、Windows 向け npm／pnpm の記事で詳しく扱っています。

購読の mixed-port と実際に指定しているポートがズレると、環境変数を書いても別口へ向きます。基本はサブスクリプション導入ガイドで揃えたうえで、GUI の表示値と突き合わせてください。

コンテナや WSL から同じワークフローを叩くと、名前空間が変わるため前提が入れ替わります。Docker とホストの Clashを併用する場合は、ゲートウェイと NO_PROXY まで含めて再確認します。

8. 実測での切り分けとログの見方

実務では次の順が扱いやすいです。（1）コアのログで対象ホストが意図した策略グループに載ったかを確認する。（2）載っているのに遅いならグループ内のノードを入れ替え、同一 fqdn で別経路のレイテンシを比較する。（3）TLS／HTTP が確定的に失敗しているなら経路ではなく資格情報・上限・サービス状態を疑う。

API と npm を短い間隔で連続するとだけ不安定になる場合、単位時間の接続数やバースト転送がノード側のポリシーに触れていないかログで確認してください。体感メモだけでなく、ホスト名と載ったプロキシ名をテキスト化しておくと再現調査が速くなります。

CI で同様のコマンドを回すときはランナー側の出站がローカルと別になる点を忘れないでください。ローカルで直ってもパイプラインだけ落ちる、という状態の切り分けに効きます。

9. よくある質問

Codex CLI のタイムアウトはプロキシだけで直りますか？
API キーや請求状態、モデル側の上限が原因なら経路変更では改善しません。HTTP 応答コードとボディにあるメッセージを優先し、問題がネットワークの一貫性にあるときだけノード選びや DNS を調整してください。

npm だけ遅いときは何を見ればよいですか？
registry.npmjs.org 以外の tarball ホストや社内キャッシュに実際には向いていない設定がないか、Clash のログと npm の詳細ログを並べます。GitHub が絡む場合は MCP 関連の記事にあるドメイン集合も確認してください。

10. まとめ

Codex CLIのようなOpenAI 由来のターミナル中心ワークフローでは、API と npm が同一出口や不安定ノードを共有するとタイムアウトや切断が増えて見えることがあります。mihomo で openai.com 系と npm レジストリを開発者向け策略に束ね、DNS fake-ip と名前解決の経路を揃え、必要ならターミナルのプロキシ環境変数まで含めてチェックすると、Claude Code・Gemini CLI・Cursor／MCP 各稿が扱わない検索意図を重ならず補えるドキュメントとして整理できます。GUI だけの汎用クライアントは手早い反面、接続ログやルールの優先順位が詳細まで見えにくく、開発者ツールチェーンとは相性が分かれることもあります。ルール評価と DNS を一体で読める構成であれば、CLI 側の失敗ログと突き合わせて再現ある修正がしやすいです。環境を整える第一歩として → Clash を無料ダウンロードし、開発者向け経路設計で快適さを確認するところから取り組むのがおすすめです。