GitHub Copilot CLIが使えない？v2rayNの端末プロキシ設定術

v2rayNではブラウザーが正常に通信できるのに、GitHub Copilot CLIだけがログインに失敗したり、候補生成の途中で停止したりすることがあります。この場合、ノードやサブスクリプションが直ちに壊れているとは限りません。ブラウザーはv2rayNのシステムプロキシ設定を自動的に参照していても、ターミナルから起動したCLIはプロキシ環境変数を持たず、通常の直接接続を試みている可能性があります。

Copilot CLIの通信は、認証、APIリクエスト、拡張機能や更新情報の取得など、複数の接続先に分かれることがあります。さらに、シェルの種類、環境変数の大文字と小文字、v2rayNのHTTPポートとSOCKSポート、ルーティング規則、DNSの処理場所が結果に影響します。ブラウザーで1つのWebページが開くことだけでは、CLIの実行経路が正しいとは判断できません。

Copilot CLIがシステムプロキシを使わない理由

v2rayNの「システムプロキシを有効にする」操作は、OSや対応アプリが参照するHTTPプロキシ情報を変更します。しかし、すべてのコマンドラインツールがその設定を読み取るわけではありません。ターミナルで起動したプログラムは、通常、親プロセスから引き継いだ環境変数、アプリ自身の設定、または実装されたプロキシ検出機能だけを利用します。ブラウザーがプロキシ経由で動作していても、CLIが同じ設定を自動取得する保証はありません。

特に確認したいのは、Copilot CLIを起動した時点で環境変数が存在していたかどうかです。v2rayNを起動する前から開いていたPowerShell、コマンドプロンプト、Windows Terminalのタブには、後から変更した環境変数が反映されないことがあります。設定後は既存のシェルを閉じ、新しいターミナルを開いてください。IDE内蔵ターミナルを使っている場合も、IDE自体を再起動しないと古い環境を保持することがあります。

HTTP_PROXYだけを設定しても、HTTPS接続には反映されない実装があります。まずHTTP_PROXYとHTTPS_PROXYを同じHTTPプロキシへ向け、必要に応じてALL_PROXYを追加します。一方、NO_PROXYに広すぎる値を入れると、Copilot関連のドメインがプロキシを迂回してしまいます。最初の診断ではNO_PROXYを空にするか、明らかに必要なローカルアドレスだけに限定してください。

シェル別にプロキシ環境変数を設定する

まずは永続設定を変更せず、現在のターミナルだけに値を設定して動作を確認します。これなら別のアプリや社内ネットワークへのアクセスに影響を広げず、問題が環境変数にあるかを短時間で判定できます。ポート番号はv2rayNの実値に置き換えてください。以下ではHTTPポートを10809として説明します。

PowerShellで一時設定する

PowerShellでは、次のコマンドを実行した後、同じウィンドウからCopilot CLIを起動します。

$env:HTTP_PROXY="http://127.0.0.1:10809"
$env:HTTPS_PROXY="http://127.0.0.1:10809"
$env:ALL_PROXY="http://127.0.0.1:10809"
$env:NO_PROXY="localhost,127.0.0.1"
copilot

利用しているCLIの実行ファイル名が異なる場合は、最後のcopilotを実際のコマンドへ置き換えます。GitHub CLIの拡張機能として実行する環境では、gh copilotを使用することがあります。重要なのは、プロキシ変数を設定した同じプロセス階層からコマンドを起動することです。

コマンドプロンプトとmacOS・Linux系シェル

コマンドプロンプトでは次のように設定します。

set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809
set ALL_PROXY=http://127.0.0.1:10809
set NO_PROXY=localhost,127.0.0.1
copilot

macOSやLinux系のシェルでは、変数名を小文字で読むツールとの互換性も考え、大小文字の両方を設定する方法があります。

export http_proxy=http://127.0.0.1:10809
export https_proxy=http://127.0.0.1:10809
export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809
export ALL_PROXY=http://127.0.0.1:10809
export NO_PROXY=localhost,127.0.0.1
copilot

設定値を確認するときは、認証情報やトークンを含む環境変数までまとめて公開しないでください。表示する対象をプロキシ変数だけに限定し、共有ログへ貼り付ける場合はホスト名、ユーザー名、秘密情報を確認します。環境変数を設定しても変化がない場合は、CLIが独自のプロキシ設定を持つ、またはHTTPプロキシをサポートせずSOCKSのみを受け付ける可能性があります。

分岐ルール、DNS、TUNを順に確認する

環境変数が正しくても、v2rayN側のルーティングでGitHub関連の通信が直通へ送られていると、CLIは失敗します。ブラウザーの一部ページだけが開く場合、静的コンテンツは直通、APIや認証エンドポイントはプロキシという分岐になっていることもあります。v2rayNのルーティング設定とログを確認し、Copilot CLIの実行時刻にどのドメインがどのアウトバウンドへ送られたかを見ます。

最初のテストでは、複雑なgeositeやgeoipの例外を一時的に減らし、対象ドメインを明示的にプロキシへ送る構成にすると判定しやすくなります。具体的な接続先はCLIのバージョンや認証方式によって変わるため、ログに記録された実際の宛先を基準にしてください。単に「GitHub」という名前だけで全通信を直通または全通信をプロキシに固定するのではなく、ログ上の失敗先と成功先を比較することが重要です。

DNSにも注意が必要です。CLIがドメイン名をローカルDNSで解決し、得られたIPへ直接接続する場合、ドメインベースのルールを適用しにくくなることがあります。v2rayNのTUNモードを使用している場合は、DNSリクエストがTUNへ入り、コアのDNS処理へ渡っているか、仮想DNSやFakeDNSの設定が通常のCLI通信と整合しているかを確認します。DNS設定を変更した後は、古いキャッシュを消すためにCLIとターミナルを再起動してください。

TUNはシステムプロキシを参照しないアプリにも通信経路を提供できますが、導入すれば必ず直るわけではありません。TUNの仮想インターフェース、ルート、DNS、管理者権限、除外アプリの設定が関係するため、HTTPプロキシ環境変数の確認より後に切り分けるのが安全です。TUNを有効にする場合は、まずブラウザーとCLIの双方で同じノードを使い、ローカルLANやv2rayN自身の管理アドレスを誤ってプロキシへ送らないようにします。

再現性のある最終チェック

一度に複数の設定を変えると、どの項目が効果を持ったのか分からなくなります。v2rayNのログを開いた状態で、同じノード、同じコマンド、同じネットワークから1回ずつテストします。まずプロキシ変数なしで失敗することを記録し、次にHTTP_PROXYとHTTPS_PROXYだけを設定し、その後に必要ならALL_PROXY、ルーティング、TUNの順で変更します。各段階で結果とエラー文を保存すると、再発時にも短時間で復旧できます。

• v2rayNのXrayコアが起動し、HTTPまたはSOCKSの待受ポートがLISTEN状態になっている。
• PowerShell、コマンドプロンプト、使用中のシェルでプロキシ環境変数を確認できる。
• CLIの実行時刻に対象ドメインがv2rayNのログへ記録されている。
• 失敗先が直通ではなく、意図したプロキシアウトバウンドへ送られている。
• DNSエラー、証明書エラー、認証エラー、接続拒否を別の問題として扱っている。
• 設定変更後にターミナル、CLI、必要に応じてv2rayNを再起動している。

よくある質問