GitHub Copilot のログインが Clash で止まる理由

GitHub Copilot にログインできない、ブラウザで認証ページは開くのに確認画面から先へ進まない、VS Code の右下にある Copilot アイコンが読み込み中のままになる——このような症状は、Clash のノードが単純に遅い場合だけでなく、認証に使われるホストが分流ルールから外れているときにも発生します。Copilot は GitHub の画面だけで完結するサービスではありません。GitHub アカウントへのログイン、デバイス認証、Copilot サービスのライセンス確認、コード補完用の API 通信が別々の接続として動くため、ひとつのドメインだけを DIRECT にしても正常化しないことがあります。

特に多いのは、ブラウザには Clash のシステムプロキシが適用されている一方で、VS Code や JetBrains IDE の拡張機能が異なるプロキシ設定を参照しているケースです。また、ログイン画面は表示できても、認証後のトークン交換や Copilot の契約確認がタイムアウトすると、ユーザーからは「GitHub Copilot に入れない」という一つのエラーに見えます。本稿では、アカウントや拡張機能をむやみに削除する前に、Clash の接続ログ、ルール、ノード、TUN、DNS を順番に確認する方法を整理します。

確認の前提：GitHub のアカウント状態、Copilot の契約、勤務先や学校のネットワークポリシーも影響します。ネットワーク設定を変更する前に、利用が許可された回線とアカウントで検証してください。認証トークンや個人アクセストークンは、ログやスクリーンショットに載せないようにします。

症状を認証段階ごとに分ける

最初から YAML を書き換えたり、ノードを何度も切り替えたりすると、原因が見えにくくなります。まず、どの段階で止まっているかを記録してください。Clash の接続一覧を開いた状態で、ログイン操作やコード補完の再現を行うと、失敗した時刻と接続先を照合できます。

  • ログイン画面が開かない：ブラウザが GitHub の認証ページへ到達できず、ページが白い、接続がリセットされる、または長時間待たされる状態です。DNS 解決、443 番ポート、ノードの安定性を先に確認します。
  • ブラウザ認証後に IDE が待ち続ける：ブラウザ側の認証は完了していても、VS Code や別の IDE がローカルのコールバック、デバイスコード、トークン交換を受け取れていない可能性があります。
  • Copilot の有効化だけ失敗する：GitHub にはログインできるのに「Copilot を有効化できません」「Unable to connect to GitHub Copilot」と表示される場合は、Copilot 固有の API 通信や契約確認用ホストが疑わしいです。
  • チャットは使えるが補完だけ止まる：拡張機能は起動していても、補完リクエストのストリーミング接続が切れている状態です。短いページ閲覧よりも、ノードの遅延、TLS の安定性、長時間接続の維持が重要になります。
  • 数分後に再び切断される：url-test や load-balance の自動切り替え、アイドルタイムアウト、スリープ復帰後の DNS キャッシュが原因になりやすい症状です。

Clash のログでは、少なくとも github.com、api.github.com、copilot を含む接続先、選択されたプロキシグループ、最終的なノード名を確認します。実際に表示されるホストは IDE のバージョン、拡張機能、地域、GitHub 側の変更によって異なるため、検索結果にある固定リストを無条件に追加するより、自分の接続ログに現れたホストを基準にする方が安全です。

まずブラウザと IDE のプロキシ状態を揃える

GitHub Copilot の認証で最初に見るべきなのは、ノードの速度ではなく通信経路が一つに揃っているかです。Clash の「システムプロキシ」がオンでも、IDE が独自のプロキシ設定を持っていれば、ブラウザだけがプロキシ経由になり、拡張機能は DIRECT で接続することがあります。逆に、IDE に古い HTTP プロキシが残っていると、Clash の混合ポートへ接続できず認証だけが失敗します。

  1. Clash の稼働状態を確認：アプリが起動し、プロファイルが読み込まれ、現在のプロキシグループに利用可能なノードが選択されていることを確認します。グループ名だけが表示され、実ノードが選ばれていない状態では通信できません。
  2. システムプロキシを確認：Clash のシステムプロキシを一度オフにしてからオンに戻し、OS のプロキシ設定に古いアドレスや別ポートが残っていないか確認します。混合ポートが 7890 とは限らないため、画面に表示された実際のポートを使います。
  3. IDE の設定を確認：VS Code では設定検索で http.proxy、http.proxySupport、http.proxyStrictSSL を確認します。明示的な古いプロキシ URL がある場合は、組織の設定で必要なものか確認したうえで整理します。
  4. 拡張機能を再起動：設定変更後はウィンドウの再読み込み、または IDE の完全終了と再起動を行います。ログイン状態だけを更新しても、拡張機能内部の接続プールが古い経路を保持していることがあります。

ターミナルから GitHub を利用するツールも同時に使っている場合は、シェルの環境変数も確認します。たとえば HTTPS_PROXY や HTTP_PROXY に停止済みのポートが設定されていると、ブラウザと IDE は直ったのに GitHub CLI だけ失敗することがあります。反対に、環境変数へ無理にプロキシを追加すればよいわけではありません。Clash の TUN が全プロセスを捕捉している環境では、二重プロキシによって TLS 接続が不安定になる場合もあります。

GitHub と Copilot の分流ルールを点検する

ルールの確認では、広い GEOIP や地域別ルールを先に疑うのが実践的です。GitHub 関連の通信が意図せず DIRECT に落ちていたり、逆にすべての GitHub 通信を一つの不安定なノードへ固定していたりすると、ログインと補完のどちらかだけが失敗します。認証を安定させる目的なら、まず GitHub 関連を専用グループへ送り、挙動を確認してから細かく分ける方が切り分けやすいでしょう。

rules:
  - DOMAIN-SUFFIX,github.com,GITHUB
  - DOMAIN-SUFFIX,githubusercontent.com,GITHUB
  - DOMAIN-SUFFIX,api.github.com,GITHUB
  - MATCH,DIRECT

上の例は構成の考え方を示す最小例であり、実際の設定では購読プロファイルのルール形式、グループ名、既存のルールプロバイダに合わせてください。GITHUB というグループが存在しないまま貼り付けると、設定の検証エラーや予期しないフォールバックを招きます。Copilot 専用の通信先については、接続ログに現れたドメインを確認し、必要なら既存の GitHub グループへ追加します。ホスト名を推測して大量に登録するより、実際に失敗した時刻のログを一件ずつ見る方が誤判定を減らせます。

ノード選びでは、単発の速度テストよりも認証ページの読み込みと数分間の補完を安定して維持できるかを重視します。自動選択グループが短い HTTP テストだけでノードを切り替える設定だと、Copilot のストリーミング中に出口が変わってセッションが切れることがあります。診断中は、地域と遅延が安定したノードを一つ手動選択し、同じ操作を二、三回繰り返してください。

確認項目 見る場所 判断の目安
ルール Clash の接続詳細・ルール表示 DIRECT や想定外のグループへ落ちていない
ノード プロキシグループと接続ログ 再試行のたびに出口が変わらない
TLS 接続詳細、IDE のログ 証明書エラーや handshake timeout が連続しない
長接続 補完中の接続一覧 入力中に頻繁な切断・再接続が起きない

TUN と DNS を使う場合の確認ポイント

システムプロキシを設定しても Copilot が動かない場合、IDE や拡張機能が OS のプロキシを継承していない可能性があります。このときは TUN モードが有効な検証手段になります。TUN は仮想インターフェースを通してアプリの TCP 通信を Clash に渡すため、ブラウザ以外のプロセスも同じ分流ルールで扱いやすくなります。ただし、TUN をオンにすれば必ず直るわけではありません。管理者権限、ルート設定、DNS の経路が不適切だと、GitHub 以外の通信まで不安定になります。

  • 有効化前：現在のプロファイルをバックアップし、ローカルネットワークや社内システムを DIRECT にする既存ルールを確認します。
  • 有効化後：Clash の TUN ステータスが実行中になり、OS に仮想インターフェースが作成されているか確認します。許可ダイアログを拒否した場合は、OS のネットワーク設定から権限を見直します。
  • ルート確認：Clash 自身のコントローラやローカル管理画面が TUN によってループしないよう、ローカルアドレスと管理ポートを除外します。
  • 比較試験：同じノード、同じプロファイルでシステムプロキシのみ、TUN のみを順番に試し、どちらで Copilot が安定するか記録します。

DNS も見落としやすい部分です。DNS が Clash の外側で解決されると、IDE は別の IP を取得し、ブラウザと接続先が一致しないことがあります。Fake-IP を使う構成では、Fake-IP フィルターに GitHub 関連ドメインを誤って除外していないか確認してください。Redir-Host と Fake-IP を何度も切り替える前に、まず Clash の DNS ログで名前解決が成功しているか、解決後の接続が同じルールを通っているかを確認するのが安全です。

TUN の注意：TUN を有効にした直後に全通信が切れた場合は、ノードを増やす前に TUN をオフへ戻してください。DNS ループ、既存 VPN との競合、社内セキュリティソフトのフィルタ競合が考えられます。復旧後に一項目ずつ変更し、何を変えたかを記録してください。

ログイン情報を消す前に行う最終チェック

ネットワークが整ったら、Copilot のログインを一度だけやり直します。何度もサインアウトとサインインを繰り返すと、認証制限や複数セッションの混乱を招くことがあります。まず IDE のアカウントメニューで現在の GitHub アカウントが正しいか、組織の Copilot ライセンスが割り当てられているかを確認し、GitHub の設定画面では契約状態や組織ポリシーを確認します。

  1. Clash の接続ログをクリア：古い接続を消し、手動で選んだ安定ノードを維持します。
  2. IDE を完全終了：ウィンドウを閉じるだけでなく、バックグラウンドに残ったプロセスがないか確認します。
  3. システムプロキシまたは TUN を一つだけ有効化：二つの経路を同時に変更せず、再現条件を固定します。
  4. GitHub へ再ログイン：認証画面が開いたらブラウザ側と IDE 側の両方で接続ログを確認します。
  5. 短いコード補完を試す：新しいファイルで数行入力し、補完が表示されるまでの時間と再接続の有無を記録します。

それでも失敗する場合は、拡張機能のログに出るエラーを、トークンやメールアドレスを伏せたうえで確認します。ETIMEDOUT や ECONNRESET は経路・ノード・長接続の問題を示すことが多く、認証画面へ戻される場合はアカウントやコールバックの問題も考えます。HTTP ステータスだけを見て「GitHub が落ちている」と決めつけず、同じ時刻の Clash ログ、IDE ログ、ブラウザの結果を並べると判断しやすくなります。

よくある質問

ブラウザでは GitHub にログインできるのに、Copilot だけ使えないのはなぜですか

ブラウザと IDE が同じプロキシ経路を使っていない可能性が高いです。ブラウザは OS のシステムプロキシを継いでいても、VS Code や拡張機能が独自の設定、環境変数、または直接接続を使うことがあります。Clash の接続一覧に Copilot 操作時の接続が現れるかを確認し、現れなければ IDE のプロキシ設定か TUN の捕捉状態を調べてください。

github.com を PROXY にすれば解決しますか

必ずしも解決しません。ログイン画面、API、補完ストリームで接続先が分かれるため、github.com だけを指定しても別ホストが DIRECT へ流れることがあります。まず実際の Clash ログに表示されたホストとルール名を確認し、必要な範囲だけ同じグループへまとめてください。

TUN モードは最初から有効にすべきですか

ブラウザと IDE のプロキシ設定を揃えれば動く環境なら、最初から TUN を使う必要はありません。TUN はプロセス単位の設定を避けられる反面、DNS、ルート、他の VPN、社内ネットワークとの競合が増えます。システムプロキシで再現する場合に、比較用の手段として段階的に試すのが無難です。

ノードを変えれば毎回直りますが、再発します

ノードの品質だけでなく、url-test の自動切り替えや DNS の不一致、接続のアイドルタイムアウトが残っている可能性があります。診断中はノードを固定し、同じ操作を複数回行ってから自動選択へ戻してください。切断直前の接続詳細を保存すると、単なる速度不足と経路の不整合を区別できます。

一般的な VPN アプリは接続開始だけなら簡単でも、GitHub Copilot のようにブラウザ認証、IDE の拡張機能、API の長接続をまたぐ場面では、プロキシ設定の見える化や分流の調整が難しく、海外製ツールでは日本語の切り分け情報が不足しがちです。Clash 公式サイト なら、ノード選択、ルール確認、TUN と DNS の比較を一つの手順として整理しやすく、今回のような「ログインは通るのに補完だけ止まる」問題も段階的に検証できます。これから GitHub Copilot と Clash の接続を整えるなら、環境に合うクライアントをClash 公式サイト のダウンロードページから入手し、まずはシステムプロキシと接続ログの確認から始めてみてください。