迷い込んだパケットを救え！HTTPリダイレクト（3xx）の仕組みと無限ループの恐怖
こんにちは！ネットワークの世界へようこそ。今日は、インターネットという広大な都市で、郵便物（パケット）が「あっちだよ！」と案内される仕組み、HTTPステータスコード「3xx（リダイレクト）」についてお話しします。
Webサイトを見ていると、URLが変わっていないのに別のページへ飛ぶことってありますよね。あれは一体、裏側で何が起きているのでしょうか？
—
1. 郵便物に例える「リダイレクト」の世界
想像してみてください。あなたは大切な手紙をある住所に送りました。でも、その家はすでに引っ越していて、新しい住人が住んでいます。
1. 301 (Moved Permanently)： 「引っ越しました。新しい住所はあちらです（転居届済み）」
- 郵便局員（ブラウザ）は、新しい住所を記憶します。次はもう古い住所には行きません。
2. 302 (Found / Temporary Redirect)： 「今はここが工事中だから、一時的にあっちにいてね」
- 郵便局員は、その場しのぎで案内された場所に行きますが、次はまた元の住所を確認しに行きます。
HTTPの「3xx」は、まさにこの「宛先変更の案内」なんです。
なぜそんなことをするの？
Webサイトの引っ越し（HTTPS化やドメイン変更）や、短縮URLの展開など、理由はさまざま。でも、ここで一つ恐ろしい問題が浮上します。もし、Aさんが「Bへ行け」と言い、Bさんが「いや、Aへ戻れ」と言ったらどうなるでしょう？
—
2. 終わらない悪夢「リダイレクトループ」
これがエンジニアを絶望させる「リダイレクトループ」です。
ブラウザは親切に案内を追いかけますが、A→B→A→B…と繰り返されると、ブラウザはついに力尽き、こう告げます。
> 「このページはリダイレクトループしています（ERR_TOO_MANY_REDIRECTS）」
このエラー、ネットワークエンジニアにとっては「あぁ、またか…」という日常茶飯事のトラブルです。
無限ループを防ぐには？
実は、最近のブラウザは非常に賢いです。一定回数（一般的に20回程度）リダイレクトが続くと、「これはおかしい！」と判断して通信を遮断してくれます。でも、開発者としてはそんなエラーが出る前に防ぎたいですよね。
対策：ログとツールで「今どこにいるか」を見る
トラブルに遭遇したら、まずは「curl」コマンドを使って、パケットの旅路を追跡しましょう。
-I: ヘッダー情報だけを表示する
-L: リダイレクトを自動で追いかける（追跡結果を確認したい時に便利！）
curl -I -L http://example.com/start-page
実行結果には「Location: …」というヘッダーが出てきます。
これが「次にどこへ行け」と指示されているかです。
—
3. 301, 302, 307…どれを使えばいいの？
似たような番号がたくさんあって混乱しますよね。一歩ずつ整理していきましょう。
- 301 (永久的な引越し)： SEO（検索エンジンの評価）を引き継ぎたい時に使います。ブラウザや検索エンジンが「もう前には戻らない」と学習します。
- 302 (一時的な引越し)： メンテナンス中やキャンペーン期間中など、「あとで元に戻すかも」という時に使います。
- 307 (一時的な引越し・厳格版)： 302と似ていますが、「送った内容（フォームのデータなど）を絶対に改変せずに次の場所に渡せ」という強い命令です。
—
4. 現場で役立つチェックポイント
もしあなたがWebサーバーの設定ファイルをいじっていて、リダイレクトを設定するなら、以下の点に気をつけてください。
1. HTTPSへの強制リダイレクト： 全ての通信を暗号化するためにリダイレクトさせる時は、必ず「ループしていないか」確認しましょう。
- `http://site.com` → `https://site.com` に飛ばす設定を入れる際、`https`側で「`http`へ戻る」設定を書いていないか要チェックです！
2. 設定ファイルのコメントアウトを活用： 設定を変更する際は、必ず元の状態をコメントアウトで残しておきましょう。
Nginxの例：httpをhttpsに強制リダイレクトする
server {
listen 80;
server_name example.com;
# ループ防止のため、Locationが自分自身でないか確認しましょう
return 301 https://example.com$request_uri;
}
—
まとめ：ネットワークは「対話」である
リダイレクトは、サーバーとブラウザ間の「あっちだよ」「ありがとう」という丁寧な対話から成り立っています。この対話が噛み合わない時に起きるのが無限ループです。
もし次にブラウザで「ERR_TOO_MANY_REDIRECTS」に出会ったら、焦らずに「パケットは今、どこからどこへ案内されているのかな？」と深呼吸してログを確認してみてください。
ネットワークのトラブルシューティングは、まるで迷路を解くパズルのようなもの。一歩ずつ、パケットの足跡を辿っていけば、必ず答えにたどり着けますよ！
次回は、このリダイレクトの先にある「キャッシュの仕組み」についてお話しします。お楽しみに！
コメント