HOME > 技術ドキュメント > Nginxリバースプロキシ構成の実践設計
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 から直接返す設定になっている
リバースプロキシ構成・ロードバランシング・SSL 証明書設定まで、インフラ構築を一貫してサポートします。
お問い合わせはこちら
関連：SSL証明書 / SSL証明書 FAQ
関連ドキュメント
- Nginx SSL/TLS 設定（Ubuntu 24.04 LTS）
- Nginx ロードバランシング・リバースプロキシ詳細設定
- Nginx アクセス制御入門（Basic認証・IP制限・レート制限）
- SSL証明書 CSR 作成・インストール手順