開発者の通信トラブルは、ブラウザでWebページを開けるかどうかだけでは判断できません。GitHubのリポジトリ取得、Docker Hubからのイメージ取得、npmレジストリからの依存関係インストールでは、使われるプロセス、DNS解決、TLS接続、プロキシの読み取り方がそれぞれ異なります。ブラウザだけVPN経由になっていても、ターミナルやDockerデーモンが別の経路を使っていれば、開発作業は遅いままです。
本記事では、Git、Docker、npmを同じ設定として扱うのではなく、アプリケーションごとに通信経路を確認する方法を整理します。最初にクライアントとサブスクリプションを正しく準備し、次にターミナルの環境変数、Gitのプロキシ、Dockerデーモン、npmのレジストリ設定を順番に確認します。最後に、個人開発とCI環境で同じ設定を使わないための注意点も説明します。
開発ツールの通信経路を分けて考える
GitHubの操作には、HTTPSでリモートリポジトリへ接続する方法と、SSHで接続する方法があります。HTTPSの場合はGitのプロキシ設定や環境変数が影響しますが、SSHは通常のHTTPプロキシ設定をそのまま利用しません。SSHを使う場合は、SSHクライアント側でProxyCommandなどを設定するか、ネットワークアダプター方式で端末全体の経路を処理する必要があります。設定を混在させると、HTTPSのcloneだけ成功し、SSHのfetchだけ失敗するという状態になります。
Dockerでは、コマンドを実行するDocker CLIと、実際にイメージを取得するDockerデーモンを分けて考えることが重要です。ローカル環境のCLIがプロキシを認識していても、Docker Desktop内部のデーモンやリモートホスト上のdockerdが別ネットワークに存在する場合、イメージ取得には反映されません。Docker Hubの認証、マニフェスト取得、レイヤーのダウンロードはデーモン側の処理です。
npmも、シェルのプロキシ環境変数だけで必ず動作するとは限りません。npm自身の設定、Node.jsのTLS証明書、lockfileに記録されたURL、企業内レジストリやミラーの設定が影響します。まず現在の設定を表示してから変更し、不要になった設定は元に戻せるようにしておくと、別のネットワークへ移動した後の切り分けが容易です。
90+
対応国・地域
200+
提供回線
不限
同時接続デバイス
5
対応プラットフォーム
YsVPNは90+か国・地域、200+の回線を提供し、Windows、macOS、iOS、Android、Linuxに対応しています。開発用途では、国や地域を頻繁に切り替えるより、まず現在のネットワークから安定して到達できる出口を選び、その後に必要なアプリだけをVPN経由にする方が管理しやすくなります。
クライアントとルーティング方式を選ぶ
WindowsとmacOSでは公式クライアントを使い、サブスクリプションURLを追加して接続先を更新する方法が最も確認しやすいでしょう。Linuxでは公式クライアントのほか、Clash Vergeやsing-boxなど、配信された設定形式に対応するクライアントを利用できます。iOSではShadowrocketなど、Androidでは対応するVPNクライアントを使えますが、アプリごとに対応するProtocolとサブスクリプション形式が異なります。
Protocolの違いも確認してください。Shadowsocksは軽量な暗号化プロキシとして使われますが、クライアントが暗号方式やプラグインの指定を正しく読める必要があります。VMess、VLESS、Trojanは転送方式、TLS、ホスト名、パスなどの組み合わせが重要です。Hysteria2はUDPを利用するため、現在のネットワークがUDPやQUICを制限していないか確認します。WireGuardはOSやクライアント側にVPNインターフェースを作る方式で、一般的なHTTPプロキシとは設定の考え方が異なります。
GitHubやパッケージレジストリの取得だけを対象にしたい場合は、ルール分流とシステム全体のVPNを比較します。ルール分流では、指定したドメインやプロセスだけを経路へ送れるため、社内サービスやローカル開発環境へのアクセスを保ちやすくなります。一方、DNSやSSH、Dockerデーモンまで個別に調整する必要があります。原因の切り分けを優先する段階では、まずシステム全体またはTUN方式で動作を確認し、安定後に分流へ移行する手順が安全です。
- ✅ 公式クライアントまたはProtocolに対応した互換クライアントを使う
- ✅ サブスクリプションURLをクライアントへ追加し、接続先一覧が表示されることを確認する
- ✅ Git、Docker、npmが同じ経路を使っているかを個別に検証する
- ✅ 開発用途ではTUN方式とシステムプロキシ方式の違いを把握する
- ❌ ブラウザで接続できたことだけを根拠に、ターミナルの通信も成功すると判断しない
ターミナルとGitの設定を確認する
まずVPNクライアントを接続した状態で、ターミナルから名前解決とHTTPS接続を確認します。次のようなコマンドは、通信の成否と証明書エラーを分けて調べるのに役立ちます。
curl -I https://github.com
git config --global --get http.proxy
git config --global --get https.proxy
git remote -vgit configに古いプロキシが残っていると、VPNを接続してもGitだけが以前の経路へ接続しようとします。特に、過去にローカルのプロキシソフトを使っていた場合は注意が必要です。現在の設定が不要なら、値を確認したうえで削除します。
git config --global --unset http.proxy
git config --global --unset https.proxyHTTPプロキシを明示的に使う構成では、クライアントが表示するHTTPプロキシのアドレスとポートをGitへ設定します。ただし、ポート番号はクライアントごとに異なるため、推測せず実際の設定画面を確認してください。プロキシを設定した後は、公開リポジトリのcloneやfetchだけでなく、通常の社内Gitサーバーへも影響する可能性があります。必要に応じて、社内ドメインを除外するno-proxy設定や、リポジトリ単位の設定を検討します。
SSH接続では、次のように接続先を確認できます。
ssh -T [email protected]
git config --show-origin --get-regexp 'http\..*proxy|https\..*proxy'SSHが失敗する場合、HTTPSのプロキシ設定を変更するだけでは解決しません。TUNまたは仮想ネットワークアダプターを有効にして経路全体を処理するか、SSH用の中継設定を別途用意します。認証鍵の問題とネットワークの問題を混同しないよう、詳細ログを確認し、認証エラーなのか名前解決・接続エラーなのかを分けて判断してください。
HTTPSとSSHは設定箇所が異なります。まず使用中のリモートURLを確認し、HTTPSならGitのプロキシ、SSHならSSH側またはTUN方式を検証してください。
Dockerとnpmを個別に設定する
Dockerの取得が遅い場合は、最初にDocker CLIではなくデーモンがどこで動作しているかを確認します。Docker Desktopならアプリのネットワーク設定、Linuxのローカル環境ならsystemdで起動するdockerdの環境、リモートホストならそのホスト自身の出口とDNSを確認します。クライアント側のシェルにHTTP_PROXYを設定しただけでは、デーモンのイメージ取得へ伝わらない場合があります。
Dockerfile内で依存関係を取得する場合も注意が必要です。ビルド時のネットワークは、ホストのブラウザ通信やコンテナ起動後の通信とは別に扱われます。Dockerデーモンへプロキシを設定すると、イメージ取得だけでなくビルド時の通信にも影響する可能性があるため、認証情報をDockerfileへ直接書き込まないでください。ログやイメージ履歴にトークンが残る構成は避け、必要な秘密情報は安全なシークレット機能で渡します。
npmでは、現在のレジストリとプロキシを先に表示します。
npm config get registry
npm config get proxy
npm config get https-proxy
npm config listVPN経由で通常のnpmレジストリへ接続する構成と、組織が用意したミラーやプライベートレジストリを使う構成は分けて管理してください。レジストリを変更したままにすると、別のプロジェクトで想定外のパッケージソースを参照することがあります。package-lock.jsonやnpm-shrinkwrap.jsonに記録されたresolved URLも確認し、チーム内で再現性を保てるようにします。
証明書エラーが出た場合、TLS検証を無効にする設定を安易に使ってはいけません。まずシステム時刻、ルート証明書、Node.jsの証明書ストア、プロキシによるTLSインスペクションの有無を確認します。VPNの接続先を変えて改善した場合でも、証明書検証を無効にしたまま運用するのではなく、原因となった証明書チェーンを修正することが重要です。
| 対象 | 主な設定箇所 | 最初に確認する項目 |
|---|---|---|
| Git HTTPS | Git設定、環境変数 | http.proxy、https.proxy、リモートURL |
| Git SSH | SSH設定、TUN方式 | 名前解決、接続経路、鍵認証 |
| Docker | Dockerデーモン、Docker Desktop | デーモンの実行場所、プロキシ、DNS |
| npm | npm設定、環境変数、lockfile | registry、proxy、HTTPS証明書 |
変更後に行う検証手順
設定を一度にすべて変更すると、どの項目が効果を与えたのか分からなくなります。次の順序で、変更範囲を小さくして検証します。
- VPNクライアントでサブスクリプションを更新し、接続先を選択する。
- ターミナルで
curl -I https://github.comを実行し、HTTPS接続を確認する。 - GitのリモートURLがHTTPSかSSHかを確認し、該当する設定だけを調べる。
- Dockerで小さな公開イメージの取得を試し、デーモン側のログを確認する。
- npmのregistry表示、依存関係の取得、lockfileのURLを確認する。
- 動作確認後にルール分流へ移行し、GitHub、Docker Hub、npm関連のドメインを必要な範囲だけ対象にする。
エラーの種類も記録してください。DNS解決失敗なら名前解決や分流ルール、接続タイムアウトなら出口や経路、TLSエラーなら証明書やプロキシ、401や403なら認証情報やレート制限を疑います。取得が遅い場合は、単純にVPNの速度だけでなく、レジストリ側の応答、並列ダウンロード、キャッシュ、Dockerレイヤーの再利用も確認します。
接続先を変更する場合は、変更前後で同じコマンドを実行し、Git、Docker、npmを別々に比較します。ある出口でGitHubが改善しても、Docker Hubやnpmまで同じ結果になるとは限りません。開発環境では「すべてを最速にする」より、頻繁に使う通信を安定した経路へ割り当て、社内サービスやローカルホストを誤ってVPNへ送らないことが重要です。
CI環境と認証情報を安全に管理する
個人PCで動作したVPN設定を、そのままCIへコピーするのは避けてください。CIランナーはクラウドや社内ネットワークなど別の実行環境にあり、ローカルクライアントのサブスクリプション、TUNインターフェース、ユーザー別のnpm設定を持っていません。CIで外部依存関係を取得する場合は、ランナーのネットワークポリシー、許可されたレジストリ、キャッシュ、プロキシの公式設定を優先します。
GitHubのアクセストークン、npmトークン、Dockerレジストリの認証情報をURLやコマンド履歴へ直接書かないでください。CIのシークレット管理機能を使い、ログへの出力を抑制します。サブスクリプションURLも認証情報に近い扱いが必要です。設定ファイルをリポジトリへコミットする場合は、トークン、パスワード、個人用プロキシURLが含まれていないか確認してください。
また、依存関係の取得を速くする目的で、出所が不明なミラーや検証できない証明書を使うのは適切ではありません。npmパッケージやDockerイメージの完全性、署名、digest、lockfileを確認し、速度と再現性を両立させます。キャッシュを利用する場合も、キャッシュのキー、更新条件、無効化方法を定義しておくと、古い成果物を使い続ける事故を減らせます。
- ✅ CIではVPNクライアントの個人設定ではなく、管理されたプロキシやキャッシュを使う
- ✅ GitHub、npm、Dockerのトークンをシークレットとして保存する
- ✅ lockfile、イメージdigest、証明書検証を維持する
- ✅ 変更前の設定と復元手順を記録する
- ❌ サブスクリプションURLや認証付きレジストリURLをログ、Issue、公開設定へ貼り付けない
開発通信の改善は、VPNへ接続するだけで完了しません。GitはHTTPSとSSHを分け、Dockerはデーモン、npmはregistryと証明書を確認し、最後にCIの秘密情報と再現性を管理することが、安定した開発フローへの近道です。