MCP が途切れる？リモートホストを分流・策略で固定

1. MCP と IDE プラグインの背景

Model Context Protocol（MCP）は、IDE やエージェントがローカル／リモートのツール・データソースと標準的に会話するためのプロトコルです。2025 年以降、Cursor や VS Code 向けの拡張・設定画面から「MCP サーバーを追加する」流れが一般化し、社内やクラウド上の リモート MCP ホストへ接続する構成も増えています。接続は短い REST だけとは限らず、WebSocket（WSS） や HTTP/2 ベースの長時間セッションを張る実装も珍しくありません。

ユーザーから見える症状は「MCP ツールの一覧が読み込めない」「呼び出しの途中で切断」「再接続を繰り返す」といった形にまとまりがちですが、根本原因は IDE プラグイン単体ではなく、OS のプロキシ設定、Clash の分流ルール、策略グループで選ばれている出口ノード、そしてDNS が一体となって現れます。本稿は違法な迂回やサービス規約違反を助長する意図はありません。契約と組織ポリシーの範囲で、自前のネットワークを整理するための一般的な話に限ります。

2. リモート MCP が「落ちる」ときの症状

リモート MCP は、ブラウザでサイトを開くのと違い、単発の GET で終わらずキープアライブを前提にした通信が多いです。そのため、次のようなパターンが典型的です。

初回だけ成功し、数分後に応答なし：長接続が中間装置やノード側で切られている
一覧取得は成功するがツール実行で失敗：別ホストや別パスへフォールスルーしてルールがずれている
夜間や混雑時だけ不安定：共有出口の輻輳・レート制限・BGP 揺らぎの影響
社内直結では安定、自宅＋ Clash だけ不安定：プロキシ経路とノード選択の問題を疑う

切り分けの第一歩は、「Clash のログに出た Server Name が、想定している MCP 用ホストと一致しているか」です。IDE のエラーメッセージだけではホスト名が省略されていることが多く、接続ログと突き合わせないとルールが空振りします。

ヒント：MCP の設定に書いた URL のホスト名とポートをメモし、Clash のヒットログと同じ綴りになっているか確認してください。サブドメインの取り違えが一番多いです。

3. 汎用 PROXY に混ぜると起きること

多くの購読プロファイルは、最終行の MATCH で一括 PROXY に寄せる設計です。一見、リモート MCP も自動的にプロキシを通るように見えます。しかし実務では次のようなミスマッチが起きます。

大きな RULE-SET の手前で GEOIP や DIRECT が先に当たる：MCP 用ホストが意図せず直結し、輻輸やブロックに弱い経路になる
策略グループが「自動選択」で頻繁に切り替わる：長接続の途中で出口が変わり、WSS がリセットされる
遅延の大きいノードに乗る：短い API では通っても、キープアライブ付きのセッションではタイムアウトしやすい

そこで有効なのが、MCP 用のホスト名だけを上位のルール行に明示し、それ専用の策略グループ（例：低遅延・固定ノード・手動選択）へバインドするやり方です。汎用 PROXYから切り出すことで、「他のトラフィック用の自動フェイルオーバー」と長接続向けの安定出口を分離できます。

4. ログで MCP 用ホスト名を拾う

リモート MCP の URL は環境ごとに異なり、mcp.example.com のような専用サブドメインや、443 以外のポートを伴うこともあります。公開のドメイン一覧に頼らず、自分のクライアントログに出た名前を正とするのが安全です。

手順のイメージは次のとおりです。① IDE で MCP を一度だけ有効にし、失敗／成功にかかわらず Clash 側のログを保存する。② TCP／TLS の行から SNI または接続先を抜き出す。③ その文字列を DOMAIN または DOMAIN-SUFFIX としてルールに追加する。④ 反映後に再度ログを見て、意図した策略グループに流れているか確認する。

社内 DNS でプライベート名が割り当てられている場合、Clash の fake-ip モードと相性の問題が出ることがあります。そのときは fake-ip／filter と DNS の切り分け記事を参照し、名前解決とルール評価の順序を揃えてください。

5. 分流ルールと専用策略グループ

Clash（Mihomo 系）では、proxy-groups: に MCP 用のグループを一つ用意し、rules: 側でそのグループ名へ流すのがわかりやすいです。次は概念例です。実ホスト名・グループ名は環境に合わせて置き換え、必ずログで検証してください。

# Example only — replace hostnames and group names; verify in logs
proxy-groups:
  - name: MCP-STABLE
    type: select
    proxies:
      - NODE-A-LATENCY
      - NODE-B-LATENCY
      - DIRECT

rules:
  - DOMAIN,mcp.example.com,MCP-STABLE
  - DOMAIN-SUFFIX,internal-mcp.example.net,MCP-STABLE
  - MATCH,GLOBAL

DOMAIN-KEYWORD は短く書けますが、意図しないホストへ誤爆しやすいです。分流ルールでは可能な限り DOMAIN／DOMAIN-SUFFIX を優先し、足りないときだけキーワードを検討してください。ルールは上から順に評価されるため、より具体的な MCP 行を、広い GEOIP や MATCH より上に置くのが鉄則です。

用語の整理や設定全体の構造は Clash のドキュメントと併読すると、proxy-groups と rules の対応が把握しやすくなります。

注意：リモート MCP が 自社 VPC 内のプライベート IP を指している場合、無闇に海外ノードへ送らないでください。ルールを誤ると社内リソースがプロキシ出口に向かう危険があります。まず経路要件を確認してください。

6. WSS・長接続と TLS／ノード

WebSocket over TLS（WSS）は、HTTP の短いリクエストより接続を開いたまま使う前提です。出口ノードが混雑していると、キープアライブの間隔より先に中間で切断されることがあります。また TLS ハンドシェイク自体が失敗する場合は、TLS Handshake Timeout と SNI の記事で、ノード・SNI・ルールの切り分けを参照してください。

策略グループでは、まず手動で遅延の小さいノードに固定し、長時間の MCP セッションが安定するかを見ます。自動フェイルオーバーや URL テスト型のグループは便利ですが、閾値によってはセッション途中の切り替えを誘発し、MCP には不向きな場合があります。安定が確認できてから、必要な範囲で自動化を足すと安全です。

症状	ありがちな原因	先に試すこと
数分おきに切断	ノードの輻輳・NAT・中間装置のタイムアウト	固定ノード・別地域・キープアライブ設定の確認
TLS／証明書エラー	HTTPS インスペクション・誤った SNI	セキュリティ製品の設定・ログの SNI 確認
ツール一覧だけ失敗	別ホストがルール未登録で DIRECT	ログで追加ホストを特定しルール追記
ターミナルは速いが IDE だけ不安定	IDE がシステムプロキシを無視	TUN モードやアプリ側プロキシ設定の確認

7. DNS・Fake-IP と IDE

DNS がプロキシの外側で解決されると、ルール上は PROXY でも実トラフィックが意図しない経路へ出ることがあります。Fake-IP では、名前解決のタイミングとルール評価の順序が絡み、ログでは正しく見えても IDE だけ挙動が悪い、という状態が起きがちです。ブラウザが DoH を直接使っている場合も、OS の名前解決と結果が食い違います。

対策の基本は、Clash の DNS 設定とルールで参照する名前を一致させ、IPv6 が別経路に抜けていないかを確認することです。ターミナルからの git や npm が絡む場合は、ターミナルと環境変数の記事も併せて読むと、IDE とシェルの差分を整理しやすくなります。

8. Cursor／GitHub 記事との違い

当サイトの Cursor／GitHub のタイムアウト記事は、github.com 系やエディタ更新経路など、比較的短い HTTP／HTTPS 要求と大容量転送を中心に説明しています。一方、本稿の主題は MCP 専用のリモートホストと長時間の WSS／HTTP セッションです。ドメイン集合が異なるため、ルールをそのままコピーしても効果が限定的です。

Windows で TUN を使い IDE 全体をトンネルに載せる場合は、TUN とファイアウォールの切り分けも参照してください。クライアントの選び方は Clash Verge と Clash for Windows の比較が役立ちます。

9. セルフチェック

最後に、リモート MCP と Clash を併用するときの短いチェックリストです。

クライアント更新：古い GUI はログとコアの挙動がズレます。公式ダウンロードページから各 OS 向けの最新系を入手する。
MCP の URL とログの一致：ホスト名・ポート・wss:// か https:// かを IDE 設定と突き合わせる。
分流ルールの位置：MCP 用行が広い MATCH より上にあるか。
策略グループ：長接続向けに、遅延の小さいノードへ手動固定できるか。
DNS／Fake-IP：名前解決がルールと矛盾していないか。
TLS とセキュリティ製品：HTTPS インスペクションがあれば例外または切り分け。

これでも改善しない場合は、MCP サーバー側の負荷・メンテナンス、あるいは組織のゼロトラストポリシーが絡んでいる可能性があります。サーバーのヘルスとドキュメントを確認し、時間を置いて再試行するのも現実的です。

10. まとめ

Model Context Protocol のリモート MCPは、IDE プラグイン越しに長い TCP／TLS セッションを張ることが多く、汎用 PROXY と同じ策略グループに載せたままでは、遅延・輻輳・フェイルオーバーで接続が途切れやすいです。分流ルールで MCP 用ホスト名を明示的に切り出し、低遅延ノードへバインドし、DNS とログを揃えると、体感の安定性は大きく改善することが多いです。

2026 年時点では、MCP のホスト名もプロバイダの運用で変わり得ます。固定リストより接続ログの実名を正としてルールを育てる運用が、再現性の高い対処です。Clash 系クライアントはログとルールの対応が追いやすく、試行錯誤のコストを下げやすいという利点があります。

→ Clash を無料ダウンロードし、MCP 向けの分流とノードを試す