Nginxリバースプロキシ構成の実践設計

執筆：株式会社エスロジカル（Webシステム受託開発・インフラ構築・運用改善）

Nginx をリバースプロキシとして使う構成は、現代の Web インフラではほぼ標準です。 しかし「とりあえず proxy_pass を書いた」だけでは、タイムアウト・ヘッダー漏れ・キャッシュの誤動作など 本番特有の問題が起きやすくなります。
本記事では、リバースプロキシ設計で押さえるべき実務上の判断基準をまとめます。

1. リバースプロキシの役割と設計意図

Nginx をリバースプロキシとして前段に置く主な目的は次の通りです。

• SSL ターミネーション：HTTPS の処理を Nginx に集約し、バックエンドは HTTP で通信する。証明書の管理箇所が 1 か所になる。
• 静的ファイルのオフロード：画像・CSS・JS などの静的ファイルを Nginx が直接返し、アプリサーバーの負荷を下げる。
• アクセス制御の集約：IP 制限・レートリミット・Basic 認証を Nginx で一元管理する。
• ルーティング：URL パスによってバックエンドを切り替える（/api/ → Go アプリ、/ → PHP アプリ 等）。
• 障害分離：バックエンドがダウンしても Nginx が 503 ページを返せるため、ユーザーへの影響を制御しやすい。

2. 構成パターンの選択

パターン	構成	向いているケース
シンプル1段	インターネット → Nginx（SSL終端）→ アプリ（HTTP）	単一サーバー・小規模
マルチバックエンド	Nginx → 複数バックエンド（パスベースのルーティング）	マイクロサービス・API ゲートウェイ的な用途
ロードバランシング	Nginx（upstream）→ 複数の同一アプリサーバー	水平スケールアウト・高可用性
2段プロキシ	CDN / ALB → Nginx → アプリ	クラウド構成・DDoS 対策

3. SSL ターミネーション設計

リバースプロキシが SSL を終端し、バックエンドとの通信は HTTP にする設計が一般的です。 バックエンドが同じサーバー内にある場合は特に問題ありませんが、 異なるサーバー間の通信（例：マネージド DB）は別途暗号化を検討します。

• TLS 1.2 以上を指定（ssl_protocols TLSv1.2 TLSv1.3;）
• 弱い暗号スイートを除外（ssl_ciphers で明示指定）
• HSTS ヘッダーを設定（Strict-Transport-Security: max-age=31536000）
• ssl_session_cache を有効化してハンドシェイクコストを削減
• OCSP Stapling を有効化して証明書の有効性確認を高速化

証明書は Let's Encrypt でも有料証明書でも Nginx に設定できます。 企業サイト・EC サイトでは OV 以上の有料証明書を推奨します。
SSL証明書の一覧・購入はこちら /  CSR 作成・Apache/Nginx へのインストール手順 /  SSL証明書 FAQ

4. バックエンドへのヘッダー転送

リバースプロキシを経由すると、バックエンドから見たクライアント IP が Nginx のアドレスになってしまいます。 アクセスログ・不正アクセス検知・地域制限などを正しく動作させるために以下のヘッダーを設定します。

設定	目的
proxy_set_header X-Real-IP $remote_addr;	実際のクライアント IP をバックエンドに転送
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;	プロキシチェーンを含む IP 一覧を転送
proxy_set_header X-Forwarded-Proto $scheme;	クライアントが HTTPS で接続したことをバックエンドに通知（リダイレクトループ防止）
proxy_set_header Host $host;	バーチャルホスト判定のためにオリジナルの Host ヘッダーを転送

注意：X-Forwarded-For はクライアント側から偽装できます。 信頼できるプロキシからのみこのヘッダーを受け付けるよう、バックエンドアプリ側でも適切に処理してください。

5. タイムアウト・バッファリング設定の落とし穴

デフォルト値のままでは、ファイルアップロードや時間のかかる API 処理で問題が起きやすくなります。

• proxy_read_timeout：バックエンドからのレスポンスを待つ最大時間（デフォルト 60 秒）。 時間のかかる処理（レポート生成・大量データ処理）がある場合は延長します。
• proxy_connect_timeout：バックエンドへの接続タイムアウト（デフォルト 60 秒）。 通常は短め（10 秒程度）でも十分で、長すぎると障害時に影響が長引きます。
• client_max_body_size：ファイルアップロードの上限（デフォルト 1MB）。 アップロード機能がある場合は必ず引き上げます（例：client_max_body_size 50m;）。
• proxy_buffering：バックエンドからのレスポンスをバッファリングする設定。 Server-Sent Events（SSE）や WebSocket を使う場合はバッファリングを無効化（proxy_buffering off;）します。

6. キャッシュ設計：静的と動的の分離

• 静的ファイルは Nginx でキャッシュ：画像・CSS・JS には長い Cache-Control ヘッダー（例：max-age=31536000）を設定し、ブラウザキャッシュを活用する。
• 動的コンテンツはキャッシュしない：ユーザー固有のデータやリアルタイム情報は Cache-Control: no-cache, no-store を設定する。
• proxy_cache の使用：バックエンドへのアクセスを Nginx がキャッシュすることで負荷を下げられますが、キャッシュの無効化ロジックが複雑になります。まず静的ファイルのオフロードから始めるのが安全です。

7. エラー時の挙動設計

• バックエンドダウン時のカスタムエラーページ：error_page 502 503 504 でメンテナンスページを返す。デフォルトの Nginx エラーページはユーザー体験が悪い。
• バックエンド複数台時の failover：upstream に複数サーバーを設定し、proxy_next_upstream error timeout で自動的に次のサーバーへフォールオーバーする。
• ヘルスチェック：upstream のバックエンドに定期的にヘルスチェックリクエストを送り、異常なサーバーを自動的に切り離す（Nginx ロードバランシング詳細設定）。

8. セキュリティ強化

• サーバーバージョン情報を非表示にする（server_tokens off;）
• 不要な HTTP メソッド（TRACE・DELETE 等）を拒否する
• 管理 URL（/admin/ 等）に IP 制限を設ける（Nginx アクセス制御）
• セキュリティヘッダー（X-Frame-Options・Content-Security-Policy 等）を追加する

設計チェックリスト

• □ TLS 1.2 以上のみを許可している
• □ HSTS ヘッダーを設定している
• □ X-Real-IP / X-Forwarded-For を正しく転送している
• □ X-Forwarded-Proto を設定しリダイレクトループを防止している
• □ client_max_body_size をアップロード要件に合わせて設定している
• □ バックエンドダウン時のカスタムエラーページを設定している
• □ server_tokens off を設定している
• □ 静的ファイルは Nginx から直接返す設定になっている

関連ドキュメント

• Nginx SSL/TLS 設定（Ubuntu 24.04 LTS）
• Nginx ロードバランシング・リバースプロキシ詳細設定
• Nginx アクセス制御入門（Basic認証・IP制限・レート制限）
• SSL証明書 CSR 作成・インストール手順

← 技術ドキュメント一覧へ戻る