1 MCP が npm・GitHub に触れる典型経路
MCP は単一ベンダーの製品名ではなく、ツール呼び出しの共通語に近い位置づけです。ホスト側のランタイムが「どの MCP サーバをどう起動するか」を決めるとき、実務では次のパターンが多く見られます。第一に、公開 npm registry 上のスコープ付きパッケージを npx やローカルインストールで引き、子プロセスとして起動する。第二に、GitHub リポジトリの README に従い、ソースを clone して npm install し、ビルド済みエントリを実行する。第三に、GitHub Releases のバイナリやアーカイブを直接取りに行く。いずれも「ブラウザで github.com が開ける」ことと「CLI が安定して tarball を取れる」ことは別問題で、後者はしばしば objects.githubusercontent.com や codeload.github.com のような下流ホストに依存します。
したがって Clash 分流の設計対象は、ドキュメント用の github.com だけでは足りません。npm registry（例：registry.npmjs.org）と、GitHub が実際に tarball や release 資産を返すためのホスト群を同じ「開発者向け出口」に載せるか、意図的に DIRECT へ落とすかを決める必要があります。ここが曖昧だと、パッケージマネージャはミラーへフォールバックしたり、証明書検証で止まったりして、ログには断片的な ETIMEDOUT だけが残ります。
2 タイムアウトと「一部だけ成功」の原因
MCP 導入で揉めやすいのは、認証以前のレイヤです。最初の npm view は通るのに tarball GET が遅い、GitHub のページは表示できるのに git clone が別経路で詰まる、といった症状は、ルールが github.com だけをカバーしていて オブジェクト配信が別アウトバウンドに滑っているときに起きやすいです。また、企業ネットワークでは TLS インスペクションとプロキシの組み合わせで、npm の keep-alive や HTTP/2 多重ストリームが途中で切れる例もあります。
対処の前に、接続ログで SNI とルール命中行を確認してください。MCP 自体の設定ミスと、出口の不安定さはログ上では似た顔をしますが、後者は同じホストへの再試行で再現率が変わるのが特徴です。TUN モードでアプリ横断の経路を揃えるか、シェルと IDE が同じローカル HTTP ポートを見るかを先に固定すると、ルール調整の打ち手が明確になります。
3 DOMAIN-SUFFIX：レジストリと配信ホストの束ね方
実務でまず広く取りたいのは次のサフィックスです。npm 方面は npmjs.org と npmjs.com（サイト・リダイレクト・周辺）を含むケースが多く、チームの購読リストに registry.npmjs.org 単体しか無い場合は不足しがちです。GitHub 方面は github.com に加え、ログに出たら追従したい候補として githubusercontent.com（raw.githubusercontent.com など）、githubassets.com、objects.githubusercontent.com、codeload.github.com が典型です。公開サービスのホスト名は変わり得るため、本稿は固定リストを保証するものではなく、ログを正に育てる前提で書きます。
これらを一つのセレクタ（例：DEV_PROXY）へ寄せるとき、GEOIP や広い DOMAIN-KEYWORD より上に、かつ誤爆しやすいキーワードより下に置くと読みやすいです。広すぎる KEYWORD は国内 CDN を巻き込むので、MCP 用にはサフィックス束を優先するのが安全です。
4 DIRECT とプロキシの棲み分け
すべてを海外プロキシへ流すのが正解とは限りません。社内で npm ミラーや Git のミラーを運用している場合、意図的に DIRECT へ落とす方が速いことがあります。逆に、ミラーが無い環境では registry とオブジェクト配信を同じ安定ノードに載せないと、パッケージ解決は成功して tarball だけが別出口で詰まる、という非対称が起きます。
方針を決めたら、チーム内で YAML の短い断片を共有し、Rule Provider の URL かリポジトリパスで配布するとドリフトが減ります。個人の巨大な購読ルールを毎日入れ替えるより、「MCP／フロントエンド開発用」のサブセットを固定化する二層構えの方が、レビューもしやすいです。
5 YAML 例と Rule Provider
以下は Mihomo／Clash Meta 互換の rules に追記するイメージです。DEV_PROXY は手元のプロキシグループ名に置き換え、MATCH より上に配置してください。実環境では接続ログに出たホストを追加し、コメントは英語のみとします。
# Place ABOVE MATCH. Replace DEV_PROXY. Extend from your connection logs.
rules:
# npm registry and site ecosystem
- DOMAIN-SUFFIX,npmjs.org,DEV_PROXY
- DOMAIN-SUFFIX,npmjs.com,DEV_PROXY
# GitHub core + common artifact hosts (verify in logs)
- DOMAIN-SUFFIX,github.com,DEV_PROXY
- DOMAIN-SUFFIX,githubusercontent.com,DEV_PROXY
- DOMAIN-SUFFIX,githubassets.com,DEV_PROXY
- DOMAIN-SUFFIX,objects.githubusercontent.com,DEV_PROXY
- DOMAIN-SUFFIX,codeload.github.com,DEV_PROXY
# rule-providers sketch:
# rule-providers:
# mcp-dev-net:
# type: http
# behavior: classical
# url: "https://example.com/rules/mcp-dev.yaml"
# path: ./rules/mcp-dev.yaml
# interval: 86400
# rules:
# - RULE-SET,mcp-dev-net,DEV_PROXY
Rule Provider に分離すると、MCP サーバのメンテ担当とネットワーク担当が同じファイルを見て合意しやすくなります。interval を極端に短くしすぎると購読元とクライアント双方に負荷が出るので、通常は日次更新で十分なことが多いです。
6 IDE・エージェントと出口の一貫性
VS Code 系や JetBrains、独自ランタイムを抱えるエージェントは、HTTPS_PROXY を無視して OS のシステムプロキシだけを見ることがあります。MCP サーバを子プロセスで起動するとき、親 IDE の環境変数が子に伝わらない実装もあるため、「ターミナルでは npm が成功するのに GUI からのインストールだけ失敗」が起きます。Mihomo の TUN や、クライアントの「システムプロキシ適用」を前提に出口を揃えると、この種のズレが減ります。
モデル API 自体は OpenRouter のように別ドメイン束へ分けたくなる一方、MCP の取得経路は npm／GitHub に集中しがちです。API 用ルールとパッケージ用ルールを混在させると評価順が読みにくくなるので、Provider ファイルを分けて名前を付けるだけでも運用が楽になります。
7 DNS・社内ミラー・パッケージマネージャ
ルール上は DEV_PROXY に見えても、DNS が別経路を返すと実パケットは期待とズレます。FakeIP と DoH の組み合わせは強力ですが、ブラウザの Secure DNS と二重に有効にして挙動が読めなくならないよう注意してください。社内ミラーを使う場合は .npmrc の registry をローカル URL に向け、Clash 側はそのミラーホストを DIRECT に固定する、という二段が分かりやすいです。
pnpm・Yarn・corepack など、ツールチェーンによって追加のホストが出ます。詰まったらログのホスト名をそのまま Rule Provider に追記し、チーム共有してください。Windows と WSL の二重環境では、片方だけプロキシが効いているケースも多いので、WSL 側のプロキシも合わせて確認するとよいです。
8 トラブルシューティング
npm installが途中で固まる： tarball ホストが別ルールに滑っていないかログで確認。objects.githubusercontent.comなどを束に入れる。- ブラウザは GitHub を開けるが
git cloneが遅い：codeload.github.comや SSH（ssh.github.com）が別出口になっていないか確認。SSH を使うなら 22 番の経路も切り分ける。 - IDE からだけ
npxが失敗： 子プロセスにプロキシ環境変数が渡っていない可能性。TUN で揃えるか、IDE 側のプロキシ設定を明示。 - ルールを足したら国内サイトが遅い：
DOMAIN-KEYWORDの取りすぎを疑い、サフィックス束に置き換える。GEOIPより上の行順も確認。 - 企業 VPN と併用で不安定： スプリットトンネルとデフォルトルートの優先順位を見直す。企業 VPN と Clash の整理も参照。
9 まとめ
2026 年の MCP 普及は、IDE とエージェントが npm registry と GitHub の両輪に触れる場面を増やしました。ここを「ブラウザが開くか」だけで判断すると、 tarball とオブジェクト配信のホストが抜け落ち、タイムアウトや直列フォールバックで体感が崩れます。DOMAIN-SUFFIX でレジストリと GitHub 系配信を束ね、Rule Provider に切り出してチームで共有すれば、開発者ネットワークの再現性は大きく上がります。
Clash 互換スタックは、DNS とルールを一体で扱えるため、パッケージ取得と API 呼び出しが混在する現代の AI 開発フローに向いています。出口の一貫性を先に取り戻し、ログを正にホストを足していく運用が、MCP サーバの追加・更新を続けるうえでの近道です。
単純なプロキシ ON/OFF より、短い YAML 断片を版管理する方が、長期のメンテでは安くつきます。一度「MCP 用の開発者ネット」セットを整えておけば、サーバを差し替えて試すループも速くなります。
