GitHubのcloneが遅い、Dockerイメージの取得が止まる、npmやpipのインストールが不安定、CIだけ外部サービスへ接続できない——こうした問題は、すべて同じ「回線速度」のせいとは限りません。通信するプログラムや実行環境によって、参照するプロキシ設定、DNS、認証情報、ネットワーク経路が異なるためです。VPNを接続しただけで、開発ツールすべての通信が自動的に同じ経路になるとも限りません。ここでは作業ごとに設定箇所を切り分け、変更を一つずつ試して原因を絞る方法を紹介します。VPNやプロキシの利用可否は、組織のネットワークポリシーと各サービスの利用条件を確認してください。
まず通信元と設定箇所を切り分ける
最初に、遅い操作を「どのプログラムが、どこから実行しているか」に分けます。ブラウザーでGitHubを開けても、Gitのコマンドが同じプロキシを使うとは限りません。Dockerのイメージ取得はDockerデーモンが担当するため、シェルに設定した環境変数がそのまま反映されないことがあります。CIでは、開発PCではなくクラウド上または社内のRunnerから通信している場合があります。
- GitHub: ブラウザー、GitのHTTPS接続、SSH接続を分けて考えます。HTTPS用のプロキシ設定は、SSH接続にはそのまま適用されません。
- Docker: イメージを取得するDockerデーモンと、Dockerfile内で動くビルド処理を区別します。どちらに設定が必要かは実行環境によって異なります。
- npm・pip: パッケージマネージャー独自の設定、シェルの環境変数、社内ミラーの有無を確認します。
- CI: Runnerのネットワーク、ジョブの環境変数、秘密情報の設定、組織の通信制限を確認します。
調査中は、VPNの接続先、クライアントのモード、プロキシの値を同時に変えないようにします。まず変更前の状態を控え、作業を一つだけ行ってから同じコマンドを再実行します。複数箇所を一度に変えると、改善した場合も原因が分からず、別のアプリの通信まで影響する可能性があります。
GitHubとGitの取得経路を確認する
GitHubのリポジトリ取得では、最初にリモートURLがHTTPSかSSHかを確認します。HTTPSの場合は、GitのHTTP設定、環境変数、利用中のクライアントの設定が影響することがあります。設定値を確認するときは、認証トークンやユーザー情報がURLに含まれていないか注意し、調査ログや画面共有に秘密情報を出さないようにしてください。共有端末で一時的に設定を加えた場合は、作業後に不要な設定を削除します。
SSHの場合、接続先ホストとポートへの到達性、SSH鍵の読み込み、ホスト鍵の確認が別の論点になります。HTTPS用のプロキシを設定してもSSHには効かないため、クローン方法をHTTPSに切り替えて比較するか、管理者が認めるSSH用の経路を確認してください。ホスト鍵の検証を無効にして接続を通す方法は、安全性を損なうため避けます。認証エラーと通信タイムアウトも区別し、鍵やアカウント設定をネットワーク障害と混同しないことが大切です。
VPNを使う場合は、Gitの通信がVPNトンネルに含まれているか、分割トンネルのルールで別経路になっていないかを確認します。接続状態の表示だけでは、Gitプロセスの経路までは分かりません。社内リポジトリを利用している場合、社内ネットワークへの直通が必要なこともあるため、個人用の経路設定で組織のルールを変えないでください。
git remote -v
git config --show-origin --get-regexp 'http\..*proxy|http\.proxy'
上記はリモートURLとGitに保存されたプロキシ設定を確認する例です。該当する設定がないときは、環境変数やOSのネットワーク設定も確認します。リポジトリ取得の遅さが大きなファイルに限られる場合は、通信経路だけでなく、Git LFSの利用状況やリポジトリの構成も調べましょう。
Docker・npm・pipは設定場所を分ける
Dockerデーモンとビルド処理
docker pullでイメージを取得するときは、通常、Dockerデーモンがレジストリに接続します。そのため、ターミナルで設定したHTTP_PROXYやHTTPS_PROXYが、デーモンの通信に適用されるとは限りません。Docker Desktop、Linux上のデーモン、管理された開発環境では設定手順が異なるため、利用環境の公式ドキュメントを確認し、設定変更後に必要な再起動があるかも調べます。レジストリへの認証が必要な場合は、プロキシの問題と認証エラーを分けて確認してください。
Dockerfileのビルド中に依存パッケージを取得する場合は、デーモンのイメージ取得とは別に、ビルド処理側が外部へ接続できる必要があります。ビルド引数や環境変数でプロキシを渡す方法はありますが、認証情報をDockerfileやイメージのレイヤーに残さないでください。ログやビルド成果物に値が記録されない方法を選び、秘密情報の扱いはチームの手順に従います。
npm・pipのレジストリとプロキシ
npmでは、設定ファイルやコマンドで指定されたレジストリ、プロキシ設定、認証情報が取得先に影響します。pipも同様に、インデックスURLやプロキシ、環境変数を確認します。社内ミラーを利用する環境では、公開レジストリへ直接接続する設定に変える前に、管理者が指定した取得先があるか確認しましょう。設定の優先順位や保存場所はツールのバージョンや環境で異なるため、現在有効な値を各ツールの表示コマンドで確かめてから変更します。
インストールが途中で止まる場合、すべての依存先が同じホストとは限りません。メタデータの取得は成功しても、実際のパッケージファイルの取得先で失敗することがあります。エラーメッセージにあるホスト名と処理段階を控え、DNS解決、接続拒否、認証、証明書検証のどこで止まるのかを見分けます。証明書検証を無効にして回避するのではなく、必要なら組織の認証局やプロキシ設定について管理者に確認してください。
- ✅ GitはリモートURLがHTTPSかSSHかを確認し、該当する接続方式の設定を調べる。
- ✅ Dockerはイメージ取得とDockerfile内の通信を分け、デーモンの設定も確認する。
- ✅ npm・pipは現在のレジストリとプロキシ設定を確認し、社内ミラーの指定を優先する。
- ❌ 認証情報をDockerfile、公開ログ、共有チャットに貼り付けない。
- ❌ 原因を特定する前に証明書検証やホスト鍵の確認を無効にしない。
変更を一つずつ試す確認手順
次の手順では、最初に失敗した操作と実行環境を記録し、その後にネットワーク経路、ツール設定、認証の順で調べます。VPNを使う場合も、オン・オフだけで判断せず、クライアントの接続モードや分割トンネルの対象を確認してください。表示名や設定項目はクライアントによって異なります。
- 対象を固定する: 失敗したコマンド、実行ディレクトリ、利用した端末、エラー全文を記録します。秘密鍵、トークン、プロキシのパスワードは記録から除きます。
- 接続先を確認する: GitのリモートURL、Dockerのレジストリ、npm・pipのインデックスなど、実際に要求しているホストを確認します。ブラウザーで開けるページと同じ宛先だと決めつけないでください。
- 基礎的な名前解決と到達性を調べる: OSのDNS確認機能や、組織で許可された診断コマンドを使います。ICMP応答がないだけでサービス停止とは判断できません。組織のネットワークポリシーに反するスキャンや大量リクエストは行わないでください。
- 有効な設定を確認する: シェルのプロキシ環境変数、Git設定、Dockerデーモン、各パッケージマネージャーの設定を別々に見ます。設定の出所も確認し、古い値や意図しない上書きがないか調べます。
- 一項目だけ変更して再実行する: たとえばVPNの経路を確認した後、同じコマンドを再実行します。次に必要であれば、管理者が認めるプロキシ設定やクライアント設定を見直します。結果を記録して元の状態と比較します。
- 元に戻して副作用を確認する: 一時設定を解除し、社内サービス、ローカル開発環境、ほかのパッケージ取得に影響がないか確認します。意図しない設定を残さないようにしてください。
この順序なら、回線の問題、ツール固有の設定、認証や証明書の問題を混同しにくくなります。VPNの接続先を変更するときは、ほかの条件を同時に変えず、同じ操作で結果を比較しましょう。コマンドの応答時間だけでは、CI全体の所要時間や将来の安定性までは判断できません。
CIとチーム利用で守ること
CIでのみ失敗する場合、開発PCのVPN設定を変更しても解決しないことがあります。Runnerが外部ネットワークへ接続できるか、実行イメージに必要な証明書があるか、ジョブに環境変数が渡っているかを確認します。セルフホストRunnerでは、ホスト側のプロキシやファイアウォール、Dockerデーモンの設定も調査対象です。共有Runnerでは、利用者がネットワーク設定を変更できない場合があるため、CI管理者にログと失敗した処理段階を伝えてください。
認証トークンやプロキシ資格情報は、CIのシークレット機能で管理し、リポジトリに平文で保存しないようにします。ログのマスキングがあっても、すべての形式の秘密情報を確実に隠せるとは限りません。デバッグ出力に環境変数全体を表示することは避け、必要最小限の値だけを確認します。チームでプロキシやVPNを共有する場合は、利用を認められた端末と用途を明確にし、個人の認証情報やサブスクリプション情報を不用意に共有しないでください。
- ✅ CIのRunner種別と実行環境を確認し、ローカル端末の結果と分けて調べる。
- ✅ 秘密情報はCIのシークレット機能で管理し、ログに環境変数全体を出さない。
- ✅ 社内レジストリや許可されたプロキシがある場合、チームの標準設定を使う。
- ❌ 通信制限を回避する目的で、未承認のトンネルや公開プロキシをCIに追加しない。
VPNやプロキシは、適切に経路を整えるための選択肢ですが、リポジトリの権限、レジストリの認証、Runnerの制約を代わりに解決するものではありません。遅い処理を特定し、通信元ごとの設定を確認してから、承認された方法で一つずつ調整することが、開発環境を安定して保つ近道です。