開発者向けv2rayN設定術：Git・npm・Dockerを快適に使う方法

開発環境では、ブラウザーだけが通信できても十分とは限りません。Gitでリモートリポジトリへ接続できない、npm installが特定のパッケージで停止する、Dockerのイメージ取得がタイムアウトする、といった問題は、各ツールがシステムプロキシを同じ方法で利用しないことから発生します。v2rayNを単に起動するだけではなく、ローカルポート、環境変数、Gitの設定、Docker Engineの設定を分けて確認することが重要です。

開発用プロキシはアプリごとに入口を分けて考える

v2rayNは通常、パソコン上でHTTPプロキシとSOCKSプロキシのローカル待ち受け口を提供します。この記事では検証用の値として、HTTPを127.0.0.1:10809、SOCKS5を127.0.0.1:10808に設定します。実際のポートは環境によって異なるため、v2rayNの「設定」→「パラメータ設定」やコアログに表示された値を優先してください。ポート番号だけを見て固定値だと判断すると、別のクライアントや古い設定との競合を見落とします。

ブラウザーや多くのCLIツールはHTTP_PROXY、HTTPS_PROXY、ALL_PROXYなどの環境変数を参照できます。一方、Gitは独自のプロキシ設定を持ち、Dockerのイメージ取得はDocker daemon側の設定を使う場合があります。つまり、Windowsのシステムプロキシを有効にしただけでは、ターミナル、IDE、Dockerのすべてが同じ経路を通るとは限りません。

v2rayN側のノードとローカルポートを整える

最初にv2rayNで、ブラウザーなど通常のHTTPS通信が安定しているノードを選びます。開発ツールの設定を始める前に、v2rayNのメイン画面で対象ノードを選択し、コアを起動します。Windowsの「システムプロキシを設定」を有効にしてブラウザーでHTTPSサイトを確認し、ノードの問題とツール固有の問題を分離してください。ブラウザーも接続できない場合は、Gitやnpmの設定を変更しても改善しません。

v2rayNの「設定」→「パラメータ設定」では、HTTP、SOCKS、混合ポートなどの待ち受け値を確認できます。すでに別のプロキシソフトが10808や10809を使っている場合は、片方を終了するか、v2rayN側を18080と18081などの未使用ポートへ変更します。変更後はコアを再起動し、ターミナルから接続テストを行います。

1. ノードを選択

   v2rayNのメイン画面で、遅延だけでなく実際にHTTPS通信できるノードを選びます。必要であれば「サーバー」一覧から別ノードも検証します。

2. ポートを確認

   「設定」→「パラメータ設定」でHTTPとSOCKSの待ち受けアドレスを確認します。この記事の例はHTTPが127.0.0.1:10809、SOCKS5が127.0.0.1:10808です。

3. システムプロキシを有効化

   v2rayNのシステムプロキシを有効にし、ブラウザーで通常のHTTPSページを開きます。ここで失敗する場合は、開発ツールへ進まずノードとコアログを確認します。

4. ローカル入口を検査

   PowerShellでTest-NetConnection 127.0.0.1 -Port 10809を実行し、TcpTestSucceeded : Trueになることを確認します。

5. 設定を記録

   ポート、選択ノード、コア種別、ルーティングモードをメモしてから、Gitやnpmの個別設定へ進みます。

Test-NetConnection 127.0.0.1 -Port 10809
Test-NetConnection 127.0.0.1 -Port 10808

HTTPプロキシは、HTTPSサイトへ接続するときも通常はHTTP CONNECTを使ってトンネルを作ります。そのため、HTTPS_PROXYの値にもhttp://127.0.0.1:10809を指定する構成が一般的です。SOCKS5を使う場合はsocks5://127.0.0.1:10808またはDNS解決もプロキシ側へ渡すsocks5h://127.0.0.1:10808を利用できるツールがあります。対応形式はツールごとに異なるため、文字列をそのまま全アプリへコピーしないでください。

ターミナルとIDEへ一時的にプロキシを適用する

最初は永続設定ではなく、現在のターミナルセッションだけに環境変数を設定する方法が安全です。Windows PowerShellでは次のように指定します。これにより、設定を解除せずに新しいターミナルを閉じるだけで元へ戻せます。

$env:HTTP_PROXY="http://127.0.0.1:10809"
$env:HTTPS_PROXY="http://127.0.0.1:10809"
$env:ALL_PROXY="socks5://127.0.0.1:10808"
$env:NO_PROXY="localhost,127.0.0.1,::1"

curl.exe -I https://example.com

Git BashやWSLなど、別のシェルを使う場合は環境変数の保存場所が分かれます。Bash系ではexport HTTP_PROXY=http://127.0.0.1:10809のように設定し、現在のシェルでenv | grep -i proxyを実行して値を確認します。PowerShellで設定した値が、別に起動したWSLのプロセスへ自動的に同じ形で渡るとは限りません。IDE内蔵ターミナルも、IDEを起動した時点の環境変数を引き継ぐため、変数変更後はIDEを再起動してください。

プロキシを使わない宛先はNO_PROXYへ登録します。localhost、127.0.0.1、::1に加えて、社内Gitサーバーやローカル開発用ドメインを指定すると、内部サービスまで外部ノードへ送ることを避けられます。NO_PROXYの区切り文字やワイルドカードの扱いは実装差があるため、広すぎる*は検証時以外に使わない方が安全です。

Gitとnpmを個別に設定して接続を確認する

Git over HTTPSを使う場合は、Gitのグローバル設定へHTTPプロキシを登録できます。次のコマンドは現在のユーザーに適用されます。まずgit config --global --get http.proxyとgit config --global --get https.proxyで既存値を確認し、古いポートや停止したプロキシが残っていないか調べてください。

git config --global http.proxy http://127.0.0.1:10809
git config --global https.proxy http://127.0.0.1:10809

git config --global --get http.proxy
git config --global --get https.proxy
git ls-remote https://example.com/sample/project.git

上のURLは接続確認の形式を示す例です。実際には利用中のリモートURLを指定してください。認証情報をプロキシURLへ埋め込んだり、設定ファイルを共有したりするのは避けます。プロキシ設定を解除する場合はgit config --global --unset http.proxyとgit config --global --unset https.proxyを実行します。SSH形式のリモートはHTTPSのGit設定を使わないため、同じ設定で直るとは限りません。まずHTTPSリモートで通信経路を検証し、SSHが必要な場合はSSHクライアント側のプロキシ方式を別途設計してください。

npmでは、registryへのアクセスとパッケージ取得が同じ設定を使うとは限りません。現在の値を確認してから、HTTPプロキシ、HTTPSプロキシ、registryを個別に設定します。

npm config get proxy
npm config get https-proxy
npm config get registry

npm config set proxy http://127.0.0.1:10809
npm config set https-proxy http://127.0.0.1:10809
npm config set registry https://registry.npmjs.org/

npm ping
npm view npm version

npm pingが成功しても、特定パッケージの取得が成功するとは限りません。依存パッケージの配布元が別ドメイン、リダイレクト先、認証付きの社内レジストリである場合があるからです。npm installが止まるときは、npmのログに表示されたURL、タイムアウトまでの時間、名前解決エラーの有無を確認します。証明書検証を無効にする設定は安全性を下げるため、プロキシ接続の問題を隠す目的でstrict-ssl=falseを常用しないでください。

Docker pullはdaemon側のプロキシを設定する

Dockerで最も誤解されやすい点は、シェルのHTTP_PROXYを設定しても、docker pullの通信主体であるDocker daemonへ自動的に反映されないことです。Docker Desktopを使っている場合は、アプリの設定画面にあるプロキシ項目を確認します。Docker Engineをサービスとして動かしている環境では、daemonの起動設定またはサービス管理設定へHTTP_PROXYとHTTPS_PROXYを登録し、daemonを再起動します。

Docker Desktopの設定項目名はバージョンや表示言語で変わる可能性がありますが、「Settings」→「Resources」または「Proxies」に相当する場所を探します。手動プロキシ欄へhttp://host.docker.internal:10809を入力する方式では、Docker daemonから見たホスト名が重要です。環境によっては127.0.0.1がDocker内部自身を指すため、v2rayNが動くWindowsホストへ到達できません。Docker DesktopとLinux上のDocker Engineでは、ホストへの到達方法が異なる点に注意してください。

docker info
docker pull hello-world
docker run --rm hello-world

docker infoでプロキシ関連の情報を確認できる場合があります。pullが失敗したら、まずregistryの名前解決、次にTLS接続、最後にレイヤーのダウンロードを分けて見ます。単純なイメージは取得できるのに大きなイメージだけが途中で止まる場合、プロキシのタイムアウト、ノードの帯域、Docker Desktopのディスク容量も確認します。v2rayNのログに接続記録がないなら、Docker daemonがまだプロキシを使っていません。

• ターミナルのcurlだけ成功し、docker pullが失敗する場合はdaemon側設定を優先します。
• docker infoに古いプロキシ値が残る場合は、設定を更新してDocker daemonまたはDocker Desktopを再起動します。
• ローカルregistryを使う場合は、NO_PROXYへregistryのホスト名とポートを登録します。
• コンテナ内のアプリが外部へ接続する場合、daemonのpull設定とコンテナ実行時の環境変数は別物です。

失敗時の切り分けと運用上の注意

複数の設定を同時に変更すると、どの変更が効果を持ったのか分からなくなります。推奨する順番は、v2rayNのノード確認、ローカルポート確認、curlによるHTTPテスト、Git、npm、Dockerの順です。各段階で成功したコマンドと失敗したコマンドを記録し、ノード変更は一度に1つだけ行います。特定のノードだけで失敗するならノード側の到達性やTLS設定、すべてのノードで失敗するならローカル設定やDNSを優先してください。

プロキシ環境変数には、通信先のホスト名や認証情報が含まれることがあります。共有ログを作るときは、ユーザー名、トークン、社内ドメイン、プロジェクト名を削除します。Gitの認証情報をURLへ直接書き込まず、npmの設定ファイルを公開リポジトリへ置かないことも重要です。v2rayNのログは通信経路の確認に役立ちますが、ノード情報や識別子を含む場合があるため、保存先と共有範囲を管理してください。

作業が終わったら、開発環境に必要な設定だけを残します。一時的に設定したPowerShellの変数はターミナルを閉じ、Gitとnpmのグローバル設定は現在値を再確認します。Docker daemonのプロキシは、運用上必要な期間だけ有効にし、不要になったら削除して再起動します。直接接続すべきローカルサービスをNO_PROXYへ登録しておけば、開発サーバー、データベース、社内APIへのアクセスを無用に外部ノードへ送らずに済みます。

git config --global --get-regexp "http.*proxy"
npm config list
Get-ChildItem Env:*PROXY*