nginxリバースプロキシ: 完全セットアップチュートリアル

nginxリバースプロキシとは、1つ以上のバックエンドアプリケーションの代わりに受信リクエストを受け付け、適切なバックエンドへ転送し、その応答をクライアントに返すnginxサーバーです。このチュートリアルでは、そのままコピーして使える完全なnginxリバースプロキシの設定例を紹介します。proxy_passと転送ヘッダーを含む完全なserverブロック、upstreamによる負荷分散、SSL終端、WebSocketサポート、バッファリングとタイムアウトの調整、gzip、location単位のルーティング、さらに、多くの人がつまずく502エラーと504エラーの解決方法まで扱います。

最後まで読めば、実際に動くnginxリバースプロキシ構成、各要素の連携を理解するための考え方、そしてnginxリバースプロキシが適切なツールではなくなり、フォワードプロキシやレジデンシャルプロキシに使い分けるべき場面についての正直な見解が得られます。

DataImpulseは、195カ国で9000万以上のレジデンシャル、モバイル、データセンターIPアドレスを提供する倫理的プロキシプロバイダーです。1GBあたり1ドルからの従量課金制を採用し、トラフィックの有効期限はありません。ウェブスクレイピング、広告検証、価格モニタリング、市場調査、マルチアカウント管理に利用されています。

nginxはリバースプロキシとして使えるのか、仕組みは?

はい、nginxは最も広く使われているリバースプロキシの1つであり、リバースプロキシ機能は追加機能ではなく標準機能です。リバースプロキシはバックエンドサーバーの前段に配置され、公開ホスト名でクライアント接続を受け付け、各リクエストをクライアントからは直接見えない内部アプリケーションへルーティングします。

構成要素を整理するため、このガイドではシンプルな名前付きモデルを使います。これをnginxリバースプロキシ5層モデルと呼び、以下の設定例は、これらの層を順に組み合わせたものです。

• リスナー。 listenディレクティブとserver_nameが、このブロックがどのリクエストを処理するか（ポート80、ポート443、ホスト名）を決定します。
• locationルーティング。 locationブロックが受信パスを振り分け、/api/、/static/、/をそれぞれ異なる宛先へ振り分けます。
• アップストリーム。 upstreamブロックがバックエンドサーバー群とロードバランシング方式を定義します。
• ヘッダー。 proxy_set_header行が元のHostとクライアントIPを保持し、バックエンドがnginxではなく、実際のクライアントからのリクエストとして認識できるようにします。
• TLS。 listen 443上のssl_certificateがnginxでHTTPSを終端し、バックエンドは内部通信では平文HTTPを使用できます。

2つのプロキシの方向性についてまだ迷っている場合は、リバースプロキシとフォワードプロキシの違いを解説した記事で概念を詳しく説明しています。この記事はリバース側のみを扱います。アウトバウンドのクライアント側設定については、姉妹記事のnginxフォワードプロキシガイドをご覧ください。

始める前に必要なもの

必要なのは、nginxがインストールされたLinuxサーバー、ローカルポートで待ち受けるバックエンドアプリケーションを少なくとも1つバックエンドアプリケーション、そしてHTTPSの場合はTLS証明書です。リバースプロキシは標準のnginxビルドのみを使用するため、カスタムモジュールや再コンパイルは不要です。

何かを編集する前に、nginxがインストールされ、設定が有効であることを確認します。

nginx -v
sudo nginx -t

nginx -tテストは設定全体を解析し、構文エラーをファイル名と行番号付きで報告します。このチュートリアルでは変更のたびに実行してください。nginxは壊れた設定のリロードを拒否し、古い設定を動かし続けるからです。ディストリビューションに応じて、リバースプロキシのserverブロックは/etc/nginx/conf.d/または/etc/nginx/sites-available/に置き、テストが通ったらsudo nginx -s reloadでリロードします。バックエンドのアドレスも用意しておきましょう。例えば127.0.0.1:3000で動作するNodeやPythonのアプリケーションなどです。これがproxy_passの転送先になります。

nginxリバースプロキシをステップバイステップで設定する方法

まずポート80で待ち受け、proxy_passで全リクエストを1つのバックエンドに転送し、転送ヘッダーを設定する単一のserverブロックから始めます。その後、負荷分散、TLS、WebSocket、バッファリング、gzipを順に追加していきます。この最初のブロックが、動作する最小限のnginxリバースプロキシ構成です。

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

この4つのproxy_set_header行は省略できません。これらがないと、バックエンドはnginxをクライアントと見なし、誤ったIPを記録し、壊れたリダイレクトURLを生成する可能性があります。Hostは要求されたホスト名を保持し、X-Real-IPとX-Forwarded-Forは実際のクライアントアドレスを伝え、X-Forwarded-Protoは元のリクエストがHTTPかHTTPSかをアプリに伝えます。

upstreamによる負荷分散を追加する。 複数のバックエンドインスタンスの前段に配置するには、upstreamブロックを定義し、proxy_passをその名前に向けます。least_conn方式は、アクティブな接続数が最も少ないインスタンスに各リクエストを送ります。

upstream app_backend {
    least_conn;
    server 10.0.0.11:3000;
    server 10.0.0.12:3000;
    server 10.0.0.13:3000 backup;
}

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

backupサーバーは、プライマリサーバーが停止した場合にのみトラフィックを受け取ります。同じクライアントを同じバックエンドに固定するスティッキーセッションが必要な場合は、least_connの代わりにip_hashを使ってください。

ポート443でSSLを終端する。 本番環境では、リバースプロキシでHTTPSを提供し、平文HTTPからリダイレクトするべきです。nginxがTLSを処理するので、バックエンドは内部で平文HTTPのままで構いません。

server {
    listen 443 ssl;
    server_name app.example.com;

    ssl_certificate     /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 80;
    server_name app.example.com;
    return 301 https://$host$request_uri;
}

WebSocketをサポートする。 WebSocket接続はHTTPとして開始された後にアップグレードされるため、nginxはUpgradeとConnectionヘッダーを渡し、HTTP/1.1を使用する必要があります。リアルタイム通信のパスには専用のlocationを用意します。

location /ws/ {
    proxy_pass http://app_backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade    $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host       $host;
    proxy_read_timeout 3600s;
}

長めのproxy_read_timeoutは、アイドル状態のソケットがセッション途中で閉じられるのを防ぎます。ライブ接続が切断される一般的な原因の1つです。

バッファリングとタイムアウトを調整する。 デフォルト値は保守的です。遅いバックエンドでは、アプリが応答する前にnginxが接続を閉じてしまわないよう、明示的な値を設定すると効果的です。

location / {
    proxy_pass http://app_backend;
    proxy_connect_timeout 5s;
    proxy_send_timeout    60s;
    proxy_read_timeout    60s;
    proxy_buffering       on;
    proxy_buffers         16 16k;
    proxy_buffer_size     32k;
}

gzipを有効にする。 プロキシされたレスポンスを圧縮すると、テキスト形式のリソースで使う帯域幅を削減できます。サイト全体に適用するには、これをhttpブロックに置きます。

gzip on;
gzip_types text/plain text/css application/json application/javascript;
gzip_min_length 1024;
gzip_comp_level 5;

パスでルーティングする。 1つのリバースプロキシで、locationごとに異なるプレフィックスを別のupstreamへ対応付けることで、複数のサービスを前段で扱え、静的ファイルはバックエンドに触れずディスクから直接配信できます。

server {
    listen 80;
    server_name example.com;

    location /api/ {
        proxy_pass http://api_backend;
        proxy_set_header Host $host;
    }

    location /static/ {
        root /var/www/assets;
    }

    location / {
        proxy_pass http://web_backend;
        proxy_set_header Host $host;
    }
}

nginxリバースプロキシが正しく動作しているか確認する方法

nginxをリロードし、公開ホスト名にリクエストを送って、レスポンスがnginxのデフォルトページではなくバックエンドから返ってくることを確認します。設定ミスでサイトを停止させないよう、まず設定をテストしてください。

sudo nginx -t && sudo nginx -s reload
curl -I http://app.example.com

レスポンスヘッダーで200や期待通りのリダイレクトが返れば、ルーティングは機能しています。バックエンドが転送ヘッダーを受け取っていることを証明するには、アクセスログやエコーエンドポイントを確認し、127.0.0.1ではなくX-Forwarded-Forから実際のクライアントIPが見えていることを確認します。DNSを迂回し、Hostヘッダーを指定してプロキシを直接ターゲットにすることもできます。

curl -H "Host: app.example.com" http://127.0.0.1

HTTPSの場合はcurl -I https://app.example.comを実行し、証明書が受理され、リクエストがHTTPへダウングレードされていないことを確認します。バックエンドが誤ったスキームでリンクやリダイレクトを生成する場合、それはほとんど常にTLSの不具合ではなくX-Forwarded-Protoヘッダーの欠落が原因です。

502エラーと504エラーのトラブルシューティング方法

502 Bad Gatewayは、nginxがupstreamに到達したものの無効または拒否されたレスポンスを受け取ったことを意味し、504 Gateway Timeoutは、upstreamが接続を受け付けたものの時間内に応答しなかったことを意味します。どちらもnginxのバグではなくupstream側の問題であり、エラーログに正確な原因が記録されます。リクエストを再現しながら、ログをリアルタイムで確認してください。

sudo tail -f /var/log/nginx/error.log
# [error] connect() failed (111: Connection refused) while connecting to upstream

よくある原因を順に確認していきます。

• 502、接続拒否。 バックエンドが起動していないか、proxy_passが指すのとは異なるアドレスやポートで待ち受けています。サーバー自身でcurl http://127.0.0.1:3000を実行して確認してください。
• 502、SELinuxまたはファイアウォール。 RHEL系システムでは、setsebool -P httpd_can_network_connect 1を実行するまでSELinuxがnginxのアウトバウンド接続をブロックします。
• 504、遅いバックエンド。 アプリの応答がproxy_read_timeoutより長くかかっています。全体の設定で問題を覆い隠すのではなく、そのlocationのタイムアウトを上げるか、遅いクエリ自体を修正してください。
• 502、大きなヘッダー。 バックエンドが大きなレスポンスヘッダーを送るとプロキシバッファがあふれることがあります。proxy_buffer_sizeとproxy_buffersを増やしてください。
• 誤ったupstreamの選択。 upstreamプール内の1台がダウンすると、nginxはそれを異常と判断して、次のサーバーへの接続を試みます。断続的な502は、多くの場合1台の不健全なバックエンドが原因です。

どのリバースプロキシが適しているか、別のプロキシが必要になるのはどんなときか

TLSの終端、負荷分散、あるいは自分のサーバーの前段でパスをルーティングする場合はnginxリバースプロキシを使い、多数のIPを使ってアウトバウンドリクエストを送る用途にはフォワードプロキシやレジデンシャルプロキシを使ってください。nginxはインバウンドの仕事に優れていますが、アウトバウンド向けには設計されていません。用途別の目安は以下の通りです。

• nginxリバースプロキシを使うべき場合: バックエンドを自前でホストしており、複数の内部サービスに対して1つの公開HTTPSエンドポイントを用意したい、インスタンス間の負荷分散が必要、あるいはエッジでのキャッシュとgzipが欲しい場合。
• nginxをプロキシとして避けるべき場合: 目的が、多数の異なるIPや国から送信しているように見せる必要があるアウトバウンドリクエストである場合。リバースプロキシはサーバー単一のIPから出ていくため、アドレスをローテーションできません。

リバースプロキシとしては、nginx、Caddy、HAProxyはそれぞれ異なるトレードオフを持っています。

大量のアウトバウンド自動化については、ウェブスクレイピングのベストプラクティスガイドでローテーションとレート制御を解説しています。また、レジデンシャルIPらしさよりもコストやキャリアIPが重要な作業には、データセンタープロキシやモバイルプロキシが適しています。

nginxリバースプロキシの限界とリスクとは

nginxリバースプロキシはインバウンドトラフィックには強力ですが、現実的な限界があります。アウトバウンドIPをローテーションできない、誤設定のヘッダーの誤設定によってクライアント情報が漏れたり、逆に見えなくなったりする、そしてパッチ適用と監視が必要な運用コンポーネントが増える、という点です。これらを理解しておくことで、現実的な期待値を保てます。

• 単一の出口IP。 プロキシからのすべてのアウトバウンドリクエストはサーバー自身のIPを通って出ていくため、多数の送信元アドレスが必要なタスクにはリバースプロキシは役立ちません。
• ヘッダーのミスは静かに起こる。 X-Forwarded-Forを忘れるとアプリケーションとそのレート制限機能から本当のクライアントIPが隠れ、X-Forwarded-Protoを忘れるとHTTPSリダイレクトが壊れます。nginxは警告してくれません。
• TLSと証明書の維持管理。 証明書は期限切れになるため、通常はcertbotとcronジョブやsystemdタイマーを通じて、更新とリロードを自分で管理する必要があります。
• 新たな障害点。 プロキシがクリティカルパスに入るため、それが落ちると背後のすべてのバックエンドに到達できなくなります。だからこそヘルスチェックと監視が重要です。
• アウトバウンドの匿名化ツールではない。 リバースプロキシはリクエストの出所を隠すようには作られていません。それはフォワードプロキシの仕事です。

nginxはDataImpulseの製品ではなく、DataImpulseはマネージドスクレイピングAPIや無料のウェブプロキシを販売していません。nginxが適する場面では自分で運用してください。アウトバウンドの規模が必要な場面では、DataImpulseは同意のうえ報酬を受け取っているユーザーから倫理的プロキシとしてIPを調達しています。最終更新日: 2026-07-22。

よくある質問

関連ガイド

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

nginxではローテーションできないアウトバウンドIPが必要ですか?

リバースプロキシはインバウンドトラフィックを処理しますが、多数の実IPからのアウトバウンドリクエストが必要な場合、DataImpulseは195カ国で9000万以上のローテーション式レジデンシャル、モバイル、データセンターIPを提供し、1GBあたり1ドルからの従量課金でトラフィックの有効期限もありません。アカウントを作成して、ゲートウェイの認証情報を取得し、クライアントをプロキシプールへルーティングしましょう。