Dockerのブリッジコンテナーからホストのプロキシに接続する

コンテナーから到達できるプロキシアドレスを選び、公開の接続先とDockerホストで動くプロキシを区別します。

通常のブリッジネットワークのコンテナーでは、127.0.0.1 はコンテナー自身のループバックアドレスです。ノートPCのlocalhostで待ち受けるプロキシが、各コンテナー内でも待ち受けるわけではありません。

同じプロキシURLがホストの端末では動き、コンテナー内では接続拒否になる違いは、このために起こります。同じアドレスでも各環境では別の接続先を指します。

公開プロキシは直接使える

サービスやHTTPプロキシ一覧から選んだ接続先が実際に到達できる公開IPなら、localhostに置き換えず、そのアドレスをアプリに渡してください。

docker run --rm \
  -e HTTP_PROXY=http://203.0.113.10:8080 \
  -e HTTPS_PROXY=http://203.0.113.10:8080 \
  your-image

文書用アドレスとイメージを置き換えます。イメージ内のプログラム自体が環境変数に対応している必要があります。変数が存在するだけでDockerがすべてのソケットをプロキシ経由に変えることはありません。

Dockerホストでプロキシが動いている場合

Docker Desktopはホストの内部アドレスへの接続に host.docker.internal を提供します。対応するネイティブEngine構成では、ホストのマッピングでこの慣用名を提供できます。

docker run --rm \
  --add-host host.docker.internal=host-gateway \
  -e HTTP_PROXY=http://host.docker.internal:8080 \
  -e HTTPS_PROXY=http://host.docker.internal:8080 \
  your-image

これは名前解決の変更であり、ポート転送のコマンドではありません。ネイティブLinuxではホストのループバックだけにバインドしたサービスに、ホストのブリッジアドレスから届かないことがあります。待受先、ファイアウォール、コンテナーの経路が接続を許可する必要があります。待受設定を変えるなら、必要なクライアントに限定し、認証のない公開プロキシを作らないでください。

アプリと同じ場所からテストする

ホスト上のcurlの結果で分かるのはホストの経路だけです。コンテナー環境から必要なリクエストを送り、意図した接続先に届くか確認してください。

「ホスト」はDocker Engineが動くマシンも意味します。リモートEngineではノートPCとは限りません。そのため、ローカルのデスクトップアプリからコピーしたループバックIPが、リモートのビルダーやサーバーでそのまま使える可能性は特に低くなります。

イメージ取得の問題は分けて扱います。アプリが上記の環境を利用できる前に、デーモンがイメージをダウンロードします。

関連記事