【Nginx】httpからhttpsとwwwありなしのリダイレクト設定方法

Nginxでウェブサイトを配信する際、同じドメインで「wwwあり/なし」や「http/https」が混在していると、ユーザーが混乱したりSEO評価が分散してしまいます。本記事では、Nginxのリダイレクト設定を用いてURLを一本化（正規化）するベストプラクティスを紹介します。

リダイレクトして正規化すべき３つの理由
rewriteとreturnどちらを使うべきか
具体的な設定例
- wwwありからwwwなしに統一
- wwwなしからwwwありに統一
推奨：全てのパターンを https://example.com に集約する
テストと本番環境適用
まとめ

リダイレクトして正規化すべき３つの理由

Googleなどの検索エンジンは、プロトコルやwwwの有無が異なるURLを、内容が同じでも「重複コンテンツ（別のサイト）」と認識してしまいます。例えば、以下の4つはすべて別物として扱われます。

http://example.com
http://www.example.com
https://example.com
https://www.example.com

これらを放置すると、以下のデメリットが生じます。

リンク評価（被リンク）の分散: 外部サイトからのリンクが各URLに分散し、ドメイン全体のSEO評価が上がりにくくなります。
インデックスの混乱: 検索結果に意図しないURLが表示されたり、評価が不安定になります。
セキュリティ警告: 現在のブラウザはHTTP接続に対して警告を表示します。これはユーザー体験を損なうだけでなく、SEOにも悪影響を与えます。

そのため、これらを1つの「正規URL」に統合する必要があります。

rewriteとreturnどちらを使うべきか

Nginxでリダイレクトを実現するには return と rewrite がありますが、単純なURLの転送であれば return を使うのがベストプラクティスです。

1. return ディレクティブ（推奨）

指定したステータスコードを即座に返します。正規表現の解析を行わないため、非常に高速でCPU負荷も低いです。

# 最もクリーンで高速な書き方
return 301 https://example.com$request_uri;

2. rewrite ディレクティブ

URLの一部を正規表現で書き換える際に使用します。

# 複雑なパスの変換が必要な場合に使用
rewrite ^/users/(.*)/profile$ /accounts/$1 permanent;

比較表

項目	return	rewrite
処理速度	非常に速い（推奨）	普通（正規表現解析が発生）
可読性	シンプルで明確	複雑になりがち
柔軟性	低い（URL全体の置換）	高い（複雑な文字列操作が可能）

具体的な設定例

1. wwwありからwwwなしに統一

https://example.com へ統一する場合の設定です。

# 1. リダイレクト用（wwwあり）
server {
    listen 80;
    listen 443 ssl;
    server_name www.example.com;

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

    return 301 https://example.com$request_uri;
}

# 2. メインコンテンツ（wwwなし）
server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

    location / {
        # サイトのメイン設定
    }
}

2. wwwなしからwwwありに統一

https://www.example.com へ統一する場合の設定です。

# 1. リダイレクト用（wwwなし）
server {
    listen 80;
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

    return 301 https://www.example.com$request_uri;
}

# 2. メインコンテンツ（wwwあり）
server {
    listen 443 ssl;
    server_name www.example.com;

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

    location / {
        # サイトのメイン設定
    }
}

【重要】SSL証明書の注意点

リダイレクト元（飛ばす側）が https の場合、そこでも有効なSSL証明書が必要です。www あり・なし両方をカバーする「SANs対応証明書」や「ワイルドカード証明書」を使用してください。証明書が正しくないと、リダイレクトされる前にブラウザで警告が表示されてしまいます。

推奨：全てのパターンを https://example.com に集約する

「httpの全アクセス」と「https://www」の両方を、一括で「https://なし」へ送る最も確実な設定です。

# 1. HTTPからHTTPSへの転送（ドメイン問わず）
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

# 2. HTTPSの wwwあり から wwwなし への転送
server {
    listen 443 ssl;
    server_name www.example.com;

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

    return 301 https://example.com$request_uri;
}

# 3. メイン：https://example.com
server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

    location / {
        # ...メインの設定
    }
}

このようにブロックを分離することで、設定の意図が明確になり、メンテナンス性も向上します。

テストと本番環境適用

本番環境に適用する前に、必ず開発環境やステージング環境でテストを行います。

Nginx設定の反映

設定を書き換えた後は、構文チェックをしてから再読み込みを行ってください。

sudo nginx -t
sudo systemctl reload nginx

curlコマンドによる動作確認

ブラウザのキャッシュに惑わされないよう、curl コマンドでヘッダーを確認します。

# Bash
# 1. リダイレクトの確認
curl --head http://www.example.com

# 出力例（Locationが正しいかチェック）
# HTTP/1.1 301 Moved Permanently
# Location: https://example.com/

# 2. 転送先が正常に開くか確認
curl --head https://example.com

# 出力例（200 OK になれば成功）
# HTTP/1.1 200 OK

本番適用のコツ

リダイレクト設定（301）はブラウザに強くキャッシュされます。設定ミスによる「無限ループ」などを防ぐため、最初は 302（一時的リダイレクト）で動作確認を行い、問題なければ 301（恒久的リダイレクト）に書き換える手法を推奨します。

まとめ

リダイレクトには、高速でシンプルな return 301 を使う。
serverブロックを分けることで、複雑な条件分岐（if文）を避け、ミスを防ぐ。
リダイレクト元のURLに対しても、適切なSSL証明書を適用する。

正しいURL正規化を行い、検索エンジンとユーザーの両方にフレンドリーなサイト構成を目指しましょう。