リファレンス

HTTPステータスコードリファレンス

HTTPレスポンスのステータスコードを、番号、フレーズ、分類、出典、ライフサイクル、実際のトラブルシューティング文脈から調べられます。標準RFCのステータスコード、よく使われるWebDAV拡張、CDNやプロキシ固有のコードを扱い、REST API、ブラウザリクエスト、SEOのクロール問題、リダイレクト、認証失敗、レート制限、ゲートウェイエラー、上流タイムアウトを調査するときに重要になる違いまで確認できます。

  • ステータスコード、フレーズ、分類、関連コード、ベンダー名、デバッグ用キーワードで検索できます。
  • 1xx、2xx、3xx、4xx、5xxの意味の違いを、ページを移動せずに比較できます。
  • API設計、ブラウザデバッグ、CDN障害、サーバー側トラブルシューティングに役立つ実践的な確認ポイントを読めます。

1xx 情報レスポンス

最終レスポンスの前に送られる暫定レスポンスです。通常はHTTPクライアント、サーバー、プロキシ、ブラウザのネットワーク層が処理します。

100

Continue(継続)

サーバーがリクエストヘッダーを受信し、クライアントはリクエストボディの送信を続行できます。

1xx 情報レスポンス 標準 非推奨 RFC 9110
詳細

100 Continue(継続)は、サーバーがリクエストの先頭部分(リクエストラインやヘッダーなど)を受信し、現時点で拒否する理由がないことを示す暫定レスポンスです。リクエスト全体が成功したことを意味するものではありません。主な用途は、クライアントが大きなボディ(ファイルアップロードや大量データ)を送る前に、サーバーが受け入れ可能かどうかを確認するためです。特にExpect: 100-continueヘッダーと組み合わせて使われ、クライアントはまずヘッダーのみを送り、サーバーが認証・権限・Content-Type・Content-Length・リソース制限などを早期チェックした後、続行許可が出たらボディを送信します。最終的な成否は後続のステータスコードで判断されます。

よくある状況
  • クライアントが大きなファイルやフォーム、バルクJSONなどをアップロードする際、サーバーが受け入れる準備があるか事前に確認したい。
  • Expect: 100-continueヘッダーを付与し、まずヘッダーのみ送信して100 Continueを待ってからボディを送る。
  • サーバー側で認証・認可・Content-Type・Content-Length・経路・リソース制限などを本体受信前に評価したい。
  • リバースプロキシやロードバランサー、ゲートウェイ、オリジンサーバーが1xxレスポンスを正しく中継する必要がある。
  • ボディ送信前にリクエストが拒否される場合に無駄な帯域消費を避けたい。
確認すること
  • 100 Continue受信後は、ファイル内容やフォームデータ、JSONなどのリクエストボディ送信を続行してください。
  • 100 Continueは最終結果ではありません。必ず後続の200, 201, 204, 400, 401, 403, 413, 415, 417などの最終レスポンスを待ってください。
  • 100 Continueの後でリクエストが停止している場合、クライアントが本当にボディ送信を開始しているか確認してください。
  • クライアントが100 Continueを受信できない場合は、サーバーやプロキシ、ロードバランサー、ゲートウェイがExpect: 100-continueを正しくサポート・中継しているか確認してください。
  • サーバー側で既にリクエストを拒否することが分かっている場合は、100 Continueではなく401, 403, 413, 415, 417などの最終エラーコードを返してください。
使わないほうがよい場面
  • 通常のREST APIやJSON APIのビジネスロジックから100 Continueを手動で返さないでください。多くの場合、HTTPサーバーやフレームワーク、プロキシが自動処理します。
  • 100 Continueを成功レスポンスとして扱わないでください。
  • すでにリクエストボディを全て受信・処理した後で100 Continueを返さないでください。
  • 非同期タスク開始の意味で100 Continueを使わないでください(202 Acceptedを使います)。
出典: RFC 9110 関連コード: 101, 102, 103, 200, 202, 204, 413, 417
101

Switching Protocols(プロトコル切り替え)

サーバーがクライアントの要求したプロトコルへの切り替えに同意したことを示します。

1xx 情報レスポンス 標準 非推奨 RFC 9110
詳細

101 Switching Protocols(プロトコル切り替え)は、Upgradeヘッダーなどでクライアントがプロトコルのアップグレードを要求し、サーバーがその接続を別のプロトコルへ切り替えることに同意した暫定レスポンスです。通常のビジネスデータ返却の成功レスポンスではなく、プロトコルハンドシェイクの一部として使われます。101が返された後は、同じ接続上の後続のバイト列がUpgradeレスポンスヘッダーで指定されたプロトコルで解釈されます。代表例はWebSocketハンドシェイクで、HTTPリクエストに対しUpgrade/Connection/Sec-WebSocket系ヘッダーを検証し、101を返して以降は双方向WebSocket通信に切り替わります。

よくある状況
  • クライアントがUpgradeヘッダーで現在のHTTP接続を別プロトコルへアップグレード要求する。
  • WebSocket接続の確立時にサーバーがWebSocketハンドシェイクを受け入れる。
  • HTTPリクエスト・レスポンス型から同一接続で別プロトコルへ切り替える必要がある。
  • リバースプロキシやAPIゲートウェイ、ロードバランサーがWebSocketなどのUpgrade/Connectionヘッダーを正しく維持・中継する必要がある。
  • サーバー側が以降の通信をアップグレード後のプロトコルで扱うことを明示したい。
確認すること
  • 101受信後は、通常のHTTPレスポンスボディとして接続を解釈せず、Upgradeヘッダーで指定されたプロトコルに切り替えてください。
  • WebSocketハンドシェイク失敗時は、Upgrade: websocket, Connection: Upgrade, Sec-WebSocket-Key, Sec-WebSocket-Version, TLS, 経路設定などを確認してください。
  • サーバーが101を返さない場合、そのパスやポートでプロトコルアップグレードが有効か確認してください。
  • NginxやCDN、ゲートウェイ、ロードバランサー経由で接続失敗する場合、中間層が長寿命なアップグレード接続を許可しているか確認してください。
  • ブラウザでWebSocket handshake failedが出た場合、実際に返されたステータスコード(400, 401, 403, 404, 426, 500等)を調査してください。
使わないほうがよい場面
  • 実際にプロトコル切り替えを行わないREST APIやJSON APIエンドポイントから101を返さないでください。
  • 101を汎用的な成功レスポンスとして使わないでください。
  • クライアントからUpgradeリクエストがない場合に101を返さないでください。
  • 単にアップグレードを推奨したい場合は101ではなく426 Upgrade Requiredを検討してください。
出典: RFC 9110 関連コード: 100, 200, 204, 400, 426
102

Processing(処理中)

サーバーがリクエスト全体を受信済みで、まだ処理中であることを示します。

1xx 情報レスポンス 非推奨 非推奨 RFC 2518
詳細

102 Processing(処理中)は、サーバーがリクエスト全体を受信し、まだ最終レスポンスを返せない状態であることを示す暫定レスポンスです。もともとWebDAVで、複数リソースの操作など長時間かかる処理のために導入されました。クライアントにリクエストが失われていない、サーバーはまだ作業中と伝えるためのものです。最終的な成功を示すものではありません。RFC 2518で定義されましたが、後のWebDAV仕様からは削除され、現在では一般的なWebサービスで意図的に返すことはほとんどありません。

よくある状況
  • WebDAVリクエストで長時間処理が想定され、サーバーが処理継続中であることを示したい。
  • 複数ファイル・ディレクトリ・コレクション・ロック・再帰操作などを含むリクエスト。
  • 長時間応答がない場合、クライアントやプロキシが接続を切断してしまう可能性がある。
  • 古いWebDAVクライアントやサーバー実装が102 Processingを期待・送信する場合。
確認すること
  • 102を受信した場合は、成功や失敗とみなさず最終レスポンスを待ち続けてください。
  • 102のまま長時間進まない場合、デッドロックやキュー詰まり、バックエンドタイムアウト、リソースロック待ちなどを確認してください。
  • 長時間処理でクライアントやプロキシがタイムアウトする場合は、リードタイムアウトやゲートウェイタイムアウト、バッファリング、バックエンド処理時間を見直してください。
  • 現代のAPIで非同期処理を受け付ける場合は、202 Accepted+タスクIDやステータスURLの返却が推奨されます。
  • 最終結果が分かったら、200, 201, 204, 207, 400, 409, 423, 500, 507などの最終コードを返してください。
使わないほうがよい場面
  • 非同期ジョブ作成の意味で通常のREST APIに102を使わないでください(202 Acceptedを使います)。
  • 102を最終的な成功レスポンスとして扱わないでください。
  • 既に最終レスポンスを返せる状態で102を繰り返さないでください。
  • リクエストボディ送信継続の指示には102でなく100 Continueを使います。
出典: RFC 2518 関連コード: 100, 103, 200, 202, 207, 408, 409, 423, 504, 507
103

Early Hints(早期ヒント)

サーバーが最終レスポンス準備前にレスポンスヘッダーのヒントを送信します。

1xx 情報レスポンス 標準 非推奨 RFC 8297
詳細

103 Early Hints(早期ヒント)は、サーバーが最終レスポンス前に、最終レスポンスにも含まれる見込みのあるヘッダー(主にLinkヘッダー)を先に送信できる暫定レスポンスです。主な用途はパフォーマンス最適化であり、ビジネス的な成功や失敗を表すものではありません。HTML生成中やDB待ち、レンダリング待ち、上流呼び出し中でも、重要なCSS/JS/フォント/画像のLinkヘッダーを先に送ることで、ブラウザがpreconnect/preload/prefetchなどを早期に開始できます。103は最終レスポンスの代わりではなく、クライアントは必ず後続の最終ステータスを待つ必要があります。

よくある状況
  • サーバーがHTML生成中に、ページで必要となる重要なCSS/JS/フォント/画像リソースが既に分かっている。
  • 最終レスポンス前にLinkヘッダー(rel=preload/preconnect/dns-prefetch等)を送信したい。
  • LCPやTTFB~リソースロードのギャップ、初回描画速度などのパフォーマンス指標を改善したい。
  • CDNやエッジ、リバースプロキシ、アプリケーションサーバーがルート情報やテンプレートから重要リソースを推定できる。
  • 最終レスポンスがレンダリング・認証・DB・上流待ちだが、リソース依存関係は予測できる。
確認すること
  • 103を最終レスポンスとみなさず、必ず最終ステータス・最終ヘッダーを待ってください。
  • ブラウザは103のLinkヘッダーを利用できますが、最終的にそのリソースが使われるかは後続レスポンス次第です。
  • パフォーマンス効果がない場合は、Linkヘッダーの書式やrel/as/crossorigin/type属性を確認してください。
  • CDN、Nginx、リバースプロキシ、ゲートウェイ経由でEarly Hintsが消える場合、中間層が1xxレスポンスを破棄していないか確認してください。
  • 早期ヒントは本当に重要なリソースだけに絞り、不必要に多く送信しないでください。
使わないほうがよい場面
  • APIの成功レスポンスとして103を使わないでください。
  • REST/JSON APIで進捗通知等の用途に103を使わないでください。
  • 確度の低いリソースや大きなリソースをpreloadして帯域を浪費しないでください。
  • 認可前や機密リソースURLを早期に公開しないでください。
出典: RFC 8297 関連コード: 100, 102, 200, 204, 304, 404, 500
104

Upload Resumption Supported(アップロード再開対応)

サーバーが現在のアップロードが再開可能であることを示します。

1xx 情報レスポンス 一時的 非推奨 draft-ietf-httpbis-resumable-upload-05
詳細

104 Upload Resumption Supported(アップロード再開対応)は、アップロードリクエスト中に、そのリソースがHTTPアップロード再開(Resumable Upload)に対応していることをクライアントに通知する暫定レスポンスです。これはドラフト仕様に基づく一時的なコードで、安定したRFCではありません。アップロード成功を示すものではなく、ネットワーク切断やタブ閉じ、接続リセット、モバイル回線切替などでアップロードが中断しても、プロトコルに従い再開できることをクライアントに伝えます。

よくある状況
  • クライアントが大容量動画・アーカイブ・バックアップ等の長時間アップロードを行い、中断後の再開を希望する。
  • サーバーがHTTP Resumable Uploadドラフトに対応しており、早期に再開サポートを通知したい。
  • モバイル回線・不安定な通信・アプリのバックグラウンド化・ブラウザリロードなどで切断リスクが高い。
  • アップロードサービスがアップロードリソースURL・リカバリーURL・Upload-Offset・再開セッション状態等を管理する必要がある。
  • クライアント・サーバーの双方が明示的にドラフト仕様と1xxレスポンスをサポートしている。
確認すること
  • 104受信後にアップロード完了とみなさず、引き続きアップロードを継続し最終レスポンスを待ってください。
  • アップロードが中断された場合は、サーバーから確認できるUpload-Offsetから再開してください。
  • 再開に失敗する場合は、Upload-Offsetの取り扱いやContent-Length、アップロードリソースID、セッション有効期限、同時アップロード競合などを確認してください。
  • プロキシやCDN、ゲートウェイ、ロードバランサー経由で104が消える場合、中間層が1xxレスポンスを正しく中継しているか確認してください。
  • 通常のアップロードエンドポイントが再開非対応の場合は、201, 204またはエラー等の通常レスポンスを返してください。
使わないほうがよい場面
  • 104をアップロード成功レスポンスとして扱わないでください。
  • アップロード再開・オフセット検証・セッション永続化・リカバリー動作を実装していない場合は104を返さないでください。
  • 通常のJSON APIや単純なアップロードエンドポイントから104を返さないでください。
  • すべてのブラウザ・HTTPクライアント・プロキシ・CDN・フレームワークがこの一時的コードをサポートしているとは限らない点に注意してください。
出典: draft-ietf-httpbis-resumable-upload-05 関連コード: 100, 102, 201, 202, 204, 206, 308, 409, 413, 416

2xx 成功

成功を示すレスポンスです。完了した処理、作成されたリソース、受け付けられたジョブ、空のレスポンス、部分コンテンツをクライアントが区別できるよう、できるだけ正確な成功コードを使います。

200

OK(成功)

リクエストが成功し、メソッドに応じた意味のあるレスポンスが返されました。

2xx 成功 標準 推奨 RFC 9110
詳細

200 OK(成功)は、サーバーがリクエストを正常に処理し、メソッドに応じた適切なレスポンスを返したことを示します。プロトコルレベルの結果をステータスコードで表し、レスポンス本文には安定したアプリケーションエラーコードやフィールド別バリデーション詳細、trace ID、リトライ指示、ドキュメントリンクなどを含めるのが推奨されます。

よくある状況
  • GETでリソースを返す、POSTで処理結果を返す、正常なJSON API、通常のWebページなど。
  • APIやブラウザの成功レスポンスで、データ返却・リソース作成・作業受理・本文不要などの区別をクライアント側で判断する必要がある場面。
確認すること
  • まず、この状況が本当に200 OKの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • 新しいリソースを作成した場合は201 Createdを使ってください。
  • 非同期処理を受け付けただけの場合は202 Acceptedを使ってください。
使わないほうがよい場面
  • アプリケーションエラーを200でラップし、本文のフラグだけで失敗を示す設計は避けてください。
  • より適切な成功コードがある場合、全てを200で返さないでください。
  • 実際はエラーページなのに200で返す(soft error)は、ユーザーやクローラー、監視を混乱させます。
出典: RFC 9110 関連コード: 201, 202, 204, 206, 304, 400, 500
201

Created(作成済み)

リクエストが成功し、新しいリソースが作成されました。

2xx 成功 標準 推奨 RFC 9110
詳細

201 Created(作成済み)は、リクエストが正常に処理され、サーバー側で新しいリソースが作成されたことを示します。プロトコルレベルの結果をステータスコードで表し、レスポンス本文には安定したアプリケーションエラーコードやフィールド別バリデーション詳細、trace ID、リトライ指示、ドキュメントリンクなどを含めるのが推奨されます。

よくある状況
  • ユーザー・注文・記事・ファイル・コメント・アクセストークンなどのサーバー側リソース作成時。
  • APIやブラウザの成功レスポンスで、データ返却・リソース作成・作業受理・本文不要などの区別をクライアント側で判断する必要がある場面。
確認すること
  • まず、この状況が本当に201 Createdの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • 新リソースの正規URLがある場合はLocationヘッダーを含めてください。
  • リソースIDや概要、状態、次のアクションなどを本文に含めるとクライアントに親切です。
使わないほうがよい場面
  • 201, 200, 202, 204, 303, 409, 422などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • 新しいリソースが作成されていない場合に201を返さないでください。
  • 通常の更新処理には201ではなく200や204を使ってください。
出典: RFC 9110 関連コード: 200, 202, 204, 303, 409, 422
202

Accepted(受理済み)

リクエストは受理されたが、処理はまだ完了していません。

2xx 成功 標準 推奨 RFC 9110
詳細

202 Accepted(受理済み)は、サーバーがリクエストを処理用に受け付けたものの、最終結果はまだ確定していないことを示します。プロトコルレベルの結果をステータスコードで表し、レスポンス本文には安定したアプリケーションエラーコードやフィールド別バリデーション詳細、trace ID、リトライ指示、ドキュメントリンクなどを含めるのが推奨されます。

よくある状況
  • 非同期ジョブ、インポート・エクスポート、動画エンコード、レポート生成、キュー処理、バルク処理など。
  • APIやブラウザの成功レスポンスで、データ返却・リソース作成・作業受理・本文不要などの区別をクライアント側で判断する必要がある場面。
確認すること
  • まず、この状況が本当に202 Acceptedの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • ジョブIDやステータスURL、ポーリング間隔、コールバック情報などを返してください。
  • 最終的にジョブが失敗する可能性がある場合は、その点も明記してください。
使わないほうがよい場面
  • 202, 200, 201, 204, 102, 303などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • ジョブが既に成功した場合に202を使わないでください。
  • 最終結果を知る手段が全くない場合に202を返さないでください。
出典: RFC 9110 関連コード: 100, 102, 200, 201, 204, 303, 409
203

Non-Authoritative Information(非権威情報)

リクエストは成功したが、ペイロードは権威のない中継サーバー等によって変換・供給されています。

2xx 成功 標準 注意して使用 RFC 9110
詳細

203 Non-Authoritative Information(非権威情報)は、レスポンス自体は成功だが、オリジンサーバーの正式な表現とは異なり、中継プロキシ等により内容が変更された場合に使います。プロトコルレベルの結果をステータスコードで表し、レスポンス本文には安定したアプリケーションエラーコードやフィールド別バリデーション詳細、trace ID、リトライ指示、ドキュメントリンクなどを含めるのが推奨されます。

よくある状況
  • プロキシ・ゲートウェイ・コンテンツ変換・ミラー・キャッシュ層が内容を変更して成功レスポンスを返す場合。
  • APIやブラウザの成功レスポンスで、データ返却・リソース作成・作業受理・本文不要などの区別をクライアント側で判断する必要がある場面。
確認すること
  • まず、この状況が本当に203 Non-Authoritative Informationの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • データ差分調査時は、オリジン応答と中継・変換後の応答を比較してください。
  • 圧縮・フィルタ・翻訳・マスキング・付加情報などの変換内容を明記してください。
使わないほうがよい場面
  • 203, 200, 204, 304などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • 通常の成功レスポンスで203を使わないでください。
  • 理由を説明せずにプロキシ由来のデータ変更を203のみで隠さないでください。
出典: RFC 9110 関連コード: 200, 204, 304, 502
204

No Content(本文なし)

リクエストは成功し、レスポンスボディは意図的に返されません。

2xx 成功 標準 推奨 RFC 9110
詳細

204 No Content(本文なし)は、サーバーがリクエストを正常に完了し、レスポンスボディを持たないことを明示的に示します。プロトコルレベルの結果をステータスコードで表し、レスポンス本文には安定したアプリケーションエラーコードやフィールド別バリデーション詳細、trace ID、リトライ指示、ドキュメントリンクなどを含めるのが推奨されます。

よくある状況
  • 正常な削除・保存・トグル更新・配信停止など、クライアントが返却データを必要としないAPI。
  • APIやブラウザの成功レスポンスで、データ返却・リソース作成・作業受理・本文不要などの区別をクライアント側で判断する必要がある場面。
確認すること
  • まず、この状況が本当に204 No Contentの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • クライアントは204レスポンスからJSON本文をパースしようとしないでください。
  • 操作後に更新済みデータが必要な場合は200を使ってください。
使わないほうがよい場面
  • 204, 200, 201, 202, 205などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • 204でJSONレスポンスボディを含めないでください。
  • 非同期タスク開始の意味で204を使わないでください。
出典: RFC 9110 関連コード: 200, 201, 202, 205
205

Reset Content(内容のリセット)

リクエストが成功し、クライアントは現在の入力画面やフォームをリセットすべきです。

2xx 成功 標準 注意して使用 RFC 9110
詳細

205 Reset Content(内容のリセット)は、操作が成功し、ユーザーエージェントがドキュメントビューやフォーム、入力状態をリセットすることが期待される場合に使います。プロトコルレベルの結果をステータスコードで表し、レスポンス本文には安定したアプリケーションエラーコードやフィールド別バリデーション詳細、trace ID、リトライ指示、ドキュメントリンクなどを含めるのが推奨されます。

よくある状況
  • フォーム送信後、UI側でフィールドをクリアしたり、エディタをリセットしたり、初期状態に戻したい場面。
  • APIやブラウザの成功レスポンスで、データ返却・リソース作成・作業受理・本文不要などの区別をクライアント側で判断する必要がある場面。
確認すること
  • まず、この状況が本当に205 Reset Contentの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • フロントエンドで205を受信した際、該当フォームやビューを実際にリセットする処理を実装してください。
  • リセット動作が不要な場合は204を使ってください。
使わないほうがよい場面
  • 205, 200, 204などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • UIの状態を維持したい場合に205を使わないでください。
  • 205レスポンス本文にビジネスデータを含めないでください。
出典: RFC 9110 関連コード: 200, 204
206

Partial Content(部分コンテンツ)

Rangeリクエストに対し、リソースの一部のみが返されました。

2xx 成功 標準 注意して使用 RFC 9110
詳細

206 Partial Content(部分コンテンツ)は、リクエストされたリソース全体ではなく、一部のバイト範囲(Range)が含まれるレスポンスであることを示します。プロトコルレベルの結果をステータスコードで表し、レスポンス本文には安定したアプリケーションエラーコードやフィールド別バリデーション詳細、trace ID、リトライ指示、ドキュメントリンクなどを含めるのが推奨されます。

よくある状況
  • Rangeダウンロード、動画シーク、音声ストリーミング、ファイル分割取得、大容量オブジェクトの分割取得など。
  • APIやブラウザの成功レスポンスで、データ返却・リソース作成・作業受理・本文不要などの区別をクライアント側で判断する必要がある場面。
確認すること
  • まず、この状況が本当に206 Partial Contentの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • リクエストに正しいRangeヘッダーが含まれているか確認してください。
  • Content-Rangeを必ず返し、どの範囲のバイトが送信されたかクライアントが判別できるようにしてください。
使わないほうがよい場面
  • 206, 200, 304, 416などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • APIのページネーション(一覧取得)では通常200を使い、206は使いません。
  • 有効なRangeセマンティクスがないのに206を返さないでください。
出典: RFC 9110 関連コード: 200, 304, 416
207

Multi-Status(複数ステータス)

レスポンス本文に複数リソースやサブ操作ごとの個別ステータス結果が含まれます。

2xx 成功 標準 非推奨 RFC 4918
詳細

207 Multi-Status(複数ステータス)は、主にWebDAVで複数リソースにまたがる操作結果をマルチパートで返す場合に使われます。プロトコルレベルの結果をステータスコードで表し、レスポンス本文には安定したアプリケーションエラーコードやフィールド別バリデーション詳細、trace ID、リトライ指示、ドキュメントリンクなどを含めるのが推奨されます。

よくある状況
  • WebDAVのバッチ操作・コレクション操作・複数ファイルのプロパティ更新・リソースツリー操作など。
  • APIやブラウザの成功レスポンスで、データ返却・リソース作成・作業受理・本文不要などの区別をクライアント側で判断する必要がある場面。
確認すること
  • まず、この状況が本当に207 Multi-Statusの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • クライアントは全体の207だけでなく、埋め込まれた個々のリソースステータスも必ず確認してください。
  • 通常のバッチJSON APIでは、WebDAVセマンティクスよりも200+構造化配列の方が扱いやすい場合があります。
使わないほうがよい場面
  • 207, 200, 206, 208, 424などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • WebDAV的な複数ステータスセマンティクスが不要なREST APIで207を使わないでください。
  • 207=全サブ操作成功と誤解しないでください。
出典: RFC 4918 関連コード: 200, 206, 208, 424
208

Already Reported(報告済み)

WebDAVバインドメンバーがレスポンス内ですでに報告済みであることを示します。

2xx 成功 標準 非推奨 RFC 5842
詳細

208 Already Reported(報告済み)は、同じWebDAVバインドメンバーの重複報告を避けるためのレスポンスです。プロトコルレベルの結果をステータスコードで表し、レスポンス本文には安定したアプリケーションエラーコードやフィールド別バリデーション詳細、trace ID、リトライ指示、ドキュメントリンクなどを含めるのが推奨されます。

よくある状況
  • WebDAVのdepthリクエストやコレクション横断で、同一リソースが複数バインディング経由で現れる場合。
  • APIやブラウザの成功レスポンスで、データ返却・リソース作成・作業受理・本文不要などの区別をクライアント側で判断する必要がある場面。
確認すること
  • まず、この状況が本当に208 Already Reportedの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • 208は207 Multi-Statusレスポンス内で解釈してください。
  • WebDAVバインディングセマンティクスが実際に関与している場合のみ使ってください。
使わないほうがよい場面
  • 208, 207, 508などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • ビジネス上の重複送信の意味で208を使わないでください。
  • 通常のREST APIで208を使わないでください。
出典: RFC 5842 関連コード: 207, 226, 508
226

IM Used(IM使用)

サーバーがインスタンス操作(例:デルタエンコーディング)を適用したレスポンスを返しました。

2xx 成功 標準 非推奨 RFC 3229
詳細

226 IM Used(IM使用)は、サーバーがクライアントがサポートするインスタンス操作(例:デルタエンコーディング)を適用してGETリクエストに応答したことを示します。プロトコルレベルの結果をステータスコードで表し、レスポンス本文には安定したアプリケーションエラーコードやフィールド別バリデーション詳細、trace ID、リトライ指示、ドキュメントリンクなどを含めるのが推奨されます。

よくある状況
  • HTTPデルタエンコーディングやインスタンス操作を明示的にサポートしたクライアントとの通信。
  • APIやブラウザの成功レスポンスで、データ返却・リソース作成・作業受理・本文不要などの区別をクライアント側で判断する必要がある場面。
確認すること
  • まず、この状況が本当に226 IM Usedの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • クライアントがそのインスタンス操作を要求・サポートしているか必ず確認してください。
  • キャッシュバリデーター・ETag・デルタエンコーディングの一貫性も検証してください。
使わないほうがよい場面
  • 226, 200, 206, 304などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • 通常の部分ダウンロード用途では226でなく206を使ってください。
  • 明示的なプロトコルサポートがない通常のJSON APIで226を使わないでください。
出典: RFC 3229 関連コード: 200, 206, 304

3xx リダイレクト

リダイレクトやキャッシュに関するレスポンスです。ブラウザ遷移、クローラー、正規URL、APIクライアント、リトライ動作に影響します。

300

Multiple Choices(複数の選択肢)

対象リソースに複数の表現や転送先があり、ユーザーやクライアントが選択する必要があります。

3xx リダイレクト 標準 注意して使用 RFC 9110
詳細

300 Multiple Choices(複数の選択肢)は、リクエストが複数の表現や転送先に一致した場合に返されます。ユーザーやクライアントがどれを選ぶか判断する必要がある状況です。HTTPステータスコードでプロトコル上の結果を示しつつ、レスポンス本文で選択肢リストやアプリケーションエラーコード、フィールド別詳細、trace ID、リトライ指示、ドキュメントリンクなどを返すことが推奨されます。

よくある状況
  • 多言語リソース、複数フォーマット、ミラー、バージョン違い、バリアントURLなど。
  • クライアントやブラウザ、クローラー、SDKがリダイレクトやコンテンツ選択レスポンスを正しく処理する必要がある場合に現れます。
確認すること
  • まず、この状況が本当に300 Multiple Choicesの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • レスポンス本文に選択肢リストを明示的に含めてください。
  • サーバー側で最適な転送先が明確な場合は、より具体的なリダイレクトコードを使ってください。
使わないほうがよい場面
  • 300, 301, 302, 303, 406などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • 明らかに一つの転送先しかない場合に300を返さないでください。
  • 選択肢リストが実際にない場合に300を返さないでください。
出典: RFC 9110 関連コード: 301, 302, 303, 406
301

Moved Permanently(恒久的に移動)

リソースが新しい恒久的なURLに移動しました。

3xx リダイレクト 標準 推奨 RFC 9110
詳細

301 Moved Permanently(恒久的に移動)は、リソースの正規URLが恒久的に変更されたことを示します。クライアントや検索エンジンは保存済みの参照を新しいURLに更新してよいと判断できます。HTTPステータスコードでプロトコル上の結果を示しつつ、レスポンス本文でアプリケーションエラーコードやフィールド別詳細、trace ID、リトライ指示、ドキュメントリンクなどを返すことが推奨されます。

よくある状況
  • サイト移転、URL正規化、HTTP→HTTPSリダイレクト、ドメイン変更、恒久的なパス変更など。
  • ブラウザの開発者ツール、SEOクローラー、APIクライアントでリダイレクト発生時に、恒久移動か一時移動か、メソッド維持が必要かを見極める場面で現れます。
確認すること
  • まず、この状況が本当に301 Moved Permanentlyの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • 必ず正しいLocationヘッダーを含めてください。
  • リダイレクトループ、チェーン、誤った転送先、HTTP/HTTPS混在の挙動も確認してください。
使わないほうがよい場面
  • 301, 302, 307, 308, 404, 410などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • 一時的なキャンペーンやA/Bテストに301を使わないでください。
  • 全ての存在しないページをトップページに301リダイレクトしないでください。
出典: RFC 9110 関連コード: 302, 307, 308, 404, 410
302

Found(一時的な移動)

リソースが一時的に別のURLで利用可能です。

3xx リダイレクト 標準 推奨 RFC 9110
詳細

302 Found(一時的な移動)は、リクエストされたリソースが一時的に別のURLで利用可能であることを示します。将来のリクエストでは引き続き元のURLを使うべきです。HTTPステータスコードでプロトコル上の結果を示しつつ、レスポンス本文でアプリケーションエラーコードやフィールド別詳細、trace ID、リトライ指示、ドキュメントリンクなどを返すことが推奨されます。

よくある状況
  • 一時的なリダイレクト、ログイン後のリターンフロー、短期キャンペーン、実験、トラフィック分散など。
  • ブラウザ開発者ツール、SEOクローラー、APIクライアントでリダイレクト発生時に、一時移動か恒久移動か、メソッド維持が必要かを判断する場面で現れます。
確認すること
  • まず、この状況が本当に302 Foundの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • Locationヘッダーで一時的な転送先を必ず指定してください。
  • 元のメソッドや本文を維持したい場合は307を使ってください。
使わないほうがよい場面
  • 302, 301, 303, 307, 308などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • 恒久的な移転に302を使わないでください。
  • API認証エラー時に401が期待される場面でHTMLログインページに302リダイレクトしないでください。
出典: RFC 9110 関連コード: 301, 303, 307, 308, 401
303

See Other(他を参照)

クライアントは別のURLをGETで取得して結果を確認する必要があります。

3xx リダイレクト 標準 注意して使用 RFC 9110
詳細

303 See Other(他を参照)は、リクエストの結果が別のURIで取得可能であり、クライアントはそのURIにGETでアクセスすべきことを示します。主にPOST-リダイレクト-GETのようなフローで使われます。HTTPステータスコードでプロトコル上の結果を示しつつ、レスポンス本文でアプリケーションエラーコードやフィールド別詳細、trace ID、リトライ指示、ドキュメントリンクなどを返すことが推奨されます。

よくある状況
  • POST送信後のリダイレクトGET、フォーム送信、タスク作成ページ、結果確認ページなど。
  • ブラウザ開発者ツール、SEOクローラー、APIクライアントでリダイレクト発生時に、一時移動か恒久移動か、メソッド維持が必要かを判断する場面で現れます。
確認すること
  • まず、この状況が本当に303 See Otherの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • GETで取得可能なリソースをLocationヘッダーで指定してください。
  • ブラウザリロード時の重複送信防止用途でも活用できます。
使わないほうがよい場面
  • 303, 201, 202, 302, 307などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • 恒久的な移転に303を使わないでください。
  • GETで取得できないエンドポイントをLocationに指定しないでください。
出典: RFC 9110 関連コード: 201, 202, 302, 307
304

Not Modified(未変更)

キャッシュ済みの表現がそのまま有効で再利用可能です。

3xx リダイレクト 標準 推奨 RFC 9110
詳細

304 Not Modified(未変更)は、条件付きリクエストが現在のリソース状態と一致したため、クライアントは自身のキャッシュをそのまま使えることを示します。HTTPステータスコードでプロトコル上の結果を示しつつ、レスポンス本文でアプリケーションエラーコードやフィールド別詳細、trace ID、リトライ指示、ドキュメントリンクなどを返すことが推奨されます。

よくある状況
  • ブラウザキャッシュ、CDNキャッシュ、ETag、Last-Modified、If-None-Match、条件付きGETなど。
  • キャッシュ検証時にブラウザやCDNが保存済みコピーを再利用できるか問い合わせる際に現れます。
確認すること
  • まず、この状況が本当に304 Not Modifiedの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • ETag、Last-Modified、Cache-Control、リソースバージョン管理を検証してください。
  • 304では本文を返さないでください。
使わないほうがよい場面
  • 304, 200, 204, 206, 412などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • 条件付きリクエストでない場合に304を返さないでください。
  • ビジネス上の成功レスポンスとして304を使わないでください。
出典: RFC 9110 関連コード: 200, 204, 206, 412
305

Use Proxy(プロキシを使用)

過去のコードで、プロキシを経由すべきことを示します。

3xx リダイレクト 非推奨 非推奨 RFC 9110
詳細

305 Use Proxy(プロキシを使用)は、リクエストされたレスポンスがプロキシを通じてのみアクセス可能であることを示しますが、この仕組みは現代では非推奨かつ安全でないため、新しいシステムでは使われません。HTTPステータスコードでプロトコル上の結果を示しつつ、レスポンス本文でアプリケーションエラーコードやフィールド別詳細、trace ID、リトライ指示、ドキュメントリンクなどを返すことが推奨されます。

よくある状況
  • レガシープロキシ挙動や過去の互換ドキュメントの説明。
  • クライアントやブラウザ、クローラー、SDKがリダイレクトやコンテンツ選択レスポンスを解釈する必要がある場面で現れることがあります。
確認すること
  • まず、この状況が本当に305 Use Proxyの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • ログで305が現れた場合、古いプロキシや独自実装が原因か調査してください。
  • 現代のシステムではプロキシ設定をHTTPレスポンス経路外で行うべきです。
使わないほうがよい場面
  • 305, 300, 307, 308などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • 新しいシステムで305を使用しないでください。
  • 通常のリダイレクト用途に305を使わないでください。
出典: RFC 9110 関連コード: 300, 307, 308
306

Unused(未使用)

現在は意味を持たない、歴史的な予約済みステータスコードです。

3xx リダイレクト 予約済み 非推奨 RFC 9110
詳細

306 Unused(未使用)は、現時点でアクティブな意味が割り当てられていない予約コードです。HTTPステータスコードでプロトコル上の結果を示しつつ、レスポンス本文でアプリケーションエラーコードやフィールド別詳細、trace ID、リトライ指示、ドキュメントリンクなどを返すことが推奨されます。

よくある状況
  • ドキュメントや互換性注記、過去のステータスコードリストの説明用など。
  • クライアントやブラウザ、クローラー、SDKがリダイレクトやコンテンツ選択レスポンスを解釈する必要がある場面で現れることがあります。
確認すること
  • まず、この状況が本当に306 Unusedの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • 本番で306が現れた場合は、独自実装や設定ミスを疑ってください。
  • ログや監視上は異常値として扱ってください。
使わないほうがよい場面
  • 306, 305, 307などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • ビジネスAPIで306を返さないでください。
  • 306に独自の公開意味を割り当てないでください。
出典: RFC 9110 関連コード: 305, 307
307

Temporary Redirect(一時的リダイレクト)

リソースが一時的にリダイレクトされ、クライアントはメソッドを変更してはいけません。

3xx リダイレクト 標準 推奨 RFC 9110
詳細

307 Temporary Redirect(一時的リダイレクト)は、クライアントが同じリクエストメソッドと本文を維持したまま、一時的なLocationでリクエストを繰り返すべきことを示します。HTTPステータスコードでプロトコル上の結果を示しつつ、レスポンス本文でアプリケーションエラーコードやフィールド別詳細、trace ID、リトライ指示、ドキュメントリンクなどを返すことが推奨されます。

よくある状況
  • 一時的なAPI移行、メンテナンス時の経路変更、短期フェイルオーバー、メソッド維持が必要なリダイレクト。
  • ブラウザ開発者ツール、SEOクローラー、APIクライアントでリダイレクト発生時に、一時移動か恒久移動か、メソッド維持が必要かを判断する場面で現れます。
確認すること
  • まず、この状況が本当に307 Temporary Redirectの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • Locationヘッダーを必ず含めてください。
  • POST, PUT, PATCH, DELETEのセマンティクス維持が重要な場合は302ではなく307を使ってください。
使わないほうがよい場面
  • 307, 302, 303, 308などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • 恒久的な移転には307でなく308を使ってください。
  • 認証失敗の意味で307を使わないでください。
出典: RFC 9110 関連コード: 302, 303, 308
308

Permanent Redirect(恒久的リダイレクト)

リソースが恒久的にリダイレクトされ、クライアントはメソッドを変更してはいけません。

3xx リダイレクト 標準 推奨 RFC 9110
詳細

308 Permanent Redirect(恒久的リダイレクト)は、クライアントが元のリクエストメソッドを維持したまま新しい恒久的なURIへ移行すべきことを示します。HTTPステータスコードでプロトコル上の結果を示しつつ、レスポンス本文でアプリケーションエラーコードやフィールド別詳細、trace ID、リトライ指示、ドキュメントリンクなどを返すことが推奨されます。

よくある状況
  • 恒久的なAPI移転、メソッド維持を伴うHTTPS/ドメイン移行、恒久的なパス正規化など。
  • ブラウザ開発者ツール、SEOクローラー、APIクライアントでリダイレクト発生時に、一時移動か恒久移動か、メソッド維持が必要かを判断する場面で現れます。
確認すること
  • まず、この状況が本当に308 Permanent Redirectの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • 恒久的な移転でPOST/PUT/PATCHのメソッド維持が必要な場合は308を使ってください。
  • 大規模移行時はクライアント・CDN・SDK・検索エンジンの対応状況も確認してください。
使わないほうがよい場面
  • 308, 301, 307などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • 一時的な経路変更に308を使わないでください。
  • 新しいURLが安定する前に308を使わないでください。
出典: RFC 9110 関連コード: 301, 307

4xx クライアントエラー

構文不正、認証、認可、存在しないリソース、バリデーションエラー、競合、レート制限、法的制限など、クライアント側のリクエストに起因する問題です。

400

Bad Request(不正なリクエスト)

リクエストの構文が不正・破損・必須構造が不足しています。

4xx クライアントエラー 標準 推奨 RFC 9110
詳細

400 Bad Request(不正なリクエスト)は、構文エラー・壊れたJSON・無効なパラメーター・不正なフレーミングなどにより、サーバーがリクエストを理解または処理できない場合に返されます。HTTPステータスコードでプロトコル上の結果を示しつつ、レスポンス本文でアプリケーションエラーコードやフィールド別詳細、trace ID、リトライ指示、ドキュメントリンクなどを返すことが推奨されます。

よくある状況
  • 壊れたJSON、パラメータ型不一致、必須フィールド欠落、不正なURL、無効なヘッダー、リクエスト解析エラーなど。
  • APIレスポンスで、呼び出し元が入力修正・競合解決・正しいリクエストでのリトライを促される場面に現れます。
確認すること
  • まず、この状況が本当に400 Bad Requestの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • どのフィールドやパラメータが問題かを詳細に返すと、呼び出し元が修正しやすくなります。
  • 構文は正しいが意味的バリデーションに失敗した場合は422を使ってください。
使わないほうがよい場面
  • 全てのクライアント側問題に400を使わないでください。
  • サーバー側例外に400を使わないでください。
  • どのフィールドや形式が不正か説明できる場合は、単に'Bad Request'だけ返さないでください。
出典: RFC 9110 関連コード: 401, 403, 404, 409, 415, 422
401

Unauthorized(認証が必要)

認証が必要、または認証情報が無効です。

4xx クライアントエラー 標準 推奨 RFC 9110
詳細

401 Unauthorized(認証が必要)は、リクエストに有効な認証情報が含まれていない場合に返されます。HTTPステータスコードでプロトコル上の結果を示しつつ、レスポンス本文でアプリケーションエラーコードやフィールド別詳細、trace ID、リトライ指示、ドキュメントリンクなどを返すことが推奨されます。

よくある状況
  • ログイン未実施、トークン未付与、トークン期限切れ、Authorizationヘッダー不正、署名エラー、OAuth認証失敗など。
  • アクセス失敗時に、認証・認可・プロキシ認証・セッション期限切れ・ネットワーク認証のどれかを切り分ける必要がある場面で現れます。
確認すること
  • まず、この状況が本当に401 Unauthorizedの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • 認証方式がある場合はWWW-Authenticateヘッダーも返してください。
  • クライアントはログイン促進・トークン再取得・認証情報付きでの再試行などを行えます。
使わないほうがよい場面
  • 認証済みユーザーの権限不足には401でなく403を使う方が分かりやすいです。
  • ビジネスバリデーションエラーに401を使わないでください。
  • レスポンスで過剰な認証情報詳細を漏らさないでください。
出典: RFC 9110 関連コード: 403, 407, 419, 440
402

Payment Required(支払いが必要)

支払い・サブスクリプション・残高・利用枠などのアクションが必要です(標準では広い意味として定義されています)。

4xx クライアントエラー 標準 注意して使用 RFC 9110
詳細

402 Payment Required(支払いが必要)は、支払いや商用権限がないとリクエストを完了できない場合に返されますが、標準仕様では具体的な決済フローは定義されていません。HTTPステータスコードでプロトコル上の結果を示しつつ、レスポンス本文でアプリケーションエラーコードやフィールド別詳細、trace ID、リトライ指示、ドキュメントリンクなどを返すことが推奨されます。

よくある状況
  • 有料API、サブスクリプション期限切れ、残高不足、有料コンテンツ、アカウント利用枠超過など。
  • リクエスト失敗時に、クライアント・認証情報・リクエスト形式・リソース状態・法的条件などの修正が必要な場合に現れます。
確認すること
  • まず、この状況が本当に402 Payment Requiredの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • どの支払い・サブスクリプション条件で402が発生したかを明記してください。
  • 請求URLやプラン情報、サポート窓口なども必要に応じて案内してください。
使わないほうがよい場面
  • 402, 403, 429などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • 無関係なビジネスエラーに402を使わないでください。
  • 一般的なHTTPクライアントが402に自動対応するとは限らない点に注意してください。
出典: RFC 9110 関連コード: 403, 429
403

Forbidden(禁止)

サーバーはリクエストを理解したが、権限がないため許可しません。

4xx クライアントエラー 標準 推奨 RFC 9110
詳細

403 Forbidden(禁止)は、構文的には正しいリクエストでも、呼び出し元にその操作を許可しない場合に返されます。HTTPステータスコードでプロトコル上の結果を示しつつ、レスポンス本文でアプリケーションエラーコードやフィールド別詳細、trace ID、リトライ指示、ドキュメントリンクなどを返すことが推奨されます。

よくある状況
  • 権限不足、禁止ロール、IPブロック、ポリシー拒否、WAF拒否、リソースアクセス制限など。
  • アクセス失敗時に、認証・認可・プロキシ認証・セッション切れ・ネットワーク認証のどれかを切り分ける必要がある場面で現れます。
確認すること
  • まず、この状況が本当に403 Forbiddenの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • ユーザーが認証済みかどうか確認し、未認証の場合は通常401を返します。
  • 安全な範囲で明確な権限エラーメッセージを返してください。
使わないほうがよい場面
  • 認証情報がない場合は403でなく401を使う方が分かりやすいです。
  • 存在しないリソースに403を返すのは、意図的に隠したい場合以外は避けてください。
  • レスポンスで機密な認可ルールを漏らさないでください。
出典: RFC 9110 関連コード: 401, 404, 451
404

Not Found(見つかりません)

サーバーが対象リソースを見つけられない、または存在を明かしたくありません。

4xx クライアントエラー 標準 推奨 RFC 9110
詳細

404 Not Found(見つかりません)は、リクエストされたURL・ルート・リソースID・エンドポイントが呼び出し元から見て存在しない場合に返されます。HTTPステータスコードでプロトコル上の結果を示しつつ、レスポンス本文でアプリケーションエラーコードやフィールド別詳細、trace ID、リトライ指示、ドキュメントリンクなどを返すことが推奨されます。

よくある状況
  • ページ未発見、ルート不一致、削除済みリソース、APIパス間違い、環境ドメイン違い、機密リソースの秘匿など。
  • Webサイト、API、クローラー、ログでリソースが提供できず、消失・恒久削除・秘匿・法的ブロックのいずれかを区別する必要がある場面で現れます。
確認すること
  • まず、この状況が本当に404 Not Foundの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • パス・ルートプレフィックス・リソースID・大文字小文字・APIバージョン・ドメイン・環境を確認してください。
  • 以前は存在したが恒久的に削除した場合は410を使ってください。
使わないほうがよい場面
  • 全てのエラーに404を使わないでください。
  • 恒久的な移転には404でなく301や308を使ってください。
  • フロントエンドルーティングで実際のAPI 404を隠さないでください。
出典: RFC 9110 関連コード: 400, 403, 410, 301
405

Method Not Allowed(許可されていないメソッド)

リソースは存在するが、そのHTTPメソッドは許可されていません。

4xx クライアントエラー 標準 推奨 RFC 9110
詳細

405 Method Not Allowed(許可されていないメソッド)は、対象リソースは存在するものの、そのHTTPメソッドは許可されていない場合に返されます。HTTPステータスコードでプロトコル上の結果を示しつつ、レスポンス本文でアプリケーションエラーコードやフィールド別詳細、trace ID、リトライ指示、ドキュメントリンクなどを返すことが推奨されます。

よくある状況
  • POST専用エンドポイントにGET送信、削除不可リソースへのDELETE、ルート設定のメソッド不一致など。
  • リクエスト失敗時に、クライアント・認証情報・リクエスト形式・リソース状態・法的条件などの修正が必要な場合に現れます。
確認すること
  • まず、この状況が本当に405 Method Not Allowedの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • Allowヘッダーで許可されているメソッドを必ず明示してください。
  • フロントエンドのメソッド・ルート定義・CORSプリフライト・プロキシのメソッド書き換えも確認してください。
使わないほうがよい場面
  • 405, 400, 404, 501などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • リソースが存在しない場合に405を返さないでください。
  • 許可メソッドを明示せずに405を返さないでください。
出典: RFC 9110 関連コード: 400, 404, 501
406

Not Acceptable(受け入れ不可)

サーバーがクライアントの要求する表現を生成できません。

4xx クライアントエラー 標準 注意して使用 RFC 9110
詳細

406 Not Acceptable(受け入れ不可)は、クライアントのAccept系ヘッダーで求められたレスポンス形式・言語・文字コード・エンコーディングなどをサーバーが提供できない場合に返されます。HTTPステータスコードでプロトコル上の結果を示しつつ、レスポンス本文でアプリケーションエラーコードやフィールド別詳細、trace ID、リトライ指示、ドキュメントリンクなどを返すことが推奨されます。

よくある状況
  • 厳格なコンテンツネゴシエーション、非対応レスポンス形式、言語ネゴシエーション、未サポートのメディアタイプ要求など。
  • リクエスト失敗時に、クライアント・認証情報・リクエスト形式・リソース状態・法的条件などの修正が必要な場合に現れます。
確認すること
  • まず、この状況が本当に406 Not Acceptableの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • Accept, Accept-Language, Accept-Encoding等のヘッダーを確認してください。
  • 対応しているレスポンスのメディアタイプ一覧もドキュメント化してください。
使わないほうがよい場面
  • 406, 300, 415などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • リクエスト本文のContent-Type不正には406でなく415を使ってください。
  • 常にJSONのみ返す簡易APIで406を濫用しないでください。
出典: RFC 9110 関連コード: 300, 415
407

Proxy Authentication Required(プロキシ認証が必要)

リクエストを進める前に、クライアントはプロキシで認証する必要があります。

4xx クライアントエラー 標準 非推奨 RFC 9110
詳細

407 Proxy Authentication Required(プロキシ認証が必要)は、オリジンサーバーではなくプロキシサーバーが認証を要求していることを示します。HTTPステータスコードでプロトコル上の結果を示しつつ、レスポンス本文でアプリケーションエラーコードやフィールド別詳細、trace ID、リトライ指示、ドキュメントリンクなどを返すことが推奨されます。

よくある状況
  • 企業内プロキシ、フォワードプロキシ、ネットワークゲートウェイ、社内アクセスレイヤーなど。
  • アクセス失敗時に、認証・認可・プロキシ認証・セッション期限切れ・ネットワークログインのどれかを切り分ける必要がある場面で現れます。
確認すること
  • まず、この状況が本当に407 Proxy Authentication Requiredの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • レスポンスがオリジンサーバーではなくプロキシから返されているか確認してください。
  • Proxy-AuthenticateとProxy-Authorizationヘッダーを確認してください。
使わないほうがよい場面
  • 407, 401, 403などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • 通常のオリジンアプリケーションコードから407を返さないでください。
  • プロキシ認証とWebサイトのログインを混同しないでください。
出典: RFC 9110 関連コード: 401, 403
408

Request Timeout(リクエストタイムアウト)

サーバーがクライアントから完全なリクエストを受け取る前にタイムアウトしました。

4xx クライアントエラー 標準 注意して使用 RFC 9110
詳細

408 Request Timeout(リクエストタイムアウト)は、クライアントが完全なリクエストを十分な速さで送信できなかった、または完了前に接続が長時間アイドル状態になったことを示します。サーバー処理が遅いという意味ではなく、サーバーがクライアント側の送信完了を待ってタイムアウトした状態です。HTTPステータスコードでプロトコル上の結果を示しつつ、レスポンス本文でアプリケーションエラーコードやフィールド別詳細、trace ID、リトライ指示、ドキュメントリンクなどを返すことが推奨されます。

よくある状況
  • 低速アップロード、アイドル状態のkeep-alive接続、不完全なリクエストボディ、不安定なクライアントネットワークなど。
  • リクエスト失敗時に、クライアント・認証情報・リクエスト形式・リソース状態・法的条件などの修正が必要な場合に現れます。
確認すること
  • まず、この状況が本当に408 Request Timeoutの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • クライアントのネットワーク品質、アップロード速度、リクエストボディサイズ、タイムアウト設定を確認してください。
  • サーバーは408送信後に接続を閉じる場合があります。
使わないほうがよい場面
  • 408, 400, 499, 504などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • サーバー側処理が遅い場合に408を使わないでください。
  • クライアントがリクエストを閉じたことを示すNginx 499と混同しないでください。
出典: RFC 9110 関連コード: 400, 499, 504
409

Conflict(競合)

リクエストが対象リソースの現在の状態と競合しています。

4xx クライアントエラー 標準 推奨 RFC 9110
詳細

409 Conflict(競合)は、リソースの状態、バージョン、ユニーク制約、同時更新ルールなどと衝突するため、サーバーがリクエストを完了できない場合に返されます。HTTPステータスコードでプロトコル上の結果を示しつつ、レスポンス本文でアプリケーションエラーコードやフィールド別詳細、trace ID、リトライ指示、ドキュメントリンクなどを返すことが推奨されます。

よくある状況
  • バージョン競合、重複作成、不正な状態遷移、同時更新、ユニーク制約違反など。
  • APIレスポンスで、呼び出し元が入力修正・競合解決・正しいリクエストでのリトライを促される場面に現れます。
確認すること
  • まず、この状況が本当に409 Conflictの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • 競合しているフィールド、バージョン、状態、リソースを説明できるだけの情報を返してください。
  • If-Matchなどの条件付きヘッダーが失敗した場合は412を使ってください。
使わないほうがよい場面
  • 409, 400, 412, 422, 423などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • 全てのビジネスエラーに409を使わないでください。
  • 競合をどう解消できるか説明せずに409を返さないでください。
出典: RFC 9110 関連コード: 400, 412, 422, 423
410

Gone(消滅)

以前は存在していたリソースが、現在は恒久的に利用できません。

4xx クライアントエラー 標準 推奨 RFC 9110
詳細

410 Gone(消滅)は、対象リソースが意図的かつ恒久的に削除されたことを示します。クライアントや検索エンジンに対し、単なる一時的な未検出ではなく、今後も戻らない可能性が高いことを明確に伝えられます。HTTPステータスコードでプロトコル上の結果を示しつつ、レスポンス本文でアプリケーションエラーコードやフィールド別詳細、trace ID、リトライ指示、ドキュメントリンクなどを返すことが推奨されます。

よくある状況
  • 削除済み記事、廃止されたAPIエンドポイント、恒久削除されたリソース、終了したキャンペーン、削除されたダウンロードなど。
  • Webサイト、API、クローラー、ログでリソースが提供できず、未検出・恒久削除・秘匿・法的ブロックのいずれかを区別する必要がある場面で現れます。
確認すること
  • まず、この状況が本当に410 Goneの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • クライアントや検索エンジンに恒久削除であることを明確に伝えたい場合に410を使ってください。
  • 代替リソースがある場合は、そのリンクも案内してください。
使わないほうがよい場面
  • 410, 404, 301, 451などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • 一時的な障害に410を使わないでください。
  • 一度も存在したことのないリソースに410を使わないでください。
  • 法的なブロックには410ではなく451を使う方が明確です。
出典: RFC 9110 関連コード: 404, 301, 451
411

Length Required(Content-Lengthが必要)

サーバーがContent-Lengthヘッダーを要求しています。

4xx クライアントエラー 標準 注意して使用 RFC 9110
詳細

411 Length Required(Content-Lengthが必要)は、リクエストに本文がある、または本文が想定されるにもかかわらず、必要な長さ情報が提供されていない場合に返されます。特にchunked転送を受け付けないサーバーや中間層で発生することがあります。HTTPステータスコードでプロトコル上の結果を示しつつ、レスポンス本文でアプリケーションエラーコードやフィールド別詳細、trace ID、リトライ指示、ドキュメントリンクなどを返すことが推奨されます。

よくある状況
  • chunkedアップロードを受け付けないサーバーやゲートウェイ、固定サイズ前提のアップロードAPI、厳格なリクエスト本文処理など。
  • リクエスト失敗時に、クライアント・認証情報・リクエスト形式・リソース状態・法的条件などの修正が必要な場合に現れます。
確認すること
  • まず、この状況が本当に411 Length Requiredの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • 本文を送信する場合は、正しいContent-Lengthヘッダーを付与してください。
  • サーバーや中間層がchunked transfer encodingをサポートしているか確認してください。
使わないほうがよい場面
  • 411, 400, 413などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • 本文のないリクエストに411を返さないでください。
  • 本文が大きすぎる場合は411ではなく413を使ってください。
出典: RFC 9110 関連コード: 400, 413
412

Precondition Failed(前提条件失敗)

リクエストヘッダー内の前提条件がfalseと評価されました。

4xx クライアントエラー 標準 推奨 RFC 9110
詳細

412 Precondition Failed(前提条件失敗)は、条件付きリクエストが失敗したことを示します。多くの場合、クライアントが保持しているリソースバージョンが古く、If-Match、If-None-Match、If-Unmodified-Since、ETagなどの条件に一致しません。HTTPステータスコードでプロトコル上の結果を示しつつ、レスポンス本文でアプリケーションエラーコードやフィールド別詳細、trace ID、リトライ指示、ドキュメントリンクなどを返すことが推奨されます。

よくある状況
  • If-Match、If-Unmodified-Since、ETagによる楽観的ロック、lost update防止など。
  • APIレスポンスで、呼び出し元が入力修正・競合解決・正しいリクエストでのリトライを促される場面に現れます。
確認すること
  • まず、この状況が本当に412 Precondition Failedの意味に合っているか確認し、汎用的なステータスとして使っていないか見直してください。
  • 直接の原因を特定するために、リクエストメソッド、URL、ヘッダー、本文、認証コンテキスト、リソース状態、キャッシュバリデーター、上流サービス、サーバーログを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたフィールド別詳細、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーがそのステータスコードを生成したか確認してください。
  • If-Match、If-None-Match、If-Unmodified-Sinceなどの条件付きヘッダーを確認してください。
  • 必要に応じて最新のリソース表現を取得し、現在のETagで再試行してください。
使わないほうがよい場面
  • 412, 304, 409, 428などと混在させると、クライアントの挙動・キャッシュ・リトライ・リダイレクト・SEO・障害分析が不安定になります。
  • 通常のバリデーションエラーに412を使わないでください。
  • 条件付きリクエストの文脈がない場合に412を返さないでください。
出典: RFC 9110 関連コード: 304, 409, 428
413

Content Too Large(コンテンツが大きすぎます)

リクエスト本文がサーバーや中間層の許容サイズを超えています。

4xx クライアントエラー 標準 推奨 RFC 9110
詳細

413 Content Too Large(コンテンツが大きすぎます)は、リクエスト本文やアップロード内容が、サーバー・プロキシ・CDN・ゲートウェイ・アプリケーションフレームワークで許可されたサイズ上限を超えた場合に返されます。大容量ファイル、巨大なJSON、フォーム送信、画像・動画アップロードなどで発生しやすく、原因がアプリケーションではなくNginx、CDN、APIゲートウェイ、ロードバランサー側の制限にあることもあります。HTTPステータスコードでプロトコル上の結果を示しつつ、レスポンス本文では許可される最大サイズ、エラーコード、trace ID、再試行や分割アップロードの案内を返すと、クライアント側で対処しやすくなります。

よくある状況
  • 大容量ファイルアップロード、巨大JSON、フォーム送信、画像・動画アップロード、バルクインポートなど。
  • Nginx client_max_body_size、CDN、APIゲートウェイ、ロードバランサー、フレームワーク、オブジェクトストレージのサイズ上限に引っかかる場合。
  • クライアントが送信サイズを小さくする、圧縮する、分割アップロードに切り替える、またはサーバー側の制限を見直す必要がある場面。
確認すること
  • まず、この状況が本当に413 Content Too Largeの意味に合っているか確認し、汎用的な400や500として扱っていないか見直してください。
  • リクエスト本文の実サイズ、Content-Length、Content-Type、アップロード対象、クライアント側の送信方法を確認してください。
  • Nginx client_max_body_size、CDNのアップロード上限、APIゲートウェイ制限、ロードバランサー制限、アプリケーションフレームワークのbody parser制限、オブジェクトストレージ制限を順番に確認してください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーが413を生成したか確認してください。
  • 可能であれば、許可される最大サイズ、アップロード方法、分割アップロードや再開可能アップロードの利用可否をレスポンス本文やAPIドキュメントに明記してください。
  • 大容量アップロードを正式にサポートする場合は、直アップロードURL、multipart upload、resumable upload、進捗管理、タイムアウト設定も合わせて設計してください。
使わないほうがよい場面
  • Content-Typeが未対応な場合は413ではなく415 Unsupported Media Typeを使ってください。
  • リクエスト本文の構文が壊れている場合は400 Bad Requestを使ってください。
  • 本文の形式は正しいが、業務ルール上の値が無効な場合は422 Unprocessable Contentを検討してください。
  • URLやクエリ文字列が長すぎる場合は413ではなく414 URI Too Longを使ってください。
  • サーバー側の処理例外や上流障害を413で隠さないでください。
出典: RFC 9110 関連コード: 400, 411, 414, 415, 422, 494
414

URI Too Long(URIが長すぎます)

リクエストURIがサーバーの処理可能な長さを超えています。

4xx クライアントエラー 標準 推奨 RFC 9110
詳細

414 URI Too Long(URIが長すぎます)は、URL、パス、またはクエリ文字列が長すぎて、サーバー・プロキシ・CDN・ゲートウェイで処理できない場合に返されます。大量の検索条件をGETクエリに詰め込んだ場合、リダイレクトでURLが繰り返し伸びる場合、自動生成されたURLが制限を超えた場合などに発生しやすいコードです。HTTPステータスコードでプロトコル上の結果を示しつつ、レスポンス本文ではURL長の問題、短縮方法、POST本文への移行、trace IDなどを返すと、クライアント側で修正しやすくなります。

よくある状況
  • クエリパラメーターが多すぎる検索URL、GET URLに大きなデータを埋め込んだリクエスト、長すぎるフィルター条件など。
  • リダイレクトループや、リダイレクトのたびにクエリ文字列が追記されてURLが肥大化する場合。
  • 生成された共有リンク、トラッキングURL、署名付きURL、深いパス構造がサーバーや中間層の長さ制限を超える場合。
確認すること
  • まず、この状況が本当に414 URI Too Longの意味に合っているか確認し、汎用的な400や413として扱っていないか見直してください。
  • 実際のURL長、パス長、クエリ文字列、リダイレクト後のURL、プロキシやCDNでの制限値を確認してください。
  • 大きな検索条件、フィルター、IDリスト、JSON風データはURLではなくPOST本文に移すことを検討してください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーが414を生成したか確認してください。
  • リダイレクトループ、繰り返し追加されるquery string、utmやtracking parameterの重複付与がないか確認してください。
  • 公開APIでは、URLに載せられる最大長や、長い条件を送るための代替POSTエンドポイントをドキュメント化してください。
使わないほうがよい場面
  • リクエスト本文が大きすぎる場合は414ではなく413 Content Too Largeを使ってください。
  • ヘッダーが大きすぎる場合は431 Request Header Fields Too Large、または環境によっては494を検討してください。
  • 通常の入力バリデーションエラーに414を使わないでください。
  • 機密情報や巨大なペイロードをURLに載せる設計は避けてください。
出典: RFC 9110 関連コード: 400, 413, 431, 494
415

Unsupported Media Type(未対応のメディアタイプ)

リクエスト本文のメディアタイプ、エンコーディング、またはアップロード形式がサポートされていません。

4xx クライアントエラー 標準 推奨 RFC 9110
詳細

415 Unsupported Media Type(未対応のメディアタイプ)は、リクエスト本文のContent-Type、Content-Encoding、またはアップロード形式が、対象エンドポイントで受け付けられていない場合に返されます。レスポンス形式の交渉に失敗した406とは異なり、415は送信されたリクエスト本文の形式が問題です。JSON専用APIにXMLやform-dataを送った場合、multipart boundaryが壊れている場合、非対応の圧縮形式やファイル形式を送った場合などに使います。

よくある状況
  • JSON専用APIにXML、form-data、text/plainなどを送信した場合。
  • Content-Typeヘッダーと実際の本文形式が一致していない場合。
  • multipart boundaryの不備、非対応ファイル形式、非対応のContent-Encodingや圧縮形式など。
確認すること
  • まず、この状況が本当に415 Unsupported Media Typeの意味に合っているか確認し、汎用的な400や422として扱っていないか見直してください。
  • Content-Type、Content-Encoding、multipart boundary、ファイルのMIME type、実際のリクエスト本文形式を確認してください。
  • APIでは、対応しているリクエストメディアタイプ、文字コード、圧縮形式、アップロード可能なファイル形式を明確にドキュメント化してください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーが415を生成したか確認してください。
  • クライアント側では、送信する本文形式に合わせてContent-Typeを正しく設定し、SDKやfetch/axiosの自動設定と競合していないか確認してください。
  • ファイルアップロードでは、拡張子だけでなく実際のMIME typeや検証ルールも確認してください。
使わないほうがよい場面
  • レスポンスのAccept交渉に失敗した場合は415ではなく406 Not Acceptableを使ってください。
  • Content-Typeは対応しているがJSON構文が壊れている場合は400 Bad Requestを使ってください。
  • 本文の形式は正しいが、業務ルール上の値が無効な場合は422 Unprocessable Contentを使ってください。
  • アップロードサイズが大きすぎる場合は415ではなく413 Content Too Largeを使ってください。
出典: RFC 9110 関連コード: 400, 406, 413, 422
416

Range Not Satisfiable(範囲を満たせません)

リクエストされたバイト範囲を返すことができません。

4xx クライアントエラー 標準 注意して使用 RFC 9110
詳細

416 Range Not Satisfiable(範囲を満たせません)は、Rangeヘッダーで要求された範囲が無効、または現在利用可能なリソース表現の範囲外である場合に返されます。ダウンロード再開、動画や音声のシーク、キャッシュ済みファイルサイズに基づく再取得などで発生しやすいコードです。クライアントはリソースの現在の長さやContent-Rangeを確認し、適切なRangeで再試行する必要があります。

よくある状況
  • ダウンロード再開時に、クライアントが古いファイルサイズを前提にRangeを送った場合。
  • 動画や音声のシークで、実際のファイル長を超えるバイト範囲を要求した場合。
  • CDNやブラウザキャッシュに古いリソース情報が残っており、現在のオリジンファイルとサイズが一致しない場合。
  • Rangeヘッダーの書式が不正、または複数範囲指定がサーバー側で受け付けられない場合。
確認すること
  • まず、この状況が本当に416 Range Not Satisfiableの意味に合っているか確認し、汎用的な400や404として扱っていないか見直してください。
  • Rangeヘッダーの値、現在のリソースサイズ、ETag、Last-Modified、キャッシュ状態を確認してください。
  • レスポンスでは、可能であればContent-Range: */lengthを返し、クライアントが現在の全体サイズを把握できるようにしてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーが416を生成したか確認してください。
  • クライアント側では、リソースを再検証してから新しいRangeで再試行するか、必要に応じてRangeなしで再取得してください。
  • 動画・音声・大容量ファイル配信では、Range対応、Content-Length、Content-Range、キャッシュ再検証の挙動を一貫させてください。
使わないほうがよい場面
  • Rangeリクエストではない通常のリクエストに416を返さないでください。
  • リソース自体が存在しない場合は416ではなく404 Not Foundを使ってください。
  • 通常のページネーションでページ番号が範囲外の場合に416を使わないでください。
  • 部分コンテンツを正常に返せる場合は416ではなく206 Partial Contentを使ってください。
出典: RFC 9110 関連コード: 200, 206, 404
417

Expectation Failed(期待条件失敗)

サーバーがExpectヘッダーで宣言された期待条件を満たせません。

4xx クライアントエラー 標準 注意して使用 RFC 9110
詳細

417 Expectation Failed(期待条件失敗)は、クライアントがExpectヘッダーで要求した条件を、サーバーまたは中間層が満たせない場合に返されます。代表的なのはExpect: 100-continueに対する拒否で、サーバーが大きなリクエスト本文を受け取る前に、認証、権限、サイズ、Content-Type、その他の条件を見て早期に拒否する場面です。リクエスト本文そのものの検証結果ではなく、Expectヘッダーに関するプロトコル上の期待条件が満たせないことを示します。

よくある状況
  • Expect: 100-continue付きの大容量アップロードをサーバーやプロキシが受け付けない場合。
  • サーバーが対応していないExpectヘッダー値をクライアントが送信した場合。
  • 本文を送る前に、認証、権限、サイズ制限、Content-Typeなどの理由でサーバーが早期拒否する場合。
  • プロキシ、CDN、APIゲートウェイ、ロードバランサーがExpectヘッダーを正しく処理できない場合。
確認すること
  • まず、この状況が本当に417 Expectation Failedの意味に合っているか確認し、汎用的な400や413として扱っていないか見直してください。
  • Expectヘッダーの値、特にExpect: 100-continueが付与されているか確認してください。
  • サーバー、プロキシ、CDN、APIゲートウェイ、ロードバランサーがExpectヘッダーと1xxレスポンスを正しく処理できるか確認してください。
  • 大容量本文を拒否している理由がサイズなら413、認証なら401、権限なら403、Content-Typeなら415の方が適切な場合があります。
  • クライアント側では、不要なExpectヘッダーを送らない設定にするか、サーバーが対応する方式に合わせてリクエストを組み立ててください。
  • ログでは、リクエスト本文が送信される前に拒否されたのか、本文送信後に別のエラーになったのかを切り分けてください。
使わないほうがよい場面
  • Expectヘッダーが関与していない通常のバリデーションエラーに417を使わないでください。
  • 本文サイズが大きすぎるだけなら413 Content Too Largeを使ってください。
  • リクエスト構文が壊れている場合は400 Bad Requestを使ってください。
  • ビジネスルール上の入力エラーを417で表現しないでください。
出典: RFC 9110 関連コード: 100, 400, 413
418

I'm a teapot(私はティーポットです)

HTCPCP由来のユーモラスな予約済みステータスコードです。

4xx クライアントエラー 予約済み 非推奨 RFC 9110
詳細

418 I'm a teapot(私はティーポットです)は、サーバーがティーポットなのでコーヒーを淹れられないというジョークから生まれたステータスコードです。現在は主に歴史的・文化的な意味を持つコードであり、実運用のAPIエラーやビジネスエラーを表すためのものではありません。デモ、テスト、イースターエッグとして見かけることはありますが、公開APIでは標準的な4xxまたは5xxを使う方がクライアントにとって分かりやすく安全です。

よくある状況
  • 開発者向けのイースターエッグ、デモページ、テスト用エンドポイント、ユーモラスなエラーページなど。
  • フレームワーク、サンプルコード、教育用資料でHTTPステータスコードの例として使われる場合。
  • 本番環境で見つかった場合は、意図的なジョークなのか、設定ミスなのか、古いテストコードの残りなのかを確認する必要があります。
確認すること
  • まず、この状況が本当に418 I'm a teapotの意図的な利用なのか確認してください。
  • 本番環境で418が出ている場合は、アプリケーションコード、ルーティング、ミドルウェア、フレームワーク設定、テスト用ハンドラーを確認してください。
  • 公開APIでは、実際の原因に合わせて400、404、409、422、500、501などの標準的なステータスコードに置き換えてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーが418を生成したか確認してください。
  • ドキュメントやデモで使う場合は、実運用で推奨されるコードではないことを明記してください。
使わないほうがよい場面
  • 実際のビジネスエラーコードとして418を使わないでください。
  • 機能未実装を表すために418を使わないでください。その場合は501 Not Implementedの方が明確です。
  • 認証、認可、バリデーション、レート制限、サーバー障害などを418で隠さないでください。
  • 公開APIクライアントに418への特別対応を求めないでください。
出典: RFC 9110 関連コード: 400, 501
419

Page Expired(ページの有効期限切れ)

ページセッション、ログインセッション、またはCSRFトークンの有効期限が切れています。

4xx クライアントエラー 非標準 注意して使用 Laravel / Web framework convention
詳細

419 Page Expired(ページの有効期限切れ)は、IANAに登録された標準HTTPステータスコードではありません。主にLaravelや一部のWebフレームワーク慣例で使われる非標準コードで、ページセッション、ログインセッション、CSRFトークンの期限切れを示すことが多いです。ただし、移植性のあるREST API契約として扱うべきではありません。ブラウザ、HTTPクライアント、監視ツール、クローラー、中間プロキシが一貫して理解するとは限らないため、公開APIでは標準コードへのマッピングを検討してください。

よくある状況
  • LaravelやWebフレームワークの慣例により、特定のセッション・CSRF検証失敗で419が生成される場合。
  • フォーム送信時にCSRFトークンが期限切れ、または現在のセッションと一致しない場合。
  • ユーザーがページを長時間開いたままにし、後から送信した場合。
  • ログインセッションが期限切れになっているのに、フロントエンドが古い状態のままリクエストを送っている場合。
確認すること
  • まず、このレスポンスがLaravelやWebフレームワーク慣例によって生成されたものか、アプリケーション独自のエラーかを確認してください。
  • オリジンアプリケーションログと、CDN、ゲートウェイ、プロキシ、ロードバランサー、Webサーバーログを比較してください。
  • セッション有効期限、Cookie、SameSite設定、cross-origin設定、HTTPS設定、CSRFミドルウェア、フォーム内トークンの更新タイミングを確認してください。
  • 公開APIでは、この状態を401、403、400、422などの標準コードにマッピングし、実装固有の理由はレスポンス本文やログに残すことを検討してください。
  • ユーザー向け画面では、ページを更新して新しいCSRFトークンを取得する案内や、再ログイン導線を用意してください。
  • SPAでは、セッション期限切れ時に古いフォームやトークンを使い続けないよう、再取得・再認証のフローを設計してください。
使わないほうがよい場面
  • すべての認証失敗に419を使わないでください。標準的な認証エラーは401に近いです。
  • 権限不足を419で表現しないでください。その場合は403を検討してください。
  • サードパーティAPIクライアントが419を理解する前提で設計しないでください。
  • 419をRFC標準のHTTPステータスコードとして説明しないでください。どの製品やフレームワークが生成しているのかを明記してください。
出典: Laravel / Web framework convention 関連コード: 400, 401, 403, 440, 422
420

Enhance Your Calm(落ち着いてください)

クライアントのリクエスト頻度が高すぎる、または攻撃的な挙動とみなされています。

4xx クライアントエラー 非標準 非推奨 Twitter legacy API convention
詳細

420 Enhance Your Calm(落ち着いてください)は、IANAに登録された標準HTTPステータスコードではありません。Twitterの旧API慣例に由来する非標準コードで、クライアントが短時間に多くのリクエストを送っている、またはサービス側のポリシー上過剰・攻撃的とみなされる挙動を示すために使われていました。新しい公開APIでは、標準化された429 Too Many Requestsを使う方が、クライアント、SDK、監視、プロキシにとって分かりやすく移植性があります。

よくある状況
  • Twitter旧APIや、その慣例に倣ったレガシーAPIがレート制限や濫用防止のシグナルとして返す場合。
  • クライアントが短時間に大量のリクエストを送り、サービス固有のポリシーで減速を求められている場合。
  • 古いAPIクライアント、SDK、監視ログで、429ではなく420がレート制限相当として記録される場合。
確認すること
  • まず、このレスポンスがTwitter旧API慣例や互換実装によって生成されたものか、現在のアプリケーション独自のエラーかを確認してください。
  • オリジンアプリケーションログと、CDN、ゲートウェイ、プロキシ、ロードバランサー、Webサーバーログを比較してください。
  • レート制限の単位(ユーザー、IP、API key、tenant、endpoint)、残り回数、リセット時刻、Retry-After相当の情報を確認してください。
  • 新しいAPIでは420ではなく429 Too Many Requestsを使い、実装固有の理由はレスポンス本文やレート制限ヘッダーに含めてください。
  • クライアント側ではリクエスト頻度を下げ、指数バックオフ、キューイング、キャッシュ、重複リクエスト抑制を導入してください。
  • レスポンス本文やヘッダーにレート制限の詳細がある場合は、それに従って再試行タイミングを調整してください。
使わないほうがよい場面
  • 新しい公開APIで420を使わないでください。標準的には429 Too Many Requestsを使います。
  • クライアントにこの歴史的な非標準コードへの依存を強制しないでください。
  • 一般的なサーバー過負荷やメンテナンスを420で表現しないでください。その場合は503を検討してください。
  • 420をRFC標準のHTTPステータスコードとして説明しないでください。どの製品や慣例が生成しているのかを明記してください。
出典: Twitter legacy API convention 関連コード: 429, 403, 503
421

Misdirected Request(誤った宛先へのリクエスト)

リクエストが、対象オーソリティに対するレスポンスを生成できないサーバーへ送られました。

4xx クライアントエラー 標準 注意して使用 RFC 9110
詳細

421 Misdirected Request(誤った宛先へのリクエスト)は、接続やルーティングの層で、リクエストが本来処理すべきオーソリティとは異なるサーバーへ配送された場合に返されます。HTTP/2の接続再利用、TLSのSNI設定、Hostヘッダー、仮想ホスト、リバースプロキシのルーティング、複数ドメインを扱うTLS構成で発生することがあります。通常のルート未定義や権限不足ではなく、接続先・証明書・オーソリティ・プロキシ経路の不一致を示すコードです。

よくある状況
  • HTTP/2の接続再利用により、別ホスト向けのリクエストが誤った接続上で送られた場合。
  • TLS SNI、Hostヘッダー、証明書の対象ドメイン、仮想ホスト設定が一致していない場合。
  • リバースプロキシ、CDN、APIゲートウェイ、ロードバランサーのルーティング設定が誤っている場合。
  • 複数ドメイン・複数テナント構成で、クライアントが正しいoriginではなく別の権威サーバーに到達している場合。
確認すること
  • まず、この状況が本当に421 Misdirected Requestの意味に合っているか確認し、汎用的な400や502として扱っていないか見直してください。
  • Hostヘッダー、SNI、TLS証明書の対象ドメイン、HTTP/2接続再利用、仮想ホスト、プロキシのルーティングルールを確認してください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーが421を生成したか確認してください。
  • クライアント側では、正しいoriginに対して新しい接続を張り直して再試行できる場合があります。
  • 複数ドメインを同一証明書や同一HTTP/2接続で扱う場合は、サーバーがそのオーソリティに対するレスポンスを生成できるか確認してください。
  • ルーティング問題を調べる際は、URL、Host、SNI、証明書SAN、CDN設定、ロードバランサーのターゲットルールを並べて確認してください。
使わないほうがよい場面
  • 通常のルート未定義には421ではなく404 Not Foundを使ってください。
  • リクエスト構文が壊れている場合は400 Bad Requestを使ってください。
  • 上流サーバーやゲートウェイの一般的な失敗には502 Bad Gatewayの方が適切な場合があります。
  • 認証や認可の失敗を421で表現しないでください。
出典: RFC 9110 関連コード: 400, 404, 502
422

Unprocessable Content(処理できないコンテンツ)

リクエストの構文は正しいものの、内容や業務ルール上の理由で処理できません。

4xx クライアントエラー 標準 推奨 RFC 9110
詳細

422 Unprocessable Content(処理できないコンテンツ)は、サーバーがリクエスト形式を理解でき、構文も有効だが、送信された値、フィールドの組み合わせ、業務ルール、状態遷移などの理由で処理できない場合に返されます。壊れたJSONや不正なContent-Typeではなく、意味的なバリデーション失敗を表すコードです。APIでは、どのフィールドがなぜ無効なのか、クライアントがどう修正すればよいのかをレスポンス本文で明確に返すと扱いやすくなります。

よくある状況
  • フォーム入力のバリデーション失敗、メールアドレス重複、在庫不足、無効なフィールド値、業務ルール違反など。
  • 構文としては正しいJSONだが、必須条件、値の範囲、依存フィールド、状態遷移ルールに違反している場合。
  • APIレスポンスで、呼び出し元が入力を修正して同じエンドポイントへ再送すれば解決できる場面。
確認すること
  • まず、この状況が本当に422 Unprocessable Contentの意味に合っているか確認し、汎用的な400や409として扱っていないか見直してください。
  • リクエスト本文、フィールド値、型、業務ルール、リソース状態、関連する一意制約や状態遷移ルールを確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、フィールド別エラー、必要に応じた修正ヒント、デバッグ用のtrace IDをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーが422を生成したか確認してください。
  • 構文が壊れていて解析できない場合は400 Bad Requestを使ってください。
  • リソース状態や同時更新の競合が主因であれば409 Conflictの方が適切な場合があります。
使わないほうがよい場面
  • 壊れたJSON、解析不能な本文、必須構造の欠落などには422ではなく400 Bad Requestを使ってください。
  • Content-Typeやアップロード形式が未対応な場合は415 Unsupported Media Typeを使ってください。
  • 認証や認可の失敗を422で表現しないでください。
  • どの入力を直せばよいか分からないレスポンス本文で422を返さないでください。
出典: RFC 9110 関連コード: 400, 409, 415
423

Locked(ロック中)

対象リソースがロックされており、現在は変更できません。

4xx クライアントエラー 標準 注意して使用 RFC 4918
詳細

423 Locked(ロック中)は、対象リソースがロックされているため、現在のリクエストでは変更や操作を完了できないことを示します。WebDAV、共同編集、ファイル操作、ワークフロー管理など、リソースに明示的なロック概念がある場面で使われます。単なる権限不足や一般的な競合ではなく、誰か、または何らかの処理がリソースを保持しているため、クライアントはロック解除、期限切れ、または再試行を待つ必要があります。

よくある状況
  • WebDAVのロックにより、ファイルやコレクションを変更できない場合。
  • 共同編集ドキュメントで、別ユーザーや別セッションが編集ロックを保持している場合。
  • ファイル操作、承認フロー、ワークフロー、ジョブ処理などで、リソースが一時的にロックされている場合。
  • ロックトークンが必要な操作で、クライアントが正しいロック情報を送っていない場合。
確認すること
  • まず、この状況が本当に423 Lockedの意味に合っているか確認し、汎用的な409や403として扱っていないか見直してください。
  • リソースのロック状態、ロック所有者、ロックトークン、有効期限、関連するワークフローやジョブの状態を確認してください。
  • 安全な範囲で、ロック所有者、ロック期限、解除方法、再試行可能なタイミングをレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーが423を生成したか確認してください。
  • クライアント側では、後で再試行する、ロック保持者に通知する、正しいロックトークンを送る、または解除操作を案内するフローを用意してください。
  • WebDAVや共同編集機能では、ロック取得・更新・解除・期限切れの仕様をAPIドキュメントに明記してください。
使わないほうがよい場面
  • 単純な権限不足には423ではなく403 Forbiddenを使ってください。
  • リソース状態の一般的な競合には409 Conflictの方が適切な場合があります。
  • システムにロックという概念がない場合に423を使わないでください。
  • どのロックが原因か分からないまま423を返さないでください。
出典: RFC 4918 関連コード: 409, 424, 507
424

Failed Dependency(依存関係の失敗)

前段または依存する操作が失敗したため、このリクエストも失敗しました。

4xx クライアントエラー 標準 非推奨 RFC 4918
詳細

424 Failed Dependency(依存関係の失敗)は、同じWebDAV操作、バッチ処理、または複数ステップのリソース操作の中で、依存している前段の処理が失敗したため、現在の操作を実行できないことを示します。現在のリクエスト単体の構文や権限だけが問題なのではなく、先に成功している必要がある別の操作、リソース状態、ロック解除、作成、更新などが失敗している点が重要です。

よくある状況
  • WebDAVの複数リソース操作で、先に必要な操作が失敗したため後続操作も失敗する場合。
  • バッチAPIや複数ステップのワークフローで、前段の作成・更新・ロック解除・検証が失敗した場合。
  • あるリソースの操作が別リソースの成功状態に依存している場合。
  • 207 Multi-Statusレスポンス内で、個別項目の失敗理由として424が使われる場合。
確認すること
  • まず、この状況が本当に424 Failed Dependencyの意味に合っているか確認し、汎用的な400や409として扱っていないか見直してください。
  • どの依存操作が最初に失敗したのかを特定してください。後続の424だけでなく、根本原因になった最初のエラーを確認することが重要です。
  • APIでは、失敗した依存関係、対象リソース、前段エラーコード、再試行前に修正すべき内容をレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーが424を生成したか確認してください。
  • クライアント側では、根本原因の操作を修正または再実行してから、依存する操作を再試行してください。
  • バッチ処理では、一部成功・一部失敗の扱い、ロールバック方針、依存順序、個別エラーの返し方を明確にしてください。
使わないほうがよい場面
  • 通常の必須パラメーター不足に424を使わないでください。
  • 根本原因のエラーを隠して、すべてを424にまとめないでください。
  • 依存関係のない単独リクエストの失敗に424を使わないでください。
  • ロック自体が主原因の場合は423 Lockedを使う方が分かりやすい場合があります。
出典: RFC 4918 関連コード: 207, 409, 423
425

Too Early(早すぎるリクエスト)

リプレイされる可能性があるリクエストを、サーバーが処理したくない状態です。

4xx クライアントエラー 標準 注意して使用 RFC 8470
詳細

425 Too Early(早すぎるリクエスト)は、リクエストがTLS 0-RTT early dataとして送られた可能性があり、同じ内容が再送されると危険な副作用を起こすおそれがある場合に返されます。支払い、注文作成、在庫変更、ユーザー作成、状態更新など、冪等でない操作ではリプレイリスクが問題になります。サーバーは、安全なフルハンドシェイク後にクライアントへ再試行させるため、このコードで早期処理を拒否できます。

よくある状況
  • TLS 0-RTT early dataで、POST、PATCH、DELETEなど副作用のあるリクエストが送られた場合。
  • 支払い、注文、予約、アカウント作成、在庫更新など、重複処理されると困る操作。
  • CDN、リバースプロキシ、TLS終端、APIゲートウェイがearly dataを受け取り、オリジンがリプレイリスクを避けたい場合。
  • クライアントは同じリクエストを、early dataではなく通常の接続確立後に再送すべき場面。
確認すること
  • まず、この状況が本当に425 Too Earlyの意味に合っているか確認し、汎用的な400、409、429として扱っていないか見直してください。
  • リクエストがTLS 0-RTT early dataとして送られているか、TLS終端、CDN、プロキシ、APIゲートウェイの設定を確認してください。
  • 副作用のある操作では、early dataを無効化する、またはフルハンドシェイク後に再試行するようクライアントへ案内してください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーが425を生成したか確認してください。
  • 決済や注文などでは、Idempotency-Keyや重複防止トークンを使って、再試行しても二重処理にならない設計にしてください。
  • 安全なGETやHEADのような冪等リクエストでは、425が本当に必要か慎重に見直してください。
使わないほうがよい場面
  • 単にサービスが混雑していることを425で表現しないでください。その場合は503を検討してください。
  • レート制限には425ではなく429 Too Many Requestsを使ってください。
  • 通常の業務競合には409 Conflictを使ってください。
  • リプレイリスクが関係しない通常の入力エラーに425を使わないでください。
出典: RFC 8470 関連コード: 400, 409, 429
426

Upgrade Required(アップグレードが必要)

サーバーがリクエストを処理するには、クライアントが別のプロトコルへ切り替える必要があります。

4xx クライアントエラー 標準 注意して使用 RFC 9110
詳細

426 Upgrade Required(アップグレードが必要)は、現在のプロトコルではサーバーがリクエストを拒否するが、指定されたプロトコルへアップグレードすれば処理できる可能性があることを示します。HTTPからTLS、HTTP/1.1からHTTP/2、WebSocket、またはその他のプロトコル機能が必要な場面で使われます。レスポンスには、クライアントが何へアップグレードすべきかをUpgradeヘッダーなどで明示する必要があります。

よくある状況
  • サーバーがTLS、HTTP/2、WebSocket、または特定のプロトコル機能を要求している場合。
  • 現在のHTTPバージョンや接続方式では、そのエンドポイントを処理できない場合。
  • クライアントが古いプロトコルでアクセスしており、サーバー側がより新しいプロトコルへの切り替えを求めている場合。
  • WebSocketなど、プロトコルアップグレードの前提を満たしていないリクエストが送られた場合。
確認すること
  • まず、この状況が本当に426 Upgrade Requiredの意味に合っているか確認し、汎用的な400や505として扱っていないか見直してください。
  • UpgradeヘッダーとConnectionヘッダーを確認し、クライアントに必要なプロトコルを明示してください。
  • TLS、HTTP/2、WebSocket、gRPCなど、クライアント・プロキシ・ロードバランサー・オリジン間で必要なプロトコル設定が一致しているか確認してください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーが426を生成したか確認してください。
  • アップグレード交渉が成功した場合は、426ではなく101 Switching Protocolsが返るべき場面があります。
  • APIドキュメントでは、最低対応HTTPバージョン、TLS要件、WebSocket要件、クライアント側の設定例を明記してください。
使わないほうがよい場面
  • 通常のリダイレクト用途に426を使わないでください。URL移動には3xx系を使ってください。
  • サポート外のHTTPバージョンを表す場合は505 HTTP Version Not Supportedの方が適切なことがあります。
  • 何へアップグレードすべきかを示さずに426を返さないでください。
  • 認証、認可、入力バリデーションの失敗を426で表現しないでください。
出典: RFC 9110 関連コード: 101, 400, 505
428

Precondition Required(前提条件が必要)

サーバーは、このリクエストを条件付きリクエストとして送ることを要求しています。

4xx クライアントエラー 標準 推奨 RFC 6585
詳細

428 Precondition Required(前提条件が必要)は、lost updateや安全でない上書きを防ぐため、サーバーがIf-Match、If-Unmodified-Since、ETagなどの前提条件ヘッダーを要求していることを示します。クライアントがリソースの現在状態を確認せずに更新しようとしている場合、サーバーはこのコードで拒否し、現在の表現を取得してから条件付きで再試行するよう促せます。412 Precondition Failedが送られた条件が失敗した状態であるのに対し、428はそもそも条件が必要なのに送られていない状態です。

よくある状況
  • ETagベースの楽観的ロックを使う更新APIで、If-Matchヘッダーが必須の場合。
  • 複数クライアントが同じリソースを更新する可能性があり、lost updateを防ぎたい場合。
  • PUT、PATCH、DELETEなど、現在のリソース状態を前提にした操作で条件ヘッダーが不足している場合。
  • クライアントが古い画面や古いキャッシュをもとに上書きしないよう保護したい場合。
確認すること
  • まず、この状況が本当に428 Precondition Requiredの意味に合っているか確認し、汎用的な400や409として扱っていないか見直してください。
  • どの前提条件ヘッダーが必要なのか、If-Match、If-Unmodified-Since、ETagなどをレスポンス本文やドキュメントで明示してください。
  • クライアント側では、まず現在のリソース表現を取得し、返されたETagなどを使って条件付きリクエストを再送してください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーが428を生成したか確認してください。
  • 条件が送られているのに一致しない場合は428ではなく412 Precondition Failedを返してください。
  • APIドキュメントでは、更新系エンドポイントで必要なETag取得手順、再試行手順、競合時の扱いを明記してください。
使わないほうがよい場面
  • 通常の入力バリデーションエラーに428を使わないでください。
  • リソース状態の競合そのものを表す場合は409 Conflictの方が適切なことがあります。
  • 条件ヘッダーが送られているが評価に失敗した場合は412 Precondition Failedを使ってください。
  • 必要な前提条件を説明せずに428を返さないでください。
出典: RFC 6585 関連コード: 409, 412
429

Too Many Requests(リクエストが多すぎます)

一定時間内にクライアントが送信したリクエスト数が多すぎます。

4xx クライアントエラー 標準 推奨 RFC 6585
詳細

429 Too Many Requests(リクエストが多すぎます)は、サーバーがクライアント、ユーザー、IP、tenant、API key、ルート単位などでレート制限を適用していることを示します。ログイン試行、SMSコード送信、API呼び出し、クローラー制御、bot対策、tenantごとのクォータ保護などでよく使われます。クライアントが後で安全に再試行できる場合は、Retry-Afterやレート制限ヘッダー、レスポンス本文で再試行タイミングや残り上限を明示すると扱いやすくなります。

よくある状況
  • API rate limit、ログイン試行のスロットリング、SMSコード送信制限、bot対策、クローラー制御、tenantごとのクォータ保護など。
  • ユーザー、IP、API key、tenant、endpoint、組織単位など、特定の粒度で短時間のリクエスト数が上限を超えた場合。
  • クライアントが即時リトライループを避け、待機、指数バックオフ、キャッシュ、キューイングを行うべき場面。
確認すること
  • まず、この状況が本当に429 Too Many Requestsの意味に合っているか確認し、汎用的な403や503として扱っていないか見直してください。
  • レート制限の単位(ユーザー、IP、API key、tenant、endpoint)、上限、残り回数、リセット時刻、ブロック時間を確認してください。
  • 可能であれば、Retry-After、RateLimit-Limit、RateLimit-Remaining、RateLimit-Resetなどのヘッダーや、同等の情報をレスポンス本文で返してください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーが429を生成したか確認してください。
  • クライアント側では、即時リトライを避け、指数バックオフ、jitter、リクエストの集約、キャッシュ、重複リクエスト抑制を導入してください。
  • ログインやSMSコードなどの悪用されやすい操作では、ユーザー体験を壊さない範囲で、セキュリティ上必要な制限と案内文を設計してください。
使わないほうがよい場面
  • 一般的なサービス停止やメンテナンスには429ではなく503 Service Unavailableを使う方が適切です。
  • 権限不足やポリシー拒否には429ではなく403 Forbiddenを使ってください。
  • クライアントが後で再試行できる場合に、再試行の目安をまったく示さず429を返さないでください。
  • サーバー側の処理例外や上流障害を429で隠さないでください。
出典: RFC 6585 関連コード: 403, 503
430

Request Header Fields Too Large(リクエストヘッダーが大きすぎます)

リクエストヘッダーが大きすぎる、またはプラットフォーム固有のルールで拒否されています。

4xx クライアントエラー 非標準 非推奨 Non-standard platform convention
詳細

430 Request Header Fields Too Large(リクエストヘッダーが大きすぎます)は、IANAに登録された標準HTTPステータスコードではありません。非標準のプラットフォーム慣例や実装固有の拡張として使われることがあり、Cookie、Authorization、カスタムヘッダーなどが大きすぎる、またはプラットフォーム固有のセキュリティルールで拒否されたことを示す場合があります。移植性のあるREST API契約としては扱わず、新しいシステムでは標準の431 Request Header Fields Too Largeを使う方が分かりやすいです。

よくある状況
  • 非標準のプラットフォームや中間層が、巨大なCookie、Authorizationヘッダー、カスタムヘッダーを拒否する場合。
  • セキュリティレイヤー、WAF、CDN、APIゲートウェイがオリジンへ到達する前にリクエストを拒否する場合。
  • 古いプラットフォームや独自実装が、標準の431ではなく430を返す場合。
確認すること
  • まず、このレスポンスがオリジンアプリケーションではなく、非標準のプラットフォーム慣例や中間層によって生成されたものか確認してください。
  • オリジンアプリケーションログと、CDN、ゲートウェイ、プロキシ、ロードバランサー、Webサーバーログを比較してください。
  • Cookie、Authorization、トレーシングヘッダー、カスタムヘッダー、リクエスト行のサイズを確認してください。
  • 公開APIでは、この状態を標準の431へマッピングし、実装固有の理由はレスポンス本文やログに残すことを検討してください。
  • 不要なCookieやヘッダーを削除し、トークンやトレーシング情報が過剰に増えていないか確認してください。
  • CDN、ゲートウェイ、Nginx、アプリケーションフレームワークのヘッダーサイズ制限を確認してください。
使わないほうがよい場面
  • 新しいシステムで430を優先して使わないでください。標準的には431を使います。
  • リクエスト本文が大きすぎる場合に430を使わないでください。その場合は413 Content Too Largeを使ってください。
  • URLが長すぎる場合は414 URI Too Longを検討してください。
  • 430をRFC標準のHTTPステータスコードとして説明しないでください。どの製品やプラットフォームが生成しているのかを明記してください。
出典: Non-standard platform convention 関連コード: 400, 431, 494
431

Request Header Fields Too Large(リクエストヘッダーが大きすぎます)

1つ以上のリクエストヘッダーフィールドが大きすぎます。

4xx クライアントエラー 標準 推奨 RFC 6585
詳細

431 Request Header Fields Too Large(リクエストヘッダーが大きすぎます)は、個別のヘッダー、またはヘッダー全体のサイズが大きすぎるため、サーバーがリクエストを拒否したことを示します。巨大なCookie、長すぎるAuthorization値、多すぎるカスタムヘッダー、トレーシングヘッダーの肥大化などで発生しやすいコードです。サーバー、CDN、ゲートウェイ、Nginx、アプリケーションフレームワークの制限に引っかかる場合があり、本文サイズの問題である413やURL長の問題である414とは区別します。

よくある状況
  • Cookieが肥大化して、ブラウザが毎回大きなCookieヘッダーを送っている場合。
  • Authorizationヘッダー、JWT、API key、署名情報、トレーシングヘッダーが大きすぎる場合。
  • カスタムヘッダーが多すぎる、またはプロキシを通るたびにヘッダーが追加されている場合。
  • CDN、APIゲートウェイ、Nginx、ロードバランサー、アプリケーションフレームワークのヘッダーサイズ制限に達した場合。
確認すること
  • まず、この状況が本当に431 Request Header Fields Too Largeの意味に合っているか確認し、汎用的な400、414、494として扱っていないか見直してください。
  • Cookie、Authorization、トレーシングヘッダー、カスタムヘッダー、リクエスト行のサイズを確認してください。
  • 不要なCookieを削除し、Cookieに保存するデータ量を減らし、セッション情報はサーバー側に置く設計を検討してください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーが431を生成したか確認してください。
  • Nginx、CDN、APIゲートウェイ、フレームワークのヘッダーサイズ制限を確認し、正当な用途で必要なら上限調整を検討してください。
  • トレーシングやプロキシ転送でヘッダーが重複・累積していないか確認してください。
使わないほうがよい場面
  • リクエスト本文が大きすぎる場合は431ではなく413 Content Too Largeを使ってください。
  • URLやクエリ文字列が長すぎる場合は414 URI Too Longを使ってください。
  • 通常の入力バリデーションエラーに431を使わないでください。
  • Cookieやtracking dataが無制限に増える設計を放置しないでください。
出典: RFC 6585 関連コード: 400, 414, 494
440

Login Time-out(ログインタイムアウト)

ログインセッションがタイムアウトしたため、ユーザーは再認証する必要があります。

4xx クライアントエラー 非標準 注意して使用 Microsoft IIS
詳細

440 Login Time-out(ログインタイムアウト)は、IANAに登録された標準HTTPステータスコードではありません。Microsoft IISやExchange系の環境で使われる実装固有の非標準コードで、ログインセッションが期限切れになり、ユーザーが再度認証する必要がある状態を示すことがあります。移植性のあるREST API契約として扱うべきではなく、ブラウザ、HTTPクライアント、監視ツール、クローラー、中間プロキシが一貫して理解するとは限りません。公開APIでは、通常は401 Unauthorizedなどの標準コードへマッピングする方が安全です。

よくある状況
  • Microsoft IIS、Exchange、OWA、社内ポータルなどでログインセッションが期限切れになった場合。
  • SSOやリバースプロキシ配下のエンタープライズアプリで、認証セッションの再確立が必要な場合。
  • ユーザーが長時間操作せず、既存セッションが無効化された後にリクエストした場合。
確認すること
  • まず、このレスポンスがMicrosoft IISやExchange系の環境で生成されたものか、アプリケーション独自のエラーかを確認してください。
  • オリジンアプリケーションログと、CDN、ゲートウェイ、プロキシ、ロードバランサー、Webサーバーログを比較してください。
  • セッション有効期限、Cookie、リバースプロキシ設定、SSO設定、認証ミドルウェア、タイムアウト設定を確認してください。
  • 公開APIでは、この状態を401 Unauthorizedなどの標準コードにマッピングし、実装固有の理由はレスポンス本文やログに残すことを検討してください。
  • ユーザー向け画面では、再ログインしてセッションを更新する導線を用意してください。
  • SPAやモバイルアプリでは、セッション期限切れ時に再認証フローへ自然に遷移できるようにしてください。
使わないほうがよい場面
  • 440を標準HTTP認証セマンティクスとして扱わないでください。
  • 公開APIでは通常、440ではなく401 Unauthorizedを使う方が分かりやすいです。
  • 権限不足を440で表現しないでください。その場合は403 Forbiddenを検討してください。
  • 440をRFC標準のHTTPステータスコードとして説明しないでください。どの製品やサーバーが生成しているのかを明記してください。
出典: Microsoft IIS 関連コード: 401, 403, 419
444

No Response(レスポンスなし)

Nginxがレスポンスを送らずに接続を閉じました。

4xx クライアントエラー 非標準 非推奨 Nginx
詳細

444 No Response(レスポンスなし)は、IANAに登録された標準HTTPステータスコードではありません。Nginx固有の非標準コードで、NginxがクライアントへHTTPレスポンスを返さず、そのまま接続を閉じたことを示します。悪意あるリクエスト、スキャナー、不正なHost、セキュリティルールに一致した通信を黙って切断する目的で使われることがあります。アプリケーションが返したビジネスエラーではなく、Nginx設定やセキュリティ層の挙動として扱う必要があります。

よくある状況
  • Nginx設定でreturn 444を使い、特定のリクエストを黙って切断している場合。
  • 不正なHostヘッダー、スキャナー、bot、明らかに悪意あるリクエスト、WAF相当のルールに一致した場合。
  • 正当なヘルスチェック、クローラー、ユーザーリクエストが誤ってブロックされている場合。
確認すること
  • まず、このレスポンスがオリジンアプリケーションではなくNginxによって生成されたものか確認してください。
  • オリジンアプリケーションログと、Nginx access log、error log、CDN、ゲートウェイ、プロキシ、ロードバランサーログを比較してください。
  • Nginxのserver_name、return 444、location、map、WAFルール、アクセス制御、Host検証ルールを確認してください。
  • 正当なクライアント、ヘルスチェック、クローラー、監視ツールが誤って444で切断されていないか確認してください。
  • 公開APIでは、必要に応じて403、400、404などの標準コードへマッピングし、理由をログに残すことを検討してください。
  • セキュリティ目的で444を使う場合でも、運用ログではどのルールが接続を閉じたか追跡できるようにしてください。
使わないほうがよい場面
  • アプリケーションコードから444を返さないでください。
  • 444をオリジンアプリケーションのビジネスエラーとして扱わないでください。
  • ヘルスチェック、クローラー、正当なユーザーを誤ってブロックしないようにしてください。
  • 444をRFC標準のHTTPステータスコードとして説明しないでください。Nginx固有の挙動であることを明記してください。
出典: Nginx 関連コード: 400, 403, 499
449

Retry With(追加情報付きで再試行)

リクエストを再試行する前に、追加情報が必要です。

4xx クライアントエラー 非標準 非推奨 Microsoft IIS
詳細

449 Retry With(追加情報付きで再試行)は、IANAに登録された標準HTTPステータスコードではありません。Microsoft IIS拡張として知られる非標準コードで、クライアントが追加情報や前提条件を付けて再試行する必要があることを示す場合があります。ただし、どの情報が必要かは標準化されていないため、移植性のあるREST API契約として使うべきではありません。新しい公開APIでは、状況に応じて400、401、403、409、428などの標準コードを使い、必要な情報をレスポンス本文で明確に説明する方が分かりやすいです。

よくある状況
  • Microsoft IIS拡張やレガシーシステムが、追加情報付きの再試行を求める場合。
  • リクエストに必要な前提情報、認証情報、確認情報、または条件が不足している場合。
  • 古いMicrosoft関連サービスや社内システムが、標準コードではなく449を返す場合。
確認すること
  • まず、このレスポンスがMicrosoft IIS拡張やレガシー実装によって生成されたものか、アプリケーション独自のエラーかを確認してください。
  • オリジンアプリケーションログと、CDN、ゲートウェイ、プロキシ、ロードバランサー、Webサーバーログを比較してください。
  • レスポンス本文、プラットフォームドキュメント、サーバーログを確認し、再試行時に何を追加すべきか特定してください。
  • 公開APIでは、この状態を400、401、403、409、428などの標準コードへマッピングし、必要な追加情報をレスポンス本文に明記してください。
  • クライアント側では、何を補って再試行すべきか分からないまま自動リトライしないでください。
  • 新しいAPI設計では449に依存せず、標準コードと構造化エラー本文で表現してください。
使わないほうがよい場面
  • 新しい公開APIで449を使わないでください。
  • 何を追加して再試行すべきか説明せずに449を返さないでください。
  • 通常の認証エラーや権限不足を449で曖昧にしないでください。
  • 449をRFC標準のHTTPステータスコードとして説明しないでください。どの製品やサーバーが生成しているのかを明記してください。
出典: Microsoft IIS 関連コード: 400, 401, 428
450

Blocked by Windows Parental Controls(Windows保護者制限によるブロック)

Windowsの保護者制限に類似したポリシーにより、アクセスがブロックされています。

4xx クライアントエラー 非標準 非推奨 Microsoft IIS
詳細

450 Blocked by Windows Parental Controls(Windows保護者制限によるブロック)は、IANAに登録された標準HTTPステータスコードではありません。MicrosoftまたはWindows系の環境に関連する非標準・実装固有のコードで、Windowsの保護者制限に類似したローカルポリシー、エンタープライズポリシー、セキュリティソフトなどによりアクセスがブロックされたことを示す場合があります。移植性のあるREST API契約として扱うべきではなく、通常のアプリケーションエラーや法的ブロックとは切り分けて考える必要があります。

よくある状況
  • Windows、Microsoft系コンポーネント、古いクライアント環境、またはローカルポリシーがアクセスをブロックする場合。
  • 保護者制限、企業ポリシー、端末管理、セキュリティソフト、ブラウザ制御によりリクエストが止められる場合。
  • オリジンアプリケーションではなく、ユーザー端末や企業ネットワーク側の制御が原因でアクセスできない場合。
確認すること
  • まず、このレスポンスがMicrosoftまたはWindows系の環境、ローカルポリシー、セキュリティソフトによって生成されたものか確認してください。
  • オリジンアプリケーションログと、CDN、ゲートウェイ、プロキシ、ロードバランサー、Webサーバーログを比較し、アプリケーションまで到達しているか確認してください。
  • ローカルOSポリシー、ブラウザの保護者制限、エンタープライズポリシー、セキュリティソフト、ネットワークフィルターを確認してください。
  • 公開APIでは、この状態を非標準の450として露出せず、必要に応じて403や451などの標準コードへマッピングすることを検討してください。
  • まずオリジンアプリケーションのコードを疑うのではなく、端末・ブラウザ・企業ポリシー・セキュリティレイヤー側の制御を確認してください。
使わないほうがよい場面
  • 法的な理由でブロックしている場合は450ではなく451 Unavailable For Legal Reasonsを使ってください。
  • 現代的なAPI設計で450を新たに使わないでください。
  • 通常の権限不足や認可エラーを450で表現しないでください。その場合は403 Forbiddenを検討してください。
  • 450をRFC標準のHTTPステータスコードとして説明しないでください。どの製品や環境が生成しているのかを明記してください。
出典: Microsoft IIS 関連コード: 403, 451
451

Unavailable For Legal Reasons(法的理由により利用不可)

法的要求または法的制限により、リソースを提供できません。

4xx クライアントエラー 標準 注意して使用 RFC 7725
詳細

451 Unavailable For Legal Reasons(法的理由により利用不可)は、裁判所命令、著作権申し立て、規制上の制限、地域ごとの法的ブロック、コンプライアンス上の削除要請など、法的理由によりサーバーがリソースを提供できないことを示します。単なる権限不足や技術的な障害ではなく、法的制約がアクセス不能の主因であることをクライアントやクローラーに伝えるためのコードです。必要かつ安全な範囲で、対象地域、法的根拠、問い合わせ先、異議申し立て手段などをレスポンス本文に含めることがあります。

よくある状況
  • 著作権申し立て、裁判所命令、規制上の制限、地域別ブロック、コンプライアンス上の削除要請など。
  • Webサイト、API、クローラー、ログで、リソースが存在しないのではなく法的理由により提供できないことを明示したい場合。
  • 一部の国や地域、ユーザー区分、法域に対してのみアクセスを制限する必要がある場合。
確認すること
  • まず、この状況が本当に451 Unavailable For Legal Reasonsの意味に合っているか確認し、汎用的な403、404、410として扱っていないか見直してください。
  • 対象リソース、適用地域、法的根拠、ブロックの主体、社内コンプライアンス記録を確認してください。
  • 必要かつ安全な範囲で、法的理由、影響範囲、問い合わせ先、異議申し立てや再審査の導線をレスポンス本文に含めてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーが451を生成したか確認してください。
  • リソースの存在を明かすこと自体が不適切な場合は、451ではなく404 Not Foundを返す方が安全な場合があります。
  • SEOやクローラーへの影響を考慮し、誤って通常の404や一時的な5xxとして返していないか確認してください。
使わないほうがよい場面
  • 通常の権限不足には451ではなく403 Forbiddenを使ってください。
  • 削除済みリソースには410 Gone、存在しないリソースには404 Not Foundを検討してください。
  • 技術的な障害やメンテナンスを451で隠さないでください。
  • 法的理由を示すべきでない、または示すと危険な場合は、レスポンス本文の情報量に注意してください。
出典: RFC 7725 関連コード: 403, 404, 410
460

Client Closed Connection(クライアントが接続を閉じました)

ロードバランサーがレスポンスを返す前に、クライアントが接続を閉じました。

4xx クライアントエラー 非標準 非推奨 AWS Elastic Load Balancing
詳細

460 Client Closed Connection(クライアントが接続を閉じました)は、IANAに登録された標準HTTPステータスコードではありません。AWS Elastic Load Balancingの非標準・ベンダー固有コードで、ロードバランサーがレスポンスを返す前に、ブラウザ、モバイルアプリ、APIクライアントなどが接続を閉じたことを示します。オリジンアプリケーションが通常のHTTPレスポンスとして返したコードではなく、ALBアクセスログやロードバランサー側のタイミング情報と合わせて読む必要があります。

よくある状況
  • ブラウザ、モバイルアプリ、APIクライアントが、ALBのレスポンス前にリクエストをキャンセルした場合。
  • フロントエンドやクライアントのタイムアウトが、バックエンド処理時間より短い場合。
  • モバイルネットワークの切断、ページ遷移、ユーザーによるキャンセル、AbortControllerなどで接続が閉じられた場合。
  • ALBは待っていたが、オリジンからの応答前にクライアント側が切断した場合。
確認すること
  • まず、このレスポンスがAWS Elastic Load Balancingによって生成されたものか確認してください。
  • ALB access logs、request_processing_time、target_processing_time、response_processing_time、target status codeを確認してください。
  • オリジンアプリケーションログとALBログを比較し、アプリケーションが実際にリクエストを処理したか、レスポンスを返したかを確認してください。
  • フロントエンドのtimeout設定、モバイルネットワーク状況、ブラウザのリクエストキャンセル、バックエンド遅延を確認してください。
  • 処理が長いエンドポイントでは、バックエンドのレイテンシ改善、非同期化、進捗通知、202 Acceptedフローを検討してください。
  • 公開APIでは、460をAPI契約として扱わず、ロードバランサーログ上の診断シグナルとして扱ってください。
使わないほうがよい場面
  • 460をオリジンアプリケーションが返したレスポンスとして扱わないでください。
  • ALBログを確認せずにアプリケーションの500エラーとして調査しないでください。
  • クライアント側のタイムアウト、ページ遷移、モバイル切断、リクエストキャンセルを無視しないでください。
  • 460をRFC標準のHTTPステータスコードとして説明しないでください。AWS Elastic Load Balancing固有のコードであることを明記してください。
出典: AWS Elastic Load Balancing 関連コード: 408, 499, 504
463

Too Many IP Addresses(IPアドレスが多すぎます)

転送されたIPヘッダーに含まれるIPアドレス数が多すぎます。

4xx クライアントエラー 非標準 非推奨 AWS Elastic Load Balancing
詳細

463 Too Many IP Addresses(IPアドレスが多すぎます)は、IANAに登録された標準HTTPステータスコードではありません。AWS Elastic Load Balancingの非標準・ベンダー固有コードで、X-Forwarded-Forなどの転送IPヘッダーに含まれるIPアドレス数が多すぎる場合に返されることがあります。プロキシチェーンが長すぎる、複数の中間層が繰り返しIPを追記している、またはクライアントや中間層がヘッダーを汚染している場合に発生します。

よくある状況
  • X-Forwarded-Forが多数のプロキシを通過して長くなりすぎた場合。
  • 複数のCDN、プロキシ、ゲートウェイ、ロードバランサーが同じ転送IPヘッダーへ繰り返し追記している場合。
  • クライアントや中間層がX-Forwarded-Forを不正に注入、重複、または汚染している場合。
  • ALBが転送IPヘッダーのIPアドレス数を過剰と判断し、オリジンへ転送する前に拒否した場合。
確認すること
  • まず、このレスポンスがAWS Elastic Load Balancingによって生成されたものか確認してください。
  • ALB access logsと、CDN、プロキシ、APIゲートウェイ、オリジンのログを比較し、どの層でX-Forwarded-Forが増えているか確認してください。
  • X-Forwarded-For、Forwarded、X-Real-IPなどの転送ヘッダーを確認し、重複・注入・過剰な追記がないか調べてください。
  • プロキシチェーンを整理し、信頼できるプロキシだけが転送IPヘッダーを設定・追記するようにしてください。
  • クライアントから送られた偽のX-Forwarded-Forをそのまま信用せず、境界プロキシで上書きまたは正規化してください。
  • 公開APIでは、463をAPI契約として扱わず、ロードバランサーログ上の診断シグナルとして扱ってください。
使わないほうがよい場面
  • 463を通常の入力パラメーターバリデーションエラーとして扱わないでください。
  • ヘッダー注入や信頼できないX-Forwarded-Forの可能性を無視しないでください。
  • URL長や本文サイズの問題と混同しないでください。
  • 463をRFC標準のHTTPステータスコードとして説明しないでください。AWS Elastic Load Balancing固有のコードであることを明記してください。
出典: AWS Elastic Load Balancing 関連コード: 400, 431, 494
464

Incompatible Protocols(互換性のないプロトコル)

クライアント、ロードバランサー、ターゲットグループのプロトコル設定が一致していません。

4xx クライアントエラー 非標準 非推奨 AWS Elastic Load Balancing
詳細

464 Incompatible Protocols(互換性のないプロトコル)は、IANAに登録された標準HTTPステータスコードではありません。AWS Elastic Load Balancingの非標準・ベンダー固有コードで、クライアント、ロードバランサー、ターゲットグループ、バックエンドサービスのプロトコル設定が互換していない場合に返されることがあります。HTTP/1.1、HTTP/2、gRPC、TLS、ターゲットグループのprotocol version、リスナー設定の不一致が主な原因です。オリジンアプリケーションの通常の500ではなく、ALB設定とバックエンドプロトコルの整合性を確認する必要があります。

よくある状況
  • ALBリスナー、ターゲットグループ、バックエンドサービスのHTTP/1.1、HTTP/2、gRPC、TLS設定が一致していない場合。
  • gRPCサービスにHTTP/1.1として転送している、またはHTTPサービスにgRPCとして転送している場合。
  • ターゲットグループのprotocol versionと、実際のバックエンドサーバーが受け付けるプロトコルが異なる場合。
  • ロードバランサーやプロキシのTLS終端、ALPN、バックエンド通信方式の設定が誤っている場合。
確認すること
  • まず、このレスポンスがAWS Elastic Load Balancingによって生成されたものか確認してください。
  • ALB access logs、リスナー設定、ターゲットグループのprotocol、protocol version、ヘルスチェック設定を確認してください。
  • バックエンドサービスが実際にHTTP/1.1、HTTP/2、gRPC、TLSのどれを受け付けているか確認してください。
  • オリジンアプリケーションログとALBログを比較し、リクエストがバックエンドまで到達しているか、ALB側で拒否されているかを切り分けてください。
  • gRPC、HTTP/2、TLS、ALPN、ターゲットグループ設定が、クライアントからバックエンドまで一貫しているか確認してください。
  • 公開APIでは、464をAPI契約として扱わず、ロードバランサーログ上の診断シグナルとして扱ってください。
使わないほうがよい場面
  • 464をオリジンアプリケーションの500エラーとして誤診しないでください。
  • ALBやターゲットグループ設定が間違っているのに、アプリケーションコードだけを修正しようとしないでください。
  • 通常の入力エラー、認証エラー、権限不足を464で表現しないでください。
  • 464をRFC標準のHTTPステータスコードとして説明しないでください。AWS Elastic Load Balancing固有のコードであることを明記してください。
出典: AWS Elastic Load Balancing 関連コード: 400, 426, 502
494

Request Header Too Large(リクエストヘッダーが大きすぎます)

Nginxが、ヘッダーが大きすぎるためリクエストを拒否しました。

4xx クライアントエラー 非標準 非推奨 Nginx
詳細

494 Request Header Too Large(リクエストヘッダーが大きすぎます)は、IANAに登録された標準HTTPステータスコードではありません。Nginx固有の非標準コードで、Cookie、リクエストヘッダー、またはリクエスト行がNginxの許容サイズを超えた場合に使われることがあります。標準の431 Request Header Fields Too Largeに近い意味ですが、Nginxの内部的・実装固有の診断シグナルとして扱うべきです。

よくある状況
  • ブラウザが肥大化したCookieを毎回送信している場合。
  • Authorizationヘッダー、JWT、トレーシングヘッダー、カスタムヘッダー、リクエスト行がNginxの制限を超えている場合。
  • large_client_header_buffersや関連するNginx設定の上限に達した場合。
  • CDNやプロキシを通るたびにヘッダーが増え、Nginxで拒否される場合。
確認すること
  • まず、このレスポンスがオリジンアプリケーションではなくNginxによって生成されたものか確認してください。
  • Nginx access log、error log、CDN、ゲートウェイ、プロキシ、ロードバランサー、オリジンアプリケーションログを比較してください。
  • Cookie、Authorization、トレーシングヘッダー、カスタムヘッダー、リクエスト行のサイズを確認してください。
  • 不要なCookieやヘッダーを削除し、セッション情報や大きな状態をCookieに詰め込みすぎていないか見直してください。
  • large_client_header_buffers、client_header_buffer_sizeなどのNginx設定を確認し、正当な用途で必要なら上限調整を検討してください。
  • 公開APIでは、494を直接露出するより、標準の431へマッピングして説明することを検討してください。
使わないほうがよい場面
  • リクエスト本文が大きすぎる場合に494を使わないでください。その場合は413 Content Too Largeを使ってください。
  • URLやクエリ文字列が長すぎる場合は414 URI Too Longを検討してください。
  • 494と標準の431の関係を説明せずに公開API仕様へ載せないでください。
  • 494をRFC標準のHTTPステータスコードとして説明しないでください。Nginx固有のコードであることを明記してください。
出典: Nginx 関連コード: 400, 431, 414
495

SSL Certificate Error(SSL証明書エラー)

Nginxがクライアント証明書の検証中にエラーを検出しました。

4xx クライアントエラー 非標準 非推奨 Nginx
詳細

495 SSL Certificate Error(SSL証明書エラー)は、IANAに登録された標準HTTPステータスコードではありません。Nginx固有の非標準コードで、mTLSなどで提示されたクライアント証明書の検証に失敗した場合に使われることがあります。証明書チェーン、信頼されたCA、期限切れ、署名、失効状態、ssl_client_certificate設定などが原因になり得ます。通常のログイン失敗ではなく、TLSクライアント証明書検証の失敗として扱う必要があります。

よくある状況
  • mTLSエンドポイントで、クライアント証明書のチェーンや署名検証に失敗した場合。
  • クライアント証明書が期限切れ、失効済み、信頼されていないCAで発行されている場合。
  • Nginxのssl_client_certificate、ssl_verify_client、CA bundle設定が誤っている場合。
  • 証明書は提示されたが、対象環境や認証ポリシーに合っていない場合。
確認すること
  • まず、このレスポンスがオリジンアプリケーションではなくNginxによって生成されたものか確認してください。
  • Nginx access log、error log、TLS設定、証明書検証ログを確認してください。
  • クライアント証明書、秘密鍵、証明書チェーン、CA bundle、有効期限、失効状態、署名アルゴリズムを確認してください。
  • ssl_client_certificate、ssl_verify_client、ssl_verify_depthなどのNginx TLS設定を確認してください。
  • mTLSが本当に必要なエンドポイントか、対象クライアントに正しい証明書が配布されているか確認してください。
  • 公開APIでは、495をAPI契約として扱わず、TLS終端やNginxログ上の診断シグナルとして扱ってください。
使わないほうがよい場面
  • 通常のID/パスワードログイン失敗に495を使わないでください。
  • Bearer tokenやAPI keyの不正を495で表現しないでください。その場合は401または403を検討してください。
  • Cloudflare 526など、別サービスの証明書検証エラーと混同しないでください。
  • 495をRFC標準のHTTPステータスコードとして説明しないでください。Nginx固有のコードであることを明記してください。
出典: Nginx 関連コード: 401, 403, 496, 526
496

SSL Certificate Required(SSL証明書が必要)

Nginxがクライアント証明書を要求しましたが、提示されませんでした。

4xx クライアントエラー 非標準 非推奨 Nginx
詳細

496 SSL Certificate Required(SSL証明書が必要)は、IANAに登録された標準HTTPステータスコードではありません。Nginx固有の非標準コードで、mTLSなどでクライアント証明書が必須にもかかわらず、クライアントが証明書を提示しなかった場合に使われることがあります。これは通常のBearer tokenやCookie認証の失敗ではなく、TLSハンドシェイク時のクライアント証明書要件に関する問題です。

よくある状況
  • mTLS必須のエンドポイントに、クライアント証明書なしでアクセスした場合。
  • ブラウザ、curl、SDK、APIクライアントが証明書を送信する設定になっていない場合。
  • Nginxのssl_verify_client設定により、クライアント証明書が必須になっている場合。
  • 証明書は端末に存在するが、対象リクエストで選択・送信されていない場合。
確認すること
  • まず、このレスポンスがオリジンアプリケーションではなくNginxによって生成されたものか確認してください。
  • Nginx access log、error log、TLSハンドシェイクログ、ssl_verify_client設定を確認してください。
  • クライアント側で証明書と秘密鍵が正しく設定され、対象リクエストで提示されているか確認してください。
  • curl、ブラウザ、SDK、モバイルアプリ、バックエンドクライアントのmTLS設定を確認してください。
  • mTLSが不要なエンドポイントで496が出ている場合は、NginxのlocationやserverブロックのTLS設定を見直してください。
  • 公開APIでは、496をAPI契約として扱わず、TLS終端やNginxログ上の診断シグナルとして扱ってください。
使わないほうがよい場面
  • Bearer token、API key、Cookieがない場合に496を使わないでください。その場合は401 Unauthorizedを検討してください。
  • mTLSが関係しない通常の認証失敗に496を使わないでください。
  • 証明書が提示されたが検証に失敗した場合は496ではなく495 SSL Certificate Errorに近いです。
  • 496をRFC標準のHTTPステータスコードとして説明しないでください。Nginx固有のコードであることを明記してください。
出典: Nginx 関連コード: 401, 403, 495
497

HTTP Request Sent to HTTPS Port(HTTPSポートへのHTTPリクエスト)

HTTPS用ポートに、暗号化されていない通常のHTTPリクエストが送られました。

4xx クライアントエラー 非標準 非推奨 Nginx
詳細

497 HTTP Request Sent to HTTPS Port(HTTPSポートへのHTTPリクエスト)は、IANAに登録された標準HTTPステータスコードではありません。Nginx固有の非標準コードで、TLSを前提とするHTTPSポートに対して、暗号化されていない通常のHTTPリクエストが送られた場合に使われることがあります。アプリケーションのビジネスロジックではなく、ポート、リスナー、TLS終端、リダイレクト設定、プロキシ設定の不一致として調査する必要があります。

よくある状況
  • ユーザー、クライアント、プロキシがhttps://ではなくhttp://でHTTPS専用ポートへアクセスした場合。
  • ロードバランサー、リバースプロキシ、Nginxのリスナー設定でHTTP/HTTPSの対応がずれている場合。
  • TLS終端の位置、ポート転送、リダイレクト設定が誤っており、平文HTTPがTLS必須のポートに届いている場合。
確認すること
  • まず、このレスポンスがオリジンアプリケーションではなくNginxによって生成されたものか確認してください。
  • Nginx access log、error log、server block、listen設定、TLS設定、リダイレクト設定を確認してください。
  • クライアントのURLがhttps://になっているか、ポート番号が正しいか、プロキシやロードバランサーの転送先が正しいか確認してください。
  • CDN、リバースプロキシ、ロードバランサー、Nginx間で、HTTPとHTTPSの終端・転送方式が一貫しているか確認してください。
  • 必要に応じてHTTPからHTTPSへの301/308リダイレクトを正しく設定してください。
  • 公開APIでは、497をAPI契約として扱わず、Nginxログ上の診断シグナルとして扱ってください。
使わないほうがよい場面
  • 497をアプリケーションのビジネスロジックとして扱わないでください。
  • バックエンドコードで497を再現しようとしないでください。
  • 通常の認証エラー、権限不足、入力エラーを497で表現しないでください。
  • 497をRFC標準のHTTPステータスコードとして説明しないでください。Nginx固有のコードであることを明記してください。
出典: Nginx 関連コード: 400, 426, 301
498

Invalid Token(無効なトークン)

トークンが無効、期限切れ、または受け付けられません。

4xx クライアントエラー 非標準 注意して使用 Esri ArcGIS
詳細

498 Invalid Token(無効なトークン)は、IANAに登録された標準HTTPステータスコードではありません。Esri ArcGISや一部のカスタムAPI慣例で使われる非標準コードで、アクセストークンが無効、期限切れ、署名不一致、環境違い、スコープ不足などの理由で受け付けられないことを示す場合があります。公開APIでは通常、401 Unauthorizedまたは403 Forbiddenを使い、実装固有の理由はレスポンス本文で表す方が移植性があります。

よくある状況
  • Esri ArcGISや互換APIが、無効または期限切れのtokenを拒否する場合。
  • トークンの署名、期限、発行環境、audience、issuer、scope、permissionが期待値と一致しない場合。
  • APIゲートウェイや認証レイヤーが、アプリケーションへ到達する前にトークンを拒否する場合。
確認すること
  • まず、このレスポンスがEsri ArcGISやカスタムAPI慣例によって生成されたものか、現在のアプリケーション独自のエラーかを確認してください。
  • オリジンアプリケーションログと、CDN、ゲートウェイ、プロキシ、ロードバランサー、認証レイヤーのログを比較してください。
  • 新しいトークンを取得し、Authorizationヘッダーやtokenパラメーターが正しく送られているか確認してください。
  • 署名鍵、期限、clock skew、issuer、audience、scope、permission、環境の不一致を確認してください。
  • 公開APIでは、498を直接露出するより、401または403へマッピングして、詳細な理由を構造化エラー本文で返すことを検討してください。
  • クライアント側では、期限切れ時の更新フロー、再ログイン、トークン再取得、権限不足時の案内を明確にしてください。
使わないほうがよい場面
  • 新しい公開APIで498を前提にしないでください。通常は401または403の方が分かりやすいです。
  • 認証と無関係な入力バリデーションエラーに498を使わないでください。
  • トークンの有効期限切れ、署名不一致、権限不足を区別できないレスポンス本文で498を返さないでください。
  • 498をRFC標準のHTTPステータスコードとして説明しないでください。どの製品やAPI慣例が生成しているのかを明記してください。
出典: Esri ArcGIS 関連コード: 401, 403, 419
499

Client Closed Request(クライアントがリクエストを閉じました)

サーバーが応答する前に、クライアントがリクエストを閉じました。

4xx クライアントエラー 非標準 非推奨 Nginx
詳細

499 Client Closed Request(クライアントがリクエストを閉じました)は、IANAに登録された標準HTTPステータスコードではありません。Nginx固有の非標準コードで、Nginxが上流サーバーの応答を待っている間に、ブラウザ、モバイルアプリ、APIクライアントなどが接続を閉じたことを示します。ユーザーのページ遷移、ブラウザのキャンセル、AbortController、フロントエンドのtimeout、モバイルネットワーク切断などが原因になり得ます。これはサーバーがクライアントへ返した通常のHTTPレスポンスではなく、Nginxログ上の診断シグナルとして扱います。

よくある状況
  • ユーザーがページを閉じる、ページ遷移する、ブラウザがリクエストをキャンセルする場合。
  • フロントエンドコードがAbortControllerやtimeoutでリクエストを中断した場合。
  • モバイルネットワークの切断、クライアント側タイムアウト、アプリのバックグラウンド化により接続が閉じられた場合。
  • Nginxが上流の応答を待っている間に、クライアント側が先に切断した場合。
確認すること
  • まず、このレスポンスがオリジンアプリケーションではなくNginxによって記録されたものか確認してください。
  • Nginx access logのrequest_time、upstream_response_time、status、upstream_statusを確認してください。
  • オリジンアプリケーションログとNginxログを比較し、アプリケーションが実際に処理を完了したか、例外を出したかを確認してください。
  • フロントエンドのtimeout設定、AbortController、ページ遷移、モバイルネットワーク、ブラウザのキャンセル挙動を確認してください。
  • 遅いエンドポイントでは、処理時間の短縮、非同期化、進捗表示、キャンセル時の扱い、202 Acceptedフローを検討してください。
  • 499をサーバー側500エラーとして扱う前に、クライアントが先に切断した可能性を確認してください。
使わないほうがよい場面
  • 499をクライアントへ返したサーバー生成レスポンスとして扱わないでください。
  • バックエンドのエラーログだけで判断しないでください。アプリケーションは例外を出していない場合があります。
  • フロントエンドのリクエストキャンセル、クライアントtimeout、ユーザーのページ離脱を無視しないでください。
  • 499をRFC標準のHTTPステータスコードとして説明しないでください。Nginx固有のコードであることを明記してください。
出典: Nginx 関連コード: 408, 460, 504

5xx サーバーエラー

アプリケーションエラー、上流サービス、プロキシ、CDN、DNS、TLS、過負荷、メンテナンス、タイムアウトなど、サーバー側またはゲートウェイ側の失敗です。

500

Internal Server Error(内部サーバーエラー)

サーバー内部で予期しない失敗が発生しました。

5xx サーバーエラー 標準 推奨 RFC 9110
詳細

500 Internal Server Error(内部サーバーエラー)は、サーバーがリクエストを処理中に予期しないエラーに遭遇し、より具体的な5xxステータスで表せない場合に返されます。未捕捉例外、アプリケーションクラッシュ、テンプレートエラー、依存サービスの異常、設定ミスなどが原因になり得ます。クライアント入力の問題を隠すための汎用コードではなく、サーバー側で調査すべき失敗として扱います。公開レスポンスでは、内部スタックトレースや秘密情報を出さず、安定したエラーコード、分かりやすいメッセージ、trace IDを返すのが安全です。

よくある状況
  • 未捕捉例外、アプリケーションクラッシュ、テンプレートエラー、予期しない依存サービスエラー、設定ミスなど。
  • 監視、ゲートウェイログ、エラーページで、通常のユーザー入力よりもサーバーやインフラ層に近い失敗として現れる場合。
  • より具体的な502、503、504、507などへ分類できない、一般的なサーバー内部エラー。
確認すること
  • まず、この状況が本当に500 Internal Server Errorの意味に合っているか確認し、予測可能な4xxエラーまで500にしていないか見直してください。
  • サーバーログ、例外スタックトレース、trace ID、最近のデプロイ、設定変更、依存サービスの変更を確認してください。
  • APIでは、安定したアプリケーションエラーコード、人が読めるメッセージ、必要に応じたtrace IDを返し、内部詳細はログに残してください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーが500を生成したか確認してください。
  • 入力ミス、認証失敗、バリデーション失敗、業務ルール違反など、予測可能なエラーは適切な4xxへ変換してください。
  • 本番レスポンスにスタックトレース、接続文字列、秘密情報、内部ファイルパスを出さないでください。
使わないほうがよい場面
  • クライアント入力の誤りに500を使わないでください。
  • 本番レスポンスにスタックトレース、接続文字列、secretを露出しないでください。
  • 予測可能なエラーをすべて500で処理し続けないでください。
  • 上流プロキシやゲートウェイの失敗が主因なら、502、503、504の方が適切な場合があります。
出典: RFC 9110 関連コード: 502, 503, 504, 400, 422
501

Not Implemented(未実装)

サーバーが、リクエストを満たすために必要な機能をサポートしていません。

5xx サーバーエラー 標準 推奨 RFC 9110
詳細

501 Not Implemented(未実装)は、リクエストで必要とされるHTTPメソッド、プロトコル機能、またはサーバー機能を、サーバー全体としてサポートしていない場合に返されます。特定のリソースでそのメソッドを許可していないだけなら405 Method Not Allowedの方が適切です。未実装のアプリケーション機能や、権限不足、非公開機能を表すための汎用コードではなく、サーバーがその機能自体を実装していないことを示すコードとして使います。

よくある状況
  • サーバーが特定のHTTPメソッド、プロトコル機能、拡張機能をまったくサポートしていない場合。
  • ゲートウェイ、プロキシ、APIサーバーが、要求された機能やメソッドを実装していない場合。
  • 監視、ゲートウェイログ、エラーページで、通常のユーザー入力ではなくサーバーやインフラ層に近い未対応機能として現れる場合。
確認すること
  • まず、この状況が本当に501 Not Implementedの意味に合っているか確認し、汎用的な500や404として扱っていないか見直してください。
  • サーバー全体がそのHTTPメソッド、プロトコル機能、拡張機能をサポートしていないのか、対象リソースだけが許可していないのかを切り分けてください。
  • 特定リソースでメソッドが許可されていない場合は、501ではなく405 Method Not Allowedを使い、Allowヘッダーを返してください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーが501を生成したか確認してください。
  • APIでは、未対応の機能、利用可能な代替手段、将来対応予定の有無をレスポンス本文やドキュメントで明確にしてください。
  • 通常の認可失敗や無効な入力を501で表現しないよう、エラーマッピングを確認してください。
使わないほうがよい場面
  • 特定リソースがメソッドを許可していないだけなら501ではなく405 Method Not Allowedを使ってください。
  • 無効化されたビジネス機能、非公開機能、権限不足を501で表現しないでください。
  • 認証や認可の失敗に501を使わないでください。
  • 実装済みだが一時的に使えないサービスには503 Service Unavailableを検討してください。
出典: RFC 9110 関連コード: 405, 426, 505
502

Bad Gateway(不正なゲートウェイ)

ゲートウェイまたはプロキシが、上流サーバーから有効なレスポンスを受け取れませんでした。

5xx サーバーエラー 標準 推奨 RFC 9110
詳細

502 Bad Gateway(不正なゲートウェイ)は、リバースプロキシ、APIゲートウェイ、CDN、サービスメッシュ、ロードバランサーなどの中間層が、上流サービスから有効なHTTPレスポンスを取得できなかったことを示します。上流アプリケーションのクラッシュ、接続リセット、不正なヘッダー、プロトコル不一致、TLSやポート設定の問題などが原因になり得ます。504が上流の応答待ちタイムアウトを示すのに対し、502は上流から無効または異常な応答を受けた状態に近いです。

よくある状況
  • リバースプロキシ、APIゲートウェイ、CDN、サービスメッシュ、ロードバランサーが、上流サーバーから無効なレスポンスを受け取った場合。
  • 上流アプリケーションがクラッシュした、接続を早期に閉じた、不正なヘッダーを返した、プロトコルが一致していない場合。
  • 監視、ゲートウェイログ、エラーページで、通常のユーザー入力よりもサーバーやインフラ層に近い失敗として現れる場合。
確認すること
  • まず、この状況が本当に502 Bad Gatewayの意味に合っているか確認し、すべてのバックエンド障害を502にまとめていないか見直してください。
  • オリジンサービスの稼働状態、上流ログ、プロキシログ、プロトコル不一致、TLS設定、ポート、レスポンスヘッダーを確認してください。
  • 上流アプリケーションがクラッシュしたのか、接続を早期に閉じたのか、不正なヘッダーを返したのかを切り分けてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーが502を生成したか確認してください。
  • 分散トレース、request ID、Ray ID、upstream status、connection reset、TLS handshakeエラーなどを突き合わせてください。
  • 502と504を混同せず、タイムアウトなのか無効応答なのかをログで確認してください。
使わないほうがよい場面
  • すべてのバックエンド失敗を502として扱わないでください。
  • 504 Gateway Timeoutと混同しないでください。504はタイムアウトです。
  • ブラウザのエラーページだけで判断せず、ゲートウェイログとオリジンログを確認してください。
  • クライアント入力の誤りを502で表現しないでください。
出典: RFC 9110 関連コード: 500, 503, 504, 521, 522
503

Service Unavailable(サービス利用不可)

サービスが一時的にリクエストを処理できません。

5xx サーバーエラー 標準 推奨 RFC 9110
詳細

503 Service Unavailable(サービス利用不可)は、サーバーが過負荷、メンテナンス中、一時停止中、依存サービス停止中、または自己保護のため、現在リクエストを処理できないことを示します。恒久的な削除やクライアント入力の問題ではなく、一時的な利用不可状態を表すコードです。クライアントが後で安全に再試行できる場合は、Retry-Afterやレスポンス本文で復旧見込みや再試行タイミングを示すと扱いやすくなります。

よくある状況
  • メンテナンス時間、過負荷、キャパシティ不足、キュー滞留、thread pool枯渇、connection pool枯渇、依存サービス障害など。
  • circuit breaker、バックプレッシャー、一時的なスロットリング、オートスケール中、デプロイ中の一時停止など。
  • 監視、ゲートウェイログ、エラーページで、通常のユーザー入力よりもサーバーやインフラ層に近い一時障害として現れる場合。
確認すること
  • まず、この状況が本当に503 Service Unavailableの意味に合っているか確認し、恒久的な404や一般的な500として扱っていないか見直してください。
  • インスタンス容量、CPU、メモリ、キュー、thread pool、connection pool、データベース、キャッシュ、下流サービス、オートスケール状況を確認してください。
  • 可能であれば、Retry-Afterやステータスページ、レスポンス本文で復旧見込みや再試行方針を伝えてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーが503を生成したか確認してください。
  • メンテナンス時は検索エンジンやクライアントに一時的な状態であることが伝わるよう、適切な503とRetry-Afterを使ってください。
  • 長期化する場合は、原因の切り分け、容量追加、依存サービス復旧、トラフィック制御、フォールバック導線を用意してください。
使わないほうがよい場面
  • 恒久的に削除されたリソースには503ではなく410 Goneを使ってください。
  • ユーザー単位やAPI key単位のレート制限には503ではなく429 Too Many Requestsを使う方が明確です。
  • 復旧計画や再試行方針がないまま長期間503を返し続けないでください。
  • クライアント入力の誤りや認証失敗を503で表現しないでください。
出典: RFC 9110 関連コード: 500, 502, 504, 429
504

Gateway Timeout(ゲートウェイタイムアウト)

ゲートウェイまたはプロキシが、上流サーバーからの応答を時間内に受け取れませんでした。

5xx サーバーエラー 標準 推奨 RFC 9110
詳細

504 Gateway Timeout(ゲートウェイタイムアウト)は、中間層が上流サービスへ接続できた、または接続を試みたものの、期待された時間内にHTTPレスポンスを受け取れなかったことを示します。遅い上流API、重いDBクエリ、ブロックされたサービスチェーン、proxy read timeout、長時間処理などで発生します。502が無効な上流レスポンスに近いのに対し、504は主に応答待ちのタイムアウトです。

よくある状況
  • 遅い上流API、重いデータベースクエリ、ブロックされたサービスチェーン、proxy read timeout、長時間処理など。
  • CDN、リバースプロキシ、APIゲートウェイ、ロードバランサーが、オリジンや上流サービスの応答を待ってタイムアウトした場合。
  • 監視、ゲートウェイログ、エラーページで、通常のユーザー入力よりもサーバーやインフラ層に近い遅延として現れる場合。
確認すること
  • まず、この状況が本当に504 Gateway Timeoutの意味に合っているか確認し、汎用的な500や502として扱っていないか見直してください。
  • ゲートウェイのtimeout設定、上流レイテンシ、slow query、分散トレース、依存サービスの応答時間を確認してください。
  • オリジンログと中間レイヤーのログを比較し、リクエストがどこまで到達し、どの区間で待ち時間が発生したか確認してください。
  • 長時間処理は同期レスポンスにせず、必要に応じて202 Acceptedを返す非同期ジョブ、進捗確認API、通知方式に切り替えてください。
  • 単にtimeoutを伸ばすだけでなく、遅いクエリ、外部API依存、ロック、キュー滞留、N+1、バックプレッシャーを改善してください。
  • クライアント側の低速アップロードやリクエスト送信未完了が原因なら、504ではなく408に近い場合があります。
使わないほうがよい場面
  • 低速なクライアントアップロードには504ではなく408 Request Timeoutを検討してください。
  • 上流から無効なレスポンスを受け取った場合は504ではなく502 Bad Gatewayに近いです。
  • 遅い処理を直さずにtimeoutだけを伸ばし続けないでください。
  • クライアント入力の誤りを504で表現しないでください。
出典: RFC 9110 関連コード: 408, 502, 503, 524
505

HTTP Version Not Supported(HTTPバージョン非対応)

サーバーが、リクエストで使われたHTTPバージョンをサポートしていません。

5xx サーバーエラー 標準 注意して使用 RFC 9110
詳細

505 HTTP Version Not Supported(HTTPバージョン非対応)は、クライアントが使用したHTTPバージョンを、サーバーが拒否またはサポートできない場合に返されます。HTTP/1.0、HTTP/2、HTTP/3、ALPN、プロキシやロードバランサーとのプロトコル不一致などで発生することがあります。APIのバージョン番号やアプリケーション機能のバージョン違いではなく、HTTPプロトコルのバージョンに関する問題です。アップグレード経路がある場合は426 Upgrade Requiredの方が適切なことがあります。

よくある状況
  • HTTP/1.0、HTTP/2、HTTP/3、ALPN、プロキシ設定、ロードバランサー設定などのプロトコルバージョン不一致。
  • クライアントがサーバーで許可されていないHTTPバージョンを使っている場合。
  • 中間層がHTTPバージョンを変換・終端する構成で、オリジンの対応バージョンと一致しない場合。
確認すること
  • まず、この状況が本当に505 HTTP Version Not Supportedの意味に合っているか確認し、汎用的な400、426、501として扱っていないか見直してください。
  • クライアントのHTTPバージョン、TLS ALPN、プロキシ設定、CDN設定、ロードバランサー設定、サーバー側のプロトコル対応状況を確認してください。
  • HTTP/2、HTTP/3、gRPC、WebSocket、TLS終端などを使う場合は、クライアントからオリジンまでの各レイヤーの対応を確認してください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーが505を生成したか確認してください。
  • クライアントが別プロトコルへ切り替えれば処理できる場合は、505ではなく426 Upgrade Requiredを検討してください。
  • APIバージョンの不一致には505を使わず、ルーティング、400、404、409、またはアプリケーションエラー本文で扱ってください。
使わないほうがよい場面
  • APIバージョンの問題に505を使わないでください。505はHTTPプロトコルバージョンの問題です。
  • TLS handshake失敗を505で表現しないでください。
  • アップグレードすれば解決できる場合は426 Upgrade Requiredの方が適切なことがあります。
  • 通常の入力エラーや認証エラーを505で表現しないでください。
出典: RFC 9110 関連コード: 400, 426, 501
506

Variant Also Negotiates(バリアントもネゴシエーションします)

サーバーのコンテンツネゴシエーション設定に循環があります。

5xx サーバーエラー 標準 非推奨 RFC 2295
詳細

506 Variant Also Negotiates(バリアントもネゴシエーションします)は、選択されたバリアントリソース自体もコンテンツネゴシエーションを行うよう設定されており、ネゴシエーションの循環や設定矛盾が発生していることを示します。通常のAcceptヘッダー不一致ではなく、透過的コンテンツネゴシエーションやバリアントリソースのマッピング設定に問題がある場合のサーバー側エラーです。現在のWeb APIではあまり見かけませんが、古いコンテンツネゴシエーション設定や特殊なサーバー構成では診断対象になります。

よくある状況
  • 透過的コンテンツネゴシエーションの設定ミスにより、選択されたバリアントがさらに別のネゴシエーション対象になっている場合。
  • バリアントリソースのマッピングが再帰的に戻り、サーバーが最終的な表現を選べない場合。
  • 監視、ゲートウェイログ、エラーページで、通常のユーザー入力ではなくサーバー設定に近い失敗として現れる場合。
確認すること
  • まず、この状況が本当に506 Variant Also Negotiatesの意味に合っているか確認し、汎用的な500として扱っていないか見直してください。
  • コンテンツネゴシエーション設定、variant resource、Alternatesヘッダー、リソースマッピング、リライト設定を確認してください。
  • バリアントリソースが再びネゴシエーション対象を指していないか、再帰的な設定や循環参照がないか確認してください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーが506を生成したか確認してください。
  • 通常のAcceptヘッダー不一致であれば、506ではなく406 Not Acceptableを使ってください。
  • 現代的なAPIでは、必要に応じて明示的なURL、拡張子、Content-Type、バージョン付きエンドポイントで表現を切り分けることも検討してください。
使わないほうがよい場面
  • 通常のAcceptヘッダー不一致に506を使わないでください。その場合は406 Not Acceptableが近いです。
  • ビジネスロジック上のエラーに506を使わないでください。
  • コンテンツネゴシエーションの循環がない場合に506を返さないでください。
  • 単なる内部例外を506で隠さないでください。
出典: RFC 2295 関連コード: 300, 406, 500
507

Insufficient Storage(ストレージ不足)

リクエストを完了するために必要なストレージ容量がサーバー側で不足しています。

5xx サーバーエラー 標準 注意して使用 RFC 4918
詳細

507 Insufficient Storage(ストレージ不足)は、サーバーが操作を完了するために必要な表現やファイル、メタデータを保存できないことを示します。WebDAVの書き込み、ファイルアップロード、一時ディレクトリの枯渇、ディスク容量不足、オブジェクトストレージのクォータ超過、ユーザー単位の保存容量上限などで発生します。リクエスト本文が大きすぎるだけなら413に近く、リソースがロックされているなら423に近いため、実際にストレージ容量やクォータが原因かを確認する必要があります。

よくある状況
  • WebDAVアップロード、ファイル書き込み、画像・動画アップロード、バックアップ、エクスポートなどで保存容量が不足している場合。
  • ディスク、tmpディレクトリ、object storage、tenant quota、user quota、inode、メタデータ保存領域が不足している場合。
  • 監視、ゲートウェイログ、エラーページで、通常のユーザー入力よりもサーバーやストレージ層に近い失敗として現れる場合。
確認すること
  • まず、この状況が本当に507 Insufficient Storageの意味に合っているか確認し、汎用的な500や413として扱っていないか見直してください。
  • ディスク容量、inode、tmpディレクトリ、object storage quota、ユーザー別quota、tenant quota、保存先の権限を確認してください。
  • 制限がシステム全体の容量不足なのか、ユーザー・tenant・プラン単位の上限なのかを切り分けてください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーが507を生成したか確認してください。
  • ユーザーに解決可能な制限であれば、上限、使用量、削除すべき対象、プラン変更や容量追加の導線をレスポンス本文で説明してください。
  • 一時領域やバックグラウンドジョブで発生している場合は、クリーンアップ、容量監視、アラート、リトライ設計を見直してください。
使わないほうがよい場面
  • リクエスト本文が単に大きすぎるだけなら507ではなく413 Content Too Largeを使ってください。
  • リソースがロックされている場合は423 Lockedを使ってください。
  • ストレージが関係しない一般的な書き込み失敗に507を使わないでください。
  • 容量不足の原因や対象が不明なまま507を返し続けないでください。
出典: RFC 4918 関連コード: 413, 423, 500
508

Loop Detected(ループを検出)

リクエスト処理中に、リソース参照やバインディングのループが検出されました。

5xx サーバーエラー 標準 非推奨 RFC 5842
詳細

508 Loop Detected(ループを検出)は、WebDAVのbinding、再帰的なディレクトリ走査、リソース参照、コレクション処理などで無限ループが検出されたことを示します。アプリケーションコードの一般的な無限ループやクラッシュを表すためのものではなく、リソース構造や参照グラフに循環があることを示すWebDAV拡張由来のステータスコードです。

よくある状況
  • WebDAV bindingにより、コレクションやリソース参照が循環している場合。
  • 再帰的なディレクトリ走査、symbolic link、リソースグラフ参照、コレクション処理でループが検出された場合。
  • 207 Multi-StatusやWebDAV操作の中で、個別リソース処理が循環参照により失敗する場合。
  • 監視、ゲートウェイログ、エラーページで、通常のユーザー入力よりもサーバーやリソース構造に近い失敗として現れる場合。
確認すること
  • まず、この状況が本当に508 Loop Detectedの意味に合っているか確認し、汎用的な500として扱っていないか見直してください。
  • WebDAV bindings、symbolic links、再帰処理、リソース参照グラフ、コレクション構造を確認してください。
  • どのリソース参照が循環しているか特定し、ループ処理を停止して診断情報を残してください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーが508を生成したか確認してください。
  • クライアントが修正できる場合は、循環しているリソース、親子関係、参照IDなどを安全な範囲でレスポンス本文に含めてください。
  • 一般的なアプリケーションの無限ループやクラッシュであれば、508ではなく500として扱う方が自然です。
使わないほうがよい場面
  • 通常のアプリケーションコードの無限ループやクラッシュに508を使わないでください。多くの場合は500です。
  • リソース参照やWebDAV的なループ意味がない場合に508を返さないでください。
  • 単なるリダイレクトループに508を使わないでください。
  • 循環している対象を調査せずに508だけを返し続けないでください。
出典: RFC 5842 関連コード: 207, 208, 500
509

Bandwidth Limit Exceeded(帯域制限を超過)

サイトまたはアカウントが帯域幅のクォータを超過しました。

5xx サーバーエラー 非標準 非推奨 Apache/cPanel hosting convention
詳細

509 Bandwidth Limit Exceeded(帯域制限を超過)は、IANAに登録された標準HTTPステータスコードではありません。Apache/cPanel系ホスティングの慣例として知られる非標準コードで、共有ホスティングのアカウント、サイト、プラン、tenantが帯域幅や転送量の上限を超えたことを示す場合があります。標準HTTPの意味としては移植性が低く、公開APIでは通常、429や503、または構造化されたquotaエラー本文で表現する方が分かりやすいです。

よくある状況
  • 共有ホスティングやcPanel環境で、月間転送量や帯域幅上限を超えた場合。
  • サイト、tenant、プラン、アカウント単位のトラフィッククォータが使い切られた場合。
  • 異常なクローラー、bot、ホットリンク、大量ダウンロード、DDoS気味のアクセスで転送量が急増した場合。
確認すること
  • まず、このレスポンスがApache/cPanel系ホスティングの慣例やホスティング制御パネルによって生成されたものか確認してください。
  • オリジンアプリケーションログと、CDN、ゲートウェイ、プロキシ、ロードバランサー、Webサーバーログ、ホスティング管理画面を比較してください。
  • ホスティングプランの帯域幅上限、月間転送量、CDNトラフィック、異常なcrawler traffic、hotlink、botアクセスを確認してください。
  • 必要に応じてプランをアップグレードし、CDNキャッシュ、画像最適化、帯域制限、bot対策、hotlink防止を導入してください。
  • 公開APIでは、509を直接露出するより、429、503、またはquota error本文へマッピングすることを検討してください。
  • どのクォータを超えたのか、いつリセットされるのか、ユーザーが取れる対応を明確にしてください。
使わないほうがよい場面
  • 509を標準HTTPステータスコードとして扱わないでください。
  • 通常のレート制限には509ではなく429 Too Many Requestsを使ってください。
  • 一時的なサービス停止やメンテナンスには503 Service Unavailableを検討してください。
  • 509をRFC標準のHTTPステータスコードとして説明しないでください。どのホスティング環境が生成しているのかを明記してください。
出典: Apache/cPanel hosting convention 関連コード: 429, 503, 507
510

Not Extended(拡張されていません)

リクエストに必要な拡張情報が不足していますが、このステータスコードは実務上ほぼ使われません。

5xx サーバーエラー 非推奨 非推奨 RFC 2774
詳細

510 Not Extended(拡張されていません)は、古いHTTP拡張フレームワークで期待される拡張情報がリクエストに含まれていないことを示すために定義されたコードです。現代のWeb APIやブラウザ向けサービスではほとんど使われず、実務上は非推奨に近い扱いです。新しいAPIでは、何が不足しているのかに応じて400、401、403、415、422、501などの明確なステータスコードと構造化エラー本文で表現する方が分かりやすく、クライアント実装にも優しいです。

よくある状況
  • 古いHTTP拡張メカニズムやレガシー互換性の文脈で、必要な拡張情報が不足している場合。
  • 歴史的なサーバー実装や特殊なプロキシが、古い拡張フレームワークのエラーとして返す場合。
  • 監視、ゲートウェイログ、エラーページで、通常のユーザー入力よりもサーバーやプロトコル拡張層に近い失敗として現れる場合。
確認すること
  • まず、この状況が本当に510 Not Extendedの意味に合っているか確認し、汎用的な400や501として扱っていないか見直してください。
  • 古いHTTP拡張フレームワーク、必要な拡張ヘッダー、プロキシ設定、レガシークライアントとの互換性を確認してください。
  • 新しいAPIでは、510ではなく、足りない情報の種類に応じて400、401、403、415、422、501などを使ってください。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合は、オリジンログと中間レイヤーのログを比較し、どのレイヤーが510を生成したか確認してください。
  • どうしてもレガシー互換のために扱う場合は、どの拡張情報が必要かをレスポンス本文やドキュメントで明確にしてください。
  • 通常の必須パラメーター不足や入力バリデーションエラーを510で表現しないようにしてください。
使わないほうがよい場面
  • 新しいAPIで510を使わないでください。
  • 通常の必須パラメーター不足に510を使わないでください。
  • 認証、認可、Content-Type、入力バリデーションの問題を510で曖昧にしないでください。
  • クライアントが理解しにくいレガシーな拡張エラーを公開API契約にしないでください。
出典: RFC 2774 関連コード: 400, 501
511

Network Authentication Required(ネットワーク認証が必要)

オリジンへアクセスする前に、クライアントはネットワーク認証を完了する必要があります。

5xx サーバーエラー 標準 非推奨 RFC 6585
詳細

511 Network Authentication Required(ネットワーク認証が必要)は、通常のWebサイトやAPIのログインではなく、ネットワークアクセス層で認証が必要であることを示します。公共Wi-Fi、ホテル、空港、学校、企業ネットワークなどのcaptive portalで、インターネットへ通常アクセスする前にログインページや利用規約同意が必要な場合に使われます。401はWebサイトやAPIの認証、407はプロキシ認証に近いのに対し、511はネットワークそのものへの認証が必要な状態です。

よくある状況
  • 公共Wi-Fi、ホテルWi-Fi、空港Wi-Fi、学校や企業ネットワークのcaptive portalに接続している場合。
  • ネットワークログインページや利用規約同意を完了するまで、通常のWebサイトやAPIへアクセスできない場合。
  • アクセス失敗時に、認証、認可、プロキシ認証、セッション期限切れ、ネットワークログインのどれかを切り分ける必要がある場合。
確認すること
  • まず、この状況が本当に511 Network Authentication Requiredの意味に合っているか確認し、Webサイトのログイン失敗と混同していないか見直してください。
  • ユーザーは通常、ブラウザでネットワークログインページを開き、ログイン、利用規約同意、認証手続きを完了する必要があります。
  • このレスポンスは通常、オリジンWebサイトではなく、ネットワークアクセス層やcaptive portalによって生成されます。
  • レスポンスがCDN、リバースプロキシ、APIゲートウェイ、ロードバランサーを通っている場合でも、まずネットワーク層で認証が必要になっていないか確認してください。
  • アプリやAPIクライアントでは、511を受けたら自動リトライを続けるのではなく、ユーザーにネットワーク認証が必要であることを案内してください。
  • プロキシ認証が必要な場合は511ではなく407 Proxy Authentication Requiredを使ってください。
使わないほうがよい場面
  • WebサイトやAPIの通常ログイン失敗に511を使わないでください。その場合は401または403を検討してください。
  • プロキシ認証には511ではなく407 Proxy Authentication Requiredを使ってください。
  • 認可不足やアカウント権限不足を511で表現しないでください。
  • オリジンアプリケーションが自分の認証エラーとして511を返さないでください。
出典: RFC 6585 関連コード: 401, 407, 403
520

Web Server Returned an Unknown Error(Webサーバーが不明なエラーを返しました)

Cloudflareが、オリジンから空・不明・分類不能なレスポンスを受け取りました。

5xx サーバーエラー 非標準 非推奨 Cloudflare
詳細

520 Web Server Returned an Unknown Error(Webサーバーが不明なエラーを返しました)は、IANAに登録された標準HTTPステータスコードではありません。Cloudflare固有の非標準コードで、Cloudflareがオリジンに到達できたものの、空のレスポンス、不正なヘッダー、早期接続終了、分類しづらい異常応答を受け取った場合に表示されることがあります。通常の500としてだけ扱うのではなく、Cloudflare Ray IDとオリジンログを突き合わせて、どの層で異常が起きたか確認する必要があります。

よくある状況
  • Cloudflareはオリジンへ到達できたが、オリジンのレスポンスが空、未知、または分類不能だった場合。
  • オリジンが接続をリセットした、不正なヘッダーを送った、レスポンスを返す前に接続を閉じた場合。
  • WAF、アプリケーションクラッシュ、ヘッダー肥大化、プロキシ設定、上流サービス異常などがCloudflare側では520として見える場合。
確認すること
  • まず、このレスポンスがオリジンアプリケーションではなくCloudflareによって生成されたものか確認してください。
  • Cloudflare Ray ID、Cloudflareログ、オリジンアプリケーションログ、Webサーバーログを突き合わせてください。
  • オリジンのクラッシュ、空レスポンス、不正なレスポンスヘッダー、早期接続終了、WAFルール、ヘッダーサイズ超過を確認してください。
  • CDN、リバースプロキシ、APIゲートウェイ、ロードバランサー、オリジンの各ログを比較し、どのレイヤーが異常なレスポンスを返したか確認してください。
  • 一時的な分類不能エラーとして片付けず、同じRay IDやrequest IDで再現パターンを探してください。
  • 公開APIでは、520をAPI契約として扱わず、Cloudflareログ上の診断シグナルとして扱ってください。
使わないほうがよい場面
  • 520を標準的な500 Internal Server Errorと同じものとして扱わないでください。
  • Cloudflareのエラーページだけを見て判断せず、Ray IDとオリジンログを必ず突き合わせてください。
  • 空レスポンス、不正ヘッダー、早期接続終了の可能性を無視しないでください。
  • 520をRFC標準のHTTPステータスコードとして説明しないでください。Cloudflare固有のコードであることを明記してください。
出典: Cloudflare 関連コード: 500, 502, 521, 522
521

Web Server Is Down(Webサーバーが停止しています)

CloudflareがオリジンWebサーバーへ接続できません。

5xx サーバーエラー 非標準 非推奨 Cloudflare
詳細

521 Web Server Is Down(Webサーバーが停止しています)は、IANAに登録された標準HTTPステータスコードではありません。Cloudflare固有の非標準コードで、CloudflareがオリジンWebサーバーへTCP接続できない、接続を拒否された、またはオリジンがCloudflareからの接続をブロックしている場合に表示されることがあります。DNSそのものの問題とは限らず、オリジンの停止、ポート未待受、firewall、security group、Cloudflare IP allowlistの不備を確認する必要があります。

よくある状況
  • オリジンサービスが停止している、80/443ポートで待ち受けていない、または接続を拒否している場合。
  • オリジンは起動しているが、firewall、security group、WAF、ネットワークACLがCloudflare IPをブロックしている場合。
  • Cloudflareから見たオリジン接続が失敗し、アプリケーションログにはリクエストが到達していない場合。
確認すること
  • まず、このレスポンスがオリジンアプリケーションではなくCloudflareによって生成されたものか確認してください。
  • オリジンサーバーが起動しており、80または443で正しく待ち受けているか確認してください。
  • firewall、security group、ネットワークACL、WAF、ホスティング側制限でCloudflare IPレンジが拒否されていないか確認してください。
  • Cloudflare Ray ID、Cloudflareログ、オリジンのWebサーバーログ、システムログ、ネットワークログを比較してください。
  • オリジンを直接curlし、Cloudflare経由ではなく直接接続できるか確認してください。
  • 公開APIでは、521をAPI契約として扱わず、Cloudflareとオリジン接続の診断シグナルとして扱ってください。
使わないほうがよい場面
  • 521をDNS問題として即断しないでください。DNSよりも接続拒否やfirewallが原因の場合があります。
  • アプリだけを再起動して終わらせず、ポート、firewall、Cloudflare IP allowlistも確認してください。
  • オリジンが実際に80または443で待ち受けているかを無視しないでください。
  • 521をRFC標準のHTTPステータスコードとして説明しないでください。Cloudflare固有のコードであることを明記してください。
出典: Cloudflare 関連コード: 502, 503, 522, 523
522

Connection Timed Out(接続タイムアウト)

Cloudflareがオリジンへの接続中にタイムアウトしました。

5xx サーバーエラー 非標準 非推奨 Cloudflare
詳細

522 Connection Timed Out(接続タイムアウト)は、IANAに登録された標準HTTPステータスコードではありません。Cloudflare固有の非標準コードで、Cloudflareがオリジンへ接続しようとしたものの、接続確立までに時間がかかりすぎた場合に表示されます。オリジンが過負荷、packet loss、firewall drop、security group、接続数上限、ネットワーク経路の問題などにより応答できない場合に発生します。524が接続後の応答待ちタイムアウトに近いのに対し、522は主に接続段階のタイムアウトです。

よくある状況
  • CloudflareがオリジンへのTCP接続を時間内に確立できない場合。
  • オリジンが過負荷、packet loss、接続数上限、SYN drop、firewall drop、security group制限により応答できない場合。
  • Cloudflare IPがrate limit、firewall、WAF、ネットワークACLで遅延またはブロックされている場合。
確認すること
  • まず、このレスポンスがオリジンアプリケーションではなくCloudflareによって生成されたものか確認してください。
  • オリジンの負荷、接続数上限、packet loss、firewall、security group、ネットワークACL、ポート待受を確認してください。
  • Cloudflare IPレンジがrate limitやfirewallで制限されていないか確認してください。
  • Cloudflare Ray ID、Cloudflareログ、オリジンのWebサーバーログ、ネットワークログ、system metricsを比較してください。
  • 接続がアプリケーションまで到達していない場合は、アプリケーションログが空でも不自然ではありません。ネットワーク層から確認してください。
  • 522と524を混同せず、接続確立前のタイムアウトか、接続後の応答待ちタイムアウトかを切り分けてください。
使わないほうがよい場面
  • 522を524と混同しないでください。522は主に接続段階のタイムアウトです。
  • 接続がアプリケーションに到達していない場合、アプリケーションログだけで判断しないでください。
  • firewall drop、security group、packet loss、オリジン過負荷の可能性を無視しないでください。
  • 522をRFC標準のHTTPステータスコードとして説明しないでください。Cloudflare固有のコードであることを明記してください。
出典: Cloudflare 関連コード: 502, 504, 521, 524
523

Origin Is Unreachable(オリジンに到達できません)

Cloudflareがオリジンネットワークへ到達できません。

5xx サーバーエラー 非標準 非推奨 Cloudflare
詳細

523 Origin Is Unreachable(オリジンに到達できません)は、IANAに登録された標準HTTPステータスコードではありません。Cloudflare固有の非標準コードで、Cloudflareが設定されたオリジンIPやオリジンネットワークへ到達できない場合に表示されます。DNSが間違った宛先を指している、origin IPが到達不能、public routingが壊れている、cloud networkingやfirewallで遮断されている、ISPやネットワーク経路に問題がある場合などに発生します。

よくある状況
  • Cloudflareから見て、設定されたオリジンIPまたはオリジンネットワークへ到達できない場合。
  • DNSレコードが誤った宛先を指している、origin IPが変わった、public routeが存在しない、ネットワーク経路が壊れている場合。
  • cloud networking、firewall、ISP、routing、BGP、ネットワークACLの問題でCloudflareから到達できない場合。
確認すること
  • まず、このレスポンスがオリジンアプリケーションではなくCloudflareによって生成されたものか確認してください。
  • Cloudflare DNSレコード、A/AAAA/CNAME、origin hostname、origin IP、DNSSEC、resolver挙動を確認してください。
  • オリジンIPが現在も有効で、インターネットから到達可能であり、正しいサーバーを指しているか確認してください。
  • public routing、firewall、cloud networking、security group、network ACL、ISP reachabilityを確認してください。
  • Cloudflare Ray ID、Cloudflareログ、DNS変更履歴、ネットワークログを突き合わせてください。
  • 523と530を混同せず、DNS解決の問題なのか、解決後のネットワーク到達性の問題なのかを切り分けてください。
使わないほうがよい場面
  • 523をアプリケーションコードの失敗として扱わないでください。多くの場合、ネットワーク到達性の問題です。
  • DNSの向き先やpublic route reachabilityを確認せずにアプリケーションだけを調査しないでください。
  • 530 Origin DNS Errorと混同しないでください。530はよりDNS解決そのものに近い問題です。
  • 523をRFC標準のHTTPステータスコードとして説明しないでください。Cloudflare固有のコードであることを明記してください。
出典: Cloudflare 関連コード: 502, 521, 522, 530
524

A Timeout Occurred(タイムアウトが発生しました)

Cloudflareはオリジンへ接続できましたが、時間内にHTTPレスポンスを受け取れませんでした。

5xx サーバーエラー 非標準 非推奨 Cloudflare
詳細

524 A Timeout Occurred(タイムアウトが発生しました)は、IANAに登録された標準HTTPステータスコードではありません。Cloudflare固有の非標準コードで、Cloudflareがオリジンへの接続には成功したものの、オリジンからHTTPレスポンスが時間内に返らなかった場合に表示されます。重いDBクエリ、長時間のエクスポート、遅いAPI、バックエンドのロック、同期的なレポート生成などが原因になりやすいコードです。522が接続段階のタイムアウトに近いのに対し、524は接続後の応答待ちタイムアウトです。

よくある状況
  • Cloudflareがオリジンへ接続できたが、オリジンが時間内にHTTPレスポンスを返さなかった場合。
  • 長いクエリ、エクスポート、レポート生成、重いAPI、バックエンドのロック、外部API待ちがCloudflareのtimeoutを超えた場合。
  • アプリケーションログにはリクエストが到達しているが、処理完了前にCloudflare側が待ち切れなくなった場合。
確認すること
  • まず、このレスポンスがオリジンアプリケーションではなくCloudflareによって生成されたものか確認してください。
  • Cloudflare Ray ID、Cloudflareログ、オリジンアプリケーションログ、database slow query、分散トレースを突き合わせてください。
  • 遅い処理、長時間クエリ、外部API待ち、ロック、キュー滞留、レポート生成、エクスポート処理を確認してください。
  • 長時間処理は同期レスポンスにせず、202 Accepted、非同期ジョブ、進捗確認API、通知方式へ切り替えることを検討してください。
  • 単にtimeoutを伸ばすだけでなく、遅い処理そのものを最適化し、キャッシュ、分割処理、バックグラウンド化を検討してください。
  • 522と524を混同せず、Cloudflareがオリジンへ接続できていたかどうかを確認してください。
使わないほうがよい場面
  • 524を522と混同しないでください。524ではCloudflareはすでにオリジンへ接続できています。
  • 遅いエンドポイントを直さず、timeoutだけを伸ばし続けないでください。
  • 長時間処理を同期HTTPレスポンスとして抱え続けないでください。202の非同期フローの方が安全な場合があります。
  • 524をRFC標準のHTTPステータスコードとして説明しないでください。Cloudflare固有のコードであることを明記してください。
出典: Cloudflare 関連コード: 504, 522, 503, 202
525

SSL Handshake Failed(SSLハンドシェイク失敗)

CloudflareがオリジンとのTLSハンドシェイクを完了できませんでした。

5xx サーバーエラー 非標準 非推奨 Cloudflare
詳細

525 SSL Handshake Failed(SSLハンドシェイク失敗)は、IANAに登録された標準HTTPステータスコードではありません。Cloudflare固有の非標準コードで、Cloudflareとオリジン間のTLSハンドシェイクが失敗した場合に表示されます。オリジン証明書、TLSバージョン、cipher suite、SNI、ALPN、証明書チェーン、CloudflareのSSL/TLS mode、オリジンのTLS設定不備などが原因になり得ます。これはブラウザとCloudflare間の証明書問題ではなく、Cloudflareからオリジンへの接続で発生するTLS問題です。

よくある状況
  • Cloudflareとオリジン間のTLSハンドシェイクが成立しない場合。
  • オリジンのTLS設定、SNI、cipher suite、TLSバージョン、証明書チェーン、ALPN設定がCloudflareと互換しない場合。
  • Cloudflare SSL/TLS modeとオリジン側のHTTPS設定が噛み合っていない場合。
確認すること
  • まず、このレスポンスがオリジンアプリケーションではなくCloudflareによって生成されたものか確認してください。
  • Cloudflare SSL/TLS mode、オリジン証明書、TLSバージョン、SNI、cipher suite、ALPN、証明書チェーンを確認してください。
  • 外部ネットワークからcurlやopenssl s_clientでオリジンTLSを直接テストしてください。
  • Cloudflare Ray ID、Cloudflareログ、オリジンのWebサーバーTLSログ、証明書設定を突き合わせてください。
  • 526との違いを確認してください。525は主にハンドシェイク失敗で、526はCloudflareが証明書を検証できない状態に近いです。
  • Cloudflareとオリジンの間でサポートされるTLSバージョンとcipher suiteが一致しているか確認してください。
使わないほうがよい場面
  • 525をブラウザからCloudflareへの証明書エラーとして扱わないでください。問題はCloudflareとオリジン間です。
  • 526 Invalid SSL Certificateと混同しないでください。526は証明書検証失敗に近いです。
  • SNI、TLSバージョン、cipher suite、Cloudflare SSL/TLS modeを確認せずに証明書だけを交換しないでください。
  • 525をRFC標準のHTTPステータスコードとして説明しないでください。Cloudflare固有のコードであることを明記してください。
出典: Cloudflare 関連コード: 502, 526, 495
526

Invalid SSL Certificate(無効なSSL証明書)

Cloudflareがオリジン証明書を検証できませんでした。

5xx サーバーエラー 非標準 非推奨 Cloudflare
詳細

526 Invalid SSL Certificate(無効なSSL証明書)は、IANAに登録された標準HTTPステータスコードではありません。Cloudflare固有の非標準コードで、CloudflareがFull Strictモードなどでオリジン証明書を検証できなかった場合に表示されます。証明書の期限切れ、自己署名、hostname不一致、SAN不足、不完全な証明書チェーン、信頼されていないCAなどが原因になり得ます。ブラウザとCloudflare間ではなく、Cloudflareとオリジン間の証明書検証が問題です。

よくある状況
  • CloudflareのFull Strictモードで、オリジン証明書が期限切れ、自己署名、hostname不一致、またはチェーン不完全な場合。
  • 証明書のSANがCloudflareでプロキシしているhostnameをカバーしていない場合。
  • オリジン証明書が信頼できるCA、またはCloudflare Origin CAで適切に発行されていない場合。
確認すること
  • まず、このレスポンスがオリジンアプリケーションではなくCloudflareによって生成されたものか確認してください。
  • オリジン証明書の有効期限、issuer、SAN、hostname一致、証明書チェーン、CA信頼性を確認してください。
  • Full Strictモードでは、Cloudflareが検証できる有効なオリジン証明書を設定してください。
  • 外部ネットワークからcurlやopenssl s_clientでオリジン証明書チェーンとhostname一致を確認してください。
  • 必要に応じて証明書を更新、再発行、チェーン修正し、対象hostnameをSANに含めてください。
  • 一時しのぎでTLSセキュリティを下げるのではなく、オリジン証明書を正しく修正してください。
使わないほうがよい場面
  • 526をユーザーのブラウザ側証明書エラーとして扱わないでください。問題はCloudflareとオリジン間です。
  • 問題を隠すためにTLSセキュリティを恒久的に下げないでください。
  • Full Strictモードで、期限切れ、自己署名、hostname不一致の証明書を使い続けないでください。
  • 526をRFC標準のHTTPステータスコードとして説明しないでください。Cloudflare固有のコードであることを明記してください。
出典: Cloudflare 関連コード: 525, 495, 403
527

Railgun Error(Railgunエラー)

Cloudflare Railgunで、オリジン接続またはプロトコル上のエラーが発生しました。

5xx サーバーエラー 非標準 非推奨 Cloudflare
詳細

527 Railgun Error(Railgunエラー)は、IANAに登録された標準HTTPステータスコードではありません。Cloudflare Railgun固有の非標準コードで、Railgun Listener、Railgunとオリジン間の接続、またはRailgunプロトコル上の問題が発生した場合に表示されることがあります。現在はRailgun自体が一般的な構成ではないため、このコードが見える場合は、実際にRailgunを使っているのか、古い設定が残っていないかをまず確認する必要があります。

よくある状況
  • Cloudflare Railgunを利用しているサイトで、Railgun Listenerやオリジン接続に問題がある場合。
  • Railgun設定、オリジンとのリンク、ネットワーク経路、プロトコル処理が失敗している場合。
  • サイトではもうRailgunを使っていないのに、Cloudflare側またはオリジン側に古いRailgun設定が残っている場合。
確認すること
  • まず、このレスポンスがオリジンアプリケーションではなくCloudflare Railgunによって生成されたものか確認してください。
  • Cloudflare設定、Railgun Listenerの稼働状態、Railgunログ、オリジンネットワーク、ファイアウォール設定を確認してください。
  • Cloudflare Ray ID、Railgunログ、オリジンアプリケーションログ、Webサーバーログを突き合わせてください。
  • Railgunを現在使っていない場合は、Cloudflare側やオリジン側に残った古いRailgun設定を削除してください。
  • Railgunを使っている場合は、Listenerの接続性、証明書、ポート、ネットワーク経路、Cloudflareとの接続状態を確認してください。
  • 公開APIでは、527をAPI契約として扱わず、Cloudflare Railgunログ上の診断シグナルとして扱ってください。
使わないほうがよい場面
  • 527を通常のオリジン500エラーとして扱わないでください。Railgun層の問題か確認してください。
  • Railgunを使っていないサイトで527が出る場合は、古い設定や誤ったCloudflare構成を疑ってください。
  • Cloudflare設定やRailgun Listenerを確認せずにアプリケーションコードだけを調査しないでください。
  • 527をRFC標準のHTTPステータスコードとして説明しないでください。Cloudflare Railgun固有のコードであることを明記してください。
出典: Cloudflare 関連コード: 502, 523, 524
530

Origin DNS Error(オリジンDNSエラー)

Cloudflareがオリジンホスト名を解決できない、またはオリジンDNSに問題があります。

5xx サーバーエラー 非標準 非推奨 Cloudflare
詳細

530 Origin DNS Error(オリジンDNSエラー)は、IANAに登録された標準HTTPステータスコードではありません。Cloudflare固有の非標準コードで、Cloudflareが設定されたオリジンホスト名をDNS解決できない、またはオリジンDNS設定に問題がある場合に表示されます。レスポンス本文には、より具体的なCloudflare 1xxxエラーコードが含まれることがあり、それを確認すると原因を絞り込みやすくなります。523が解決後のネットワーク到達性に近いのに対し、530はDNS解決やCloudflare側のオリジン設定に近い問題です。

よくある状況
  • Cloudflareが設定されたオリジンホスト名をDNS解決できない場合。
  • CNAMEの向き先、A/AAAAレコード、origin hostname、DNSSEC、resolver挙動、Cloudflare DNS設定に問題がある場合。
  • レスポンス本文にCloudflare 1xxxエラーコードが含まれており、より詳細なDNSまたは設定上の原因を示している場合。
確認すること
  • まず、このレスポンスがオリジンアプリケーションではなくCloudflareによって生成されたものか確認してください。
  • Cloudflare DNSレコード、CNAMEの向き先、A/AAAAレコード、origin hostname、DNSSEC、resolver挙動を確認してください。
  • レスポンス本文にCloudflare 1xxxエラーが含まれている場合は、その詳細コードを使って原因を絞り込んでください。
  • Cloudflareログ、DNS変更履歴、オリジンDNSプロバイダーの設定、権威DNSの応答を突き合わせてください。
  • オリジンホスト名が内部専用DNS、削除済みレコード、誤ったCNAME、到達不能なプライベート名を指していないか確認してください。
  • 公開APIでは、530をAPI契約として扱わず、Cloudflare DNS設定やオリジン解決の診断シグナルとして扱ってください。
使わないほうがよい場面
  • 530を標準HTTPセマンティクスとして扱わないでください。Cloudflare固有のコードです。
  • 523 Origin Is Unreachableと混同しないでください。523はDNS解決後のネットワーク到達性に近い問題です。
  • レスポンス本文にあるCloudflare 1xxxの詳細を無視しないでください。
  • アプリケーションログだけを見て判断しないでください。オリジンへ到達する前のDNS設定が原因の可能性があります。
出典: Cloudflare 関連コード: 523, 521, 522
561

Unauthorized(認証失敗)

AWSロードバランサーの認証が失敗した、または完了できませんでした。

5xx サーバーエラー 非標準 非推奨 AWS Elastic Load Balancing
詳細

561 Unauthorized(認証失敗)は、IANAに登録された標準HTTPステータスコードではありません。AWS Elastic Load Balancingの非標準・ベンダー固有コードで、ALBの認証機能がOIDC、Cognito、または外部IdPとの認証フローを完了できない場合に表示されることがあります。通常のアプリケーションが返す401とは異なり、リクエストがターゲットへ転送される前にロードバランサー層で認証が失敗している可能性があります。ALBログとIdPログを突き合わせて原因を確認する必要があります。

よくある状況
  • ALB認証でOIDC、Cognito、または外部Identity Providerとの認証フローが失敗した場合。
  • callback URL、client secret、issuer、token、scope、session cookie、IdP設定がALB設定と一致していない場合。
  • ロードバランサーがターゲットへ転送する前に認証を完了できず、オリジンアプリケーションログにリクエストが残らない場合。
確認すること
  • まず、このレスポンスがオリジンアプリケーションではなくAWS Elastic Load Balancingによって生成されたものか確認してください。
  • ALB access logs、認証アクション設定、OIDC/Cognito設定、callback URL、client ID、client secret、issuer、scopeを確認してください。
  • ALBログとIdentity Providerログを比較し、どの段階で認証フローが失敗したか確認してください。
  • Cookie、セッション有効期限、redirect URI、HTTPS設定、IdP側のアプリ登録内容が一致しているか確認してください。
  • 公開APIでは、561をAPI契約として扱わず、ロードバランサー認証ログ上の診断シグナルとして扱ってください。
  • アプリケーション側の401/403と混同せず、ターゲットへ到達する前にALBで止まっていないか切り分けてください。
使わないほうがよい場面
  • 561を標準的な401 Unauthorizedと同じものとして扱わないでください。ALB固有のコードです。
  • 認証がALBで失敗しているのに、オリジンアプリケーションコードだけを調査しないでください。
  • IdPログ、ALB認証設定、callback URL、client secretを確認せずに原因を断定しないでください。
  • 561をRFC標準のHTTPステータスコードとして説明しないでください。AWS Elastic Load Balancing固有のコードであることを明記してください。
出典: AWS Elastic Load Balancing 関連コード: 401, 403, 511
598

Network Read Timeout Error(ネットワーク読み取りタイムアウト)

プロキシまたはクライアントが、上流レスポンスの読み取り中にタイムアウトしました。

5xx サーバーエラー 非標準 非推奨 Proxy / Gateway convention
詳細

598 Network Read Timeout Error(ネットワーク読み取りタイムアウト)は、IANAに登録された標準HTTPステータスコードではありません。プロキシ、ゲートウェイ、または一部のクライアントライブラリの慣例として使われる非標準コードで、上流への接続は成立したものの、レスポンスを時間内に読み取れなかった場合に使われることがあります。接続段階で失敗する599とは異なり、598は主に接続後の読み取りタイムアウトに近い意味です。標準的な公開APIでは、504 Gateway Timeoutや実装固有のエラー本文へマッピングする方が分かりやすいです。

よくある状況
  • プロキシやクライアントライブラリが上流へ接続できたが、レスポンス全体を時間内に読み取れなかった場合。
  • 上流サービスが接続後に遅く、レスポンスヘッダーや本文の送信がタイムアウトした場合。
  • 長時間処理、遅いDBクエリ、外部API待ち、大きなレスポンス、ストリーミング不備などで読み取りが完了しない場合。
確認すること
  • まず、このレスポンスがオリジンアプリケーションではなく、プロキシ、ゲートウェイ、またはクライアントライブラリの慣例によって生成されたものか確認してください。
  • プロキシログ、クライアントログ、オリジンログを比較し、接続は成立していたのか、読み取り中にタイムアウトしたのかを確認してください。
  • upstream response time、read timeout、proxy timeout、レスポンスサイズ、streaming挙動、長時間処理の設計を確認してください。
  • 長い処理は同期レスポンスにせず、必要に応じて202 Accepted、非同期ジョブ、進捗確認APIへ切り替えてください。
  • 単にread timeoutを伸ばすだけでなく、上流が遅い理由、レスポンス生成、DBクエリ、外部API依存、転送サイズを見直してください。
  • 公開APIでは、598をAPI契約として扱わず、504や構造化エラー本文へのマッピングを検討してください。
使わないほうがよい場面
  • 598をIANA標準のHTTPステータスコードとして扱わないでください。
  • 接続確立前のタイムアウトである599と混同しないでください。
  • 上流が遅い理由を確認せずに、読み取りタイムアウトだけを延ばし続けないでください。
  • クライアント入力の誤りや認証失敗を598で表現しないでください。
出典: Proxy / Gateway convention 関連コード: 504, 524, 599
599

Network Connect Timeout Error(ネットワーク接続タイムアウト)

プロキシまたはクライアントが、上流への接続中にタイムアウトしました。

5xx サーバーエラー 非標準 非推奨 Proxy / Gateway convention
詳細

599 Network Connect Timeout Error(ネットワーク接続タイムアウト)は、IANAに登録された標準HTTPステータスコードではありません。プロキシ、ゲートウェイ、または一部のクライアントライブラリの慣例として使われる非標準コードで、上流サービスへ接続しようとしたものの、接続確立までに時間がかかりすぎた場合に使われることがあります。598が接続後の読み取りタイムアウトに近いのに対し、599は主にDNS、routing、firewall、security group、port listener、origin healthなど接続段階の問題に近いコードです。

よくある状況
  • プロキシやクライアントライブラリが、上流サービスへ時間内に接続できなかった場合。
  • DNS、routing、firewall、security group、ポート未待受、upstream health、ネットワーク経路の問題により接続できない場合。
  • 接続が確立する前にタイムアウトしており、オリジンアプリケーションログにリクエストが残らない場合。
確認すること
  • まず、このレスポンスがオリジンアプリケーションではなく、プロキシ、ゲートウェイ、またはクライアントライブラリの慣例によって生成されたものか確認してください。
  • DNS、routing、firewall、security group、port listener、upstream health、ネットワークACLを確認してください。
  • プロキシログやクライアントログを確認し、タイムアウトが接続中に起きたのか、接続後の読み取り中に起きたのかを切り分けてください。
  • オリジンアプリケーションログが空の場合は、アプリケーションへ到達する前に接続段階で失敗している可能性があります。
  • 接続数上限、SYN drop、packet loss、TLS終端、ロードバランサーのターゲット状態も確認してください。
  • 公開APIでは、599をAPI契約として扱わず、502、522、504、または構造化エラー本文へのマッピングを検討してください。
使わないほうがよい場面
  • 599をIANA標準のHTTPステータスコードとして扱わないでください。
  • 接続後の読み取りタイムアウトである598や、標準の504と混同しないでください。
  • 上流接続が確立していたか確認する前に、アプリケーションロジックだけを調査しないでください。
  • クライアント入力の誤りや認証失敗を599で表現しないでください。
出典: Proxy / Gateway convention 関連コード: 502, 522, 598

概要

このページは、単に番号を覚えるためではなく、日常的なAPIデバッグや本番障害の振り返りで使うことを想定しています。各項目ではプロトコル上の意味と実務上の文脈を合わせて説明しているため、フロントエンド開発者、バックエンドエンジニア、QA、SRE、SEO監査、APIドキュメント作成まで幅広く活用できます。

  1. 01

    標準コードと拡張ステータスコード

    RFCで定義された一般的なステータスコードに加え、WebDAV、Nginx、Cloudflare、AWSロードバランサー、Microsoft/IISの慣例、プロキシゲートウェイ、再開可能アップロードのドラフトで見かける拡張コードやベンダー固有コードも含みます。

  2. 02

    検索できるトラブルシューティング文脈

    コード番号、英語フレーズ、分類、概要、出典、関連コード、よくある状況、確認ポイント、使わないほうがよい場面まで検索対象にしています。そのためcacheCORStimeoutWebSocketrate limitのような症状ベースの検索から適切な項目にたどり着けます。

  3. 03

    API設計の推奨度

    各ステータスコードには推奨度を付けています。公開REST APIやJSON APIで安全に使いやすいコードと、通常は内部実装・ベンダー固有・インフラ側の詳細として扱うべきコードを切り分ける手がかりになります。

  4. 04

    運用・SEOへの影響

    リダイレクト、soft error、クローラーから見える404/410、ゲートウェイ障害、429のレート制限、5xx障害を、ユーザー向けページと自動クライアントの両方をデバッグしやすい観点で説明します。

使い方

ブラウザのDevTools、サーバーログ、APIレスポンス、CDNダッシュボード、ロードバランサーログ、クローラーレポート、監視アラートを確認するときに使えます。

  1. 01

    ログやネットワークツールに表示された番号、理由フレーズ、ベンダー名、症状を検索します。

  2. 02

    レスポンスが情報レスポンス、成功、リダイレクト、クライアント側エラー、サーバー側エラーのどれか分かっている場合は、ステータスクラスのフィルターで絞り込みます。

  3. 03

    一致した項目を開き、まず概要を読みます。その後、よくある状況を確認して、どのレイヤーがそのレスポンスを生成した可能性が高いかを見極めます。

  4. 04

    API契約を変更する前に関連コードを比較します。200、400、401、403、404、409、422、429、500、502、503、504を混同するミスはよくあります。

  5. 05

    出典とライフサイクルのラベルを見て、そのコードを公開ドキュメントに載せてもよいか、インフラ内部の詳細として扱うべきかを判断します。

詳細

実際のデバッグ中に素早く読める構成にしつつ、APIドキュメントや社内エンジニアリングメモにも使えるだけの詳細を入れています。

  • 正式なコード番号、理由フレーズ、ステータスクラス。
  • 素早く確認するための短い概要と、深く調べるための詳しい説明。
  • API、ブラウザ、CDN、ゲートウェイ、プロキシ、サーバーログでそのステータスコードが出やすい場面。
  • クライアントリクエスト、バックエンドサービス、ルーティング、認証、キャッシュ、リダイレクト、インフラ層を確認するための具体的な観点。
  • 誤解を招きやすい使い方や、使われすぎているコードを避けるための注意点。
  • 実装の挙動を変える前に比較すべき関連ステータスコード。
  • 標準、非推奨、一時的、ベンダー固有、実装固有のコードを見分けるためのライフサイクルと出典情報。

活用シーン

レスポンス、ログ行、SEOレポート、稼働監視アラート、APIテスト、SDKエラー、リバースプロキシのダッシュボードにステータスコードが出てきたときに役立ちます。

  1. REST APIとJSON APIの設計

    作成、更新、バリデーション、認証、認可、競合、レート制限、非同期ジョブ、空レスポンスのフローに適したステータスコードを選べます。

  2. フロントエンドとブラウザのデバッグ

    Networkパネルから、リダイレクト、CORSに似た失敗、認証チャレンジ、前提条件エラー、キャッシュ再検証、WebSocketアップグレード、アセット読み込み失敗を読み解けます。

  3. SEOとクロール診断

    301、302、307、308、404、410、429、500、503、soft error、リダイレクトチェーン、利用できないページ、クローラーから見えるサーバーエラーを確認できます。

  4. CDN、ゲートウェイ、ロードバランサーの障害

    アプリケーションコードを変更する前に、オリジンのエラーなのか、Cloudflare、Nginx、AWS ALB、プロキシタイムアウト、TLS、DNS、上流到達性の問題なのかを切り分けられます。

関連情報

HTTPエラーがサービスのポート、ファイアウォールルール、受信経路に関係している場合は、 ポート リファレンス でサービス、プロトコル、公開範囲の目安を確認できます。問題がリクエストURLの構造、クエリパラメーター、エンコードに関係している場合は、 URL ツール でリンク全体を解析して確認できます。

使い方のヒント

ステータスコードは、プロトコルレベルの結果を明確に表すべきです。レスポンス本文には、アプリケーション固有のエラーコード、フィールド別メッセージ、trace ID、リトライのヒント、サポートリンクを追加できます。

  • サーバーがJSON本文を返せたという理由だけで、アプリケーションエラーを200にしないでください。
  • 新しいリソースを作成した場合は201、あとで処理する作業を受け付けた場合は202、処理は成功したが本文が不要な場合は204を使います。
  • 不正なリクエストには400、認証がない・無効な場合は401、認証済みだが許可されない場合は403、見つからない場合は404、状態の競合には409、意味的に無効な入力を区別したい場合は422を使います。
  • レート制限には429を使い、クライアントが安全に待って再試行できる場合はリトライの目安も返します。
  • 呼び出し元がそのインフラ詳細を明示的に必要としていない限り、非標準のベンダーコードを公開API契約として露出しないでください。
  • 公開Webサイトでは、検索エンジンがsoft 404や一時的な障害ページを通常コンテンツとしてインデックスしないよう、エラーページに正しいステータスコードを返してください。

制限事項

HTTPステータスコードは標準化されたプロトコル上のシグナルですが、正確な原因はルート、リクエストメソッド、ヘッダー、レスポンス本文、キャッシュ層、プロキシチェーン、サーバーログによって変わります。

  • ステータスコードだけで、どのサービスがレスポンスを生成したかを断定できることはほとんどありません。アプリケーションログと、CDN、ゲートウェイ、プロキシ、ロードバランサー、オリジンのログを突き合わせてください。
  • ベンダー固有または実装固有のコードには、運用ダッシュボードでは有用でも、移植可能なHTTPセマンティクスとは言えないものがあります。
  • ブラウザ、APIクライアント、クローラー、SDKは、リダイレクト、認証チャレンジ、キャッシュ、暫定レスポンスをそれぞれ異なる形で扱うことがあります。
  • 最終的なAPIの挙動を安定して判断できるように、HTTPステータスコードと構造化されたレスポンス本文の両方をドキュメント化してください。

よくある質問

使い分け、データの扱い、結果確認、実務上の限界についてよくある質問に答えます。

401と403の違いは何ですか?

401は、有効な認証情報がない、または認証チャレンジが必要であることを示します。403は、サーバーが呼び出し元を把握している、または少なくともリクエストを理解しているものの、そのリソースへのアクセスを許可しないことを示します。

APIのバリデーションエラーでは400と422のどちらを返すべきですか?

リクエストが壊れている、または解析できない場合は400を使います。構文は正しいものの、送信された値が業務ルールや意味的な検証に失敗した場合は422を使います。実際には、どちらか一方の方針に統一して明確にドキュメント化するチームも多いです。

Webサイトでは404と410をいつ使い分けるべきですか?

リソースが見つからない場合、または存在有無を明かしたくない場合は404を使います。リソースが意図的に削除され、その状態が恒久的だと分かっている場合は410を使うと、クローラーやクライアントにとってより明確です。

Cloudflare、Nginx、AWS固有のステータスコードが出るのはなぜですか?

それらのレスポンスは、リクエストがアプリケーションに届く前にインフラが生成している場合もあれば、オリジンが正しく応答できなかった後に生成される場合もあります。アプリケーションが返したと決めつける前に、プロキシ、CDN、ゲートウェイ、DNS、TLS、ファイアウォール、ロードバランサーのログを確認してください。

5xxレスポンスはすべてサーバーバグですか?

必ずしもそうではありません。5xxは通信のサーバー側で失敗したことを示しますが、原因は上流依存サービス、メンテナンスモード、過負荷、ゲートウェイタイムアウト、DNSの問題、TLSの問題、リバースプロキシ設定にある場合もあります。

関連ツール

HTTPデバッグからネットワークポート、MIMEタイプ、ヘッダー、URLの挙動、その他の実装詳細に調査が広がる場合は、リファレンスカテゴリの関連ツールも使えます。