症状と検索意図：CLI ログインが時々落ちる、MCP がつながらない

GitHub Copilot CLI を使っていると、同じマシンでも今日は通ったのに明日はデバイス認証が終わらない、あるいは MCP（Model Context Protocol） 経由のツール呼び出しだけがタイムアウトする、といった断続的な失敗に遭遇することがあります。検索では「Copilot CLI ログイン」「MCP 接続」「開発者 プロキシ」といった語が一緒に現れやすく、背景としては海外系ホストへ伸びる経路の混線、キャリアや回線の差、企業プロキシ、常時 DNS の揺れなどが挙げられます。

日本語圏の読者でも、リモート開発で海外データセンターへ伸びる経路や、社内セキュリティ機器の TLS 検査とぶつかる場面は珍しくありません。ここでの論点は「Copilot が悪い」の単純化ではなく、CLI が実際にどのホストへ、どの出口で TLS を張っているかを可視化し、不安定な素通りを避けることです。

本稿の前提：以降の手順は Clash Verge Rev（Mihomo / Meta コアを載せる GUI クライアント）を想定していますが、考え方は他の Clash 系デスクトップにも転用できます。利用規約・勤務先ポリシー・接続先プロバイダのルールを必ず優先してください。

Copilot CLI と MCP が触りがちな通信の型

実装や版により細部は変わりますが、CLI 周辺ではだいたい次のような外向きが混ざります。

  • GitHub API：api.github.com などへの REST／GraphQL 風の呼び出し。
  • 認証とウェブフロー：github.com ドメイン群、デバイスコード入力のためのブラウザ遷移。
  • MCP：ローカルの MCP サーバと IDE／CLI の間はループバックが中心でも、モデルや検索など外部ツールを併用する構成では、追加の HTTPS／WebSocket 系が増えます。

ポイントは、1 つのアクションの裏で複数ホストに縦割りアクセスが走ることです。ブラウザのタブでは「とりあえず表示できた」ように見えても、CLI だけが別ホスト・別ポートのハンドシェイクで詰まることがあります。

Clash Verge Rev 側の下準備（購読・競合・権限）

分流を語る前に、GUI で次を満たしているか確認してください。

  1. 有効な購読プロフィールが選択され、ルール／プロキシグループが読み込まれている。
  2. 別ベンダーの常駐 VPNやフィルタが同一ルートを握っていない（検証中は止めると切り分けが速い）。
  3. TUN を使う OS では、ネットワーク拡張や UAC の許可が途中でキャンセルされていない。

Verge Rev はプロフィールの切り替えや接続ログの表示がしやすいので、「今どのルールに当たったか」を追う学習コストが下がります。ここが 開発者向けプロキシ を自己管理するときの快適さにつながります。

ルール分流：GitHub 系をプロキシ側へ「載せる」

国内外スプリット型の購読では、GEOIP や巨大な DIRECT ルールが先に置かれ、GitHub だけが狭い直通出口へ落ちることがあります。CLI の TLS がダメージを受けやすいのはこのパターンです。

運用上のコツは次のとおりです。

  • ドメイン系ルールを上流に置く：DOMAIN-SUFFIX や DOMAIN-KEYWORD で github.com などを明示し、意図したプロキシグループへ流す。
  • ログで実名を確認：購読の辞書に無い CDN 名が出たら、その行をプロフィールのローカル追記や rules の手前側に足す。
  • 過剰なグローバルの回避：開発ツールだけ海外プロキシ、社内イントラだけ直進、などに寄せると日常の遅延も下がります。
# Example snippet — adjust group names to match your profile
# DOMAIN-SUFFIX,github.com,PROXY
# DOMAIN-SUFFIX,githubusercontent.com,PROXY
# DOMAIN,api.github.com,PROXY

コメントとマーカーは英字のままにしてあります（チームで差分を共有しやすくするため）。本番のグループ名は購読側の定義に合わせて置き換えてください。

システムプロキシだけで足りないときに TUN を検討する理由

macOS や Windows では、GUI から システムプロキシ をオンにできる場合があります。多くの IDE はこれを拾う一方、ターミナルを別起動したシェルや、バックグラウンドのエージェントが環境変数を読まずに外向きへ行くケースがあります。

TUN（仮想 NIC）は、HTTP プロキシをアプリごとに説教する代わりに、OS 近辺で TCP／UDP をルールエンジンへ一度集約する発想です。GitHub Copilot CLI のように複数ホストへ短いセッションを連発するワークロードでは、接続パネルで命中結果を追いやすいことが多いです。

初期切り分けの注意：システムプロキシと TUN を同時にオンにして挙動が読みにくくなら、どちらか一方に寄せてから copilot コマンドや MCP を試してください。二重経路はログ解析を面倒にします。

DNS・fake-ip と「名前は通るのに経路がズレる」罠

Mihomo 系プロフィールでは dns.enhanced-mode が fake-ip の構成も珍しくありません。名前解決の応答と実接続の順序が噛み合わないと、画面上はプロキシに見えて実際は別出口、という印象を持ちやすいです。

  • 購読提供者の README に沿って、国内ドメインだけ直進などの例外を矛盾なく置く。
  • CLI ツールが 独自の DNS を指定していないか（企業マシンのグループポリシー等）を確認する。
  • IPv6 が別経路のときだけ症状が出る場合は、検証期間だけ比較実験する（恒久設定は慎重に）。

ログインと MCP をログで突き合わせる実務フロー

手順を短くまとめると次の流れです。

  1. Verge Rev で接続ログを開き、フィルタを絞れる状態にする。
  2. GitHub 系ホストが想定どおりのプロキシグループへ流れているか確認する。
  3. CLI のログインをもう一度実行し、タイムアウト直前の宛先名をメモする。
  4. MCP 利用時も同様に、ツール呼び出しの瞬間に新しい外向きが増えないか追う。

ここで見つかったホスト名は、ルールの上流側に明示ルールとして足すのが早いです。「全部 PROXY」よりも読みやすい購読なら、国内トラフィックの体感速度も維持しやすくなります。

チェックリスト：それでも不安定なとき

  • 別 VPN が常駐していて TUN と競合していないか。
  • プロキシグループの自動選択が不安定ノードを掴んでいないか（遅延テストと手動ノードの比較）。
  • ウイルス対策の HTTPS 検査が TLS を壊していないか（個人端末・許可された検証環境での話）。
  • レート制限やアカウント側の一時ブロックを疑い、時間を空けて再試行する。

よくある質問

ブラウザは通るのに CLI だけ落ちるように見えるのはどういうこと？

プロセス境界とプロキシ参照の差です。ブラウザは拡張や独自のプロキシチェーンを持ち、CLI はシンプルな TCP スタックのまま不安定な直出口へ落ちることがあります。デバイス認証の途中で一発だけ別ホストへ飛び、そこで詰まるパターンが典型です。

MCP サーバはローカルなのに外部が関係するの？

ローカル IPC が中心でも、ツールが外部 API を読む構成なら結果として HTTPS が増えます。IDE から見える接続と、CLI 側エージェントの接続が一致しない場合があるので、ログで実名を取るのが近道です。

会社の PC で試してよい？

内規とセキュリティポリシーが最優先です。許可なきプロキシ変更や証明書操作は避け、必要なら IT 部門のガイドに沿ってください。

単体プロキシより Clash 系を開発フローに載せる利点

環境変数を毎ターミナルで手入力する運用は、単一リポジトリでは速い一方、IDE 統合ターミナルやバックグラウンドタスクになると抜けがちです。また HTTP_PROXY だけでは、UDP や複数ホスト縦割りのケースで追いづらくなります。

Clash Verge Rev のようなクライアントは、購読・ルール・接続ログ・TUNを一つの画面から扱えることが多く、GitHub Copilot CLI や MCP のように外向きが細かく分岐するツールほど差が出ます。単機能の軽量プロキシより、ルールエンジンと可視化が揃っている方が、断続的な失敗を再現しにくいタイプの不具合に強いです。

配布物や署名付きパッケージの入手経路が分散しがちなので、公式サイトで整理された導線から揃えるのが安全です。下のリンクから、各 OS 向けの Clash クライアント一覧へ進めます。

Clash を無料ダウンロードし、Verge Rev 相当のクライアントを入手する →