MCP ツール取得がタイムアウト？npm と GitHub を Clash で分流し Model Context エコシステムを安定させる（2026）

1. なぜ MCP は「npm / GitHub」とセットで語る必要があるか

MCP はアプリケーションと外部ツールの橋渡しを標準化するプロトコルですが、実務ではサンプルサーバやコミュニティ製サーバを npm パッケージとして入れる、ソースやバイナリを GitHub から取る、API レートやリリース取得に api.github.com が絡むといった流れがごく普通に起きます。つまり「MCP を有効にしたら急に遅くなった」の正体は、画面のチャット API ではなく、裏で動くパッケージマネージャと Git の HTTP(S) 経路であることが多いです。

ここで重要なのは、エディタが使うドメインと、ターミナルの npm / git / npx が向かうドメインが同一の策略に乗っていないと、外から見えにくい再現性の低いタイムアウトになる点です。Clash ではDOMAIN ルールでホストを先に固定し、広い MATCH や GEOIP より上に評価させるのが基本です。

2. Cursor 専稿との違い（プロトコル層とパッケージ層）

当サイトでは、Cursor と IDE 周辺ドメインを、画面・拡張・モデル API中心に整理した記事があります。本稿はMCP というプロトコル周辺の「インストールと実行の足回り」に焦点を当て、registry.npmjs.org、npm パッケージ tarball の配信先、github.com / api.github.com / objects.githubusercontent.com など、ChatGPT や Claude の单一クラウド記事とは異なるドメイン集合を扱います。両方を読むと、IDE 内の接続とCLI・パッケージの接続を揃えやすくなります。

なお、サービス利用規約やアカウント制限は、プロキシ以前の話である場合があります。本稿は名前解決と出口を揃える技術的な観点に限定します。

3. タイムアウトの典型パターンとホストの切り分け

代表的には次のような症状です。（1）npm install が特定のスコープや tarball 取得で固まる。（2）npx で公開パッケージを取る段階で ETIMEDOUT が出る。（3）GitHub の API や raw 取得が遅く、MCP サーバのセットアップスクリプトが失敗する。いずれも、コアログでどのホスト名がどの策略に入ったかを見ると、意図しない DIRECT 落ちや遅延の大きいノードが判明しやすいです。

url-test や fallbackで全体を自動選択していても、細かい DOMAIN 行がその上にないと、リクエストごとに別ノードへ分散し、TLS や帯域の差でタイムアウトに見えることがあります。MCP 用に「開発者向けの固定または低遅延グループ」を一つ決め、関連ドメインをそこへ寄せるのが扱いやすいです。

4. まず押さえるドメインとルールの優先順位

ドメインはCDN や事業者側の変更で増減し得るため、以下は出発点として捉え、失敗ログに出た実名を足してください。パッケージのメタデータと tarball の多くは registry.npmjs.org 経由で、文書・Web 導線では npmjs.com が現れることもあります。ミラーや企業プロキシを使う場合は 社内のレジストリホストが別名になります。GitHub では github.com、api.github.com、codeload.github.com、objects.githubusercontent.com などがバラバラに現れ、大きすぎる DOMAIN-SUFFIX,github.com は職場の別用途まで同じ策略に巻き込む副作用があるため、ログに出たサフィックスを順に足す方が安全です。

ルールの評価順は ルールルーティングのとおり、具体的な行を、広い MATCH より上に置きます。購読の末尾に追記するだけでは効かない配置になっていないか、GUI でルールの実際の並びも確認してください。

5. mihomo ルール例：MCP_DEV 策略へ束ねる

実務では 「開発者向け（MCP・npm・GitHub 共有）」の策略グループを一つ用意し、関連サフィックスを送る形が扱いやすいです。以下は構造例です。プロキシ名は環境に合わせて置き換えてください。コメントは英語表記としています。

# proxy-groups: one group for MCP-related npm + GitHub fetches
proxy-groups:
  - name: MCP_DEV
    type: select
    proxies:
      - LOW_LATENCY
      - NODE_STABLE
      - DIRECT

# rules: place before broad MATCH / GEOIP
rules:
  - DOMAIN-SUFFIX,registry.npmjs.org,MCP_DEV
  - DOMAIN-SUFFIX,npmjs.com,MCP_DEV
  - DOMAIN-SUFFIX,github.com,MCP_DEV
  - DOMAIN-SUFFIX,api.github.com,MCP_DEV
  - DOMAIN-SUFFIX,codeload.github.com,MCP_DEV
  - DOMAIN-SUFFIX,objects.githubusercontent.com,MCP_DEV
  - DOMAIN-SUFFIX,githubusercontent.com,MCP_DEV
  - MATCH,PROXY

コンテナ内やWSLで MCP サーバを動かす場合は、プロセス名やゲートウェイがホストとずれ、意図したルールに掛からないことがあります。TUN 利用時は TUN モードの解説も参照し、トラフィックがコアに乗っているかを先に揃えてください。

6. DNS（fake-ip）と .npmrc・企業レジストリ

fake-ip や redir-host では、ルールに書いたドメインと、実際に解決に使ったリゾルバがずれると、意図した策略にマッチしないように見えることがあります。npm 側は .npmrc で registry や プロキシを切り替えており、社内の Verdaccio や国内ミラーへ直結させる運用では、Clash 側のルールと二重管理にならないよう、どのホスト名が最終的に出るかを一行ずつ把握しておくと安全です。

企業レジストリを DIRECT に固定したい一方で、GitHub だけ外へ出したい場合は、DOMAIN 行の順序とNO_PROXY（環境変数）の除外リストを併用するケースが出ます。矛盾すると「npm は通るが git clone だけ落ちる」といった挙動になるため、失敗したコマンドの URL をそのままメモする習慣が効きます。

7. Windows では HTTP_PROXY との関係も要確認

Windows では、システムプロキシとPowerShell 上の HTTP_PROXY / HTTPS_PROXY、Clash の mixed-portの組み合わせで、npm が別経路になることがあります。詳しい切り分けは Windows 向け npm / pnpm と代理環境変数の記事に譲り、本稿ではMCP サーバ導入フロー全体で「レジストリ行」と「GitHub 行」の両方を同じ方針で揃えることに着目します。

サブスクリプションの導入や購読の取り込みは サブスクリプション導入ガイドを参照し、ルール追記の位置が意図通りかを併せて確認してください。

8. ログドリブンで足し込む運用

実測のおすすめ手順は次のとおりです。（1）コアログで、タイムアウト直前の接続先ホストと割り当てられた策略を確認する。（2）意図した MCP_DEV 等に入っていなければ、サフィックスルールの欠落か順序の問題を疑う。（3）入っているのに遅い場合は、そのグループ内のノードを差し替え、UDP や HTTP/3の影響を他稿で切り分ける。

MCP のサーバ実装は増え続けるため、「このスコープのパッケージは常にあのレジストリ」のような固定ルールより、一度失敗したらホスト名を追記する運用の方が長く持ちます。チームで共有するなら、合意した策略名と足したサフィックスを README に残すと、個人差による切り分け負担が減ります。

9. まとめ

MCPはエディタ画面の中だけの話ではなく、npm エコシステムと GitHub 上の資産に強く依存します。Clash / mihomo で registry 系と GitHub 系を同じ開発者向け策略に束ね、DNS と .npmrc / 代理環境変数の整合を取れば、「ツール呼び出しだけタイムアウト」系の再現性の低い不調を、ログ上のホスト名で着実に潰しやすくなります。Cursor 向けの IDE ルート整理と併用すると、画面・CLI の両方の経路を揃えられます。

同じ系統のクライアントでも表記は世代で変わるため、手元のコアを更新し、ルールの並びを確認しながら運用するのが確実です。クライアント導入から手を付けるなら、 → 無料で Clash をダウンロードし、快適な接続体験を試す から揃えるのがおすすめです。