OpenCode CLI・プラグインがタイムアウト？2026 は Clash 分流

なぜ「ブラウザは動くのに OpenCode だけ不安定」になりやすいか

ブラウザは OS のプロキシ設定や拡張に従いやすい一方、node や npm、pnpm、yarn、gh などの CLI は HTTPS_PROXY を見たり見なかったりします。OpenCode のようなターミナル中心ツールは、親シェルが通っていた経路と、バックグラウンドで起動する取得プロセスの経路が一致しないと、画面ではなくログにだけ失敗が残ります。

レジストリのリダイレクト連鎖：registry.npmjs.org から CDN 行へ飛ぶ一行が、別ルールに吸われて帯域ではなく初回 TCP で詰まる。
GitHub のオブジェクト分散：github.com は通るが objects.githubusercontent.com だけ遅い、と git / リリース資産取得が途中で切れる。
モデルとツールの二系統：推論 API とダウンロード系が同一測定グループに載ると、長いストリームがレジストリ取得の体感を悪化させる。

切り口

「モデルが弱い」の前に、Connections のホスト名と実 outbound を一行ずつ照合する。同じノード名を選んでいても、当たっているルール行が違えば結果は別物です。

OpenCode 周辺で束ねたいドメインバケット

環境や設定によって増減しますが、ターミナルで OpenCode 系を動かすときは次のようなバケット分けが扱いやすいです。本番投入前に、必ず自ホストのログで実名を確認してください。

バケット	代表ホスト（例）	メモ
npm / JS レジストリ	`registry.npmjs.org`、CDN 系	プラグイン tarball・メタデータ取得で同時接続が跳ねやすい
GitHub	`github.com`、`raw.githubusercontent.com`、`objects.githubusercontent.com`	clone、Release、スクリプト取得でオブジェクト行が増える
モデル／ゲートウェイ	利用する推論・ルーティング提供者の API ドメイン	OpenRouter 等を併用するなら OpenRouter 分流の観点と重複確認
配布・HF 系（任意）	`huggingface.co` など	重いウェイト取得はモデル DL 向けルールと分離しやすい
エコシステム	`open-vsx.org`、`marketplace.visualstudio.com` など	拡張・バイナリ取得の参照元として現れやすい

プラグインマニフェストが任意 URL を指すと、上表に無いホストが一気に増えます。辞書を無限に広げるより、失敗 URL をログから逆引きして安全に 1 行ずつ足す方が事故が少ないです。リモートの rule-providers に頼る場合は、取得失敗と更新間隔も合わせて確認してください。

分流ルールの順序：開発者出口を GEOIP より上へ

広い GEOIP や最終 MATCH の直前まで細かい行を置き忘れると、npm や GitHub だけ意図せず直結したり、遅いデフォルト出口へ吸われたりします。OpenCode が密集して触るホストをまとめ、エンタメ向けの遅延測定グループとは別の低遅延・安定優先ポリシーへ流すのが実務的です。

# Illustrative snippet — replace PROXY_DEV with your policy group name
rules:
  - DOMAIN-SUFFIX,npmjs.org,PROXY_DEV
  - DOMAIN-SUFFIX,npm.community,PROXY_DEV
  - DOMAIN-SUFFIX,github.com,PROXY_DEV
  - DOMAIN-SUFFIX,githubusercontent.com,PROXY_DEV
  - DOMAIN-SUFFIX,openvsx.org,PROXY_DEV
  - DOMAIN-SUFFIX,visualstudio.com,PROXY_DEV
  # Add model/API provider suffixes you actually use (verify in logs)
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

DOMAIN-KEYWORD は誤爆しやすいので、最初は DOMAIN-SUFFIX とログで裏取りした DOMAIN 行から始めます。社内の Nexus / Verdaccio がある場合は、そのホストは DIRECT 固定が安全なことが多いです。

DNS・fake-ip と長接続

fake-ip では、アプリによって名前解決と実接続の見え方がズレ、再試行ループが増えます。CLI だけおかしいときはブラウザのセキュア DNS を一時オフにして検証経路を一本化し、切り分け後に元へ戻すのが定石です。詳細は DNS 漏れと fake-ip を参照してください。

二重解決：DoH と Clash 内 DNS が別回答を返すと、ルールと実接続の組み合わせがブレる。
長めの読み取りタイムアウト：ストリーム型 API と大きな tarball 取得が重なると、ノード側アイドル切断が表面化しやすい。
IPv6：IPv4 だけ安定している出口に、AAAA が先行して失敗するケース。

コンプライアンス

企業ネットワークではプロキシ迂回が禁止されていることがあります。本稿は許可された環境での経路最適化を想定しています。

ノード選択：url-test のフラップを避ける

開発者向けポリシーは「帯域テストで一位のノード」より、小さな TLS ハンドシェイクが安定するノードを選びたい場面が多いです。url-test の間隔が短すぎると出口が頻繁に切り替わり、進行中の git / npm が張り直されてタイムアウトに見えます。間隔と tolerance を緩め、フォールバック鎖の深さを抑えると改善することがあります。

ターミナル全体の HTTP(S) プロキシ整合はターミナル HTTP / Git プロキシも参照し、シェル・Git・パッケージマネージャで語られる「同じ出口」が本当に一致しているかを先に揃えます。

TUN とプロセス名：Node 子プロセスを捕まえる

環境変数だけでは拾えないトラフィックは、Clash Meta（Mihomo）系の TUN と PROCESS-NAME / PROCESS-PATH で IDE 付属の node やランチャーを明示的にマークする手があります。プロセス名は OS ごとに異なるため、タスクマネージャや ps で実名を確認してからルール化してください。ゲーム向け TUN 稿とは用途が違っても、「キャプチャ点をカーネル近くに置く」発想は共通です。

npm / pnpm / yarn を安定させる観点

レジストリミラーと Clash の組み合わせでループプロキシになっていないか。
strict-ssl 周りのエラーが、実際は経路タイムアウトの二重表示になっていないか。
CI 用トークンや .npmrc のレジストリ URL が、意図しないホストへ向いていないか。

MCP と OpenCode を一緒に使うときの分類

MCP はローカル stdio サーバーからリモート SSE まで幅があり、起動時に一度だけ npm で依存を取りに行く実装もあれば、セッション中も GitHub や外部 API を叩き続ける実装もあります。後者は長接続とレート制限の両方に当たりやすいので、ログで「詰まっているのはモデル API か、レジストリか、GitHub か」を分類してください。Claude Code 側の MCP 稿と手順は似通いますが、OpenCode はプラグインと CLI の更新サイクルが速い分、失敗 URL の追加入力が回数多めになりがちです。

npx 一発起動：毎回キャッシュミスでレジストリへ戻り、渋滞時に失敗しやすい。
複数 MCP の同時起動：同じ CDN 行に集中し、帯域ではなく同時 TCP 数が限界になる。
マニフェスト URL：組織内レジストリを挟むと証明書チェーンが変わり、プロキシと相性が出る。

エディタ全体の AI 補完トラフィックは Cursor / AI 開発ネットワークの観点と重なるため、すでにカバーしたホストは二重に書かず、どの記事の分類に寄せるかを決めるとメンテが楽です。

よくある質問

OpenCode の CLI だけ npm install が遅いのはなぜ？

ブラウザと異なり Node やパッケージマネージャは HTTPS_PROXY などを参照しない場合があり、Clash のシステムプロキシと実際の出口がズレるとレジストリだけ遅延します。Connections ログで registry.npmjs.org 系の outbound を確認してください。

プラグインは取れるのにモデル取得だけ失敗する

モデル推論やゲートウェイ用のホストが別ルールに落ちている、長いストリームがアイドル切断に当たっている、IPv6 の AAAA が先に失敗しているなどが典型です。失敗 URL をログで特定し、専用ポリシーへ分離してください。

MCP サーバーを OpenCode から使うと不安定になる

MCP は起動時だけ外部へ出る実装と、セッション中も API や GitHub を叩く実装が混在します。詰まっているホストがレジストリかモデル API かを分類し、測定グループを分けて混雑の伝播を避けてください。

チェックリスト

ブラウザと CLI で、同一ホストの outbound が一致しているか確認する。
npm・GitHub・利用中のモデル API を GEOIP より上に置く。
DNS / fake-ip を切り分け、必要なら検証期間だけ経路を揃える。
開発者用ポリシーの url-test がフラップしていないか見る。
MCP ごとに「起動時のみ外部」「常時外部」を分類し、混在を避ける。

2026 年のターミナル AI 開発では、単一の「速いノード」より、npm・GitHub・モデル API・MCP 周辺が別々の測定グループに飲み込まれていないかを先に潰すほうが効きます。汎用 VPN やブラウザ拡張だけに頼ると、CLI 子プロセスの出口が追いにくく、ログに散らばったタイムアウトの原因を特定しづらいまま時間が溶けることがあります。

一方、Clash はルール順とポリシー分離、DNS、長接続、ノード切り替わりといった開発者トラフィック特有の詰まりを、GUI 一つで観測しながら調整しやすい設計です。ドメイン単位で意図した出口を先に決め、必要なら TUN とプロセス束ねまで踏み込めば、OpenCode のようなターミナル優先ツールでも取得失敗の体感は大きく減らせることが多いです。もし同じ課題を抱えているなら、Clash を無料ダウンロードし、まずは Connections ログから出口を揃えるところから試してみてください。

OpenCode CLI とプラグイン取得がタイムアウトしがちなとき：2026 年、Clash の分流で npm・GitHub・MCP を安定させる