Gemini CLIが接続できない？v2rayNのプロキシ設定を確認

Gemini CLIだけ接続できない理由

v2rayNを起動し、ノードを選択し、ブラウザーで通常のウェブページを開けたとしても、Gemini CLIの通信が自動的に同じ経路を使うとは限りません。ブラウザーはv2rayNが設定するシステムプロキシを利用できますが、ターミナルで動くNode.jsアプリケーションは、起動時の環境変数、アプリ内部のHTTPクライアント、OSのネットワーク設定によって動作が変わります。

特にWindowsでは、v2rayNの「システムプロキシを設定する」を有効にしても、すべてのCLIツールがその設定を読み取るわけではありません。PowerShellやコマンドプロンプトから起動したプロセスは、HTTP_PROXY、HTTPS_PROXY、ALL_PROXYなどの環境変数を参照することがあります。一方、環境変数を設定しても、使用中のGemini CLIのバージョンや依存ライブラリがその変数に対応していなければ、通信は直結のままです。

また、プロキシを設定した後に同じターミナルでコマンドを実行しているかも重要です。Windowsの「システムのプロパティ」で環境変数を追加した場合、すでに開いているPowerShellには反映されません。設定後はターミナルを閉じて開き直し、値を表示してからGemini CLIを起動してください。

10808と10809は説明用によく使われる値であり、現在のv2rayNで必ず同じとは限りません。実際の番号は「設定」→「パラメーター設定」→ローカルプロキシ関連の項目で確認します。Gemini CLIへ設定するポートと、v2rayNが実際に待ち受けているポートが1桁でも違うと、CLI側では接続拒否、タイムアウト、ソケットエラーとして現れます。

v2rayNのローカルプロキシを確認する

最初にv2rayNのメイン画面で、ノードが選択され、Xrayコアが実行中であることを確認します。ノードを選択しただけでは、ローカルプロキシの待受が正常とは限りません。コアの起動に失敗している、別のアプリがポートを使用している、設定ファイルの生成に失敗している場合は、Gemini CLIに環境変数を設定しても接続できません。

v2rayNでは「設定」→「パラメーター設定」を開き、HTTP、SOCKS、混合ポートの番号を記録します。混合ポートはHTTPプロキシとSOCKS5の両方を受け付ける構成で使われますが、画面上の名称や初期値はバージョンによって異なる可能性があります。CLIがHTTPプロキシ環境変数を使うならHTTPまたは混合ポート、SOCKS5を明示的に扱うツールならSOCKSポートを指定します。

ポートの待受は、OSのコマンドでも確認できます。Windows PowerShellでは、たとえば次のように実行します。実際の番号が10808でない場合は、v2rayNの表示に合わせて置き換えてください。

Test-NetConnection 127.0.0.1 -Port 10808

TcpTestSucceeded : Trueなら、少なくとも指定ポートへTCP接続できています。ただし、これはプロキシ経由で外部APIへ到達できることを証明するものではありません。ポートが開いていても、Xrayコアが停止している、ノード認証に失敗している、宛先がルールで直結になっているといった問題は残ります。v2rayNのログに「listen error」「address already in use」「failed to start」などがないかも確認してください。

環境変数をシェルごとに設定する

Gemini CLIを環境変数でプロキシへ接続させる場合、まずHTTPプロキシ形式を試します。URLのポートはv2rayNの実値へ変更してください。PowerShellでは、現在のウィンドウでだけ有効にする方法が安全です。設定を戻したいときに簡単で、別のアプリへ意図せず影響を広げにくいからです。

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

コマンドプロンプトでは次の形式を使います。

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

macOSやLinuxのシェルでは、変数名を小文字で要求するツールもあるため、大文字と小文字を両方設定して挙動を比較できます。常時設定する場合はシェルの設定ファイルへ追加できますが、プロキシが停止していると他のNode.jsツールやパッケージ管理コマンドまで失敗することがあります。最初は一時設定で確認してください。

export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export NO_PROXY=localhost,127.0.0.1
gemini

設定値が本当に現在のプロセスへ渡っているかは、次のコマンドで確認します。認証情報付きのプロキシURLを使う場合は、画面共有やログへ値を貼り付けないでください。

echo $HTTP_PROXY
echo $HTTPS_PROXY

Windows PowerShellでは、$env:HTTPS_PROXYを表示します。空欄なら、そのターミナルには設定がありません。値が表示されても、Gemini CLIが無視している可能性があります。その場合は、後述するプロキシ対応の確認やTunモードによる比較へ進みます。

最小構成で接続経路をテストする

環境変数を設定したら、いきなり複雑なプロンプトを送るのではなく、外部HTTPS通信がプロキシを通るかを確認します。WindowsではPowerShellのInvoke-WebRequestがシステム設定を自動利用するとは限らないため、CLIと同じプロセス環境で再現できる検証方法を選びます。curlが利用できる環境なら、HTTPプロキシを明示して接続を試します。

curl.exe -I -x http://127.0.0.1:10809 https://generativelanguage.googleapis.com/

このテストの目的は、APIキーの有効性を確認することではありません。HTTPプロキシの入口が応答し、TLS接続の開始まで進めるかを確認するものです。401や403のようなHTTP応答が返る場合でも、ネットワーク経路自体は確立できている可能性があります。反対に「Could not connect to server」「Connection refused」「Failed to connect to 127.0.0.1」の場合は、API認証を調べる前にローカルポートを直します。

1. コア状態を確認

   v2rayNでノードを選択し、「設定」→「パラメーター設定」から使用中のXrayコアとローカルポートを記録します。

2. 入口をテスト

   Test-NetConnectionまたは同等のTCP確認で、127.0.0.1と指定ポートの待受を確認します。

3. 環境変数を設定

   新しいターミナルでHTTP_PROXYとHTTPS_PROXYを設定し、変数が空でないことを表示してからGemini CLIを起動します。

4. HTTPSを確認

   curlで対象HTTPSドメインへ接続し、拒否、タイムアウト、TLSエラー、HTTP応答のどこまで進んだかを記録します。

5. ルールを比較

   v2rayNのルーティングを確認し、対象ドメインが直結やブロックへ分類されていないかを調べます。

6. Tunを試す

   環境変数方式だけが失敗する場合、Tunモードを一時的に有効にして同じCLIコマンドを再実行します。

curlの明示的なプロキシ接続は成功するのにGemini CLIが失敗するなら、v2rayNよりもCLI側のプロキシ実装、Node.jsの起動環境、証明書検証、またはCLI独自のAPI設定を疑います。逆にcurlも失敗するなら、CLIを再インストールする前にXrayログ、ノード、DNS、ルーティングを確認する方が効率的です。

ルーティングとDNSを確認する

Gemini CLIは、1つのホスト名だけで完結せず、認証、API、更新処理など複数のHTTPS接続を発生させることがあります。v2rayNのルール設定で主要なGoogle関連ドメインが直結へ送られていると、ブラウザーでは動作してもCLIの特定リクエストだけが失敗する場合があります。ルールを変更する前に、v2rayNのログで実際の宛先と処理結果を確認してください。

ルールの「プロキシ」、「ダイレクト」、「ブロック」の意味を確認し、対象ドメインが意図した出站へ送られているかを見ます。ドメイン名の完全一致だけを登録していると、サブドメインや別のAPIエンドポイントを取りこぼすことがあります。ただし、Google関連の広いドメインを無条件にすべてプロキシへ送ると、必要以上に通信経路が変わるため、ログに現れた宛先を根拠に段階的に追加してください。

DNSも切り分け対象です。ドメイン名の解決に失敗する場合、プロキシ設定が正しくても接続は始まりません。v2rayNのDNS設定、システムDNS、Tunモード時のDNS hijack設定がそれぞれ異なる経路を使っていないかを確認します。名前解決だけ成功しても、TCP接続やTLS検証まで成功したとは限りません。

Tunモードへ切り替える判断

環境変数を設定してもGemini CLIが直結してしまう場合は、v2rayNのTunモードを比較テストとして使います。Tunモードは仮想ネットワークインターフェースを作成し、アプリケーションがHTTP_PROXYを読まない場合でも、OSのIP通信をルーティング規則に従って捕捉できます。ただし、これは「必ず解決するモード」ではありません。管理者権限が必要な場合があり、仮想アダプター、DNS、他のVPN、セキュリティソフトとの競合も発生します。

Tunを有効にする前に、他のVPNや別のプロキシアプリを停止し、v2rayNのノードとルーティングモードを記録します。その後、「設定」内のTun関連項目を開き、必要な権限を許可して有効化します。設定名はv2rayNのバージョンによって異なるため、画面に表示される仮想アダプター名、DNS処理、ルーティングモードを確認してください。最初はルールを増やしすぎず、CLIを1回実行してログを取得します。

Tunで接続でき、環境変数方式では接続できないなら、Gemini CLIまたはその依存ライブラリが環境変数を解釈していない可能性が高くなります。反対に、両方の方式で失敗するなら、ノード、ルーティング、DNS、時刻、認証、API側の制限を確認します。Tunを有効にしたまま環境変数も残すと、二重プロキシや予想外の経路になることがあるため、比較時は片方だけを有効にしてください。

安全に設定を固定する

接続に成功した後は、必要な設定だけを残します。常時プロキシが不要なら、PowerShellの一時変数を使う方法が適しています。永続環境変数へ保存する場合は、別の作業で起動するCLIやパッケージ管理ツールも同じプロキシを使うことを理解しておきましょう。プロキシ停止中にターミナルを開くと、名前解決はできても接続がタイムアウトすることがあります。

APIキーや認証情報をプロキシURLへ埋め込む構成は避け、シェル履歴、ターミナル共有、ログファイル、画面キャプチャに秘密情報が残っていないか確認します。NO_PROXYには通常、localhostや127.0.0.1のようなローカル宛先だけを記述し、外部APIドメインを誤って追加しないでください。外部ドメインを除外すると、その通信だけが直結へ戻るため、接続結果が不安定になる場合があります。

最終的な確認では、使用したv2rayNのバージョン、Xrayコアのバージョン、ノード名、ローカルポート、プロキシ方式、Tunの有無、エラー発生時刻を記録します。たとえばv2rayN 7.x、Xray-core 25.x、HTTPプロキシ10809、Windows PowerShellの一時環境変数という形で残すと、再発時に設定差分を比較できます。単に「v2rayNは起動している」と記録するより、どのプロセスがどの入口を使ったかを残す方が有用です。