ClashでGitHub Copilotが使えない？接続エラーの直し方

Clashを有効にした状態でVS CodeやJetBrains IDEを起動すると、GitHub Copilotの補完が表示されない、サインインが完了しない、「ネットワークエラー」「Failed to connect」のようなメッセージが出ることがあります。GitHub Copilotが使えない原因は、単純なノード障害だけではありません。Clashのプロキシモード、GitHub関連ドメインのルール、DNS解決、システムプロキシの反映、TUNモードの競合など、複数の層が関係しています。この記事では、Clash使用時にGitHub Copilotが接続できない場合の確認方法を、切り分けしやすい順番で解説します。

GitHub Copilotが接続できない主な原因

GitHub Copilotは、単一のWebページを開くだけのサービスではありません。IDEの拡張機能は、認証、補完リクエスト、設定取得、ライセンス確認、テレメトリーなど、複数の接続先へHTTPSリクエストを送信します。そのため、ブラウザーでGitHubが開けても、Copilotだけが動作しないことがあります。

特に多いのは、Clashがシステム全体の通信を処理していると思っていたのに、VS CodeやJetBrainsが別のプロキシ設定を使っているケースです。逆に、IDE側でプロキシを指定した結果、Clashのポートへ二重に接続しようとして失敗する場合もあります。また、GitHub本体だけをプロキシ対象にして、CopilotのAPIや認証用ドメインをDIRECTにしているルールも典型的な原因です。

まずは問題を「Clashを停止するとCopilotが動くか」「ブラウザーでは関連サイトへ接続できるか」「別のノードで改善するか」の3点に分けて考えます。Clashを停止すると直るなら、アカウントや拡張機能そのものよりも、経路設定に原因がある可能性が高くなります。

プロキシモードとIDE設定を確認する

最初に確認するのはClashの動作モードです。Clash VergeやClash Verge Revでは、通常のHTTPプロキシとして動作するシステムプロキシモードと、アプリケーションの通信をより広く取り込むTUNモードを利用できます。一般的なデスクトップ環境では、まずシステムプロキシを有効にし、VS CodeまたはJetBrains側のプロキシ設定を「システム設定」または自動検出にする構成が安定します。

Clashの混合ポートが例えば7890の場合、HTTPとSOCKSの両方を受け付けるクライアントでは次のような設定になります。ただし、IDEに手動入力する前に、Clashが実際にそのポートで待ち受けているかを確認してください。ポート番号が異なる状態で固定値を入力すると、認証画面も補完機能も接続できません。

mixed-port: 7890
mode: rule
log-level: info
allow-lan: false

# APIを使う場合の例。外部公開は避けてください
external-controller: 127.0.0.1:9090

VS Codeでは、設定画面で「proxy」や「proxy support」を検索します。通常はClashがシステムプロキシを設定しているなら、プロキシURLを手動で指定せず、自動検出を利用する方がトラブルを減らせます。組織のネットワークなどで手動設定が必要な場合は、Clashの混合ポートをHTTPプロキシとして指定し、不要な認証情報を入力しないでください。設定変更後は、拡張機能の再読み込みだけでなく、VS Code自体を再起動すると確実です。

JetBrains IDEでは、Settings → Appearance & Behavior → System Settings → HTTP Proxyを開きます。「No proxy」「Auto-detect proxy settings」「Manual proxy configuration」の違いを確認し、Clashのシステムプロキシを使う場合は自動検出を試してください。手動設定を使う場合、HTTPプロキシのホストは127.0.0.1、ポートはClashの混合ポートです。SOCKSポートをHTTP欄に入力したり、HTTPポートをSOCKS欄に入力したりすると、接続が不安定になります。

GitHub関連ルールとノードを検証する

GitHub Copilotの通信を正しく処理するには、GitHubのトップページだけでなく、認証や補完APIに使われるドメインも同じ経路で到達できなければなりません。設定ファイルやルールプロバイダーにGitHub用の分類がある場合、まず現在のモードがruleであること、そしてGitHub関連ルールが意図したプロキシグループを指していることを確認します。

ルールの順番も重要です。広い範囲のDOMAIN-SUFFIX,github.com,DIRECTが先に置かれていると、後ろに追加したプロキシルールへ到達しません。ルールプロバイダーを使っている場合は、更新に失敗して古い内容が残っていないか、ダッシュボードのルール画面で確認してください。

rules:
  # 実際の環境にあるプロキシグループ名へ置き換えます
  - DOMAIN-SUFFIX,github.com,Proxy
  - DOMAIN-SUFFIX,githubusercontent.com,Proxy
  - DOMAIN-SUFFIX,githubassets.com,Proxy
  - DOMAIN-SUFFIX,copilot.microsoft.com,Proxy
  - DOMAIN-SUFFIX,microsoft.com,Proxy
  - MATCH,DIRECT

これは診断用の例であり、すべての環境で同じルールを恒久的に追加する必要はありません。接続ログに表示される実際の宛先を見ながら、必要なドメインだけを調整してください。GitHub関連の通信を広範囲にプロキシすると、Git操作やパッケージ取得まで経路が変わり、速度や社内サービスへのアクセスに影響することがあります。

次にノードを確認します。ノード一覧でping値が低くても、GitHubやMicrosoft系サービスへのHTTPS接続が正常とは限りません。ノードの出口ネットワークが特定サービスで制限されている場合や、TLS中継に問題がある場合があります。現在のノードで失敗したら、同じプロキシグループ内の別地域ノードを選び、IDEを再起動して比較します。複数ノードで同じ結果ならルールやDNSを、特定ノードだけで失敗するならノード側を重点的に疑います。

動作ログを見ながら修正する手順

ここでは、設定をむやみに変更せず、接続ログを使って原因を絞り込む手順を実行します。Clash VergeやMihomoのダッシュボードでは、接続一覧に宛先、使用ルール、プロキシグループ、接続状態が表示されます。Copilotの再接続を実行した直後にログを確認すると、どのリクエストが失敗しているかを見つけやすくなります。

1. Clashを起動し、プロキシモードを一度「Rule」に設定します。グローバルモードでの検証は可能ですが、通常のルール構成で再現するか確認する方が実用的です。
2. Clashのログレベルを一時的にinfoへ変更し、接続履歴を空にします。大量のバックグラウンド通信がある場合は、IDE以外のアプリを閉じます。
3. VS CodeまたはJetBrainsでGitHub Copilotからサインアウトし、IDEを完全終了します。その後、Clashの接続履歴を確認してからIDEを再起動します。
4. 認証操作や補完入力を行い、GitHub関連のドメインがログに現れるかを確認します。表示されない場合は、IDEがClashを使っていないか、別のプロキシ設定を参照している可能性があります。
5. 表示された接続のルール欄を確認します。DIRECTで失敗しているなら、診断用に対象ドメインをプロキシへ変更し、再試行します。
6. プロキシ経由でも失敗する場合は、別ノードへ切り替えます。別ノードで直るなら、設定を変更する前に元ノードの到達性や出口IPを疑います。
7. 接続が成功したら、ログレベルを元に戻し、必要なドメインだけをルールへ反映します。診断用に追加した広範囲のルールは削除してください。

DNSとTUNモードの最終確認

ルールとノードに問題がない場合は、DNSを確認します。DNSがローカルネットワークで書き換えられている、IPv6だけ名前解決に成功している、またはTUNモードのDNS hijackが別のアプリと競合していると、ブラウザーとIDEで異なる結果になることがあります。ClashのDNSログや接続エラーを確認し、同じドメインが毎回異なるIPへ解決されていないかを見ます。

Mihomoを使っている場合、TUNモードではauto-routeやdns-hijackが通信経路を大きく変更します。TUNはシステムプロキシを無視するアプリにも有効ですが、仮想ネットワークアダプター、他のVPN、セキュリティソフトのWeb保護機能と競合しやすい機能です。TUNを一時的に無効にしてシステムプロキシだけでCopilotを試し、逆にシステムプロキシを無効にしてTUNだけで試すと、どの層で問題が発生しているか分かります。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

この設定をそのまま追加するのではなく、使用しているMihomoのバージョンとクライアントのGUI項目に合わせて確認してください。特に既存のVPNや別のTUN実装が動作している場合は、同時利用を避けます。DNS変更後はキャッシュが残るため、Clashの再起動、IDEの再起動、必要に応じたOSのDNSキャッシュ削除を行います。

最後に、証明書エラーが出ている場合は、安易にskip-cert-verify: trueを有効にしないでください。これは接続を一時的に通すように見えても、TLS証明書の検証を無効化し、安全性を下げます。まずシステム時刻、ノードのTLS設定、SNI、セキュリティソフトによるHTTPS検査を確認し、信頼できるノードへ切り替えて再テストするのが安全です。

GitHub Copilotの接続問題は、Clashを単にオン・オフするだけでは解決しないことがあります。プロキシモードとIDE設定を一つに整理し、接続ログで実際の宛先とルールを確認し、別ノード、DNS、TUNの順に切り分けると、原因を短時間で特定できます。設定を見直した後もCopilotが動かない場合は、Clashを停止した状態でIDEのログイン状態や拡張機能の更新も確認し、ネットワーク経路とアカウント側の問題を分けて調査してください。