開発者向けv2rayN設定｜Git・npm・Dockerを端末から快適に使う方法

最初に選ぶ：システムプロキシかTUNモードか

v2rayNはWindows上でノードとコアを管理し、ローカルのプロキシ入口を提供します。端末からの通信をその入口へ渡す方法は、大きく分けてシステムプロキシを利用する方法と、TUNモードでネットワーク通信を取り込む方法があります。どちらを選ぶかで、Gitやパッケージ管理ツールへの設定範囲と、問題発生時に確認する場所が変わります。

はじめて設定する場合は、TUNとシステムプロキシを同時に有効にせず、まず一方だけで検証してください。システムプロキシはアプリがWindowsの設定を参照することが前提です。PowerShellから起動したGitやnpmが、その設定を自動で利用するとは限りません。TUNはより広い範囲の通信を取り込めますが、ツール単位でプロキシを有効・無効にする仕組みとは異なります。

PowerShellの端末だけにプロキシを設定する

まずv2rayNでノードを選択し、コアが起動していることを確認します。次に、PowerShellから利用できるHTTPプロキシ形式のローカル入口を確認します。ここでは、実際のHTTPまたは混合ポートが例と同じ場合に限り、127.0.0.1:10808を使います。URLのスキームはローカル側のプロキシ方式を表します。接続先サイトがHTTPSでも、HTTPプロキシ経由のCONNECT方式で通信できるため、環境変数の値を必ずhttps://にする必要はありません。

1. ポートを確認

   v2rayNの「設定」→「パラメータ設定」を開き、HTTPまたは混合待ち受けポートを確認します。画面名はバージョンによって異なる場合があります。以降の例では、確認したポートが10808であるものとして説明します。

2. 変数を設定

   PowerShellでHTTP_PROXYとHTTPS_PROXYを設定します。ツールごとの環境変数名の差に備えて、小文字の変数も同じ値にします。この設定は現在のPowerShellプロセスと、そこから起動した子プロセスに適用されます。

3. 入口をテスト

   curl.exeで外部のHTTPSサイトへHEADリクエストを送り、応答が返るか確認します。コマンドが成功しても、GitやDockerの全機能が設定済みとは限らないため、それぞれのツールでも確認します。

4. 不要時に解除

   変数を設定したPowerShellだけを閉じるか、Remove-Itemで該当変数を削除します。Windows全体の環境変数へ登録するのは、適用範囲と解除手順を理解してからにしてください。

$proxy = "http://127.0.0.1:10808"
$env:HTTP_PROXY = $proxy
$env:HTTPS_PROXY = $proxy
$env:http_proxy = $proxy
$env:https_proxy = $proxy

curl.exe -I --max-time 15 https://pypi.org/

Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:http_proxy, Env:https_proxy -ErrorAction SilentlyContinue

応答のHTTPステータスは、宛先サイトや中継経路によって異なります。ここで見るのは、DNSエラーや接続タイムアウトではなく、HTTP応答まで到達するかどうかです。プロキシのローカル入口に接続できないときは、v2rayNのコア稼働状態、待ち受けアドレス、ポート番号、Windowsのファイアウォールや他のネットワーク制御ソフトを確認します。

Git・npm・pipへ個別に設定する

PowerShellの環境変数は、そのウィンドウから起動したプロセスへ渡されます。一方、Gitやnpmに保存した設定は、ほかのシェルから起動した場合にも適用されることがあります。環境変数とツール固有設定を同時に使うと、どちらの値が採用されたか分かりにくくなるため、最初の検証では片方に統一してください。以下の例でも、ポート番号は実際のHTTPまたは混合待ち受けポートに置き換えます。

GitのHTTP・HTTPS通信

GitのリモートURLがHTTPまたはHTTPSの場合、http.proxyでプロキシを指定できます。Git設定のキー名にあるhttpは、HTTPSのリモートにも適用されます。接続先がSSH形式のgit@ホスト:組織/リポジトリなら、このHTTPプロキシ設定だけではSSH通信を中継できません。HTTPS形式のリモートを使うか、SSH側のプロキシ経路を別途設計してください。

git config --global http.proxy http://127.0.0.1:10808
git config --global --get http.proxy

# 設定を解除する場合
git config --global --unset http.proxy

--globalは現在のWindowsユーザーのGit設定へ保存します。特定のリポジトリだけに適用するなら、そのリポジトリ内で--localを指定できます。企業内ミラーなどプロキシを通さない宛先がある場合は、適用範囲を確認してから設定してください。認証情報を含むプロキシURLを登録すると、設定ファイルや診断出力に秘密情報が残る可能性があります。

npmとpipのレジストリアクセス

npmはproxyとhttps-proxyを設定できます。レジストリURLがHTTPSでも、ローカルのHTTPプロキシを指定する例は次のとおりです。値を保存したあとは、設定を表示してポートとURL形式を確認します。npmの設定ファイルに保存する場合、同じユーザーアカウントで使うほかのプロジェクトにも影響し得ます。

npm config set proxy http://127.0.0.1:10808
npm config set https-proxy http://127.0.0.1:10808
npm config get proxy
npm config get https-proxy

# 設定を解除する場合
npm config delete proxy
npm config delete https-proxy

PyPIから取得するpipでは、環境変数またはコマンドラインの--proxyを使えます。HTTPプロキシ入口を使用する場合は、次のように指定します。

python -m pip install --proxy http://127.0.0.1:10808 パッケージ名

パッケージ名は実際にインストールする対象へ置き換えてください。会社やプロジェクトが指定するプライベートインデックス、証明書設定、認証方式がある場合は、それらの指示を優先します。証明書エラーを回避する目的でTLS検証を無効にすると、接続先の真正性を確認できなくなるため、安易に設定を変更しないでください。

DockerはCLI・ビルド・Engineを分けて確認する

Dockerのタイムアウトは、端末上のdockerコマンドがプロキシを使っていない場合だけでなく、Docker DesktopのバックグラウンドEngineが別のプロキシ設定を使っている場合にも起こります。PowerShellで環境変数を設定しただけでは、すでに起動しているDocker DesktopやEngineへ設定が伝わらないことがあります。さらに、イメージの取得と、Dockerfile内のビルド手順から行うnpm・pip・Git通信は、確認する設定箇所が異なる場合があります。

• イメージの取得：docker pullの通信主体はDocker Engineです。Docker Desktopの設定画面でプロキシ項目を確認し、変更後は画面の案内に従って設定を反映させます。Docker Engineへ到達するレジストリと、PC上のPowerShellが使うプロキシを混同しないでください。
• Dockerfileのビルド：ビルド中に外部レジストリやパッケージサイトへ接続する工程は、ビルド環境にもプロキシ設定を渡す必要があります。ビルド引数や環境変数の適用方法は、Docker Desktopとビルド方式によって異なるため、ビルドログで失敗した工程を特定します。
• コンテナ実行後：コンテナ内のアプリケーション通信は、ホスト上のDocker CLI設定とは別に考えます。コンテナへ環境変数を渡す場合も、ホストの127.0.0.1はコンテナ自身を指すため、そのまま指定してもホスト上のv2rayNには到達しません。
• WSLを使用する場合：Windows PowerShell、WSL内のシェル、Docker Desktopの間で環境変数やネットワーク名前空間が異なります。Windows側で設定した127.0.0.1がWSLやコンテナから同じ意味になると仮定せず、実行環境ごとに接続先を確認します。

まずWindows側でdocker versionを実行し、ClientだけでなくServerの情報も取得できるか確認します。次にdocker pullの失敗内容を見て、Engineへの接続失敗なのか、レジストリへの名前解決・TLS・認証の問題なのかを分けます。Docker Desktopの画面にプロキシ設定がある場合は、その値をv2rayNの実際のローカルHTTP待ち受けに合わせます。設定を変更したあとは、クライアントを再起動する必要があるか画面の案内を確認してください。

タイムアウトを段階ごとに切り分ける

複数の設定を一度に変更すると、直った理由も新たな問題の原因も分からなくなります。v2rayNのコア、ローカル待ち受け、端末、ツール、接続先の順に確認し、各段階で同じテストを繰り返してください。特定のサービスだけ失敗する場合は、ノード全体の問題と決めつけず、DNS、証明書、認証、相手側サービスの応答も調べます。

1. コア：v2rayNで選択中のノードが有効か確認し、ログに設定解析エラーや認証失敗がないか見ます。
2. ローカル入口：HTTPまたは混合ポートの番号とプロトコルを確認します。別のアプリが同じポートを使用している場合や、コアが待ち受けていない場合は接続できません。
3. 端末の環境：PowerShellの環境変数を表示し、現在のウィンドウに正しい値が設定されているか確かめます。新しいウィンドウや別の実行環境には値が引き継がれていないことがあります。
4. ツールの設定：Git、npm、pipそれぞれで保存済みのプロキシがないか調べます。シェルの環境変数と異なる値が残っていると、想定外の経路を使う場合があります。
5. 宛先サービス：名前解決、TLS証明書、ログイン認証、レジストリの利用制限を確認します。プロキシ接続が成立しても、接続先が応答するとは限りません。

エラー文は発生位置を推測する手掛かりになります。たとえば、ローカルプロキシへの接続拒否は待ち受けポートやコアの状態を、名前解決エラーはDNS処理を、TLSエラーは時刻・証明書・中継設定を優先して確認します。ただし、エラーの表現はツールやバージョンで異なります。ログを共有する際は、サブスクリプションURL、ユーザーID、認証情報、社内ホスト名を削除してください。