SSLとリバースプロキシの基本知識と設定方法完全ガイド

2025 11/28

2025/11/28

はじめに

本ドキュメントの目的

本書は「ssl リバースプロキシ」に関する実務向けのガイドです。リバースプロキシとSSLの基本から、Apache／Nginxでの具体的な設定、証明書の取得と自動更新、負荷分散やセキュリティ強化までを扱います。実際の運用を想定した手順や設定例を中心にまとめています。

読者想定と前提知識

対象は、サーバ運用やWeb公開を担当する方、あるいはリバースプロキシ導入を検討しているエンジニアです。Linuxの基本操作、Webサーバの概念（HTTPやポート）、管理者権限での操作に慣れていることを前提にしています。専門用語は最小限にし、具体例で補足します。

本書の構成（概要）

第2章: リバースプロキシとSSLの基本概念—役割や通信の流れをやさしく解説します。
第3章: Apacheでのリバースプロキシ設定—実例と設定ファイルの書き方を示します。
第4章: Nginxでのリバースプロキシ設定—Nginx特有の注意点と設定例を紹介します。
章ごとに設定例と検証方法を示すので、手順に沿って進めれば実運用に役立ちます。

注意点とおすすめの進め方

まずテスト環境で設定を試してください。設定変更前に必ず設定ファイルのバックアップを取り、ログを確認しながら段階的に適用します。証明書は自動更新の仕組みを導入すると運用が楽になります。

以降の章では、具体的なコマンド例や設定ファイルを示して、実際に手を動かしながら学べるようにします。ご不明点があれば、章ごとに確認しながら進めてください。

リバースプロキシとSSLの基本概念

リバースプロキシとは

リバースプロキシは、外から来るWebのリクエストを受け取り、内部のサーバーに代わって応答を返す仕組みです。たとえば、https://example.com への接続を受け、内部のWebサーバー（例: 10.0.0.5）に転送します。利用者は内部構成を意識せずにサービスを使えます。

SSL終端（SSL/TLSの終端）とは

SSL終端はリバースプロキシ側で暗号化（SSL/TLS）を解除する構成です。外部の通信は暗号化されたままプロキシが受け取り、プロキシが復号して内部サーバーへはHTTPで送ります。たとえばプロキシが証明書を持ち、HTTPSで受けて内部は平文で通信します。

なぜ使うのか（利点）

証明書管理を一か所に集められます。複数サーバーで個別に管理する手間が減ります。
バックエンドの負荷を軽くできます。暗号処理をプロキシが代行するためです。
ファイアウォールやアクセス制御をプロキシに集中できます。ネットワーク設計が簡単になります。

注意点（考慮すべき点）

内部通信が暗号化されない場合、内部ネットワークの保護が必要です。重要な場合はプロキシとバックエンド間もTLSにするか、専用ネットワークを使います。
元のクライアントIPを残すにはヘッダー（例: X-Forwarded-For）を正しく扱う必要があります。
設定ミスでセッション切れや証明書の更新忘れが発生しやすいので運用を整えます。

動作の流れ（簡単な例）

クライアントがHTTPSで接続します。
リバースプロキシが受けてSSLを復号します。
プロキシが内部のサーバーにHTTPでリクエストを転送します。
サーバーの応答をプロキシが受け、再びHTTPSでクライアントに返します。

この章では基本の概念をわかりやすく説明しました。次章で具体的な設定例を扱います。

Apacheでのリバースプロキシ設定

前提

Apacheでリバースプロキシを使うには、proxy、proxy_http、sslモジュールを有効にし、SSL証明書を用意します。ここではUbuntu系を想定した例で説明します。

モジュールの有効化

例: a2enmod proxy proxy_http ssl
コマンドでモジュールを有効にし、設定を反映するためにApacheを再起動します。

SSL証明書の入手

Let’s Encrypt（certbot）などで証明書を取得し、/etc/letsencrypt/live/your.example.com/fullchain.pem と privkey.pem を配置します。

バーチャルホストの設定例

以下はHTTPSで受け、内部のバックエンドに転送する基本例です。

<VirtualHost *:443>
  ServerName www.example.com
  SSLEngine on
  SSLCertificateFile /etc/letsencrypt/live/www.example.com/fullchain.pem
  SSLCertificateKeyFile /etc/letsencrypt/live/www.example.com/privkey.pem

  ProxyPreserveHost On
  ProxyPass / http://127.0.0.1:8080/
  ProxyPassReverse / http://127.0.0.1:8080/

  # 必要に応じてアクセス制限やヘッダ編集を追加
</VirtualHost>

ProxyPreserveHostを有効にすると、バックエンドに元のHostヘッダが渡ります。Redirectを使ってHTTPからHTTPSへ転送することも一般的です。

複数バックエンド（負荷分散）

Balancerを使うと複数のバックエンドに振り分けられます。

<Proxy "balancer://mycluster">
  BalancerMember http://192.168.0.10:8080
  BalancerMember http://192.168.0.11:8080
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/

セキュリティ強化

強力な暗号スイートを設定し、TLSバージョンを制限します。例: SSLCipherSuiteやSSLProtocolを設定して古い暗号を無効にします。

設定確認と再起動

設定ファイルはapachectl configtestで確認し、問題なければsystemctl restart apache2で再起動します。運用中はログやアクセスを確認して動作を確かめてください。

Nginxでのリバースプロキシ設定

概要

Nginxではnginx.confにSSL設定を書き、Let’s Encryptで取得した証明書を使います。証明書は90日で失効するため自動更新を準備します。ここでは代表的な設定例と運用上の注意点をやさしく説明します。

SSL設定（nginx.confの例）

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

server {
  listen 443 ssl;
  server_name example.com;
  ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

  location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
}

証明書の自動更新

certbot renewコマンドを定期実行します。cronの例：

0 3 * * * /usr/bin/certbot renew --quiet && systemctl reload nginx

systemdタイマーを使う場合はcertbot.timerを有効化します。自動更新後はNginxをリロードして新証明書を反映してください。

バックエンドAPIへのリバースプロキシ

API向けにはパスごとにproxy_passを分けます。タイムアウトやヘッダー設定を明示すると安定します。WebSocketがある場合はUpgradeヘッダーを追加します。

location /api/ {
  proxy_pass http://backend:8080/;
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_connect_timeout 10s;
  proxy_read_timeout 60s;
}

運用ではログと証明書の期限を定期確認してください。問題があればまずNginxのエラーログを確認すると原因を特定しやすいです。