GitHub Copilotが遅い・接続できない時のClash設定

GitHub Copilotだけが遅くなる理由を先に切り分ける

GitHub Copilot を使っていると、「補完候補が数秒後に表示される」「サインイン画面が完了しない」「Copilot Chat だけが接続タイムアウトになる」といった症状が起きることがあります。ブラウザで GitHub を開けるため、最初は IDE や拡張機能の不具合だと思いがちです。しかし実際には、GitHub のウェブ画面、Copilot の認証、補完リクエスト、Copilot Chat、拡張機能の更新確認が、常に同じホストや同じ通信方式を使うとは限りません。Clash のシステムプロキシを有効にしただけでもブラウザは通る一方、IDE のバックグラウンド通信だけが別経路に残るケースがあります。

VS Code、JetBrains IDE、Visual Studio などの開発環境では、Copilot 拡張が親プロセスとは別に HTTPS 接続を作ります。さらに、認証時にはブラウザを開いて GitHub 側の OAuth を利用し、認証後のトークン確認や補完 API では別のエンドポイントへ接続します。そのため「GitHub.com は表示できるのに、Copilot の提案だけ来ない」という現象は、単純なサイト全体の遮断ではなく、特定ホストのルール、ノード品質、TLS 接続、IDE のプロキシ継承を分けて調べる必要があります。

Clash のモードと IDE が使うプロキシを確認する

まず Clash 側でプロファイルが正常に読み込まれ、コアが起動しているか確認します。購読更新直後にプロファイルが空になっていたり、プロキシグループの選択が未設定になっていたりすると、画面上では「Clash が起動中」に見えても通信は MATCH の既定ルールへ流れます。最初の検証では複雑なルールセットを一度に変更せず、現在選択されているグループ、ノードの遅延、接続ログの三つだけを確認するほうが安全です。

ブラウザで GitHub を開くテストには、Clash のシステムプロキシを使う構成が便利です。ただし、システムプロキシが有効でも、IDE や拡張機能がその設定を自動継承するとは限りません。VS Code では設定の http.proxy、http.proxySupport、プロキシ認証の有無を確認し、JetBrains 系では HTTP Proxy の設定画面で「システムプロキシ」または手動指定がどちらになっているか確認します。Clash の mixed-port が 7890 なら、IDE 側の HTTP プロキシも同じポートを参照しているかを見比べてください。

一方、TUN モードを使用している場合は、アプリごとにプロキシ設定を渡さなくてもカーネル側で通信を捕捉できることがあります。ただし、TUN とシステムプロキシを同時に使うと、アプリによって二重経路になったり、既存 VPN やセキュリティソフトのフィルタと競合したりします。最初は「システムプロキシだけ」、次に「TUN だけ」というように一つずつ試し、同じ補完操作で結果を比較してください。二つの方式を同時に切り替えると、どの変更が効いたのか分からなくなります。

GitHub・Copilot 関連通信をルールで確認する

Copilot の問題を直すために、最初から GitHub 関連のすべてのドメインを同じノードへ固定する必要はありません。重要なのは、接続ログに実際に現れたホストがどのルールへ一致したかを確認することです。一般的には github.com、api.github.com、githubusercontent.com のような GitHub の基盤、認証に関係するホスト、Copilot の補完や Chat が利用するサービス側のホストが別々に現れる可能性があります。サービス構成は更新されるため、古いブログのドメイン一覧をそのまま信頼しないでください。

ルールの順番も重要です。上位に広い広告ブロック、地域別ルール、GEOIP、または別サービス向けの DOMAIN-SUFFIX があると、GitHub 関連ホストが意図しない策略に先に一致する場合があります。Clash は基本的に上から評価し、最初に一致したルールで出口を決めます。そのため、Copilot 用の検証ルールは一時的に MATCH より上へ置き、どのルールに当たったかをログで確認すると原因を追いやすくなります。動作確認が終わったら、広すぎる指定を削り、必要なホストだけに縮小してください。

Illustrative rules fragment — replace the policy with your own group name

rules:
  - DOMAIN,github.com,COPILOT_STABLE
  - DOMAIN,api.github.com,COPILOT_STABLE
  - DOMAIN-SUFFIX,githubusercontent.com,COPILOT_STABLE
  - DOMAIN-SUFFIX,githubassets.com,COPILOT_STABLE
  - MATCH,PROXY

上の例は考え方を示すための雛型であり、すべての環境で必要な固定リストではありません。Copilot のログインだけが失敗する場合は認証ホストを、補完だけが遅い場合は補完リクエストのホストを、それぞれ接続ログから追加します。未知のホストを推測で大量に登録すると、将来の設定更新で不要な通信まで同じ出口へ送ることになります。また、GitHub の企業アカウントや組織ポリシーを利用している場合は、管理者が指定する認証・ネットワーク要件を優先してください。

認証エラー・補完遅延・Chat タイムアウトを分けて直す

認証画面が開かない場合は、まずブラウザで GitHub にログインできるかを確認します。ブラウザも開けないなら、Clash のノード、DNS、システムプロキシを先に調べます。ブラウザは正常なのに IDE の認証だけ止まるなら、IDE がシステムプロキシを継承していない、内蔵ブラウザの証明書ストアが別、またはローカルコールバック用のポートがセキュリティソフトに遮られている可能性があります。ログアウトと再ログインを繰り返す前に、IDE の出力パネルや拡張機能ログで HTTP ステータスと接続先を確認してください。

認証は完了したが補完候補が遅い場合は、常時切断ではなく、ノードの遅延やストリーミング応答の不安定さを疑います。短いコードを入力して候補を待つテストを数回行い、最初の候補だけ遅いのか、すべての候補が遅いのかを区別します。最初だけ遅いなら認証トークンの確認や接続確立が原因かもしれません。入力のたびに遅いなら、IDE の拡張機能、除外設定、ネットワーク品質、または Copilot 側のレート制限を確認します。

Copilot Chat だけがタイムアウトするときは、通常の補完と Chat が別 API 経路である可能性があります。補完が成功した事実だけで、Chat の接続性まで保証されたとは考えないでください。Clash の接続一覧で、Chat を送信した瞬間に新しいホストが現れるか、そのホストが DIRECT や拒否ポリシーへ落ちていないかを見ます。IDE の再起動で一時的に直る場合でも、DNS キャッシュやトークン更新のタイミングが変わっただけかもしれないため、再現条件をメモしておくと再発時に役立ちます。

1. 認証テスト：IDE からログアウトし、ブラウザ認証を一度だけ実行する。
2. 補完テスト：小さなコード片で候補表示までの時間を測る。
3. Chat テスト：短い質問を送り、Clash の新規接続と応答時間を見る。
4. 比較テスト：別ノードまたは別のプロキシ方式で同じ操作を繰り返す。
5. 固定化：改善した条件だけを YAML と IDE 設定へ反映する。

DNS と TLS の確認ポイント

ドメインルールを正しく書いても、名前解決が不安定なら Copilot はタイムアウトします。Clash の DNS モード、Fake-IP の挙動、OS 側の DNS キャッシュ、企業ネットワークの DNS 強制を確認してください。とくに TUN を有効にした直後だけ接続できなくなる場合、ブラウザの DNS と IDE の DNS が別経路になっていないかが重要です。Clash のログに名前解決エラーがあるなら、ノード変更より先に DNS 方針を整理します。

TLS エラーが出る場合は、証明書検査や HTTPS 復号を無闇に有効化しないでください。IDE、Java ランタイム、Node.js ランタイムは、それぞれ異なる証明書ストアを参照することがあります。企業の TLS インスペクション環境では、管理者が配布した CA 証明書が必要な場合もあります。個人環境で突然証明書エラーが出たなら、Clash の設定だけでなく、システム時刻、セキュリティソフト、古い IDE、拡張機能の破損も候補に含めます。

再発を防ぐための運用手順

GitHub Copilot を安定させるには、設定を一度書いて終わりにせず、変更の単位を小さく保つことが大切です。購読プロファイルを直接編集すると更新時に消えることがあるため、Clash Verge、Clash Verge Rev、Mihomo 系クライアントで利用できるローカルオーバーライドや専用プロファイルへ追記します。編集前には元の YAML を保存し、変更したルール、使用したノード、テスト日時を短いメモに残してください。こうすれば、次の購読更新で遅延が発生したときにも、ルール変更とノード品質の差を比較できます。

ノードを選ぶ際は、単発の速度テストだけで判断しないことも重要です。Copilot は短い HTTPS リクエストを繰り返すだけでなく、認証更新や Chat の長めの応答を含むため、平均レイテンシが低いノードでも接続維持が不安定なことがあります。複数の候補を同じ時間帯に試し、認証、補完、Chat の三つがすべて安定する出口を選びます。自動選択グループを使う場合も、測定 URL が GitHub や Copilot の実通信品質を直接表すとは限らないため、最終判断は実際の IDE 操作で行ってください。

最後に、GitHub 側の障害や Copilot の利用制限も切り捨てないでください。Clash の接続ログが正常で、複数のノードと複数のプロキシ方式で同じ時間帯に失敗するなら、クライアント側だけを何度も編集するより、GitHub のステータス、組織の利用ポリシー、アカウント状態を確認するほうが合理的です。逆に特定のノードだけで再現するなら、原因はサービス全体ではなく出口品質やルールに寄っている可能性が高くなります。

GitHub Copilot のトラブルでは、ブラウザ中心の単純な VPN アプリは IDE ごとのプロキシ継承や TUN／DNS の切り分けが弱く、古い Clash クライアントでは Mihomo の新しい設定項目やログ表示に追いつかないことがあります。その点、Clash V.CORE はプロファイル、策略グループ、接続ログ、システムプロキシを一つの流れで確認しやすく、Copilot の認証・補完・Chat を同じ検証手順で比較できます。設定を自分で管理しながら安定した開発環境を作りたい方は、対応クライアントと更新情報を確認したうえで、Clash V.CORE をダウンロードして今回の切り分けを始めてください。