なぜMCPは「普通のブラウザ越え」と切り分けが違うのか
MCPは仕様としてクライアント実装が分散しており、接続は最終的にOSのソケットスタックに落ちます。IDE統合ではホストプロセスがElectron系だったり、言語ランタイム上のHTTPクライアントだったりします。ここでシステムプロキシを参照しない実装があると、ClashをONにしてもHTTPSがDIRECTのまま残り、国境をまたぐ往復だけが律速になることがあります。逆にTUNで全域捕捉しているつもりでも、ループバック越しの別プロセスやすでに張られた長寿命コネクションが古い経路を握っていると、設定を直してもしばらく症状が残ります。まず「どのプロセスが」「どのホスト名へ」出ているかをログで固めるのが近道です。同じ開発者向けの整理として、Cursor・GitHub・npm向けの分流稿とも棲み分けできます。あちらはパッケージとGitが主役で、本稿はMCPとリモートモデルAPIに寄せています。
症状のラベル：タイムアウト、TLS、名前解決
典型的には次の三つに分類できます。① 接続タイムアウト：SYNすら返ってこない、または中間でRSTが多い。多くは意図しないDIRECTか、プロキシチェーンの片道だけ不通です。② TLS失敗：証明書名不一致や突然の切断は、誤った経路でターミネーションされている疑い（企業フィルタ、誤ったSNI、透明プロキシ）もありますが、Clash利用者で多いのは中継ノードの品質とルールの取り違えです。③ 名前解決の遅延・誤答：DoHとローカルキャッシュの二重解決、ISPのDNS改ざん、FakeIPとfake-ip-filterの不足などで、ルール以前にIPが期待とズレます。ここはMetaコアのDNSリーク防止ガイドとセットで読むと、用語の対応が取りやすいです。
第一步：接続ログでFQDNを確定する
記事に載っている「このドメインだけブロックすれば一生安心」リストは、MCPでは壊れやすいです。プロバイダがCDNや推論ゲートウェイのホストを増やすため、実行時ログのFQDNを正とします。Clash系クライアントのコネクション一覧で、失敗したタイムスタンプ付近のホスト名・ポリシー名・チェーンをメモしてください。HTTPSでSNIが見えない場合は、SnifferやDNSモード側の話になります。HTTPSのドメインをルールに載せたい読者は、Sniffer稿でHTTPSとドメインの関係を先に押さえると、MCPの切り分けが速くなります。
実務のコツ：「ブラウザでは開けるのにMCPだけ死ぬ」場合、ブラウザはプロキシPACや拡張で別経路を持っていることがあります。同一マシンでもプロセスごとに出口が違う前提でログを比較してください。
分流ルール：APIエンドポイントを束ねる考え方
FQDNが取れたら、rules:の上から最初の一致に載るよう並べ替えます。広いGEOIP,CN,DIRECTや巨大なRULE-SETが先に来ていると、細かいDOMAIN-SUFFIXを足しても届きません。MCPが叩くホストは、推論サービス本体に加え、認証トークン、テレメトリ、モデル一覧のメタデータなど複数に分かれることがあり、一見すると無関係なドメインでも同じポリシーに揃えた方が安定します。説明用のスケッチです。ポリシー名は手元のプロファイルに合わせて置き換えてください。
# Example sketch — align MCP-related HTTPS to one proxy group
# Replace YOUR_PROXY_GROUP with your proxy-groups name (exact match)
rules:
- DOMAIN-SUFFIX,example-inference.example,YOUR_PROXY_GROUP
- DOMAIN-SUFFIX,example-cdn.example,YOUR_PROXY_GROUP
- DOMAIN-KEYWORD,SomeVendorApi,YOUR_PROXY_GROUP
DOMAIN-KEYWORDは便利ですが過剰マッチしやすいので、運用ではログで拾ったホストをDOMAIN-SUFFIXに分解していくのが安全です。ルール順のデバッグ自体は、ルール順とMATCHの稿とセットで読むと、「書いたのに効かない」状態を短時間で潰せます。
DNS：FakeIP、直結、DoHの整合
分流は「名前がIPに変換されたあと」にも効きますが、解決がClash外で起きていると破綻します。FakeIPを使う構成では、アプリが受け取ったIPが実サーバではなくプール内の仮アドレスになります。ここがルール評価と矛盾すると、意図しないDIRECTや逆にループに見える挙動が出ます。nameserver-policyで特定サフィックスだけ別DNSへ、といった分割もよく使われますが、増やすほど二重解決やキャッシュの食い違いのリスクも上がります。MCPのように長めのHTTPSを張りっぱなしにするワークロードでは、DNSの揺らぎがすぐタイムアウトに化けるため、変更後はクライアントの接続ログとDNSログの両方を一度見直すのがおすすめです。
DoHとOSキャッシュの取り合い
ブラウザが独自DoH、OSが別のリゾルバ、ClashもDoH、の三層になると、「どこで名前が決まったか」が曖昧になります。トラブル時は一時的に経路を一本化して事実を取るのが早いです。本番運用に戻すときは、職場ポリシーと整合するか必ず確認してください。
TUNとシステムプロキシ：捕捉のすき間を埋める
システムプロキシだけでは拾えないプロセスがあるとき、TUNでOSルーティング層から入る手があります。一方でVPNや別のフィルタと二重になると遅延が増えるので、まずはプロキシのみで再現するかを切り分けます。手順の全体像はClash Verge RevのTUNモードガイドにまとめています。MCPサーバをstdioでローカル起動し、そこから外向きHTTPSを出す構成では、親IDEのプロキシ設定が子プロセスに継承されない例もあるため、環境変数HTTP(S)_PROXYの有無も併記してログに残すと後工程が楽です。
IDEプラグインとサードパーティMCP
拡張機能マーケットやモデルプロバイダのエンドポイントは、エディタ更新でホストが増えることがあります。類似の切り分けはWindsurf向け稿でも扱っています。MCPはプロトコル層が違っても、最終的にはドメイン単位のHTTPSに落ちるので、考え方は共通です。社内で許可リスト型のファイアウォールがある場合は、Clash以前に許可FQDNの更新がボトルネックになる点に注意してください。
作業チェックリスト（短い順）
- Ruleモードで購読とローカルルールが読み込めているか確認する。
- 問題操作を一つに絞り、接続ログのFQDNと命中ポリシーを取る。
- ルール配列の上側に広い行がないか確認し、必要なら例外を上へ移す。
- DNSがClashと矛盾していないか、FakeIP／DoH／OSリゾルバを点検する。
- システムプロキシだけで足りないプロセスがいればTUNを試し、二重トンネルに注意する。
- 長寿命接続が残っている場合は、対象アプリの再起動で経路を取り直す。
コンプライアンス
職場・学校・契約回線では、プロキシやトラフィック改道、外部推論APIの利用そのものが制限されていることがあります。許可された環境とポリシーの範囲でのみ設定し、第三者の資格情報や課金境界をまたいで中継しないでください。
注意：本稿のYAMLは理解を助ける例示です。キーや修飾子の正式な一覧は、利用中のコアとGUIのバージョンに合わせて必ず確認してください。
まとめ
MCP経由でリモートモデルに届かない問題は、単一のスイッチでは直りません。Clashの分流で出口を揃え、DNSで名前とIPの物語を一致させ、必要ならTUNで捕捉のすき間を埋める——この三層をログで順に潰すのが、2026年現在もっとも再現性の高いやり方です。ホットなプロトコルだからこそ、固定ドメイン表より実行時ログ優先を徹底してください。クライアントの入手と更新は、仕様確認とあわせて公式ダウンロードページを第一の導線にすると、配布物とソース閲覧の目的が混ざりにくくなります。
ルールとログが往復しやすいクライアントを選ぶと、一行動かした結果をすぐ確認でき、MCPのように試行錯誤が多い用途でもストレスが下がります。安定した接続はモデル選び以上に体感に効くので、まずは経路を静かに整えるところから始めるのがおすすめです。