Lycolog

nginxからApache2のバーチャルホストにいい感じにリバプロする方法

投稿日：2025/10/17ミドルウェア::HTTPD::nginxミドルウェア::HTTPD::Apache2ネットワーク::HTTP

nginxでhttps://example.comを受けて、https非対応のApache2にリバプロし、Apache2側でもhttps://example.comでアクセスされているように振舞わせる方法。取り敢えず最低限こんだけあると無難だろうという内容。

Apache2（後段）の設定

/etc/apache2/ports.conf

80や443を開けるとnginxと衝突するため、適当にずらしておく。

Listen 8080

/etc/apache2/sites-enabled/001-example.conf

ServerNameは外側と同じものにする。

<VirtualHost *:8080>
        ServerName example.com

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html

        ErrorLog ${APACHE_LOG_DIR}/example-error.log
        CustomLog ${APACHE_LOG_DIR}/example-access.log combined
</VirtualHost>

nginx（前段）の設定

/etc/nginx/nginx.conf

httpセクションにupstream apacheを追記することで、conf.d/配下の設定ファイルから共通的に参照できるようにする。同じことを複数の設定ファイルに書くと構文エラーで起動しなくなる。

user  nginx;
worker_processes  auto;

error_log  /var/log/nginx/error.log notice;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    keepalive_timeout  65;

    upstream apache {
      server [::1]:8080;
    }

    include /etc/nginx/conf.d/*.conf;
}

/etc/nginx/conf.d/example.conf

ここでは/etc/nginx/nginx.confで設定したupstreamにプロキシする設定を作っている。

proxy_set_header Host $host;はnginxが受けたホストヘッダをそのままApacheに飛ばすことで、Apache側がバーチャルホストでルーティングできるようにしている。Apacheとnginxで別々のホスト名にすることもできるが、そうした場合、Apache側はApache側で定義したホスト名で動作するため、CGIなどのスクリプトを動かすときに支障があるうえ、Apache側のホスト名をhostsに書かないと疎通できないこともあり、手間なので基本的に前段のドメインに合わせておくのが無難だ。

proxy_set_header X-Real-IP $remote_addr;はnginxにアクセスしてきたクライアントのIPをApacheに渡すための設定。そのままだとnginxのIPが渡ってしまう。

proxy_set_header X-Forwarded-Proto $scheme;もホストヘッダの転送と似ていて、nginxが受けたプロトコルスキーマをApacheに飛ばすための設定。こうしておくとApache側はhttpで受けているのに、httpsでアクセスされたものとして認識させることが出来るため、プロトコルスキーマ付きでURLを生成するCGIがいるときに都合がいい。単にスキーマを誤魔化しているだけなので実際は暗号化されていない。

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;

  access_log   /var/log/nginx/example.access.log;
  error_log    /var/log/nginx/example.error.log;

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

余談：HTTP通信に用いられるHOSTヘッダーについて

HTTP通信で利用されるドメインは単にHOSTヘッダーにドメインを書いているだけなので、以下のようなことをするとhostsを書かなくとも疎通できる。

curl -H "HOST: lycolia.info" http://"[2403:3a00:101:13:133:167:8:98]"

これは一般的なHTTPクライアントの仕組みとして、まずドメインをDNSに問い合わせ、IPを取得したのち、ドメインをホストヘッダーに載せてIPアドレス宛にHTTP要求を出しているからだと思われる。

hostsの書き換えができない環境で、任意のドメインに対してHTTP要求を出したい時にも重宝するので、覚えておくと何かと役に立つ。

コメント（0件）