2026年6月5日

サブサブドメインをリダイレクトする方法：DNS・証明書・Webサーバー設定の順に確認

ドメイン管理

old.blog.example.com のような2階層目のサブドメイン（サブサブドメイン）を別のURLへ転送するには、DNSで名前を解決させ、その名前を含むSSL証明書を用意し、Webサーバーで301リダイレクトを返す、の3段階がそろっている必要があります。特に見落とされやすいのが証明書で、*.example.com のワイルドカード証明書はサブサブドメインを対象にしていません。この記事では、3段階それぞれの設定と、nginx・Apache・CDNでの書き方、動作確認の方法を説明します。

リダイレクトが動くまでの流れ

ブラウザが https://old.blog.example.com/page を開くと、次の順に処理が進みます。

DNSで old.blog.example.com のIPアドレスを調べる
そのサーバーとTLS接続し、証明書が old.blog.example.com に有効かを検証する
HTTPリクエストを送り、サーバーが301と転送先URLを返す

リダイレクトは3番目の段階で初めて返されます。つまり、1か2で失敗するとリダイレクト設定がどれだけ正しくても転送されません。「設定したのに転送されない」ときは、この順に切り分けるのが近道です。

手順1：DNSでサブサブドメインを解決させる

まず、転送元の名前が今どう解決されるかを確認します。

dig old.blog.example.com A +short

何も返らない場合はレコードを追加します。個別に登録するなら old.blog.example.com のA（またはCNAME）レコードを、blog.example.com 配下をまとめて扱うなら *.blog.example.com のワイルドカードレコードを作り、リダイレクトを返すサーバーへ向けます。

DNSのワイルドカードは階層の扱いが少し独特です。*.example.com は、途中の blog.example.com という名前がDNSに存在しない場合に限り、old.blog.example.com にも応答します。blog.example.com のレコードが既にあるなら、その配下には *.example.com は効きません。意図しない挙動を避けるため、サブサブドメインは個別レコードか *.blog.example.com で明示的に設定するほうが分かりやすくなります。

手順2：サブサブドメインを含む証明書を用意する

TLSのワイルドカード証明書は1階層だけが対象です。*.example.com の証明書は blog.example.com には有効ですが、old.blog.example.com には有効ではありません。この状態で転送元にアクセスすると、リダイレクトが返る前にブラウザが証明書エラーを表示します。

対応方法は次のいずれかです。

転送元のホスト名を証明書のSAN（対象ホスト名）に個別に加える
*.blog.example.com のワイルドカード証明書を別途取得する（Let's Encrypt では DNS-01 認証が必要）

個別に加える場合、Certbot なら次のように取得できます。HTTP-01 認証を使うため、手順1でDNSがこのサーバーに向いていること、80番ポートが開いていることが前提です。

sudo certbot certonly --nginx -d old.blog.example.com

HTTPからの転送だけで済むと思われがちですが、旧URLが検索結果やブックマークに https:// で残っている場合は、証明書がないとそこからの訪問者は転送されません。

手順3：Webサーバーで301を返す

nginx の場合

転送元専用の server ブロックを作り、return 301 で転送します。$request_uri を付けるとパスとクエリ文字列が引き継がれます。

server {
    listen 80;
    listen 443 ssl;
    server_name old.blog.example.com;

    ssl_certificate     /etc/letsencrypt/live/old.blog.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/old.blog.example.com/privkey.pem;

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

nginx は設定に書かれた証明書ファイルが存在しないと起動・再読み込みに失敗するため、443番の設定は手順2で証明書を取得してから追加します。

*.old.example.com 配下のサブドメインを、同じ名前のまま新ドメインへ移すような場合は、正規表現の server_name で名前を取り出せます。

server {
    listen 443 ssl;
    server_name ~^(?<sub>[a-z0-9-]+)\.old\.example\.com$;

    ssl_certificate     /etc/letsencrypt/live/old.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/old.example.com/privkey.pem;

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

この例の証明書は *.old.example.com を含んでいる必要があります。設定を変えたら sudo nginx -t で構文を確認してから sudo systemctl reload nginx で反映します。

Apache の場合

VirtualHost を分けられるなら、Redirect ディレクティブが簡潔です。

<VirtualHost *:443>
    ServerName old.blog.example.com
    SSLEngine on
    SSLCertificateFile    /etc/letsencrypt/live/old.blog.example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/old.blog.example.com/privkey.pem

    Redirect permanent / https://blog.example.com/
</VirtualHost>

レンタルサーバーなどで .htaccess しか使えない場合は、mod_rewrite でホスト名を条件にします。

RewriteEngine On
RewriteCond %{HTTP_HOST} ^old\.blog\.example\.com$ [NC]
RewriteRule ^(.*)$ https://blog.example.com/$1 [R=301,L]

.htaccess を編集する前は元のファイルを複製して残しておきます。記述ミスで500エラーになった場合でも、すぐに戻せます。レンタルサーバーでは、管理画面でサブサブドメインを追加できない、または無料SSLの対象外になることがあるため、提供元の仕様を確認してください。

CDNのリダイレクト機能を使う場合

Cloudflare などのCDNを使っているなら、CDN側のリダイレクト機能で転送することもできます。オリジンサーバーに設定を置かずに済みますが、CDNが発行する証明書がサブサブドメインを含むかはサービスやプランによって異なります（2026年10月現在）。設定画面の名称も変わることがあるため、利用中のサービスのドキュメントで確認してください。

301・302・308の使い分け

恒久的な移転なら301を使います。検索エンジンは301を、転送先を正規のURLとして扱うシグナルとして利用します。一時的なメンテナンスやキャンペーンなら302です。POSTリクエストのメソッドを維持したまま恒久転送したい場合（APIのエンドポイント移転など）は308が向いています。

301はブラウザにキャッシュされやすく、誤った転送先を設定すると修正後も利用者のブラウザに古い転送が残ることがあります。最初は302で動作を確かめ、問題がなければ301に切り替える進め方も検討してください。

動作確認とよくある失敗

curl でヘッダーだけを確認すると、ブラウザのキャッシュに惑わされずに済みます。

# 転送の連鎖をたどって表示
curl -sIL https://old.blog.example.com/some/page?x=1 | grep -iE '^(HTTP|location)'

HTTP/... 301 の次に location: https://blog.example.com/some/page?x=1 が表示され、最終的に200になれば成功です。

よくある失敗と確認先は次のとおりです。

証明書エラーが出る: 手順2を見直します。openssl s_client -connect old.blog.example.com:443 -servername old.blog.example.com で配信中の証明書のSANを確認します。
転送がループする: 転送先がWordPressの場合、サイトアドレス（siteurl / home）とリダイレクト設定が食い違っていないかを確認します。CDNとオリジンの間でHTTPとHTTPSを行き来しているケースもあります。
パスが引き継がれない: nginx なら $request_uri、.htaccess なら $1 の付け忘れがないかを確認します。
別のサイトが表示される: そのホスト名に一致する server_name / ServerName が無く、既定のサイトが応答しています。

まとめ

サブサブドメインのリダイレクトは、DNS → 証明書 → Webサーバーの順に成り立ちます。転送されないときもこの順に切り分けます。
*.example.com のワイルドカード証明書はサブサブドメインに有効ではありません。個別のSANか *.blog.example.com の証明書を用意します。
nginx は return 301、Apache は Redirect permanent か mod_rewrite で転送し、パスとクエリを引き継ぎます。
301はキャッシュされやすいため、302で確認してから切り替える方法もあります。設定ファイルは変更前に控えを取り、curl -sIL で結果を確かめます。