GitHub Copilotがつながらない？Clashのタイムアウト解消法
無料ノードは手軽ですが、速度低下や通信量制限、運営元が不明なリスクがあります。有料サービスを含めた比較基準、試用時のチェック項目、契約後にClashへ購読リンクを追加する方法をまとめました。
GitHub Copilot がつながらないときに確認する範囲
Clash を有効にしている状態で GitHub Copilot が使えない場合、原因は単純な「ノードの速度不足」とは限りません。VS Code の拡張機能は、通常のブラウザとは別の通信経路を使うことがあります。ブラウザでは GitHub が開けるのに Copilot の補完だけが表示されない、サインイン画面が終わらない、拡張機能のログに ETIMEDOUT や ECONNRESET が出る、といった症状では、Clash のルール、DNS、VS Code のプロキシ設定を順番に調べる必要があります。
GitHub Copilot の通信には、GitHub のログイン、Copilot の API、補完候補を取得するサービス、拡張機能の更新など、複数のドメインが関係します。そのため、GitHub のトップページだけを開いて「接続は正常」と判断すると、問題を見落とすことがあります。まずは次の表で症状と疑う場所を整理してください。
| 症状 | 優先して確認する場所 | 切り分けの方法 |
|---|---|---|
| 補完候補が表示されない | Clash のルール、VS Code のプロキシ | Clash の接続ログと Copilot ログを同時に確認する |
| GitHub ログインが完了しない | ブラウザ連携、DNS、TLS | ブラウザで GitHub にログインできるか確認する |
| 数分後にタイムアウトする | ノードの品質、経路、接続維持 | 別ノードと Global モードで比較する |
| ブラウザは正常だが VS Code だけ失敗する | アプリ単位のプロキシ設定 | HTTP_PROXY や VS Code の設定を確認する |
切り分けの基本：最初から設定をすべて変更するのではなく、同じノードで「ブラウザ」「VS Code」「Clash の接続ログ」を比較してください。変更を一度に一つだけにすると、原因を追跡しやすくなります。
ステップ 1：Clash のモードとルールを確認する
最初に確認するのは、Clash のコアが起動しているかではなく、VS Code の通信が本当に Clash を通過しているかです。画面上で Clash が「実行中」になっていても、システムプロキシが無効なら、VS Code はネットワークへ直接接続している可能性があります。
- システムプロキシを有効にし、Clash の mixed port または HTTP ポートが OS のプロキシ設定と一致しているか確認します。
- 一時的に
Globalモードへ切り替え、動作中のノードを明示的に選択します。Global で Copilot が動き、Rule で失敗する場合は、ノードよりルールが原因である可能性が高いです。 - Clash の接続ログを開き、VS Code の操作中に GitHub 関連の接続が表示されるか確認します。何も表示されなければ、アプリが Clash を迂回しています。
- 接続先が
DIRECTやREJECTになっていないか確認します。必要な通信が直送されると、ブラウザの一部だけ動作して Copilot だけタイムアウトすることがあります。
Rule モードでは、ルールの上から順番に判定されます。広すぎる DOMAIN-SUFFIX、誤った GeoIP ルール、購読設定に含まれる古いルールセットが先にマッチすると、本来プロキシへ送るべき通信が別の出口へ送られます。ルールを編集する前に、まずログで実際に適用されたルール名とポリシーグループを確認してください。
確認する項目
- VS Code の通信が Clash の接続一覧に現れているか
- GitHub 関連ドメインの出口が意図したプロキシグループになっているか
- プロキシグループ内で実際のノードが選択されているか
- ヘルスチェック失敗後に
DIRECTへ自動フォールバックしていないか
ステップ 2：VS Code と拡張機能の通信経路を確認する
VS Code は OS のシステムプロキシを利用できる一方、環境変数やアプリ内設定の影響も受けます。別の VPN、会社のセキュリティソフト、以前設定したプロキシ環境変数が残っていると、Clash と異なる経路へ接続することがあります。ブラウザが正常でも、VS Code のプロセスだけが別のプロキシを使っているケースは珍しくありません。
VS Code の設定で http.proxy、http.proxySupport、http.proxyStrictSSL を検索し、意図しない固定プロキシが設定されていないか確認します。Clash のシステムプロキシを使う構成では、古い会社プロキシやローカルポートを残さないほうが安全です。ただし、組織の管理ポリシーで指定されたプロキシを勝手に削除できない場合は、管理者の指示を優先してください。
ターミナルから起動した VS Code では、HTTP_PROXY、HTTPS_PROXY、ALL_PROXY の環境変数が通信に影響する場合があります。ターミナルで次の値を確認し、Clash のポートと一致しない設定があれば、いったん別のシェルで比較してください。
echo $HTTP_PROXY
echo $HTTPS_PROXY
echo $ALL_PROXYWindows では PowerShell の $env:HTTP_PROXY、macOS や Linux では env | grep -i proxy で確認できます。設定変更後は VS Code のウィンドウを再読み込みするだけでなく、必要に応じてアプリを完全終了してから起動してください。拡張機能のプロセスが以前のネットワーク設定を保持していることがあるためです。
注意：http.proxyStrictSSL を無効にすると証明書検証を弱めることになります。TLS エラーの原因を調べる一時的な比較以外では使用せず、問題が解決したら元に戻してください。証明書エラーを隠すだけでは、タイムアウトの根本原因は解消されません。
ステップ 3：DNS、TLS、ノード品質を切り分ける
GitHub Copilot のタイムアウトは、TCP 接続が確立する前の名前解決で止まっている場合と、接続後の TLS や長時間通信で止まっている場合があります。Clash のログに「dial tcp」「lookup」「TLS handshake」などの違いが出るため、エラー文をまとめて見ることが重要です。
| ログの例 | 考えられる原因 | 対策の方向 |
|---|---|---|
lookup ... timeout |
DNS が遅い、または Clash を迂回している | DNS モードと nameserver を確認する |
dial tcp ... i/o timeout |
ノードや出口経路が応答しない | 別ノード、別グループで試す |
TLS handshake timeout |
経路の品質、時刻、証明書検証 | 端末時刻、TLS ログ、ノードを確認する |
ECONNRESET |
接続が途中で切断された | 長時間接続に強い別ノードで比較する |
DNS 設定を変更する場合は、まず現在の設定を保存してください。fake-ip はドメインベースの分流と相性がよく、通常は高速ですが、一部の開発ツールや認証フローでは互換性問題が出ることがあります。fake-ip を使っていて Copilot だけ失敗する場合は、短時間だけ redir-host に切り替えて再現性を比較すると、DNS とアプリの相性を判断できます。
また、端末の時刻が大きくずれていると、HTTPS 証明書の検証に失敗します。自動時刻設定を有効にし、システムのタイムゾーンも確認してください。ノードを評価するときは、単純な速度テストだけでなく、GitHub への接続、一定時間の維持、ログイン画面の表示まで確認する必要があります。速度が速いノードでも、TLS 接続が不安定なら Copilot には向きません。
比較テストの手順：同じ設定でノード A とノード B を試し、Clash のログ、VS Code の Copilot ログ、補完が表示されるまでの時間を記録します。複数ノードで同じ失敗が続くなら、ルールや VS Code 側を優先して調べてください。
ステップ 4：ログイン状態とキャッシュをリセットする
ネットワークを直した後も Copilot が使えない場合、古い認証状態や拡張機能のキャッシュが残っている可能性があります。VS Code のアカウントメニューから GitHub とのサインアウトを実行し、VS Code を再起動してから、もう一度サインインしてください。ブラウザで認証を完了した後に VS Code へ戻る手順では、既定のブラウザが正しく開くことも確認します。
次に、拡張機能が無効化されていないか、更新が保留されていないかを確認します。GitHub Copilot と GitHub Copilot Chat は別の拡張機能として表示される場合があるため、片方だけ正常でもう片方が古い状態になっていないか確認してください。拡張機能を一度無効化して再有効化する方法もありますが、設定やアカウント情報を削除する前には、必要なデータを確認しておきましょう。
VS Code の「出力」パネルで GitHub Copilot を選択すると、ログイン、接続、補完要求に関する情報を確認できます。ログに認証失敗があるならアカウント状態を、接続先が記録されていないならプロキシ経路を、特定ノードでのみ失敗するなら出口品質を優先します。このように、症状を「つながらない」と一括りにせず、どの段階で止まっているかを分けることが解決への近道です。
最終チェックリスト
- Clash が起動し、システムプロキシまたは TUN が有効になっている。
- VS Code が意図しない固定プロキシや環境変数を使っていない。
- Clash のログで GitHub 関連通信のルールと出口を確認できる。
- Global と Rule を比較し、ルールによる誤判定を除外した。
- 別ノード、DNS モード、端末時刻を比較した。
- Copilot のサインイン状態と拡張機能を更新した。
単純な VPN アプリでは、アプリごとのプロキシ経路やルールの適用先を確認しにくく、ブラウザは動くのに開発ツールだけがタイムアウトする場面で設定を追い込みづらいことがあります。Clash なら、Rule と Global の切り替え、接続ログ、DNS モード、ノードグループを分けて確認できるため、GitHub Copilot の問題を感覚ではなく通信経路ごとに検証できます。VS Code と GitHub の通信を安定させながら細かなルーティングも管理したい方は、環境に合った Clash をClashを無料でダウンロードして試してみてください。