GitHub CopilotがClashでタイムアウトする時の設定・解決策

まずタイムアウトする通信を切り分ける

GitHub Copilotの認証、拡張機能の起動、コード補完、チャットの送信がClash使用時だけ失敗する場合、最初からTUNやDNSを大きく変更する必要はありません。Copilotの処理には、GitHubアカウントへの認証、トークン取得、CopilotサービスへのHTTPS接続、エディターからのストリーミング応答という複数の通信が関係しています。どの段階で止まっているかによって、確認すべき設定は異なります。

まずClashを完全に終了し、通常のネットワークでCopilotが動作するかを確認してください。Clashを無効にすると正常で、システムプロキシまたはTUNを有効にした時だけ失敗するなら、アカウントや拡張機能の再インストールよりも、モード、ルール、DNS、ノードの順に確認するほうが効率的です。反対にClashを使っていない状態でも失敗するなら、GitHub側の障害、拡張機能のバージョン、ログインセッションの期限切れを先に調べます。

症状	疑う箇所	最初に行う確認
GitHubログイン画面から戻らない	ブラウザー経路、認証リダイレクト、DNS	ブラウザーでGitHubへログインできるか確認する
認証済みだが補完だけタイムアウトする	Copilot APIへのルール、ノード品質、ストリーミング接続	Clashの接続ログで失敗したホスト名を見る
チャット送信後に応答が途中で止まる	長時間HTTPS、HTTP/2、ノードの切断	同じノードで短い補完とチャットを比較する
TUN有効時だけエディターが接続できない	仮想インターフェース、DNS hijack、ルーティング	システムプロキシだけの状態で再テストする
一定時間後に突然401や403になる	認証トークン、時刻、アカウント権限	GitHubへ再ログインし、PCの時刻を確認する

Clashのモードとルールを確認する

Copilotのタイムアウトで最も多い設定上の原因は、必要な通信がDIRECTへ送られていること、または意図しないノードへ送られていることです。Clashの「全局」モードで動くかどうかを短時間だけ確認すると、ルールの問題か、ノードやDNSの問題かを分けられます。全局モードで補完が成功し、ruleモードで失敗する場合は、設定の基本構造を変更するのではなく、接続ログに表示された宛先に対するルールを見直してください。

普段の利用では、mode: ruleを維持するほうが安全です。全局モードはすべての通信を同じプロキシへ送るため、認証確認には便利ですが、ローカルサービス、社内ドメイン、Gitの内部サーバーまで外部ノードへ送ってしまう可能性があります。テストが終わったらruleモードへ戻し、必要な宛先だけを明示的に処理してください。

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

rules:
  - DOMAIN-SUFFIX,github.com,Copilot
  - DOMAIN-SUFFIX,githubusercontent.com,Copilot
  - DOMAIN-SUFFIX,githubassets.com,Copilot
  - MATCH,DIRECT

上の例で使っているプロキシグループ名Copilotは、実際の設定に存在するグループ名へ置き換えてください。設定に存在しないグループ名をそのまま追加すると、設定の検証に失敗したり、意図しないフォールバックが発生したりします。既存のグループが「自動選択」「Proxy」「ノード選択」などの名前なら、その名称を使います。

GitHub関連ドメインを固定しすぎない

Copilotの接続先は、エディター、拡張機能のバージョン、GitHub側のサービス構成によって変わる可能性があります。github.comだけをプロキシへ送っても、トークン取得や補完ストリームが別のホストへ接続していれば問題は解決しません。ログに表示された実際の宛先を確認し、GitHubまたはCopilotに関係するホストだけを段階的に追加してください。

認証通信：GitHubのログイン、OAuthリダイレクト、トークン確認に関係します。
補完通信：コード候補やチャット応答を返すAPIへ接続します。接続が長時間維持されることがあります。
静的リソース：拡張機能やGitHubの画面が必要とするスクリプト、画像、設定を取得します。
開発環境の通信：Git、企業内GitHub、パッケージレジストリなどはCopilotとは別のルールが必要になる場合があります。

ノードとDNSを一つずつ検証する

ルールが正しいのにタイムアウトする場合は、選択中のノードを疑います。遅延テストの数値が低いノードでも、CopilotのHTTPSストリーミングが安定するとは限りません。ICMPや短いTCP接続が速くても、TLS確立後の長時間通信で切断されるノードがあります。現在のノードを固定したまま何度も再試行するのではなく、同じルールで少なくとも2～3個のノードを比較してください。

テスト	確認する内容	判断の目安
GitHubをブラウザーで開く	基本的なHTTPS接続と証明書検証	開けない場合はCopilot以前の経路を確認する
認証状態を更新する	GitHubログインとOAuthのリダイレクト	認証だけ失敗するならブラウザー経路や時刻を確認する
短いコード補完を行う	Copilot APIへの接続と候補の返却	補完だけ失敗するならルールまたはAPI経路を確認する
長めのチャットを送信する	ストリーミング接続の維持	途中切断ならノード品質や接続タイムアウトを確認する

DNSも重要です。ClashのDNS機能を有効にしている場合、ブラウザーはシステムDNSを使い、TUN経由のエディターだけがClash DNSを使うという差が生じることがあります。分割DNS、fake-IP、nameserver-policy、DNS hijackが複雑に組み合わさると、GitHubのホスト名が誤ったアドレスへ解決されたり、接続先とルールの判定が一致しなかったりします。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback:
    - https://1.0.0.1/dns-query
  fallback-filter:
    geoip: true

これは動作確認用の例であり、すべての環境にそのまま適用する設定ではありません。既存の購読設定が独自のDNS構成を持つ場合は、まず現在の設定を保存してから1項目ずつ変更してください。fake-IPで問題が出る場合は、短時間だけredir-host相当の構成へ切り替えて比較すると、名前解決とアドレス変換のどちらに問題があるかを判断しやすくなります。

TUNとシステムプロキシを段階的に確認する

エディターはシステムプロキシの設定を参照する場合がありますが、すべての通信が必ず参照されるとは限りません。逆にTUNモードでは、システムプロキシを使わないプロセスも仮想ネットワークインターフェース経由で処理できます。そのため、システムプロキシではCopilotが動くのにTUNでは失敗する、またはその逆の状況が起こります。

検証は次の順序で行うと、変更範囲を小さくできます。最初にTUNを無効にし、Clashのシステムプロキシだけを有効にします。次にエディターを完全に終了して再起動し、GitHub認証と短いコード補完を確認します。成功したらTUNを有効にし、同じノード、同じモード、同じルールで再テストします。TUNを有効にした瞬間だけ失敗するなら、権限、DNS hijack、auto-route、strict-route、IPv6の扱いを確認します。

システムプロキシ：ブラウザーや対応アプリの確認に向いています。HTTP、HTTPS、SOCKSのポートが実際のmixed-portと一致しているか確認します。
TUN：プロキシ設定を参照しないエディターやCLIも取り込めますが、OSのネットワーク権限とルーティングに依存します。
DNS hijack：DNS要求をClashへ集約できますが、企業ネットワークやVPNのDNSと競合することがあります。
IPv6：IPv6だけ別経路へ出る環境では、IPv4では成功しても接続が不安定になる場合があります。

認証エラーとログの安全な確認方法

Clash側の経路が正常でも、GitHubの認証情報が古い場合はCopilotを利用できません。エディターのアカウントメニューからGitHubを一度サインアウトし、再度サインインしてください。認証操作中は、ブラウザーで開かれたGitHubのURL、エディターへ戻るリダイレクト、拡張機能の認証完了を順番に確認します。ログイン画面が表示されない、または戻り先で止まる場合は、認証用ドメインへのルールがDIRECTになっていないかを見直します。

PCの日時が大きくずれている場合、TLS証明書の検証やトークンの有効期間判定に失敗することがあります。自動時刻設定を有効にし、タイムゾーンも正しいことを確認してください。また、会社や学校のネットワークでは、HTTPS検査プロキシが証明書を差し替えている場合があります。ClashのTLSエラーと組織側の証明書エラーを混同しないよう、同じアカウントを別のネットワークでも確認します。

Clashログで記録する項目：
時刻       2026-09-10 14:32:18
宛先       ホスト名のみを記録
ルール     実際に選ばれたルール
ポリシー   使用したプロキシグループとノード
結果       timeout / reset / 401 / 403 / TLS error

ログをサポートへ送る場合、GitHubのアクセストークン、Copilotの認証トークン、サブスクリプションURL、Cookie、Authorizationヘッダーを必ず削除してください。ホスト名、HTTPステータス、発生時刻、使用OS、Clashクライアント名、mihomoのバージョン、TUNの有効・無効だけでも、初期の切り分けには十分役立ちます。認証情報を含む完全なログを公開してはいけません。

最終的には、ノードを変える、モードを変える、DNSを変える、TUNを変えるという順番で1項目ずつ確認するのが安全です。全局モードで一時的に成功しても、常用設定まで全局にする必要はありません。Copilot関連の実際の宛先をログで確認し、ruleモードへ戻した上で必要な通信だけを適切なプロキシへ送る構成を目指してください。