2026年7月18日

サーバーのHTTPSリダイレクト設定まとめ（Apache・Nginx・CDN・WordPress）

VPS・クラウド

HTTP でのアクセスを HTTPS へ転送する設定は、サーバーの種類と「どこで HTTPS を終端しているか」によって書き方が変わります。この記事では、Apache（.htaccess と VirtualHost）、Nginx、ロードバランサーや CDN の後ろにあるサーバー、WordPress 側の設定をまとめ、リダイレクトループを起こさずに301で一回転送するための考え方と確認方法を説明します。

設定前に決めておくこと

証明書が先、リダイレクトは後

リダイレクトを入れる前に、https:// でサイトが正しく表示されることを確認します。証明書が無い・期限切れの状態で転送を有効にすると、訪問者全員に警告画面が出てしまいます。

どのステータスコードを使うか

恒久的な移転なので、基本は301（Moved Permanently）を使います。検索エンジンは301を「URL が移った」という強いシグナルとして扱います。308（Permanent Redirect）はリクエストのメソッドを変えずに転送する点が301と異なり、フォームの POST を転送したい API などで使われます。302や307は一時的な転送なので、HTTPS 化には向きません。

正規の URL を一つに決める

http://example.com、http://www.example.com、https://www.example.com のどれでアクセスされても、最終的に一つの URL（例：https://example.com）へ一回で届くようにします。HTTP→HTTPS と www の有無の統一を別々のルールで書くと、http://www → https://www → https:// のように2回転送されることがあります。動作はしますが、表示までの時間が延びるため一回にまとめるのが望ましい形です。

Apache の設定

VirtualHost で書く（サーバーの設定を触れる場合）

VPS などで Apache の設定ファイルを編集できるなら、80番ポートの VirtualHost で転送するのがシンプルです。.htaccess はリクエストのたびに読み込まれるため、設定ファイルで済むならそちらが効率的です。

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    Redirect permanent / https://example.com/
</VirtualHost>

Redirect はパス以下を引き継いで転送するので、http://example.com/about/ は https://example.com/about/ に移ります。

.htaccess で書く（レンタルサーバーなど）

設定ファイルを触れない環境では、.htaccess に mod_rewrite のルールを書きます。WordPress のサイトでは、既存の # BEGIN WordPress ブロックより上に書いてください。WordPress のブロック内は、パーマリンク設定の保存時に書き換えられることがあるためです。

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]

この例では、HTTP でのアクセスと www 付きのアクセスの両方を、www なしの HTTPS へ一回で転送します。編集前に元の .htaccess をコピーしておき、500エラーが出たらすぐ戻せるようにしておきます。

Nginx の設定

Nginx では、80番ポートの server ブロックで return 301 を使います。rewrite で正規表現を書くより、処理が単純で読みやすくなります。

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

www 付きの HTTPS も統一する場合は、443番ポートに www 用の server ブロックを別に作り、同じく return 301 で転送します。その際、www 側にも有効な証明書が必要です。設定を変えたら sudo nginx -t で構文を確認してから sudo systemctl reload nginx で反映します。

Let's Encrypt の証明書更新に HTTP-01 認証を使っている場合でも、Let's Encrypt の検証は HTTPS への転送をたどるため、/.well-known/acme-challenge/ へのリクエストが転送されても通常は問題になりません。ただし転送先が別のサーバーで、そこに検証用ファイルが無い構成などでは失敗するので、certbot renew --dry-run で更新を試しておくと安心です。

ロードバランサー・CDN の後ろにある場合

クラウドのロードバランサーや CDN で HTTPS を終端し、サーバーには HTTP で転送している構成では、サーバーから見るとすべてのアクセスが HTTP です。この状態で上の %{HTTPS} off のようなルールを書くと、HTTPS でアクセスしても「HTTP だから転送する」と判定され、リダイレクトループになります。

この場合は、次のどちらかで対応します。

ロードバランサーや CDN 側でリダイレクトする：多くのサービスに HTTP→HTTPS の転送設定があります。サーバー側の設定が不要になるので、まずこちらを検討します。
プロキシが付けるヘッダーで判定する：多くのプロキシは元の通信方式を X-Forwarded-Proto ヘッダーで伝えます。

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

CDN の SSL 設定で「CDN とサーバーの間は HTTP」となるモード（Cloudflare の Flexible など）を使いながら、サーバー側でも HTTPS へ転送すると、ループの典型的な原因になります。サーバーにも証明書を入れて、CDN とサーバーの間も HTTPS で通信するモードに切り替えるのが根本的な対処です。各サービスの設定項目の名前は変わることがあるため、公式ドキュメントで確認してください。

WordPress 側の設定

サーバーで転送を設定しても、WordPress の「WordPress アドレス（URL）」と「サイトアドレス（URL）」が http:// のままだと、内部リンクや画像の URL が HTTP で出力されます。設定画面で両方を https:// に変更します。WordPress のバージョンによっては、サイトヘルス画面に HTTPS への切り替えを案内する項目が表示されます。

プロキシの後ろにある WordPress では、WordPress 自身が HTTPS を認識できずにループすることがあります。その場合は wp-config.php の /* That's all, stop editing! */ より上に次を追加し、ヘッダーをもとに HTTPS と判定させます。

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
    $_SERVER['HTTPS'] = 'on';
}

このヘッダーは誰でも付けられるため、サーバーに直接アクセスできない構成（プロキシ経由だけを受け付ける）で使うことが前提です。管理画面だけを HTTPS に固定したい場合は、define( 'FORCE_SSL_ADMIN', true ); という定数も使えます。

転送を設定したあとに、ページの一部が HTTP で読み込まれて警告が出る場合は、記事本文やテーマに http:// の URL が残っています。これは混在コンテンツと呼ばれる別の問題で、データベース内の URL の置換などで対処します。

設定後の確認方法

ブラウザはリダイレクトをキャッシュするため、表示だけで判断すると古い結果を見てしまうことがあります。curl で応答を直接確認すると、キャッシュの影響を受けずに判断できます。

# 転送先とステータスコードを確認
curl -I http://example.com/about/
curl -I http://www.example.com/about/

# 最終到達先までの転送回数を表示
curl -sIL -o /dev/null -w '%{num_redirects} %{url_effective}\n' http://www.example.com/

1行目と2行目で 301 と正しい Location が返り、3行目の転送回数が1になっていれば想定どおりです。パスやクエリ文字列（?p=123 など）が転送後も保たれているかも確認します。

HTTPS への転送が安定したら、ブラウザに HTTPS だけを使わせる HSTS の導入を検討できます。ただし HSTS は一度有効にすると取り消しに時間がかかるため、短い max-age から試してください。プリロードリストの登録条件は hstspreload.org に掲載されており、変わることもあるため最新の内容を確認します（2026年10月現在）。

まとめ

証明書を入れて HTTPS の表示を確認してから、301でリダイレクトを設定する。
HTTP→HTTPS と www の統一は、一回の転送で正規 URL に届くようにまとめる。
Apache は VirtualHost か .htaccess、Nginx は return 301 が基本。
CDN やロードバランサーで HTTPS を終端する構成では、X-Forwarded-Proto で判定するか、手前でリダイレクトしてループを防ぐ。
WordPress の URL 設定も https:// にそろえ、curl -I で転送回数とステータスを確認する。