1. 検索意図：マーケットが開くのに MCP だけ落ちる理由
まず押さえたいのは、拡張マーケットやエディタ本体の更新が通っているのに、追加した MCP サーバだけが応答しない、というパターンです。前者は主に Cursor 公式の配信・CDN・認証ドメインに依存し、後者はしばしば GitHub Releases や raw コンテンツ、あるいはあなたが指定したリモート URL（SSE を含む）へ直接伸びます。社内ゲートウェイでは、ブラウザ向けの例外と、IDE が起こす長回線の TLS が別扱いになることも珍しくありません。切り分けの第一歩は、「Cursor 全体が悪いのか」「MCP 用のホスト集合だけが別経路に落ちているのか」を分けることです。
YAML の流れや購読の取り込みに不安がある場合は、サブスクリプション取り込みの記事で設定ファイルの骨格を確認してから読み進めると理解が早いです。
2. MCP 伝送チェーンを「層」で把握する
リモート MCP は実装ごとに差がありますが、Clash のルール設計では次のような層に分けて考えると迷いにくいです。重要なのは、一枚岩の「cursor ドメイン」だけ見て満足しないことです。
| 層 | 典型ホストのイメージ | 障害時の手がかり |
|---|---|---|
| カタログ／レジストリ | 公式やコミュニティが案内する MCP 一覧の取得元 | 一覧は見えるが、個別サーバ追加で止まる。 |
| 配布物・ソース取得 | github.com、api.github.com、objects.githubusercontent.com、raw.githubusercontent.com など | インストール手順に従うと TLS やタイムアウト、レート制限の気配。 |
| ベンダ API | MCP 実装が依存する REST／GraphQL 相当 | ツール一覧は出るが実行結果だけ返らない。 |
| SSE／ストリーミング | /sse 等を公開する別サブドメインやパス | 接続直後は成功に見え、しばらくして切断・再試行ループ。 |
実際のホスト名はテンプレートや自己ホスト運用で大きく変わります。Cursor の接続ログや OS の名前解決結果だけでなく、Clash の接続ビューに出た行を正にしてください。GitHub 周辺の一般的な切り分けは、GitHub Copilot と Microsoft 系を分けた記事とも参照できますが、MCP はCopilot 以外のリポジトリや raw 取得が増えがちです。
3. 画面に出やすい症状と、背後のネットワーク意味
スピナーが終わらない場合、多くは「SSE や WebSocket 相当の長回線が途中で詰まっている」か「DNS が返す宛先と、実際に張られた TCP の出口が食い違っている」かのどちらかです。TLS ハンドシェイク失敗と表示されるときは、プロキシがCONNECT を正しく中継していない、企業ゲートウェイの証明書置換とクライアントのピン留めが衝突している、SNI が検査対象になっている、といった層を疑います。逆に、マーケットは開けるのに MCP だけ失敗するなら、Cursor 本体の経路は概ね健全で、MCP 専用のサフィックス群が購読ルールの広い DIRECT に落ちている可能性が高まります。
4. ログ収集：MCP を有効化した直後だけを切り取る
手順の要点は次のとおりです。余計なタブやバックグラウンド更新を減らすと読みやすくなります。
- Clash を起動し、システムプロキシまたは TUN のどちらで握っているか固定する。別 VPN は一旦無効化する。
- Cursor で MCP サーバを追加し、問題のスピナーやエラーを再現する。
- 同じ時間帯の接続ログをエクスポートまたは画面キャプチャし、
github、cursor、sse、ベンダ固有のサフィックスを目視でタグ付けする。 - 失敗した行について、策略名（
DIRECTか特定のproxy-groupsか）と遅延・エラー種別をメモする。 - 購読ルールのどの行より上に自作ルールを置くべきかを決める。
CLI からも GitHub へ到達する場合は、ターミナル環境変数と Clash の記事で、シェルと GUI が別出口になっていないかも併せて確認するとよいです。
5. 検証コマンド：TLS と HTTP／2 を切り分ける
IDE の裏で何が起きているかを短時間で見るには、ターミナルからの確認が有効です。以下は例示であり、実際のホスト名とポートはログに合わせて置き換えてください。
# Example: check TLS to GitHub API (replace hosts as needed)
curl -vI https://api.github.com/
# Example: inspect certificate chain for a custom MCP host
openssl s_client -connect example-mcp.example.com:443 -servername example-mcp.example.com </dev/nullcurl -v の出力では、HTTP/2 の SETTINGS 以降で止まるのか、Client Hello の直後で切れるのかを見分けると、プロキシ互換性か純粋な到達性かの当たりが付きます。openssl s_client は、企業検査用の中間 CA が挿入されていないかを人間の目で追うのに向いています。Windows でシステムプロキシの取りこぼしが疑わしいときは、UWP と Microsoft Store 周辺の記事も参照ください。
6. 分流ルールの考え方（コピーはログ確認後に）
購読ルールに「国内直結の広い DOMAIN-SUFFIX」が先に来ていると、GitHub の一部ホストだけ意図せず DIRECT へ落ち、残りがプロキシ、という分裂が起きます。対策は、ログで頻出した名前をより上段に、サフィックス単位で矛盾なく並べることです。以下は出発点の例です。実運用では必ず自分のログに合わせて増減してください。
# Example only — verify in your Clash logs; align proxy group names with your config
rules:
- DOMAIN-SUFFIX,github.com,PROXY
- DOMAIN-SUFFIX,api.github.com,PROXY
- DOMAIN-SUFFIX,raw.githubusercontent.com,PROXY
- DOMAIN-SUFFIX,objects.githubusercontent.com,PROXY
- DOMAIN-SUFFIX,githubusercontent.com,PROXYSSE を別ドメインで提供している実装では、そのホストを Web API 用のグループと長回線用のグループに分けるか、同一グループでもUDP や HTTP/2 の扱いが安定したノードへ寄せるかを検討します。グループ名は proxy-groups に存在するものに合わせてください。
7. DNS／fake-ip：名前と実接続のズレ
fake-ip は体感を速くしますが、ルール判定に使う名前と、実際のバックエンド解決がズレると、IDE 側では「接続したのにすぐ切れる」ように見えます。MCP のように短い REST と長い SSEが混在するケースでは、ズレが出やすいです。対策として、頻出サフィックスに nameserver-policy 相当の設定を当てる、上流 DNS を信頼できるものに固定する、といった方針が取られます。フィールド名はコアのバージョン差があるため、利用中の Mihomo／Meta のドキュメントと突き合わせてください。
8. システムプロキシと TUN：長回線の取りこぼし
SSE はしばしば同一 TCP 上で長時間アイドルに近い状態が続きます。システムプロキシを読まないサブプロセスや、別製品の TUN と競合すると、イベントだけ届かないという部分故障が出ます。TUN モードの解説を参照し、有効化したあとに再接続ログですべての MCP 関連ホストが期待する策略に入ったかを再確認してください。併用 VPN がある場合は、ルートの奪い合いで片方の経路だけ生きる瞬間がある点にも注意が必要です。
9. 推奨する切り分け順序（チェックリスト）
- Clash のモード（ルール／グローバル等）と、実際に命中しているルール行を確認する。
- MCP 追加直後のログで、GitHub 系とカスタム SSE ホストを色分けしてリスト化する。
curl -vIとopenssl s_clientで、ターミナルからの TLS が GUI と一致するか比較する。- 必要なら TUN に切り替え、または一時的に全会話を同一安定ノードへ寄せて再現性を見る。
- 改善後も、購読更新でルール順が崩れないよう自作ルールの位置をテンプレート化しておく。
汎用的なポート占有やコア起動失敗はトラブルシュート記事へ。本稿は MCP と GitHub／SSE の多ドメイン性に絞っています。
10. 追加の落とし穴：レート制限・IPv6・企業 SSL 検査
GitHub API は匿名アクセスでもレート制限があり、MCP のインストーラが短時間に多数リクエストを投げると 403 や遅延に見えることがあります。これはプロキシの良しあしではなく、トークン設定やキャッシュ設計の問題であることもあるため、HTTP ステータスをログで確認してください。また IPv6 が有効な回線では、IPv4 だけプロキシへ乗る偏りで「ブラウザでは成功、IDE では失敗」が起きます。企業側の SSL 検査は証明書チェーンを壊すため、TLS 失敗として表面化しやすいです。セキュリティ担当と例外方針を調整する前に、検査のない回線で同じ手順が通るかを見ると層が分かれます。
11. 既稿のマーケット記事との役割分担
拡張マーケット向けの分流記事では、エディタ本体・マーケット CDN・AI 補完 API の束ね方を中心に扱いました。本稿では、MCP の追加フローが伸ばす GitHub と SSE の専用経路に焦点を当てています。症状が似ていても、ログに出るドメイン集合が異なる場合は、記事を読み分けてください。両方のホストが混在するなら、ルールは共通の安定出口に寄せつつ、ログで副作用のない範囲に絞り込むのが安全です。
12. まとめ：証拠ベースで MCP の多ドメインを束ねる
遠隔 MCP の不調は、単一の「Cursor がダメ」よりも、GitHub 資産取得・レジストリ・API・SSEのどこで経路が割れたかをログで示すと改善が早いです。2026 年も AI 開発ツールチェーンの更新は速いので、購読ルールに頼り切らず、自分の環境で一度ホスト表を更新する習慣を持つと安心です。接続ビューと YAML 編集を一体で扱えるクライアントを選ぶと、運用負荷も下がります。
同種のツールのなかでも、策略表示とコアの整合が取りやすい製品ほど、MCP のような長回線混在構成で長く使い続けやすい印象です。安定した出口設計から始めたい方は、→ Clash を無料ダウンロードして、快適な接続体験を始める