Webサーバーを公開していると、「IPアドレスを直接叩かれて攻撃を受けた」「バックエンドのシステム構成が外部に露出している」というリスクが頭をよぎります。リバースプロキシは、こうした悩みを解決する技術のひとつです。
この記事では、リバースプロキシの仕組みから具体的なセキュリティ効果、Nginxを使った基本設定まで、現場で使えるレベルで解説します。「サーバー公開時のセキュリティをどう強化すればいいか」と悩んでいる方に読んでいただきたい内容です。

リバースプロキシとは?フォワードプロキシとの違い
リバースプロキシとは、クライアント(ブラウザ等)とバックエンドサーバーの間に立ち、クライアントからのリクエストを受け取って内部サーバーに転送する中継サーバーのことです。
「プロキシ(Proxy)」という言葉自体は「代理」を意味しますが、フォワードプロキシとリバースプロキシでは代理の方向が異なります。
| 種類 | 何の代理か | 主な用途 |
|---|---|---|
| フォワードプロキシ | クライアント側の代理 | 社内からインターネットへのアクセス制御・フィルタリング |
| リバースプロキシ | サーバー側の代理 | 外部からのリクエストを受け取り内部サーバーへ転送・保護 |
フォワードプロキシは「社内の誰がどのサイトにアクセスしたか」を管理するために使われることが多く、一方のリバースプロキシは「外部からのリクエストを適切な内部サーバーへ届けながら、バックエンドを保護する」用途で使われます。
リバースプロキシの仕組み
リクエストの流れを整理すると次のようになります。
・Step 1: ユーザーがブラウザから「https://example.com」にアクセスする
・Step 2: リクエストはリバースプロキシサーバーに届く(ユーザーはバックエンドサーバーの存在を知らない)
・Step 3: リバースプロキシがリクエストの内容を解析し、適切なバックエンドサーバーへ転送する
・Step 4: バックエンドサーバーが処理し、結果をリバースプロキシへ返す
・Step 5: リバースプロキシがレスポンスをユーザーへ返す
この構成により、バックエンドサーバーのIPアドレスや構成情報がユーザー側に直接見えない状態を作れます。代表的なリバースプロキシ実装としては Nginx、Apache(mod_proxy)、HAProxy、Caddy などがあります。クラウド環境では AWS CloudFront・ALB、Google Cloud Load Balancing なども同等の機能を担います。
リバースプロキシがもたらすセキュリティ効果
1. 内部サーバーのIPアドレスを隠す
リバースプロキシを介することで、バックエンドサーバーのIPアドレスが外部から直接見えなくなります。攻撃者がバックエンドのIPアドレスを知っていれば、リバースプロキシを迂回して直接攻撃することも理論上は可能ですが、その経路を塞ぐことができます。
・バックエンドサーバーのファイアウォール設定: リバースプロキシからのトラフィックのみ許可する
・バックエンドサーバーへの外部からの直接アクセスを遮断: リバースプロキシのIPアドレスだけをホワイトリストに登録
この「バックエンドの完全な隠蔽」がリバースプロキシ導入の根本的なセキュリティ効果です。
2. TLS終端でHTTPS化を一元管理する
TLS終端(TLS Termination)とは、HTTPS通信の暗号化・復号をリバースプロキシで処理し、バックエンドサーバーとの通信はHTTPで行う構成です。
この構成のメリットは次の通りです。
・証明書管理の一元化: SSL/TLS証明書をリバースプロキシだけで管理すれば良く、バックエンドごとの証明書設定が不要になる
・パフォーマンスの向上: TLS処理をリバースプロキシに集約することでバックエンドの負荷を軽減できる
・Let’s Encrypt の自動更新が容易: Certbot などのツールで証明書の更新を自動化しやすい
ただし、バックエンドとリバースプロキシ間の通信が平文になる点には注意が必要です。同一サーバー・同一プライベートネットワーク内での通信であれば問題は小さいですが、外部に出る経路がある場合は内部通信もHTTPS化(TLS Passthrough)を検討してください。
3. WAFと組み合わせて攻撃をフィルタリングする
リバースプロキシとWAF(Web Application Firewall・Webアプリケーションファイアウォール)は非常に相性が良い組み合わせです。Nginxでは ModSecurity を組み込んでWAF機能を持たせることができます。クラウド環境では AWS WAF を ALB の前段に置く構成が一般的です。
リバースプロキシが「入口」を一本化することで、WAFのルール適用箇所がリバースプロキシだけで済み、バックエンドが複数台あっても一括でセキュリティポリシーを適用できます。
WAFの仕組みと導入方法については、本サイトの「WAFとは?Webアプリケーションファイアウォールの仕組み・選び方・導入手順をわかりやすく解説」も参考にしてください。
4. DDoS対策・レート制限を集約する
リバースプロキシレイヤーでレート制限(接続数・リクエスト数の上限設定)を実装することで、DDoS攻撃や過剰なスクレイピングに対する最初の防衛線を設けられます。バックエンドサーバーに大量のリクエストが直接到達する前に、リバースプロキシ段階で流量を制限できます。
Nginxでリバースプロキシを設定する基本手順
最も広く使われる Nginx を例に、基本的なリバースプロキシ設定を紹介します。
1. 基本的なリバースプロキシ設定
# /etc/nginx/conf.d/reverse-proxy.conf server { listen 443 ssl; server_name example.com; # SSL証明書の設定(Let's Encrypt を想定) ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; ssl_protocols TLSv1.2 TLSv1.3; # TLS1.0/1.1は無効化 ssl_ciphers HIGH:!aNULL:!MD5; location / { proxy_pass http://127.0.0.1:8080; # バックエンドへ転送 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; } } # HTTPはHTTPSへリダイレクト server { listen 80; server_name example.com; return 301 https://$host$request_uri; }
2. セキュリティヘッダーの追加
リバースプロキシのレスポンスにセキュリティヘッダーを付与することで、ブラウザ側のセキュリティ機能を有効化できます。
# server ブロック内に追加するセキュリティヘッダー # クリックジャッキング対策 add_header X-Frame-Options "SAMEORIGIN" always; # MIMEタイプのスニッフィング防止 add_header X-Content-Type-Options "nosniff" always; # XSS保護(モダンブラウザでは CSP が主流だが念のため) add_header X-XSS-Protection "1; mode=block" always; # HTTPS強制(初回アクセスから1年間) add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; # バックエンドのNginxバージョン情報を隠す server_tokens off;
3. レート制限の設定
# http ブロックでゾーンを定義(同一IPからのリクエスト数を制限) http { limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s; # 10m: 共有メモリサイズ / 10r/s: 1秒あたり10リクエストまで } # location ブロックで適用 location /api/ { limit_req zone=api_limit burst=20 nodelay; # burst=20: 一時的に20リクエストまでのバーストを許可 proxy_pass http://127.0.0.1:8080; }
Linuxのfirewalldと組み合わせることで、リバースプロキシへのアクセス制御をさらに強化できます。詳細は姉妹サイトLinuxMaster.JPで解説しています。
中小企業でも今日からできること
「Nginxの設定は難しそう」と感じる場合でも、クラウドサービスを活用すれば設定ハードルを下げられます。
・Cloudflare の無料プランを使う: Cloudflare はリバースプロキシ・CDN・基本的なDDoS対策を無料で提供しています。DNS設定を変更するだけでWebサーバーの前段にリバースプロキシを置ける
・AWS ALB + CloudFront を使う: AWSを利用中であれば、Application Load Balancer と CloudFront の組み合わせでリバースプロキシ機能を実現できる
・オンプレミスでは Nginx をまず試す: 公式ドキュメントが充実しており、基本的なリバースプロキシ設定であれば数十行の設定ファイルで実現できる
・既存のWebサーバー設定を見直す: リバースプロキシを新規導入しなくても、現在のWebサーバー設定でセキュリティヘッダーが付与されているか確認し、不足していれば追加する
まず「外部からバックエンドのポートに直接アクセスできないか」をポートスキャン(nmap 等)で確認することをお勧めします。不要なポートが開いていれば、ファイアウォール設定で塞ぐことが最初のステップです。
よくある誤解と注意点
誤解1:リバースプロキシを入れれば完全に安全
リバースプロキシはセキュリティ対策の一部にすぎません。バックエンドアプリケーション自体の脆弱性(SQLインジェクション、認証バイパス等)はリバースプロキシだけでは防げません。アプリケーション層のセキュリティ対策(セキュアコーディング、入力バリデーション等)と組み合わせて多層防御を構築することが重要です。
誤解2:TLS終端をリバースプロキシで行えばバックエンドは平文で良い
同一サーバー内の通信(ループバックアドレス経由)であれば現実的なリスクは低いですが、バックエンドサーバーが別のホスト・別のセグメントにある場合は、内部通信も暗号化することを検討してください。「内部だから安全」という思い込みは、内部脅威の観点から見直す必要があります。
誤解3:リバースプロキシを設定すればバックエンドのIPが完全に隠れる
メールヘッダー、エラーメッセージ、証明書のサブジェクト情報など、さまざまな経路でバックエンドのIPアドレスが漏洩することがあります。設定後は外部スキャンサービス等で意図せずバックエンドが露出していないかを確認する習慣をつけましょう。
本記事のまとめ
リバースプロキシはWebサーバーのセキュリティ強化において非常に効果的な技術です。設定のポイントをまとめます。
| 対策 | 効果 | 難易度 |
|---|---|---|
| バックエンドIPの隠蔽 | 直接攻撃の経路を塞ぐ | 低(ファイアウォール設定) |
| TLS終端の一元化 | 証明書管理の簡略化・HTTPS強制 | 低〜中(設定作業) |
| セキュリティヘッダーの付与 | クリックジャッキング・MIME混乱攻撃等を防ぐ | 低(設定追加のみ) |
| レート制限 | DDoS・過剰アクセスへの最初の防衛線 | 中(パラメータ調整が必要) |
| WAFとの連携 | アプリケーション層の攻撃をフィルタリング | 中〜高(ルール設定) |
リバースプロキシ単体でセキュリティが完結するわけではありませんが、「入口の一本化」を実現することで他のセキュリティ施策(WAF・ログ監視・レート制限)を効率よく適用できます。まずは Cloudflare などのクラウドサービスからリバースプロキシの効果を体験してみてください。
ネットワーク設計のセキュリティ、自信を持って説明できますか?
リバースプロキシ・WAF・ファイアウォールを組み合わせた多層防御の設計をわかりやすく解説します。
正しいセキュリティ知識を体系的に身につけたい方へ、メルマガで実践的なセキュリティ対策ノウハウをお届けしています。


コメント