IDE やブラウザと違う「OpenCode CLI が壊れる」理由

ブラウザや一部のデスクトップ製品は macOS／Windows のシステムプロキシを尊重しやすく、認証フローも同じ経路に乗りがちです。一方、OpenCode CLI のようにシェルから起動するツールは、親プロセスの環境変数、コンテナ／WSL／リモート SSH、CI のジョブなどコンテキストが分かれた瞬間にプロキシ設定が継承されない場面が少なくありません。Clash が TUN により内核側から覆う場合と、単に mixed-port に環境変数で向けるだけの場合では、出口の一貫性がまったく違います。

OpenCode は設定と拡張により複数の推論プロバイダを行き来しやすく、単一ベンダに閉じた CLI よりログに現れる名前空間が増えやすいという特徴があります。既存の社内ルールが「ChatGPT 用」「Copilot 用」に最適化されていると、OpenCode 向けに足りないサフィックスが残り、MATCH 直前の広いポリシーへ吸い込まれます。症状がログ全体のタイムアウトに見えるのは、実際にはどれか一つのホストが別経路で止まっているだけ、というパターンが多いです。

まず Clash のライブ接続で、失敗ウィンドウの数十秒だけ SNI と選択ポリシーを並べてください。モデル API のみ赤字なのか、OAuth のリダイレクト先だけ交互に落ちるのか、静的アセットやパッケージレジストリだけ遅いのかをメモすると、認証・推論・CDN・外部ツールのどれが経路だけ割れているかがはっきりします。恒久障害を疑う前に、この階層分けの方がコストが低いことが多く、チーム内の再現ログ共有にも向きます。

ℹ 観測のコツ：問題が出ているターミナルから短いウィンドウだけ計測し、成功している別シェルと環境変数の差分を並べます。ALL_PROXY と NO_PROXY にローカル例外が紛れていないか、企業プロキシ PAC がターミナルにだけ効いていないかも合わせて見ます。OpenCode が内部で別プロセスを起こす構成では、親シェルと子プロセスで値が分かれる点にも注意してください。

ターミナルが踏む層：OAuth・モデル API・CDN・MCP

実運用でまとめやすい層は次のとおりです。(1) アカウントとトークン——opencode auth login などのフローが踏む名前。プロバイダや組織設定によりホストは変わるため、自分のログを正にします。(2) モデル応答の API——OpenAI・Anthropic・Google など、選択したプロバイダの推論エンドポイント。ここが別出口だとAPI タイムアウトに直結します。(3) UI・ドキュメント・静的アセット——ヘルプページやスクリプトホスト、CDN 上のオブジェクト。(4) MCP まわり——外部ツール連携を OAuth するサーバは、本体のモデル API とは別ドメインになりがちです。(5) 配布と更新——インストーラやバイナリ確認が GitHub Releases、パッケージレジストリ、Bun／npm 系の名前へ伸びることがあります。

「モデル呼び出しだけタイムアウト」は層 (2) が典型ですが、(1)(3)(4)(5) のどれかが先に詰まっていると、(2) に到達する前に長い待ちに見えます。逆に (2) だけ通っていても、コールバック URL やブラウザ補助が (1) で止まれば認証が完了しません。ひとつの安定した出口を「この CLI がそのセッションで触る名前の束」に割り当て、増分で DOMAIN 行を足すと読みやすいです。

YAML での概念的な束ね方（例）

ポリシー名は自分の構成に置き換えてください。断片は出発点であり、丸写しではありません。ログに現れたホストから始め、範囲が広すぎると国内向け一般サイトまで巻き込みます。

Illustrative rules fragment — replace suffixes with your observed hosts

rules:
  - DOMAIN-SUFFIX,api.anthropic.com,OPENCODE_STABLE
  - DOMAIN-SUFFIX,api.openai.com,OPENCODE_STABLE
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,OPENCODE_STABLE
  - DOMAIN-SUFFIX,github.com,OPENCODE_STABLE
  - DOMAIN-SUFFIX,registry.npmjs.org,OPENCODE_STABLE
  - MATCH,YOUR_FALLBACK_POLICY

実際にはプロバイダのエンドポイントは追加・変更されます。公式ドキュメントを読みつつ、自分の失敗ログが最優先です。リストの並べ替えと更新の型は ルール分流のベストプラクティス を参照してください。許可されていないサービスへの迂回には使わないでください。

DOMAIN-SUFFIX とルール順：MATCH より上で揃える

Clash は一行目から順に評価し、最初に当たった行で出口が決まります。広告ブロック用ルールや大きな拒否リスト、広すぎる GEOIP が開発者向けドメインを先に片付けていたり、CDN を誤って直結／拒否していたりすると、ブラウザだけ別プロファイルで結果だけ見えている状態になります。開発者向けブロックセットを入れているプロファイルほど、この誤遮蔽を疑う価値があります。

「昨日まで OpenCode が動いた」なら、(a) ルールプロバイダの自動更新で順序が変わった、(b) 更新取得自体がプロキシループで詰まり古いリストのまま、(c) サブスクリプション更新後にノード品質だけが劣化——の三通りを順に見ます。購読とノード保守 と タイムアウトと TLS の読み方 をセットにすると切り分けが速くなります。

システムプロキシ／TUN／HTTPS_PROXY の取りこぼし

開発者環境では、ブラウザ用に Clash のシステムプロキシをオンにしている一方、ターミナルだけ HTTPS_PROXY を設定していなかった、WSL／Docker だけ別ブリッジにいる——といったパターンが珍しくありません。Docker／ターミナル向け記事 の構成と突き合わせ、すべてのプロセスが同じ Clash アップストリームに到達できるかを確認してください。

TUN はPOSIX 環境への注入漏れを減らす一方、企業 VPN やホスト側の複数 NIC と競合することがあります。TUN の深掘り を読み、「システムプロキシに切り替えるとだけ直る」のか、「TUN が必要なのか」を短時間で A/B します。両方を同時に誤って二重に載せないよう注意してください。

DNS・fake-ip が原因の「名前は返るが止まる」

fake-ip を使っていると、アプリには合成アドレスが返り実解決は後段になります。このとき DOMAIN 規則と DNS の順序理解が食い違うと、名前解決は一瞬でも TCP が進まず API タイムアウト にしか見えません。CLI はブラウザよりキャッシュ層が薄く、結果としてログに残るほうが素直です。

社内 NW で分割 DNS を使っていると、公開向けとは別のアドレスに誘導され、OAuth だけ失敗することがあります。IT の案内がある場合は順守しつつ、「家のクリーンな回線では再現しない」事実だけでも切り分け材料になります。一般的な確認は FAQ も参照してください。

OpenAI Codex CLI のターミナル記事 は OpenAI の認証・API・静的 CDN に寄りますが、本稿はプロバイダ横断の OpenCode に焦点を当てます。Gemini CLI の CDN 分流記事 と考え方は似ていますが、Google 名前空間固定ではありません。Cursor のログイン記事 は IDE 前提の典型経路であり、ターミナル単体の OpenCode とはホスト集合が一致しません。丸写しは避け、自分のログで束ね直してください。

⚠ コンプライアンス：サービス規約や法的制限、アクセス許可されていない環境での利用を前提にした迂回は説明対象ではありません。職場のセキュリティ方針に従ってください。

許可環境でのチェックリスト

  1. この CLI と Clash で外部モデルへ接続することが契約およびポリシー上許されているか確認した。
  2. 失敗ウィンドウの接続ログから、OAuth・モデル API・静的 CDN・MCP・更新取得に分類してホスト名を列挙した。
  3. それらが広域ブロックリストより上の行へ載っていることを確認した。
  4. ブラウザとターミナルで HTTPS_PROXY／TUN／システムプロキシの差を A/B した。
  5. fake-ip 利用時は nameserver と DOMAIN 規則の整合を読み直した。
  6. 購読とルール更新がループせず成功することをログで確認した。
  7. 問題が残るときだけノード総入れ替えやベンダーダウン確認に進んだ。

メモだけで済ませず、設定ファイルの変更点を短文で残すと数日後の自分が助かります。チームで展開する場合も同様で、レビュアが「どのサフィックスをいつ足したか」を追えると再現切り分けが速くなります。OpenCode はプロバイダや MCP を一つの作業ディレクトリに寄せやすい反面、名前空間が増えるほど設定の履歴が重要になります。

よくある質問

簡単な質疑を並べました。FAQPage の構造化データは <head> にあります。

ブラウザではプロバイダの管理画面が開けるのに OpenCode CLI だけ止まるのはなぜですか。

ブラウザはシステムプロキシを尊重しやすく、CLI は環境変数やカーネル捕捉に依存しがちです。OAuth、モデル API、静的 CDN が別出口に割れると、片方だけタイムアウトに見えます。

OpenAI Codex CLI の記事と何が違いますか。

OpenCode は複数プロバイダと MCP を束ねる設計になりやすく、ログに現れるホストがベンダ固定ではありません。Codex 向けの OpenAI 束を流用しても足りない名前が残ることがあります。

MCP サーバの OAuth だけ遅い場合はどう切り分けますか。

本体のモデル API とは別の名前空間になりがちです。MCP 追加時に出るホストを Clash ログで列挙し、本体と同じ安定出口へ寄せるか、必要なら別グループで明示します。

DOMAIN だけで足りますか、それとも DOMAIN-SUFFIX が必要ですか。

ログに基づき DOMAIN から始め、増えたサフィックスを徐々に DOMAIN-SUFFIX へ拡張するのが安全です。最初から広すぎるサフィックスを敷くと無関係な通信まで同じポリシーになります。

まとめ

OpenCode CLI は単一ホストとの会話というより、OAuth・モデル API・CDN・MCP・配布インフラへの短い連鎖です。MATCH まで届いているか、認証と推論と静的ホストが同じ出口か、DNS がルール設計と同じ視点か——この三通りを押さえると、ノード性能やベンダ障害を疑うより先に体感が変わることがあります。2026 年もエンドポイントは増減するため、黒箱の単一プリセットよりログを読んで増分更新するモデルのほうが持続します。

一部の単一チャネル VPN やブランド固定クライアントは、どの名前が増えたか観測しづらく、開発者がターミナルで待たされる原因を特定しにくい面があります。Clash はドメインベースでルールプロバイダを差し替えやすく、上流リストが不透明でも自分で順序と例外を足せます。この透明性があるからこそ、許可環境でのセルフサービスにも向きます。

Clash V.CORE はその設計語彙に沿って UI とログを並べやすく、「CLI のどのフェーズが詰まっているか」を短いセッションで切り分けやすいです。黒箱より出口とログが追える構成に寄せると、同僚との再現議論も早くなります。Clash を無料ダウンロードし、自分のワークステーションだけで検証するところから始めてください。OAuth とモデル API が別経路だった、という発見はすぐログに現れます。