こんにちは、AIシステムズです。
この記事は、代表コバが現場で対応してきたnginx運用の知見をもとに、AIを活用して構成・執筆し、弊社にて最終チェックを行ったものです。
「ブラウザでサイトを開くと ERR_TOO_MANY_REDIRECTS が出てページが表示されない」——nginxの設定変更直後やSSL証明書の導入時に発生する典型的なトラブルです。302リダイレクトループは、HTTPSリダイレクトの判定条件が常に成立してしまうことが原因であることがほとんどです。
- リダイレクトループが起きる仕組み
- ロードバランサ・CDN配下での落とし穴
- WordPressの
siteurlとリダイレクトの関係 - nginxとアプリ側の二重リダイレクト
- 切り分けに使えるcurlコマンド
目次
- リダイレクトループが起きる仕組み
- 原因を切り分けるcurlコマンド
- 典型パターンと修正方法
- WordPressサイトでよくある事例
- こういうサイトに向いている／向いていない
- 再発防止チェックリスト
リダイレクトループが起きる仕組み
HTTPSリダイレクトの典型的な設定はこうなっています。
server {
listen 80;
return 302 https://$host$request_uri;
}「HTTPで来たらHTTPSに飛ばす」という意図ですが、ロードバランサやCDNがHTTPS終端をしている場合、nginxから見るとリクエストは常にHTTPになります。すると、HTTPSに飛ばす → ロードバランサがHTTPSを終端 → nginxへはHTTPで届く → またHTTPSに飛ばす…と無限ループになります。
原因を切り分けるcurlコマンド
ブラウザのキャッシュやCookieに惑わされず、リダイレクトの連鎖を観察するにはcurlが確実です。
curl -I -L https://example.com-L でリダイレクトを追跡し、-I でヘッダーのみ表示します。同じLocationが繰り返し出ていれば、それがループしている箇所です。
curl -I -L -H "X-Forwarded-Proto: https" http://example.comこのようにヘッダーを付け足して、ロードバランサがいる状況を再現できます。ヘッダーを付けるとループが止まるなら、原因はnginx側でX-Forwarded-Protoを見ていないことです。
典型パターンと修正方法
1. ロードバランサ配下の正しいHTTPSリダイレクト
server {
listen 80;
server_name example.com;
if ($http_x_forwarded_proto != "https") {
return 302 https://$host$request_uri;
}
}ロードバランサが X-Forwarded-Proto: https を付けてくる前提です。AWS ALB、Cloudflare、さくらのクラウドロードバランサなど、ほとんどのサービスで標準的にこのヘッダーを付与します。
2. www有無の統一とHTTPSの両方を扱う
server {
listen 80;
listen 443 ssl;
server_name www.example.com;
return 301 https://example.com$request_uri;
}
server {
listen 80;
server_name example.com;
if ($http_x_forwarded_proto != "https") {
return 301 https://example.com$request_uri;
}
root /var/www/html;
}www有無とhttp/httpsの組み合わせは4パターンになります。4パターンすべてが「最終形」にたどり着くようルールを設計しないと、組み合わせによってはループします。
WordPressサイトでよくある事例
nginxの設定は正しいのに、ループが止まらないケースの大半はWordPress側の設定が原因です。
wp_optionsのsiteurlとhomeがhttp://のままで、WordPressがHTTPSへリダイレクトをかけ続けているwp-config.phpでFORCE_SSL_ADMINが有効だが、$_SERVER['HTTPS']がロードバランサ配下で空のままで判定が失敗- セキュリティ系プラグインの「HTTPS強制リダイレクト」設定とnginxのリダイレクトが二重に走っている
WordPress側で X-Forwarded-Proto を認識させるには、wp-config.php に次を追加します。
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}こういうサイトに向いている／向いていない
このトラブル対応は、nginxを使った中小企業のWordPressサイトや業務システム、特にAWS・GCP・各種クラウドのロードバランサ配下で稼働するサイトに直接関係します。Apache単体のシンプルな構成では発生頻度が低いです。
再発防止チェックリスト
- ロードバランサ・CDNを介する場合は
X-Forwarded-Protoで判定しているか - www有無・http/httpsの4パターンが循環せず最終形に収束するか
- WordPressの
siteurl/homeがHTTPSになっているか - セキュリティプラグインとサーバー側のリダイレクトが二重になっていないか
- 設定変更時はcurlでループを確認してから本番反映しているか
まとめ
nginxの302リダイレクトループは、ロードバランサ配下でHTTPS判定を誤っていることが圧倒的に多い原因です。curlでリダイレクト連鎖を観察し、X-Forwarded-Proto を見るように直すのが定石です。WordPressサイトでは、サーバー側だけでなくWordPress側の設定も合わせて見る必要があります。
本記事は、代表コバが中小企業のnginx・WordPress運用の現場で対応してきた知見をもとに、AIを活用して構成・執筆し、弊社にて最終確認を行っています。サーバー構成見直し、SSL対応、リダイレクト設計について、具体的な状況をふまえた相談を承っています。費用感だけ知りたい方も、お気軽にご相談ください。
