ALBのログに潜む「謎の数字」を読み解く ― 460と463エラーの正体
現場でインフラを運用していると、AWSのApplication Load Balancer（ALB）のアクセスログを見ながら頭を抱える瞬間があるはずです。正常系が並ぶ中に突如として現れる 460 や 463 といったステータスコード。公式ドキュメントには確かに記載されていますが、パケットレベルで何が起きているのかを理解していないと、根本的な解決策にはたどり着けません。
今回は、SREの現場で「おっ、またこいつか」と遭遇するこれら特殊なHTTPステータスコードに焦点を当て、その背景にあるネットワークの挙動を解剖します。
—
1. 460エラー：クライアントの「逃げ足」を捕まえる
460 エラーは、ALBがリクエストをバックエンドに転送しようとしている最中、あるいは転送待ちの瞬間に、クライアント側が接続を強制終了（TCP RST）させたときに発生します。
なぜこれが起きるのか？
典型的なシナリオは「タイムアウト待ちのイライラ」です。
1. クライアントがリクエストを送信。
2. ALBがそれを受け取り、バックエンド（Target Group）へ転送。
3. バックエンドの処理が遅延し、ALBがレスポンスを待つ。
4. 待たされすぎて、クライアントのブラウザやアプリが接続を諦めて切断。
このとき、ALBは「まだ処理中なのに、お前なんで消えたんだよ！」と判断し、自分自身で 460 を記録します。
調査と対策の勘所
まず疑うべきはバックエンドの処理時間です。CloudWatchの TargetResponseTime を確認してください。もしこれがスパイクしているなら、DBのロックや重い外部API呼び出しが原因です。
クライアント側の挙動を再現するPythonコード:
import requests
# 意図的に短めのタイムアウトを設定して、ALBからの応答を待たずに切断する実験
try:
# 0.1秒で強制切断する設定
response = requests.get("https://your-api.example.com/slow-endpoint", timeout=0.1)
except requests.exceptions.Timeout:
print("クライアントがタイムアウトにより接続を切断しました")このコードを実行し、ALBのアクセスログを確認すると、見事に 460 が記録されるはずです。
—
2. 463エラー：ヘッダーの「大渋滞」
463 は、ALBがリクエストを転送する際、X-Forwarded-For ヘッダーが長すぎて転送できないときに発生します。
なぜこれが起きるのか？
ALBはクライアントのIPアドレスを記録するために、X-Forwarded-For ヘッダーにIPを追加・更新してバックエンドへ渡します。しかし、プロキシやWAF、あるいは社内ネットワークの多段構成を経由しすぎると、ヘッダーの要素数（IPの数）が上限を超えてしまうのです。
AWSの仕様では、X-Forwarded-For ヘッダーの要素数が30を超えると、ALBは「これ以上はパースできん！」と匙を投げ、463 を返します。
トラブルシューティングの定石
もし 463 が頻発しているなら、構成図を広げて「どこでヘッダーが肥大化しているか」を追跡してください。
curlでヘッダーを過剰に付与してテストする例:
# ヘッダーをわざと多重に付与して463を誘発させる（概念コード）
curl -v -H "X-Forwarded-For: 1.1.1.1, 2.2.2.2, ..., 30.30.30.30" \
https://your-api.example.com/もしこれが自社アプリケーション内部からのリクエストで起きているなら、ロードバランサーの配置を整理するか、アプリケーション側でヘッダーをサニタイズ（不要な値を削除）する実装を検討する必要があります。
—
3. 現場のSREとして伝えたい「ログを読む作法」
これらのコードは、単なる「エラー」ではなく、「ネットワーク経路のどこかで何かが期待通りに動いていない」というシグナルです。
- 460が多発している場合: バックエンドのパフォーマンスチューニング（SQL改善、非同期処理への移行）が急務です。単にタイムアウト時間を延ばすだけでは、ユーザー体験は改善しません。
- 463が多発している場合: ネットワークトポロジーが複雑化しすぎています。アーキテクチャの単純化、あるいはクライアントIPを特定するための代替ヘッダー（
X-Forwarded-For以外の独自ヘッダー利用）を検討するタイミングかもしれません。
最後に：ログは嘘をつかない
トラブルシューティングにおいて、最も信頼できるのは常に「ALBのアクセスログ」です。460 や 463 は、一見すると不気味な数字ですが、実はシステムが「今の通信には無理があるぞ」と教えてくれている親切なアラートでもあります。
次にログで見かけたときは、慌てて「ALBの不具合」を疑うのではなく、「クライアントとの握手」と「ヘッダーの旅路」に思いを馳せてみてください。それが、優秀なSREへの第一歩です。
現場からは以上です。明日からの運用が少しでも楽になることを願っています。
コメント