301リダイレクトを設定した後、サイトが開かない場合の対処方法

301リダイレクトを設定した後にサイトが開かなくなった場合は、まずリクエストがどの段階で止まっているかを確認します。旧URLが応答しないのか、複数のアドレス間でリダイレクトを繰り返しているのか、それとも新しいURLに移動した後、新サイトでエラーが発生しているのかを切り分けてください。検索でよく見かける「301エラー」は、301自体に障害があることを意味するわけではありません。301は恒久的なリダイレクトを示すもので、調査すべきなのはリダイレクトルール、転送先アドレス、アクセス経路です。

まずリダイレクト経路全体を記録してから、該当する設定を変更してください。ドメインのDNS設定、証明書、リライトルールを同時に変更すると、障害の原因を特定しにくくなります。

リクエストがどこで止まっているかを確認する

ブラウザーの開発者ツールを開き、「ネットワーク」パネルで「ログを保持」を有効にしてから、問題の完全なURLに再度アクセスします。ステータスコードと、次の転送先アドレスを示すレスポンスヘッダーのLocationを重点的に確認してください。

• リダイレクトが多すぎるというメッセージが表示される場合：2つのアドレス間で相互にリダイレクトしていないか、同じアドレスに繰り返し戻っていないかを確認します。
• リダイレクト後に404または5xxが表示される場合：リクエストは転送先に到達しています。ページパス、アプリケーションサービス、またはゲートウェイを確認します。
• 証明書エラー、ドメインを解決できない、または接続がタイムアウトすると表示される場合：まず証明書、DNS、またはネットワークの問題に対処します。リクエストがまだ301ルールに到達していない可能性があります。

コマンドライン環境がある場合は、curl -I https://old.example.com/pathでレスポンスヘッダーを確認し、続けてcurl -IL --max-redirs 10 https://old.example.com/pathで連続するリダイレクトを確認できます。サイトによってHEADリクエストの処理が異なるため、結果に疑問がある場合は、ブラウザーでの実際のGETリクエストを基準にするか、curl -sS -D - -o /dev/null URLで確認してください。

ループが発生した場合は、まずプロトコル、ドメイン、プロキシの設定を確認する

よくあるループとして、HTTPからHTTPSに転送された後、再びHTTPに戻されるケースや、www付きドメインとwwwなしドメインが相互に転送し合うケースがあります。たとえば、サーバーがexample.comをwww.example.comに転送し、サイト構築管理画面では後者を前者に戻す設定になっていると、ブラウザーはページに到達できません。

まず正規のアクセス先を1つに決め、CDN、ロードバランサー、サーバー、サイト構築管理画面で同じ転送先が設定されているか確認します。複数の階層でルールを連携させることはできますが、それぞれが異なるドメインやプロトコルを指定してはいけません。

リバースプロキシを導入している場合は、オリジンサーバーが訪問者の使用プロトコルをどのように判定しているかも確認します。訪問者はHTTPSでCDNにアクセスしている一方、CDNはHTTPでオリジンサーバーに接続している場合があります。オリジンサーバーが自身の接続だけを参照していると、HTTPSへの転送を繰り返し要求し、ループが発生する可能性があります。

この場合は、オリジンへの接続プロトコルと、アプリケーションが信頼できるプロキシから伝達されたプロトコル情報（X-Forwarded-Protoなど）を正しく認識しているかを確認してください。このリクエストヘッダーを任意の送信元からの値として信頼せず、信頼できるプロキシの範囲を限定してください。

ルール同士が相互に転送していなくても、適用範囲と実行順序を確認する

変更前に既存の設定をバックアップし、サーバーのリライトルール、コントロールパネルのリダイレクト、プログラムのプラグイン、CDNルールを1つずつ確認します。特に次の3種類の問題を探してください。

• 転送先にも元のルールが適用される：すべてのリクエストを特定のアドレスに転送する一方で、転送先アドレス自体を対象外にしていない。
• ワイルドカードや正規表現の範囲が広すぎる：トップページへのリダイレクトルールが、商品ページ、管理画面、API、静的リソースまで誤って対象にしている。
• パスの連結ミス：ディレクトリの重複、スラッシュの処理の不一致、キャプチャグループの参照ミスなどにより、存在しないページに転送される。

あるルールを一時的に無効にしてアクセスが復旧しても、そのルール、または他のルールとの組み合わせに問題があることが分かったにすぎません。必要なドメイン正規化設定をそのまま削除せず、引き続き適用条件を確認してください。Apacheではルールの順序と継承関係に注意し、Nginxではserver、location、rewrite間のマッチング関係も確認します。変更後は設定構文をチェックしてから再読み込みしてください。

転送先URLが開かない場合は、DNS、証明書、ページのマッピングを確認する

Locationに記載された完全なアドレスに直接アクセスします。転送先も開かない場合は、旧サイトの301を何度も変更するのではなく、転送先サイトを引き続き調査してください。

ドメイン移行時は、新ドメインのA、AAAA、またはCNAMEレコードが想定したサービスを指しているか確認します。IPv4とIPv6を同時に設定している場合、一方が利用できないと、一部のネットワークでは正常に動作し、別のネットワークでは失敗することがあります。

HTTPSでは、旧ドメインがTLSハンドシェイクを完了して初めて、ブラウザーは旧ドメインから返される301を受け取ることができます。そのため、旧ドメインをリダイレクト専用で使う場合でも、有効でドメインに一致する証明書が必要です。www付きとwwwなしの両方の入口を確認してください。転送先サイトの証明書が正常でも、旧ドメインの証明書の代わりにはなりません。

トップページは正常でも、商品ページや多言語ページで404が発生する場合は、新旧パスのマッピングを確認します。301はブラウザーを新しいアドレスに移動させるだけで、ページを自動作成するものではありません。海外向けサイトを移行する際は、旧商品ページ、カテゴリーページ、言語別ページを対応するコンテンツに優先的にマッピングし、すべてをトップページに転送することは避けてください。

サーバーを修正してもブラウザーで失敗する場合は？

301はブラウザーやCDNにキャッシュされることがあります。コマンドラインでは正しい結果が返るのに、普段使っているブラウザーが旧転送先に移動する場合は、新しいブラウザープロファイルや別の端末で再テストし、該当ドメインのキャッシュを消去してください。開発者ツールでキャッシュを無効にする場合は、ツールを開いたままにしてください。

CDNが古いリダイレクトレスポンスを返し続けることもあるため、影響を受けているURLのキャッシュを消去する必要があります。ブラウザーがHTTPを自動的にHTTPSへアップグレードする場合は、HSTSが関係している可能性もあります。実際のネットワークリクエストを確認して判断し、すべてを301のキャッシュとみなさないでください。

調整中は、適切な状況で一時的なリダイレクトを使って転送先とパスを検証し、安定を確認してから301に変更できます。すでに設定されている恒久的なリダイレクトのキャッシュは、別途対処が必要です。

アクセス復旧後、業務上の入口が利用できるか確認する

HTTPとHTTPS、www付きとwwwなし、トップページ、商品詳細ページ、言語別ディレクトリを最低限再テストし、広告のランディングページや検索結果にある旧リンクからもアクセスします。最終ページが正常に読み込まれ、余分な中継を避けた直接的なリダイレクト経路になっていることを確認してください。

問い合わせフォーム、ショッピングカート、決済コールバックが関係する場合は、送信プロセスを個別に検証してください。一部のクライアントでは、301によってPOSTがGETに変わることがあります。このようなAPIに一般的なページ転送ルールをそのまま適用するのは適切ではありません。リクエストメソッドを維持する必要がある場合は、アプリケーションのロジックを踏まえて307または308を検討してください。

広告パラメーターが保持されるか、サイト内リンクとサイトマップが更新されているかも確認します。サイト構築プラットフォームを利用している場合は、障害URL、リダイレクトチェーン、発生時刻、最近の設定変更をサービス提供元に伝えると、プラットフォーム、CDN、サーバーのどの階層を修正すべきかを迅速に特定できます。