Dockerのリバースプロキシ: nginx-proxy対Traefik

Dockerのリバースプロキシは、コンテナの前に立つ単一のエントリーポイントであり、受信した各リクエストをホスト名に基づいて適切なサービスへルーティングします。このガイドでは、その役割で最も人気のある2つの選択肢であるnginx-proxyとTraefikを、それぞれの動作するdocker-compose.yml、Let’s Encryptによる自動TLS、明確な意思決定マトリクスとともに比較します。

対象は意図的に絞っています。自分でセルフホストするコンテナの前でDockerのリバースプロキシをどう動かすか、という点です。送信トラフィックをプロキシすることは扱いません。それはまったく別のツールであり、末尾近くのブリッジノートで触れます。

DataImpulseは倫理的なプロキシプロバイダーであり、195か国にわたって9,000万を超える住宅用、モバイル、データセンターのIPアドレスを提供します。1GBあたり1ドルからの従量課金モデルを採用し、トラフィックは失効せず、ウェブスクレイピング、広告検証、価格モニタリング、市場調査、複数アカウント管理などに利用されています。

どのDockerリバースプロキシを使うべきか?

構成をできるだけシンプルにしたい小規模で安定したWebコンテナ環境にはnginx-proxyを使い、コンテナが頻繁に増減し、ラベル駆動のルーティングが欲しい場合はTraefikを使いましょう。どちらも単一の公開ポート、TLS終端、証明書の自動更新を提供します。

サービスがほとんど静的で新しく追加することがまれなら、nginx-proxyとそのacme-companionが動作するHTTPSを最短で実現できます。頻繁にデプロイし、短命なコンテナを多数動かし、あるいはダッシュボードとミドルウェアが欲しいなら、Traefikは学習コストをかける価値があります。Caddyは知っておく価値のある3つ目の選択肢で、両者の中間に位置します。

Dockerのリバースプロキシとは何か、なぜ使うのか?

Dockerのリバースプロキシは、ポート80と443で受信するすべてのWebトラフィックを受け付け、要求されたホスト名やパスに基づいて各リクエストを正しいバックエンドコンテナへ転送するコンテナです。これがないと、公開アクセスが必要なコンテナはそれぞれ自身のホストポートを公開しなければならず、TLS証明書は各サービスに散らばってしまいます。

構成を理解するには、各要素を整理して考えると役立ちます。これを5段階のコンテナリバースプロキシスタックと呼びましょう。エントリーポイント、ルーター、サービス検出、TLS、コンテナの5つです。エントリーポイントは公開ポートです。ルーターはホスト名をルールに一致させます。サービス検出は、どのコンテナが存在するかをプロキシが把握する仕組みです。TLSは証明書が発行され終端される場所です。コンテナは実際のアプリケーションです。以下のツールはいずれもこの5段階を実現しますが、各段階をどこまで自動化するかが異なります。

• ルーティング: アプリごとのホスト名へのアクセスをすべて単一のエントリーポイントに集約するため、インターネットにはポート80と443だけを公開します。
• TLS終端: 証明書は各アプリケーションの内部ではなく、一か所で取得、保存、更新されます。
• 単一のエントリーポイント: ロギング、レート制限、アクセスルールのための単一の制御点になります。

リバースプロキシの選択肢をどう比較したか?

各ツールは、上記の5段階に加えてセットアップコストの観点から、各プロジェクトの公式サイトに記載された挙動のみを用いて評価しました。目的はスループットのベンチマークではなく、日々の運用を判断することでした。

この比較では4つの実用的な要素を重視します。サービス検出がどこまで自動化されるか、TLSがどのように取得され更新されるか、サービスが増えても設定がどれだけ読みやすく保たれるか、そして初めてのユーザーがどれだけの予備知識を必要とするかです。機能の説明はTraefikのドキュメント(traefik.io、2026-07-22時点)、nginx-proxyとacme-companionのプロジェクトページ(github.com/nginx-proxy、2026-07-22時点)、Caddyのドキュメント(caddyserver.com、2026-07-22時点)に基づいています。性能の数値はハードウェアやワークロードに大きく依存するため、ここでは掲載していません。

Dockerのリバースプロキシサーバーをどう構築するか?

プロキシをdocker-compose.yml内の1つのサービスとして定義し、2つの公開ポートを与え、他のコンテナを検出できるようにDockerソケットを読み取り専用でマウントします。以下は自動TLSを有効にした最小構成のTraefikエントリーポイントです。

services:
  traefik:
    image: traefik:v3.1
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.le.acme.tlschallenge=true"
      - "[email protected]"
      - "--certificatesresolvers.le.acme.storage=/letsencrypt/acme.json"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
      - "./letsencrypt:/letsencrypt"

バックエンドサービスはラベルでオプトインします。TraefikはそれらをDocker APIから読み取り、ルーターを構築し、leという名前のリゾルバを通じて証明書を要求します。コンテナ起動時にプロキシの再起動は不要です。

  whoami:
    image: traefik/whoami
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.whoami.rule=Host(`app.example.com`)"
      - "traefik.http.routers.whoami.entrypoints=websecure"
      - "traefik.http.routers.whoami.tls.certresolver=le"

nginx-proxyはDockerソケットを監視し、VIRTUAL_HOST環境変数を持つコンテナが現れるたびにnginx設定を再構築します。一方、コンパニオンコンテナがLet’s Encrypt証明書を扱います。意図はラベルではなく環境変数で宣言します。

services:
  nginx-proxy:
    image: nginxproxy/nginx-proxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "/var/run/docker.sock:/tmp/docker.sock:ro"
      - "certs:/etc/nginx/certs"
      - "vhost:/etc/nginx/vhost.d"
      - "html:/usr/share/nginx/html"
  acme:
    image: nginxproxy/acme-companion
    volumes_from:
      - nginx-proxy
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
      - "acme:/etc/acme.sh"
    environment:
      - "[email protected]"
  app:
    image: traefik/whoami
    environment:
      - "VIRTUAL_HOST=app.example.com"
      - "LETSENCRYPT_HOST=app.example.com"
volumes:
  certs:
  vhost:
  html:
  acme:

Caddyはより軽量な3つ目の選択肢です。デフォルトで証明書を自動的に取得し更新し、設定ファイルは短いままです。compose内でサービスを定義し、Caddyfileと証明書用のデータボリュームをマウントします。

services:
  caddy:
    image: caddy:2
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "./Caddyfile:/etc/caddy/Caddyfile"
      - "caddy_data:/data"
volumes:
  caddy_data:

Caddyfile自体は1行のプロキシに自動TLSを加えたものです。

app.example.com {
    reverse_proxy app:8080
}

nginx-proxy、Traefik、Caddyはどう比較されるか?

3つともTLSを終端しホスト名でルーティングします。主な違いは設定スタイルと自動化の度合いです。表に実用的なトレードオフをまとめます。

どのリバースプロキシをいつ選ぶべきか?

コンテナがどれだけ頻繁に変わるか、そしてどれだけの設定を自分で持ちたいかに合わせてツールを選びましょう。以下のルールは比較を直接の判断に変えます。

• nginx-proxyを使う場面: 固定されたWebアプリ群を動かし、ほぼ設定なしで動作するHTTPSが欲しいとき。
• Traefikを使う場面: コンテナが頻繁に作成・破棄される、またはダッシュボード、ミドルウェア、ラベル駆動のルーティングが欲しいとき。
• Caddyを使う場面: 可能な限り短い設定が欲しく、自動TLSが主な要件であるとき。
• nginx-proxyを避ける場面: サービスが絶えずスケールアップ・ダウンするとき。そのペースでは環境変数による検出では管理しにくくなるためです。
• Traefikを避ける場面: チームがそのラベル構文に慣れておらず、安定した2、3のサイトをプロキシするだけでよいとき。

制限事項と注意点は何か?

Dockerのリバースプロキシは受信ルーティングとTLSを解決しますが、すべてを直せるわけではなく、実際のリスクを伴います。Dockerソケットをマウントすると、読み取り専用でもプロキシからホストの情報を広く参照できます。そのため、このコンテナはセキュリティ上重要なコンポーネントとして扱い、継続的にパッチを適用してください。

ほかにも注意すべき点があります。DNSがまだホストを指していない、またはポート80と443がブロックされていると自動証明書は失敗するため、初回デプロイの前にDNSを確認してください。バックエンドコンテナはプロキシとDockerネットワークを共有する必要があり、そうでないとルーティングは明確なエラーを出さずに失敗します。Let’s Encryptのレート制限があるため、本番証明書に切り替える前にステージング環境でテストすべきです。また、リバースプロキシ自体が処理能力を増やすわけではありません。バックエンドが遅ければ、プロキシはその遅さをそのまま転送するだけです。

ブリッジノート、フォワードとリバース。 この記事全体はリバースプロキシ、つまりコンテナに入ってくるトラフィックを扱うものについてです。その逆の役割、すなわちウェブスクレイピングや地域テストのために自分のマシンから別のIPを通じてトラフィックを送信することには、代わりにフォワードプロキシが必要です。両者はよく混同されます。その違いはreverse proxy vs forward proxyで説明されています。その送信側について、DataImpulseは倫理的に調達された住宅用プロキシを1GBあたり1ドルから提供します。これはリバースプロキシではなく、コンテナへトラフィックをルーティングしないので、2つの役割は分けて考えてください。

よくある質問

関連ガイド

• NGINX リバースプロキシ
• Cloudflare リバースプロキシ
• NGINX フォワードプロキシ

受信ルーティングだけでなく、送信プロキシも必要ですか?

プロジェクトが多くの拠点からWebにアクセスする必要もある場合、DataImpulseは195か国にわたって倫理的に調達された住宅用、モバイル、データセンターのIPを、サブスクリプションなしの従量課金で1GBあたり1ドルから提供します。無料アカウントを作成して、リバースプロキシ構成と併せて試してみてください。