GitHubのcloneやDocker pullが遅い開発者向け高速化設定ガイド

GitHubのclone、Dockerイメージの取得、npm・pipの依存パッケージ導入が遅い場合、原因は回線だけとは限りません。名前解決、プロキシの設定範囲、GitやDockerの接続先、パッケージレジストリ、CI環境の制約がそれぞれ影響します。最初にどの操作が遅いのかを切り分け、その操作を実行しているプロセスに合った設定を行うのが近道です。

この記事では、ターミナル、IDE、Dockerデーモン、CIを分けて確認する方法を紹介します。コマンド例のポート番号や設定値は利用環境に合わせて置き換えてください。プロキシクライアントの接続モードやポートは製品ごとに異なるため、クライアントの設定画面で実際の値を確認しましょう。

遅い処理を特定して設定範囲を決める

「開発環境が遅い」という状態をひとまとめにせず、Gitの通信、レジストリからの取得、依存パッケージのダウンロード、ビルドのどこで待たされているかを確認します。たとえば、Dockerイメージの取得だけが遅く、同じ端末のブラウザーやGit操作が正常なら、Dockerデーモン側のプロキシ設定やレジストリへの接続を優先して調べます。逆に、複数のツールが同時にタイムアウトする場合は、ネットワーク経路やDNS、プロキシクライアントの状態も確認する必要があります。

まず、同じネットワーク環境で、同じ宛先に対する操作を比較します。Wi-Fiと有線、VPNクライアントの接続前後、ターミナルとIDE内蔵ターミナルなど、条件を一度に変えずに試すと原因を絞りやすくなります。接続先が変わると結果も変わるので、速度測定サイトの値だけでGitHubやDocker Hubへの通信状態を判断しないでください。

Git

clone・fetch

Docker

image pull

npm

依存パッケージ

pip

Pythonパッケージ

これらは別々のプログラムであり、同じ端末上でもプロキシ設定を共有するとは限りません。OSのシステムプロキシを参照するアプリがある一方、環境変数や個別設定を優先するツールもあります。設定を変更する前に、現在のクライアントモード、ローカルポート、対象アプリのプロキシ設定をメモしておくと、変更後の比較や元の状態への復帰が簡単です。

✅ どのコマンド、どの宛先、どの段階で遅くなるかを記録する
✅ VPNクライアントの接続状態と、システムプロキシ・TUNなどの動作モードを確認する
✅ 変更は一つずつ行い、成功した設定と失敗した設定を区別する
❌ 同じ端末で複数のプロキシクライアントを同時に動かし、経路を重ねない

ターミナルとIDEでGitの接続を整える

GitのHTTPS通信をローカルのHTTPプロキシ経由にする場合は、クライアントが待ち受けているアドレスとポートを指定します。次の例にあるポートは例示用です。利用中のクライアントの設定と一致させてください。

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890
git config --global --get-regexp '^(http|https)\.proxy$'

この設定はグローバル設定なので、同じユーザーで実行する複数のリポジトリに適用されます。特定のプロジェクトだけで使う場合は、そのリポジトリ内で --local を指定します。設定を解除するには、適用範囲に合わせて git config --global --unset http.proxy と git config --global --unset https.proxy を実行します。社内ネットワークやプロキシ不要の接続先まで一律に変更すると、かえって接続できなくなることがあるため、必要な範囲だけに設定してください。

HTTPSではなくSSH形式のリモートURLを使っている場合、GitのHTTPプロキシ設定は通常そのSSH通信には適用されません。SSHの接続先、利用ネットワークの制約、組織が認めている接続方法を確認してください。GitHubへの接続をHTTPSに切り替える場合も、認証方法や既存のリモートURLに影響がないか確かめてから変更します。資格情報やアクセストークンをプロキシURLに直接埋め込んだり、共有端末のコマンド履歴に残したりしないようにしましょう。

IDE内のGit操作がターミナルと異なる結果になる場合は、IDEのプロキシ設定とGit実行ファイルの指定を確認します。IDEが独自のネットワーク機能を使う場合、OSのシステムプロキシやシェルの環境変数を引き継がないことがあります。IDEを起動したターミナルでは成功するか、IDE内蔵ターミナルとソース管理パネルの両方で差があるかを比べると、設定場所を特定しやすくなります。

シェル単位で試すなら、環境変数を一時的に設定して同じコマンドを再実行できます。設定を終えたら、シェルを閉じるか変数を解除してください。HTTPS接続で利用する場合、プロキシの種類とアプリの対応を確認し、SOCKS用のアドレスをHTTPプロキシの設定欄に誤って指定しないことも大切です。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
git clone https://github.com/OWNER/REPOSITORY.git

Docker pullはデーモン側の設定も確認する

Docker CLIのコマンドを実行するシェルにプロキシ変数を設定しただけでは、イメージを取得するDockerデーモンの通信経路が変わらない場合があります。特にLinuxでは、Docker Engineがsystemdサービスとして起動している構成が一般的です。デーモンの実行環境にプロキシが設定されているか、Dockerの公式ドキュメントと現在のOSのサービス設定を確認してください。設定の変更後は、適切な方法でデーモンを再起動し、ログに構文エラーや接続エラーがないか確認します。

Docker Desktopを利用している場合は、Linuxのsystemd設定をそのまま適用せず、Docker Desktopのネットワークやプロキシ設定を確認します。OS、Docker Engine、Docker Desktopでは設定場所が異なることがあります。作業用コンテナの中にプロキシ設定を足しても、イメージのpullそのものには適用されない点にも注意してください。pullは通常、クライアントから要求を受けたDockerデーモンがレジストリと通信して実行します。

取得対象を分けて確認するには、公開イメージとプライベートイメージ、異なるレジストリのイメージをそれぞれ試します。認証が必要なレジストリだけ失敗するなら、速度の問題ではなくログイン状態や権限の可能性があります。レジストリミラーを設定する場合は、利用組織が承認したミラーを使い、配信元、認証、イメージの更新方針を確認してください。出所の分からないミラーへ切り替えると、取得元の信頼性やイメージの完全性を確認しにくくなります。

イメージ取得後のビルドが遅い場合は、pullとビルドを区別します。Dockerfileの命令順やキャッシュの無効化、依存ファイルのコピー位置によって、変更のたびに大きなレイヤーを再取得・再構築していることがあります。ログ上でどのレイヤーを待っているかを見て、通信待ちなのかローカルの展開・ビルド処理なのかを判断しましょう。

Docker CLIの設定、Dockerデーモンのプロキシ、ビルド時にコンテナへ渡すプロキシは別の設定範囲です。どの段階の通信を変えたいのかを確認してから設定してください。

npm・pipのレジストリ設定とコンテナ内の依存導入

npmやpipが遅いときは、まず標準のレジストリへ接続できるか、DNS解決やTLS検証で止まっていないかを確認します。組織で承認済みの社内レジストリやミラーがある場合は、管理者の案内に従って設定します。公開されているミラーなら何でも安全、あるいは常に速いとは限りません。接続先の運用者、利用条件、パッケージの同期状況、認証の方法を確かめずに切り替えないでください。

npmでは設定ファイルや環境変数でプロキシ、レジストリを指定できます。変更前後の値を確認し、端末全体に影響するグローバル設定とプロジェクトの設定を区別してください。pipも同様に、設定ファイルや環境変数、コマンドライン引数で接続先やプロキシを指定できます。設定が重複していると意図しない値が優先されることがあるため、現在の設定を確認してから変更しましょう。

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

python -m pip config list
python -m pip install PACKAGE_NAME

コンテナのビルド中に npm install や pip install が遅い場合、ホスト端末の環境変数がビルド環境に自動で渡るとは限りません。ビルド引数として渡す設計にする場合でも、プロキシ認証情報をDockerfileへ直接書かないでください。Dockerfileに固定値として書くと、イメージのレイヤーやビルド履歴に残るおそれがあります。BuildKitのシークレット機能など、利用中のビルド方式が提供する機密情報の受け渡し方法を確認し、必要なビルド工程だけに限定します。

パッケージの導入を再現可能にするには、ロックファイルや依存関係のバージョン固定、キャッシュの利用方針も合わせて確認します。キャッシュは同じ依存関係を再利用するのに役立ちますが、破損したキャッシュや古いキャッシュが原因で失敗することもあります。キャッシュを消す前に、エラー内容と対象の依存パッケージを記録し、必要な場合に限ってキャッシュを更新してください。

✅ npm・pipの現在のレジストリとプロキシ設定を表示してから変更する
✅ コンテナのビルドとホスト上のインストールを別々にテストする
✅ 認証情報は秘密情報として扱い、ソースコードやイメージに残さない
❌ 接続失敗を直す目的でTLS証明書の検証を無効にしない

CIを含めて検証しタイムアウトを切り分ける

CIの実行環境は、開発端末と異なるネットワーク、DNS、証明書、プロキシ設定を使うことがあります。ローカルで成功しても、CIの実行ランナーから同じGitリモートやレジストリに接続できるとは限りません。ジョブログで、ソースコード取得、依存パッケージの導入、Dockerイメージ取得、ビルドのどの段階が失敗しているかを確認し、その段階を実行するジョブに必要な設定だけを渡します。

CIで秘密情報を使う場合は、プラットフォームのシークレット管理機能を利用し、ログへ値が出ないようにします。プロキシURLにユーザー名やパスワードを含める場合も、コマンドをそのまま表示する設定やデバッグログに注意してください。ビルドキャッシュを共有する場合は、ブランチや依存関係の変更によってキャッシュが適切に無効化されるかを確認します。キャッシュの利用は通信量を抑える助けになりますが、常にビルド時間が短くなるとは限りません。

タイムアウト時は、最初にエラーの種類を見ます。名前解決の失敗ならDNSとネットワーク、TLSエラーならシステム時刻・証明書・中継機器、認証エラーなら資格情報と権限、接続拒否ならプロキシの待ち受け状態やポートが候補です。特定の大きなファイルだけで停止する場合は、転送中断やディスク容量も確認してください。タイムアウト値だけを増やすと、根本原因を見つけにくくなるため、原因に合った修正を先に行います。

VPNやプロキシクライアントを使う場合、Git、Docker、npm、pipの通信がその経路に入っているかを個別に確かめます。ルール分岐を利用していると、ブラウザーはプロキシ経由でも開発ツールは直接接続になっていることがあります。必要なら一時的に対象アプリの経路を変更して比較し、結果を確認したら元の設定に戻してください。端末やネットワーク環境ごとに挙動が異なる場合は、OS、クライアント、実行コマンド、エラーの該当部分を記録すると、再現と調査が進めやすくなります。

結論: Gitの設定、Dockerデーモン、パッケージマネージャー、CIを別々に確認し、失敗する段階だけに設定を適用するのが、安全で切り分けやすい方法です。

クライアントの導入や接続設定を確認したい場合は、設定ガイドを見るから対応する案内を参照してください。利用するツールやOSによって設定項目は異なるため、実行前にクライアントの説明と組織のネットワークポリシーも確認しましょう。