2026/06/22(月)nginxで設定をモジュール化して再利用する

投稿日：

PHP-FPMとかの設定がvhostに散らばってて一元化したかったけど/etc/nginx/nginx.confにlocationディレクティブを書くと構造上エラーになるため、再利用可能なモジュールと切り出し各vhostの設定から呼び出して解決したログ。

確認環境

  • nginx/1.26.1

やり方の一例

PHP-FPMを設定する例

  1. /etc/nginx/snippetsに適当な名前で.confを作る
    • 例：/etc/nginx/snippets/php-fpm.conf
  2. 作ったファイルに設定を書く 
    location ~ ^.+\.php$ {
  fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
  fastcgi_index index.php;
  include fastcgi_params;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  fastcgi_param HTTPS on;
  fastcgi_param SERVER_PORT 443;
}

  3. 読み込みたいvhostの.confから参照する

    server {
  listen [::]:443 ssl;
  server_name hoge.example.com;

  # ワイルドカード証明の設定も外出ししておくと共通化できて便利
  include snippets/cert.conf;

  client_max_body_size 100M;

  root /var/www/hoge;
  index index.php;

  location / {
    index index.php;
    try_files $uri $uri/ =404;
  }

  include snippets/php-fpm.conf;

}
コメント（0件）

2026/06/10(水)今日のサーバー整備の話と、サイト改築を始めた話。

投稿日：

今日のサーバー整備

nginxの共通設定にgzipの設定を入れて転送量を削減した。

この設定を入れただけ。

    gzip on;
    gzip_types
        text/plain
        text/css
        text/javascript
        text/xml
        application/javascript
        application/json
        application/xml
        application/rss+xml
        application/atom+xml
        application/font-woff
        application/octet-stream
        image/gif
        image/png
        image/jpeg
        image/gif
        image/webp
        image/svg+xml;

nginxとApacheのリバースプロキシについて色々確かめた。

nginxからApacheにリバースプロキシしてる時、nginxを前段のTLS終端、Apacheを後段にしているときにApacheの中でリダイレクトが走るとhttpsが壊れることがある現象を確認した。

これはディレクトリに対しhttps://example.com/hogeのようにアクセスするとhttp://example.com/hoge/に301リダイレクトがかかるのだが、どうもこの時にスキーマが引き継がれずHTTPになってしまうようだ。初めからhttp://example.com/hoge/としてアクセスすれば問題ない。

またこの現象が起きると証明書があるのにエラー表示になることも確認しているが、サブ機やスマホでは起きないようにも見えるので、この端末の証明書が何かしら変になっている可能性がある。キャッシュクリアしてもhttp降格が起きると再発するので、原因はよくわかっていない。GPT-5.5に聞いたもののハルシネーションしか得られず、ググってもnginx→Apacheの情報はほとんど得られなかった。多分ニッチな構成なのだろう。

さくらのレンタルサーバーもnginxからApacheに繋いでいるので、これをどうやっているかが知れれば改善の手掛かりになりそうだが、知る術がないので何ともだ。まさか聞くわけにもいかないし…。

そういえばさくらのレンタルサーバーではSNI SSL[1]が使われていると聞くので、これを使えば上手くいくのかもしれない。

SSL/TLS接続のはじめに、クライアントはSSL/TLSのサーバから（サーバとCAの）証明書を受け取り、証明書の改ざんされていないことなどを確認する。サーバ証明書にはホスト名が書かれており、それが今接続しようとしているホスト名と一致することをクライアントは確認する。そうでない場合、なりすましや中間者攻撃の恐れがあるため、クライアントはユーザに警告をする。ユーザの責任で証明書を信用し、警告を迂回することができるアプリケーションも存在する。

というかWikipediaに上記の記述があったので、これのせいかもしれない。問題が起きているドメインはlycolia.infoで、元々さくら側で証明書を設定していたのでHTTPに落ちたときにその証明書が引っかかってエラーになっているとかはあるのかも？

さくらのドメインであるsakura.ne.jpを踏むとhttpでもhttpsに転送されるのと、ひょっとしたら類似の現象が起きているのかも…？いや、わからないが…。

サイト構成の変更をし始めた

このサイトの構成がイケてないなという思いが強くなったのでやることにした。

まずlycolia.infoが単なるLPに成り下がっていることが勿体なかったので、このドメインの傘下にコンテンツを増やすことにした。

一つ目はtool.lycolia.infoのドメインを廃止して、lycolia.info/tool/にぶら下げた。これはそもそもドメインを分割してやるようなサイトではなかったし、コンテンツの一部でいいと思ったからだ。

二つ目はこのブログにあったリンク集をlycolia.info/link/にぶら下げた。そもそも、本質的にサイトトップではない、このブログにリンク集があることに長らく違和感があったので丁度よかった。また移設に伴い紹介コメントも多少変更しているほか、元々のリンクが間違っていたなどもあったので、そのあたりも修正している。

そして今後は自己紹介などもブログから剝がして移動したいと思っている。ただ今のところすべてサーバー内からのHTML手打ちで、厳しさを感じるので、将来的にはCMSにしたいとも思った。

少なくとも今今は自宅サーバーである以上、家の中にいれば直にファイルをいじれるので問題はない。出先で書き換えたくなった時に困るくらいだ（一応頑張れば出先からもいじれなくはないが…）

サイト構成の変遷

本日リアルタイムでサイトを書き換えていて本番Hot Module Replacementみたいなことになっていた風景の一部を残しておく。

これが元々の状態。

改築途中の状態、なんか色々アレなことに…。

そして一旦本日の作業が終わった状態。また明日以降ちょいちょい直していくと思う。

移設したリンク集

移設前 移設後

見た目的には大きく変わり映えしないどころか、まともにスタイルを当ててないので殺風景だが、その辺りは追々どうにかしていこうと思う。

これでも一応レスポンシブデザイン、しかもモバイルファーストで作っているのでスマホで見たときの見やすさは向上している。

何せフルスクラッチでHTMLを手書きして、置換ではなく手作業で移設を行ったので移設するだけで時間が溶けてしまったので、今日はこんなところといった感じだ。

  1. Server Name Indication SSL ↩
コメント（0件）

2026/02/26(木)nginxからApache2へセキュアにリバプロしたときに真のクライアントIPを取得できるようにする

更新日：
投稿日：

nginxからApache2のバーチャルホストにいい感じにリバプロする方法の続きで、nginxからApache2にリバースプロキシされた時にクライアントのIPを拾う設定の方法について。

確認環境

Env Ver
OS Ubuntu 24.04.3 LTS
nginx 1.26.1
Apache2 2.4.58

やりたいこと

Apache2で動いているCGIのREMOTE_ADDRからクライアントIPを取れるようにする。

nginxからApache2のバーチャルホストにいい感じにリバプロする方法ではApache2側でREMOTE_ADDRを取得しようとするとnginxのIPになってしまうため、これを回避する方法。

前提条件

  1. nginxからApache2へのリバースプロキシをする時に、真のクライアントIPをX-Real-IPヘッダーに入れていること。 
    proxy_set_header X-Real-IP $remote_addr;
  2. nginxとApacheが動いているマシンが同じ
  3. IPv6を使っている

やること

# remoteipモジュールの有効化
sudo a2enmod remoteip
# ::1からのHTTPリクエストを信頼しX-Real-IPをREMOTE_ADDRとして解釈する
cat <<'EOF' | sudo tee /etc/apache2/conf-available/remoteip.conf
RemoteIPHeader X-Real-IP
RemoteIPInternalProxy 127.0.0.1
RemoteIPInternalProxy ::1
EOF
# 設定の有効化
sudo a2enconf remoteip
# 設定の反映
sudo systemctl restart apache2

意味合いの解説

sudo a2enmod remoteip

remoteipモジュールの有効化をしている。

逆はa2dismodで無効化出来るっぽい。

RemoteIPHeader <header-field>

ここで指定したHTTPヘッダーをクライアントのIPアドレス(useragent IP address)として扱うようにする。

例えばRemoteIPHeader X-Forwarded-ForとすればX-Forwarded-ForをクライアントIPとして扱える。

この設定だけだと問答無用で信頼してしまうため、本来と異なる経路で攻撃を受けた時に偽装されたヘッダをクライアントIPとして解釈するリスクがある。そのため、次項の設定も行う。

参考：mod_remoteip - Apache HTTP Server Version 2.4

RemoteIPInternalProxy <proxy-ip|proxy-ip/subnet|hostname ...>

RemoteIPHeader単品では前段のnginxを無視してApache2へ直にアクセスされたときに偽のX-Real-IPなどが来ていると、偽のIPが取れてしまうので、これを回避する仕組み。

RemoteIPInternalProxy ::1のように指定することで、そのIPから来たRemoteIPHeaderを信頼する。異なるIPからリクエストが来た場合は、RemoteIPHeaderを無視して、そのクライアントのIPが設定される。

RemoteIPTrustedProxyでも同じことができるのだが、違いはよくわかっていない。一応内部用と外部用で分かれているらしいが、RemoteIPTrustedProxy ::1でも期待通り機能したので謎。

公式ドキュメントではIPv4アドレスが指定されているので、恐らくIPv4でも行けると思うが確認していない。

参考：mod_remoteip - Apache HTTP Server Version 2.4

sudo a2enconf remoteip

作成した設定の有効化を行う。これを行っていない場合、設定は反映されない。

やっていることは/etc/apache2/conf-available/にある設定ファイルのシンボリックリンクを/etc/apache2/conf-enabled/に張っているだけだと思われる。

標準では/etc/apache2/apache2.confでIncludeOptional conf-enabled/*.confを指定しているため、これで設定が読み込まれるようになる。

逆はa2disconfで無効化できる。

あとがき

ここまで書いたところで/etc/apache2/sites-available/と/etc/apache2/sites-enabled/の違いに気が付いた。これも多分有効無効を切り替えるもので、sites-enabled側に設定を直書きするのは誤っているのだろう、きっと。

コメント（0件）