HTTP 301 Moved Permanently：意味とは

このエラーの意味と見分け方

• ブラウザー、API クライアント、監視サービス、HTTP チェッカーなどで 301 Moved Permanently が報告される。
• ブラウザーがリダイレクトを自動的に追従したり、別の URL を表示したり、リダイレクト先が元の URL に戻ることでリダイレクトループを示したりする。
• レスポンスに、リダイレクト先を含む Location ヘッダーが含まれることがある。
• 1 つの URL、ホスト名、HTTP メソッド、認証状態、ユーザーエージェント、ネットワーク経路でのみ発生することがある。
• エンドポイントが HTTP レスポンスを返しているため、DNS は正常に解決され、TLS も正常に完了する場合がある。
• API クライアントや自動化ツールは、リダイレクト設定によっては 301 で停止し、リダイレクト先へ進まないことがある。

可能性の高い順の主な原因

1. 意図的な URL の正規化： サイトが別のホスト名、パス、末尾スラッシュの有無、その他の URL の形式を、優先するアドレスへリダイレクトしている。
2. プロトコルまたはホスト名の移行： HTTP トラフィックを HTTPS へリダイレクトしている、または古いホスト名を移行先のホスト名へ転送している。
3. アプリケーションまたはフレームワークのルーティング： パスの変更、ログイン状態の変更、リソースの移動後に、アプリケーションがルートをリダイレクトしている。
4. Web サーバー、リバースプロキシ、CDN のルール： インフラストラクチャの設定が、リクエストをアプリケーションへ到達させる前にリダイレクトを適用している。
5. キャッシュされたリダイレクト： 設定変更が反映される間、ブラウザー、中間キャッシュ、CDN が以前にキャッシュしたリダイレクトを返し続けている。
6. メソッド固有の挙動： ブラウザーのナビゲーションには適切なリダイレクトルールが、API リクエストやリクエストのセマンティクスを維持する必要があるメソッドには適さないことがある。
7. 予期しないルールまたは競合するルール： 複数のレイヤーが異なる宛先へリダイレクトし、チェーンやループを作っている。

修正方法

サイトを訪問している場合

1. ホスト名、パス、プロトコルを含め、正確なアドレスを確認します。宛先が見慣れたもので、想定どおりの場合にのみリダイレクトに従ってください。
2. 宛先でアカウントが必要な場合は、サイトの通常のインターフェースからサインインして再試行します。見慣れないリダイレクト先のドメインに認証情報を入力しないでください。
3. ブラウザーが目的のページに到達するなら、301 は設計どおりに機能している可能性があります。ループする、誤ったホストに到達する、存在しないページで終わる場合は、元の URL と宛先を記録します。
4. API または自動化クライアントでは、リダイレクトに従う設定になっているか、リダイレクト後の URL が同じリクエストメソッドと認証コンテキストで有効かを確認します。
5. 元の URL、宛先、おおよその時刻、クライアントの種類、確認されたステータスをサイト所有者に報告します。パスワード、Cookie、API シークレットは共有しないでください。

サイトを所有または管理している場合

1. 正確なリクエストを再現します。HTTP メソッド、完全な URL、ホスト、プロトコル、該当する場合は認証状態、最終ステータス、各リダイレクト先を記録します。
2. レスポンスヘッダーを確認します。特に Location、キャッシュ関連ヘッダー、認証関連ヘッダー、プロキシやサーバーレイヤーを識別できるヘッダーを確認してください。
3. 301 を生成したコンポーネントを特定します。アプリケーション、Web サーバー、リバースプロキシ、CDN、WAF のどれかを確認し、リクエスト時刻と、利用可能ならリクエスト ID を使って該当するログを調べます。
4. 実際の挙動を意図したルーティング設計と比較します。ホスト名の変更、HTTP から HTTPS へのポリシー、正規パス、移動したリソース、アプリケーションフローのどれを処理するリダイレクトなのか確認します。
5. リダイレクトチェーン、ループ、競合するルール、誤った宛先がないか確認します。最近のデプロイと、ルーティング、認証、キャッシュ、プロキシ、CDN の設定変更を確認してください。
6. レスポンスを生成したレイヤーに対して、権限のある最小限の修正を行います。1 つのルートまたは条件が誤っている場合に、権限、セキュリティ、リダイレクトルールを広範囲に変更することは避けてください。
7. 適切なクライアントから同じ URL とメソッドで再テストします。その後、宛先、重要な関連ルート、認証済みと未認証の該当ケースをテストします。
8. キャッシュされたリダイレクトが疑われる場合は、承認済みのキャッシュ無効化手順に従い、その変更による運用上の影響を考慮してから実施します。

予防と修正確認

• 意図的なリダイレクトについて、旧 URL、宛先、影響を受けるメソッド、担当者を含めて定義・文書化します。
• Web サーバー、アプリケーション、リバースプロキシ、CDN、WAF のルールは、対応している場合はバージョン管理します。
• リリース後に、正規 URL、HTTP から HTTPS への挙動、ホスト名の変更、重要な API メソッド、認証が必要なルートをテストします。
• すべての 301 を障害として扱うのではなく、ルートやデプロイごとにリダイレクト率、チェーン、ループを監視します。
• 予期しないリダイレクトを照合できる期間、リクエストログとインフラストラクチャログを保持します。
• リダイレクトルールを変更する際は、古いレスポンスが修正結果を隠さないよう、キャッシュの挙動を確認します。

よくある質問