【実務・中級編】HTTPステータスコード3xx(Redirection)の挙動と無限ループ対策 – HTTPプロトコル・通信規格実践ガイド

リダイレクトの深淵：3xx系ステータスコードと「無限ループ」の悪夢を制御せよ

Webエンジニアであれば、一度は「リダイレクト地獄」に陥った経験があるはずだ。ブラウザが「このページはリダイレクトが多すぎます」と悲鳴を上げ、ユーザーが離脱していく——。あの冷や汗が出る瞬間を、我々は技術的にどう制御し、防ぐべきなのか。

今日は、HTTP/1.1の標準仕様をベースに、リダイレクトの挙動と、現場で遭遇する無限ループの罠について、ネットワークの「流儀」を交えて解説しよう。

—

1. 3xx系リダイレクトの「微妙な」使い分け

リダイレクトの役割は、リソースの所在をクライアントに教えることだ。しかし、この「教え方」によって、後のSEOやキャッシュの挙動、そして何よりシステムの安定性が大きく変わる。

301 Moved Permanently（恒久的な移動）: 「もうここにはない、次からはこっちへ行け」という宣言。ブラウザはこれをキャッシュする。SEOの評価も転送されるため、ドメイン変更時などはこれを使う。
302 Found（一時的な移動）: 「今はこっちにいるけど、次はまた元の場所に来るかもしれない」というニュアンス。キャッシュは推奨されない。
307 Temporary Redirect: 302の「メソッド変更するなよ」版。HTTP仕様では、302はPOSTをGETに変えて再送する実装が蔓延したが、307は「元のメソッドとボディを維持したまま移動せよ」と厳格に規定されている。

実務の教訓: API設計において、POSTリクエストを伴うエンドポイントを移動させるなら、迷わず307を使うべきだ。302で適当に返すと、クライアント側でボディが欠落し、整合性が取れなくなる事故が多発する。

—

2. なぜ「無限ループ」は起きるのか？

ブラウザやHTTPクライアントは、リダイレクトを自動追跡する機能を持っている。しかし、無制限に追跡すれば、A→B→A…と巡回する無限ループによって、リソースを枯渇させるDoS攻撃に近い状態になる。

そのため、主要なクライアントは「リダイレクト回数の上限」を持っている。

Chrome/Firefox等: 一般的に20回前後。
cURL: デフォルトでは追跡しない（`-L`オプションが必要）。
Python (requests): デフォルトで30回。

トラブルシューティングの現場から

運用中のプロキシサーバーやロードバランサーの設定ミスで、`http`→`https`へのリダイレクトが循環し、ログが埋め尽くされるケースは後を絶たない。デバッグの際は、まず「どこでループしているか」を可視化すること。

curlでリダイレクトの経路を追跡する（-vでヘッダーを確認するのが鉄則）
curl -IvL http://example.com/api/v1/resource

このコマンドを打てば、`Location`ヘッダーの値がどう推移しているか、どの段階でループが始まっているかが一目瞭然だ。

—

3. コードレベルでの制御：無限ループを回避する実装

APIクライアントを実装する際、ライブラリのデフォルトに依存するのは危険だ。特にマイクロサービス間通信では、リダイレクト回数を明示的に制御するべきである。

Python `requests` での制御例

import requests

リダイレクト回数を制限し、無限ループを物理的に遮断する
try:
response = requests.get(
“https://api.example.com/data”,
allow_redirects=True,
max_redirects=3 # 3回以上のリダイレクトは例外を投げる
)
response.raise_for_status()
except requests.exceptions.TooManyRedirects:
# ここでアラートを上げるか、ログを記録する
print(“警告: リダイレクトループが発生しました。”)

Fetch API (JavaScript) での挙動

実は、ブラウザ標準のFetch APIには、リダイレクト回数を制限する直接的な引数は存在しない。ブラウザの仕様に依存する。そのため、「そもそもリダイレクトが発生しないように設計する」のが最も重要だ。

—

4. インフラ側で防ぐためのTips

アプリケーションコードで対処するのも大切だが、インフラ側の設定でループを断ち切るのが、シニアエンジニアの流儀だ。

Nginxでのリダイレクト設定例:

無限ループを防ぐための典型的な防衛策
server {
listen 80;
server_name example.com;

# 1. そもそもリダイレクト先と一致していないか確認
# 2. 意図しないリダイレクトループを検知したらログを出して破棄
return 301 https://$host$request_uri;
}

トラブルシューティング時に必ず確認すべきは、「リダイレクトの多段化」だ。
A→B→Cとリダイレクトが3つ以上連なっている場合、それは設計の敗北と言っていい。クライアントのオーバーヘッドを増やし、レイテンシを悪化させるだけだ。

—

まとめ：ネットワークエンジニアとしての心構え

リダイレクトは便利な機能だが、魔法ではない。
1. ステータスコードの意図を汲み取れ（301/302/307の使い分け）。
2. 追跡ログを読み解け（`curl -Iv` が最強の武器）。
3. 回数制限を実装レベルで意識せよ（デフォルトを信じるな）。

ネットワークの通信経路に「曖昧さ」を残さないことが、システムを堅牢にする唯一の道だ。今日から、君の書くコードのレスポンスヘッダーに少しだけ注意を払ってみてほしい。そこには、パケットたちが語る「正しい経路」が必ず記されているはずだ。