Dockerコンテナでのプロキシ設定：コード例付きの完全ガイド

Dockerコンテナは、外部リソースへのアクセスにプロキシを必要とすることがよくあります。これは、データのパース、異なる地域からのテスト、または制限の回避のためです。プロキシの設定が不適切だと、接続エラー、実際のIPアドレスの漏洩、アプリケーションの動作不良が発生します。この記事では、Dockerでのプロキシ設定のすべての方法を、単純な環境変数からdocker-composeやカスタムネットワークを使用した高度なシナリオまで解説します。

Dockerコンテナにプロキシが必要な理由

Dockerコンテナは、プロキシが必要なさまざまなシナリオで使用されます。コンテナ化されたアプリケーションでプロキシが解決する主なタスクを見てみましょう。

データのパースと収集： マーケットプレイス（Wildberries、Ozon）、ソーシャルネットワーク、または検索エンジンからデータを収集するためにDockerコンテナ内でパーサーを実行する場合、プロキシはIPによるブロックから保護します。コンテナを使用すると、パースをスケールアップでき、10〜50のインスタンスを同時に起動し、それぞれに独自のプロキシを割り当てることができます。

異なる地域からのテスト： ウェブアプリケーションやモバイルAPIを開発する際、サービスが異なる国からどのように動作するかを確認する必要があります。異なる地理的位置のプロキシを使用したDockerコンテナは、CI/CDパイプラインでの自動テストを可能にします。

自動化とボット： Selenium、Puppeteer、またはPlaywrightを使用してブラウザを自動化するコンテナは、複数のアカウントで作業するためにプロキシを必要とします。各コンテナは独自のプロキシと隔離された環境を取得します。

企業の制限を回避： 一部のインフラストラクチャでは、Dockerコンテナはインターネットにアクセスするために企業のプロキシを通過する必要があります。適切に設定されていない場合、コンテナはパッケージをダウンロードしたり、外部APIにアクセスしたりできません。

環境変数による基本設定

Dockerコンテナ内でプロキシを設定する最も簡単な方法は、起動時に環境変数を渡すことです。この方法は、標準のHTTP_PROXY、HTTPS_PROXY、NO_PROXY環境変数を尊重するほとんどのアプリケーションで機能します。

docker runを使用してプロキシ付きでコンテナを起動：

docker run -d \
  -e HTTP_PROXY="http://username:password@proxy.example.com:8080" \
  -e HTTPS_PROXY="http://username:password@proxy.example.com:8080" \
  -e NO_PROXY="localhost,127.0.0.1,.local" \
  your-image:latest

パラメータの説明：

• HTTP_PROXY — HTTPリクエスト用のプロキシ
• HTTPS_PROXY — HTTPSリクエスト用のプロキシ（http://を使用し、https://は使用しないでください）
• NO_PROXY — プロキシを通過しないアドレスのリスト

SOCKS5プロキシの例：

docker run -d \
  -e HTTP_PROXY="socks5://username:password@proxy.example.com:1080" \
  -e HTTPS_PROXY="socks5://username:password@proxy.example.com:1080" \
  your-image:latest

Dockerデーモン用のプロキシ設定（すべてのコンテナに影響）：

すべてのコンテナがデフォルトでプロキシを使用する必要がある場合は、Dockerデーモンを設定します。ファイル/etc/systemd/system/docker.service.d/http-proxy.confを作成します：

[Service]
Environment="HTTP_PROXY=http://proxy.example.com:8080"
Environment="HTTPS_PROXY=http://proxy.example.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1,.local"

変更後、Dockerを再起動します：

sudo systemctl daemon-reload
sudo systemctl restart docker

Dockerfileでのプロキシ設定

プロキシを介してパッケージをダウンロードする必要があるDockerイメージをビルドする際（例：apt-get、pip、npm）、ビルド時にプロキシを設定する必要があります。Dockerはこれに対してビルド時引数をサポートしています。

プロキシをサポートするDockerfileの例：

FROM python:3.11-slim

# プロキシ用の引数（ビルド時に渡される）
ARG HTTP_PROXY
ARG HTTPS_PROXY
ARG NO_PROXY

# ビルド用の環境変数を設定
ENV HTTP_PROXY=${HTTP_PROXY}
ENV HTTPS_PROXY=${HTTPS_PROXY}
ENV NO_PROXY=${NO_PROXY}

# プロキシを介して依存関係をインストール
RUN apt-get update && apt-get install -y curl

# Pythonパッケージのインストール
COPY requirements.txt .
RUN pip install --proxy ${HTTP_PROXY} -r requirements.txt

# アプリケーションのコピー
COPY . /app
WORKDIR /app

# 実行時用にプロキシ変数を削除（オプション）
ENV HTTP_PROXY=
ENV HTTPS_PROXY=

CMD ["python", "app.py"]

プロキシを渡してイメージをビルド：

docker build \
  --build-arg HTTP_PROXY=http://proxy.example.com:8080 \
  --build-arg HTTPS_PROXY=http://proxy.example.com:8080 \
  --build-arg NO_PROXY=localhost,127.0.0.1 \
  -t my-app:latest .

Node.jsアプリケーション（npmをプロキシ経由で使用）：

FROM node:18-alpine

ARG HTTP_PROXY
ARG HTTPS_PROXY

# プロキシ経由で動作するようにnpmを設定
RUN npm config set proxy ${HTTP_PROXY}
RUN npm config set https-proxy ${HTTPS_PROXY}

COPY package*.json ./
RUN npm install

# npmのプロキシ設定をクリア
RUN npm config delete proxy
RUN npm config delete https-proxy

COPY . .
CMD ["node", "server.js"]

docker-compose.ymlでのプロキシ構成

Docker Composeは、マルチコンテナアプリケーションのプロキシ管理を簡素化します。プロキシをグローバルに設定することも、個別のサービスに設定することもできます。

単一サービス用のプロキシを含む基本構成：

version: '3.8'

services:
  parser:
    image: python:3.11-slim
    environment:
      - HTTP_PROXY=http://username:password@proxy.example.com:8080
      - HTTPS_PROXY=http://username:password@proxy.example.com:8080
      - NO_PROXY=localhost,127.0.0.1,db
    volumes:
      - ./app:/app
    working_dir: /app
    command: python parser.py
    
  db:
    image: postgres:15
    # データベースはプロキシを使用しません
    environment:
      - POSTGRES_PASSWORD=secret

資格情報を安全に保管するための.envファイルの使用：

docker-compose.ymlがあるディレクトリに.envファイルを作成します：

PROXY_URL=http://username:password@proxy.example.com:8080
NO_PROXY=localhost,127.0.0.1

docker-compose.ymlで変数を参照します：

version: '3.8'

services:
  parser:
    image: python:3.11-slim
    environment:
      - HTTP_PROXY=${PROXY_URL}
      - HTTPS_PROXY=${PROXY_URL}
      - NO_PROXY=${NO_PROXY}
    volumes:
      - ./app:/app
    working_dir: /app
    command: python parser.py

docker-composeでのイメージビルド用のプロキシ構成：

version: '3.8'

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
      args:
        - HTTP_PROXY=${PROXY_URL}
        - HTTPS_PROXY=${PROXY_URL}
        - NO_PROXY=${NO_PROXY}
    environment:
      - HTTP_PROXY=${PROXY_URL}
      - HTTPS_PROXY=${PROXY_URL}
    ports:
      - "3000:3000"

各インスタンスに異なるプロキシを使用してスケール：

各プロキシを持つ複数のパーサーを起動する必要がある場合は、個別のサービスを使用します：

version: '3.8'

services:
  parser-1:
    image: my-parser:latest
    environment:
      - PROXY_URL=http://user:pass@proxy1.example.com:8080
    volumes:
      - ./data:/data
    
  parser-2:
    image: my-parser:latest
    environment:
      - PROXY_URL=http://user:pass@proxy2.example.com:8080
    volumes:
      - ./data:/data
    
  parser-3:
    image: my-parser:latest
    environment:
      - PROXY_URL=http://user:pass@proxy3.example.com:8080
    volumes:
      - ./data:/data

アプリケーションレベルでのプロキシ設定

一部のアプリケーションは標準のHTTP_PROXY環境変数をサポートしていません。このような場合、アプリケーションのコードや設定ファイルでプロキシを設定する必要があります。

Python（requestsライブラリ）：

import os
import requests

# 環境変数からプロキシを取得
proxy_url = os.getenv('PROXY_URL', 'http://proxy.example.com:8080')

proxies = {
    'http': proxy_url,
    'https': proxy_url
}

# リクエストでプロキシを使用
response = requests.get('https://api.example.com/data', proxies=proxies)
print(response.json())

# SOCKS5プロキシの場合はpip install requests[socks]を実行
# proxies = {
#     'http': 'socks5://user:pass@proxy.example.com:1080',
#     'https': 'socks5://user:pass@proxy.example.com:1080'
# }

Python（aiohttpによる非同期リクエスト）：

import os
import aiohttp
import asyncio

async def fetch_with_proxy():
    proxy_url = os.getenv('PROXY_URL')
    
    async with aiohttp.ClientSession() as session:
        async with session.get(
            'https://api.example.com/data',
            proxy=proxy_url
        ) as response:
            data = await response.json()
            print(data)

asyncio.run(fetch_with_proxy())

Node.js（axiosライブラリ）：

const axios = require('axios');
const { HttpsProxyAgent } = require('https-proxy-agent');

const proxyUrl = process.env.PROXY_URL || 'http://proxy.example.com:8080';
const agent = new HttpsProxyAgent(proxyUrl);

axios.get('https://api.example.com/data', {
  httpsAgent: agent
})
.then(response => {
  console.log(response.data);
})
.catch(error => {
  console.error('Error:', error.message);
});

Node.js（組み込みのhttpsモジュール）：

const https = require('https');
const { HttpsProxyAgent } = require('https-proxy-agent');

const proxyUrl = process.env.PROXY_URL;
const agent = new HttpsProxyAgent(proxyUrl);

const options = {
  hostname: 'api.example.com',
  port: 443,
  path: '/data',
  method: 'GET',
  agent: agent
};

const req = https.request(options, (res) => {
  let data = '';
  res.on('data', (chunk) => data += chunk);
  res.on('end', () => console.log(JSON.parse(data)));
});

req.on('error', (error) => console.error(error));
req.end();

Dockerコンテナ内のSeleniumでプロキシを使用：

from selenium import webdriver
from selenium.webdriver.common.proxy import Proxy, ProxyType
import os

proxy_url = os.getenv('PROXY_URL', 'proxy.example.com:8080')

# Chrome用のプロキシ設定
chrome_options = webdriver.ChromeOptions()
chrome_options.add_argument(f'--proxy-server={proxy_url}')

# 認証には拡張機能またはSSHトンネルを使用
driver = webdriver.Chrome(options=chrome_options)
driver.get('https://example.com')
print(driver.title)
driver.quit()

Puppeteerでのプロキシ使用：

const puppeteer = require('puppeteer');

(async () => {
  const proxyUrl = process.env.PROXY_URL || 'proxy.example.com:8080';
  
  const browser = await puppeteer.launch({
    args: [`--proxy-server=${proxyUrl}`],
    headless: true
  });
  
  const page = await browser.newPage();
  
  // プロキシの認証
  await page.authenticate({
    username: 'your-username',
    password: 'your-password'
  });
  
  await page.goto('https://example.com');
  console.log(await page.title());
  
  await browser.close();
})();

Docker用のプロキシタイプの選択

プロキシのタイプの選択は、Dockerコンテナ内のアプリケーションが解決するタスクによって異なります。主なシナリオと推奨事項を見てみましょう。

特定のタスクに対する選択の推奨：

マーケットプレイスや商品カタログのパース： Wildberries、OzonなどのマーケットプレイスをDockerコンテナを介してパースする場合は、レジデンシャルプロキシを使用してください。これらのプラットフォームはデータセンターのIPを積極的にブロックします。異なるユーザーを模倣するために、5〜10分ごとにプロキシをローテーションするように設定してください。

APIテストと開発： 自分のAPIや外部サービスとの統合をテストする場合は、データセンターのプロキシが適しています。これらは高い速度と安定した接続を提供し、CI/CDでの自動テストにとって重要です。

Selenium/Puppeteerの自動化： 保護されたサイト（ソーシャルメディア、銀行、複雑なWebアプリケーション）でのブラウザ自動化をコンテナで実行する場合は、レジデンシャルプロキシを選択してください。これにより、CAPTCHAやブロックの可能性が低下します。

地理的分散テスト： 異なる国からサービスの可用性を確認する必要がある場合は、特定の地理的位置を選択したレジデンシャルプロキシを使用してください。各国のプロキシを持つ複数のDockerコンテナを起動します。

よくある問題の解決

Dockerコンテナでプロキシを使用する際に発生する一般的な問題があります。最も一般的な問題とその解決策を見てみましょう。

問題1：コンテナがプロキシに接続できない

症状： "Connection refused"、"Proxy connection failed"エラー、コンテナ起動時のタイムアウト。

解決策：

• ホストからプロキシの可用性を確認します：curl -x http://proxy:port https://example.com
• プロキシサーバーがDockerネットワークからアクセス可能であることを確認します。ホストのlocalhostにプロキシがある場合は、host.docker.internal（Mac/Windows）またはブリッジネットワーク内のホストのIPを使用します。
• ファイアウォールのルールを確認します — Dockerコンテナはアウトバウンド接続がブロックされることがあります。
• 認証付きプロキシの場合は、ユーザー名とパスワードが正しいことを確認し、URL内の特殊文字をエスケープします。

ホスト上のプロキシへのアクセスの例：

# Mac/Windows
docker run -e HTTP_PROXY=http://host.docker.internal:8080 my-image

# Linux（ブリッジネットワーク内のホストのIPを確認）
ip addr show docker0  # 通常は172.17.0.1
docker run -e HTTP_PROXY=http://172.17.0.1:8080 my-image

問題2：DNSがプロキシを介して解決されない

症状： "Could not resolve host"エラー、DNSリクエストがプロキシを通過しない。

解決策：

• HTTPの代わりにSOCKS5プロキシを使用します — SOCKS5はDNSリクエストをプロキシします。
• DockerのDNSを設定します：コンテナ起動時に--dns 8.8.8.8を追加します。
• プロキシを介してDNSをサポートしていないアプリケーションの場合は、コンテナ内でproxychainsを使用します。

# proxychainsを使用したDockerfile
FROM python:3.11-slim

RUN apt-get update && apt-get install -y proxychains4

# proxychainsの設定
RUN echo "strict_chain\nproxy_dns\n[ProxyList]\nsocks5 proxy.example.com 1080" > /etc/proxychains4.conf

# proxychainsを介してアプリケーションを起動
CMD ["proxychains4", "python", "app.py"]

問題3：コンテナの実際のIPが漏洩する

症状： 対象サービスがプロキシのIPではなく、ホストまたはコンテナのIPを検出します。

解決策：

• アプリケーションが実際にプロキシを使用していることを確認します — https://api.ipify.orgにリクエストを送信します。
• コード内のすべてのHTTPクライアントがプロキシを使用するように設定されていることを確認します。
• WebRTCおよびWebSocket接続の場合、プロキシが機能しないことがあります — ブラウザでWebRTCを無効にします。
• リクエストヘッダーを確認します — 一部のライブラリは実際のIPを持つX-Forwarded-Forを追加します。

コンテナ内のIP漏洩テスト：

# プロキシなし
docker run --rm curlimages/curl:latest curl https://api.ipify.org

# プロキシあり
docker run --rm \
  -e HTTPS_PROXY=http://proxy.example.com:8080 \
  curlimages/curl:latest curl https://api.ipify.org

問題4：プロキシ経由での動作が遅い

症状： 高い遅延、タイムアウト、データの遅い読み込み。

解決策：

• ホストから直接プロキシの速度を確認します — 問題がプロキシ自体にある可能性があります。
• 遅いプロキシで動作するためにアプリケーションのタイムアウトを増やします。
• TCP接続を再利用するためにkeep-alive接続を使用します。
• レジデンシャルプロキシの場合、遅い速度は通常のことです — リクエストの数を最適化します。
• HTTPクライアントで並行リクエストのために接続プールを設定します。

問題5：HTTPでは動作するがHTTPSでは動作しないプロキシ

症状： HTTPリクエストは通過しますが、HTTPSはSSL/TLSエラーを返します。

解決策：

• HTTPS_PROXYが設定されていることを確認します（HTTP_PROXYだけではありません）。
• HTTPS_PROXYのプロキシURLにはhttp://を使用し、https://は使用しないでください。
• プロキシがHTTPSトンネリングのためにCONNECTメソッドをサポートしているか確認します。
• 自己署名証明書を持つプロキシの場合、SSLチェックを無効にします（テスト用のみ！）。

セキュリティと資格情報の管理

Dockerコンテナ内のプロキシ資格情報の保存は、セキュリティに特別な注意を要します。パスワードの管理が不適切だと、ログ、イメージ、またはリポジトリに漏洩する可能性があります。

本番環境ではDocker Secretsを使用：

Docker Swarmは、パスワードを安全に保存するためのSecretsメカニズムをサポートしています。シークレットを作成します：

echo "http://username:password@proxy.example.com:8080" | docker secret create proxy_url -

Swarm用のdocker-composeで使用します：

version: '3.8'

services:
  app:
    image: my-app:latest
    secrets:
      - proxy_url
    environment:
      - PROXY_URL_FILE=/run/secrets/proxy_url
    command: sh -c 'export HTTP_PROXY=$(cat $$PROXY_URL_FILE) && python app.py'

secrets:
  proxy_url:
    external: true

ファイルを介した環境変数（.env）：

開発用に.envファイルを使用しますが、絶対にGitにコミットしないでください。 .gitignoreに追加してください：

# .gitignore
.env
.env.local
*.env

実際の資格情報を含まない.env.exampleを作成します：

# .env.example
PROXY_URL=http://username:password@proxy.example.com:8080
NO_PROXY=localhost,127.0.0.1

イメージ内に資格情報をハードコーディングしない：

# ❌ 悪い - パスワードはイメージに残ります
FROM python:3.11
ENV HTTP_PROXY=http://user:secretpass@proxy.com:8080
COPY . /app

# ✅ 良い - ビルド引数またはランタイム変数を介して渡します
FROM python:3.11
ARG HTTP_PROXY
# ビルド時のみ使用され、最終イメージには保存されません

資格情報をクリーンアップするためにマルチステージビルドを使用：

# プロキシを使用したビルドステージ
FROM python:3.11 AS builder
ARG HTTP_PROXY
ENV HTTP_PROXY=${HTTP_PROXY}
COPY requirements.txt .
RUN pip install -r requirements.txt

# プロキシ変数なしの最終ステージ
FROM python:3.11-slim
COPY --from=builder /usr/local/lib/python3.11/site-packages /usr/local/lib/python3.11/site-packages
COPY . /app
WORKDIR /app
CMD ["python", "app.py"]

プロキシ資格情報のローテーション：

プロキシプロバイダーが一時的な資格情報を生成するAPIをサポートしている場合は、静的パスワードの代わりにそれを使用してください。コンテナ内に初期化スクリプトを作成します：

#!/bin/bash
# entrypoint.sh

# APIから一時的な資格情報を取得
PROXY_CREDS=$(curl -s https://api.proxyservice.com/generate-temp-auth)
export HTTP_PROXY="http://${PROXY_CREDS}@proxy.example.com:8080"

# アプリケーションを起動
exec python app.py

パスワード漏洩なしのロギング：

プロキシの変数が出力に含まれないようにロギングを設定します：

import os
import re

def safe_log_env():
    """パスワードなしで環境変数をログに記録する"""
    for key, value in os.environ.items():
        if 'PROXY' in key:
            # URL内のパスワードをマスクします
            safe_value = re.sub(r'://([^:]+):([^@]+)@', r'://\1:****@', value)
            print(f"{key}={safe_value}")
        else:
            print(f"{key}={value}")

safe_log_env()

結論

Dockerコンテナ内のプロキシ設定は、パース、自動化、分散システムで作業する開発者にとって重要なスキルです。環境変数、Dockerfile、docker-composeを介してプロキシを設定する方法、PythonおよびNode.jsのアプリケーションコードにプロキシを統合する方法、接続やセキュリティに関する一般的な問題を解決する方法を学びました。

Dockerでプロキシを使用して成功するための重要なポイント：柔軟性のために環境変数を使用し、資格情報をSecretsや.envファイルを介して安全に保管し、タスクに応じてプロキシタイプを選択し、本番環境に移行する前に実際のIP漏洩がないことを常にテストしてください。

ほとんどのパースおよび自動化タスクに対して、Dockerコンテナ内での使用にはレジデンシャルプロキシをお勧めします。これにより、保護されたサイトやAPIでの作業時に高い匿名性と最小限のブロックリスクが確保されます。一方、APIテストや内部タスクのために最大の速度が必要な場合は、データセンターのプロキシに注目してください。