301と302の「迷い」を断つ：リダイレクトの正体とインフラエンジニアの流儀
インフラの現場で最も頻繁に、そして最も適当に扱われがちな設定の一つが「HTTPリダイレクト」だ。
「とりあえず301か302を返しておけばブラウザが勝手に飛んでくれるだろ？」
そう思っているなら、一度立ち止まってほしい。リダイレクトは単なるURLの転送ではない。クライアント、サーバー、そして検索エンジンのクローラーという「三者」の間で交わされる、極めて繊細な「契約」なのだ。今回は、HTTP/1.1の仕様を紐解きながら、なぜ今さらこの古臭いステータスコードにこだわる必要があるのか、現場の視点から解説する。
—
301 (Moved Permanently) と 302 (Found) の本質的な差
RFC 7231における定義はシンプルだ。しかし、その背後にある「意図」を理解していないと、後で恐ろしい技術的負債を抱えることになる。
- 301 Moved Permanently: 「そのリソースは永久に移動した。二度と元の場所にはアクセスするな」という宣言。
- 302 Found: 「今はこっちにいるが、元の場所も生きている。次はまた元の場所にアクセスしてくれ」という一時的な案内。
なぜこの「一時的か恒久か」が重要なのか
最大の理由は、ブラウザと検索エンジンの「キャッシュ」の挙動にある。
301を受け取ったブラウザやクローラーは、「あ、もうここのURLは用済みなんだな」と判断し、ブラウザは即座にブラウザキャッシュを更新し、検索エンジンはインデックスのURLを新しい方へ書き換える（SEOパワーの移譲）。
逆に302を安易に使うと、検索エンジンは「元のURL」をインデックスし続け、新しいURLへの権限移譲（Link Juiceの引き継ぎ）が行われない。インフラ運用において、ドメイン移管やSSL/TLSへの完全移行といった「恒久的な変更」に302を使ってしまうと、いつまで経っても検索エンジンが古いURLを離さず、トラフィックが分散し続けるという悲劇を招く。
—
現場で役立つ検証コマンドとフロー
「口頭で説明するより、パケットを見ろ」というのが我がチームの教育方針だ。curlを使って、サーバーが何を語っているかを確認しよう。
1. 301リダイレクトの確認
-Iでヘッダーのみを取得、-Lは追跡しない（リダイレクトをその場で止める）
curl -I -L http://example.com/old-path
出力の着眼点: `HTTP/1.1 301 Moved Permanently` と `Location: https://example.com/new-path` があるかを確認する。ここを見れば、サーバーが何を意図しているか一目瞭然だ。
2. Python (Requests) での挙動確認
開発中にリダイレクト先をプログラムで制御したい場合は、以下のように記述する。
import requests
allow_redirects=Falseにすることで、30xの挙動を直接キャッチできる
response = requests.get(‘http://example.com/old-path’, allow_redirects=False)
if response.status_code == 301:
print(f”恒久的な移動を検知: {response.headers[‘Location’]} へ変更を推奨”)
elif response.status_code == 302:
print(f”一時的な移動: {response.headers[‘Location’]} へ一時的に転送”)
—
Webサーバー設定の勘所（Nginxの例）
実務では、アプリケーションコードでリダイレクトを書くのは推奨しない。可能な限りWebサーバーのレイヤーで処理すべきだ。アプリケーションまでリクエストを到達させるのは、インフラとしてあまりに非効率だからだ。
Nginx設定ファイル例
server {
listen 80;
server_name old-site.com;
# 恒久的な移転：SEOを考慮し、検索エンジンに新しいURLを教える
location / {
return 301 https://new-site.com$request_uri;
}
}
server {
listen 80;
server_name maintenance.example.com;
# 一時的な移転：メンテナンス中など、元のURLを維持したい場合
location / {
return 302 https://status.example.com/maintenance;
}
}
—
トラブルシューティングのTips：現場の「地雷」
最後に、私がこれまで現場で見てきた「リダイレクトの罠」を共有する。
1. リダイレクトループ: `301` を設定した結果、移動先が元のURLを指していて、ブラウザが「ERR_TOO_MANY_REDIRECTS」を吐くパターン。これは設定変更後に必ず `curl` で確認すれば防げる。
2. POSTメソッドのリダイレクト: 302は歴史的な経緯で、リダイレクト時にPOSTがGETに変換されることがある（ブラウザ実装依存）。意図せずデータを失う可能性があるため、POSTを維持したリダイレクトが必要なら `307 Temporary Redirect` を検討すべきだ。
3. SEO情報の消失: ドメインを変える際、301を適切に設定しなかった結果、旧ドメインのSEO評価がリセットされ、検索順位が急落するケース。これは「技術」以前の「ビジネス」の損失だ。
結論
リダイレクトは、ただの「転送命令」ではない。それはユーザーと検索エンジンに対する「誠実な宣言」だ。
「恒久的な変更には301」「一時的な変更には302」。この使い分けを徹底するだけで、あなたの構築するWebインフラの信頼性は格段に向上する。教科書を暗記するのではなく、その裏にあるクライアントの挙動を常に想像してほしい。ネットワークエンジニアとしての真価は、パケットの先にある「ユーザー体験」をどれだけ守り抜けるかにあるのだから。
コメント