HTTP ステータスコード — 意味と例付きの完全一覧

暫定レスポンス：サーバーがリクエストヘッダーを受け取ったので、クライアントはそのままボディを送信してよいことを示します。

クライアントが大きなボディをアップロードする前に「Expect: 100-continue」を付けたときにサーバーが自動的に送信します。これにより、拒否されるリクエストで帯域を無駄にせずに済みます。

アプリケーションコードから最終ステータスとして送信しないでください。これはリクエストへの応答そのものではなく、本来のレスポンスの前段階にすぎません。

該当なし

RFC 9110 §15.2.1

PUT /upload HTTP/1.1
Content-Length: 104857600
Expect: 100-continue

HTTP/1.1 100 Continue

サーバーが、Upgrade ヘッダーで指定されたプロトコルへの接続の切り替えに同意したことを示します。

WebSocket 接続（Upgrade: websocket）のハンドシェイクのレスポンス。かつては HTTP/1.1 から h2c へのアップグレードにも使われました。

HTTP/2 と HTTP/3 では使われません。HTTP/2 上の WebSocket は代わりに拡張 CONNECT メソッド（RFC 8441）を使います。

該当なし

RFC 9110 §15.2.2

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

サーバーが時間のかかる WebDAV リクエストをまだ処理中であり、クライアントはタイムアウトすべきでないことを伝える暫定レスポンスです。

WebDAV。RFC 4918 で WebDAV から削除されましたが、IANA レジストリには残っています。

深い COPY や MOVE など、時間のかかる再帰的な操作を処理するレガシーな WebDAV サーバーでのみ使われます。

新しい API では、長時間かかる処理には代わりにステータス確認用 URL 付きの 202 Accepted を返しましょう。

該当なし

RFC 2518 §10.1

HTTP/1.1 102 Processing

Link ヘッダーを含む暫定レスポンスで、サーバーが最終レスポンスを準備している間に、ブラウザがプリロードや事前接続を始められるようにします。

HTML の生成に時間がかかり（サーバーサイドレンダリング、データベースクエリ）、ページに必要な CSS、フォント、オリジンが事前にわかっている場合。Chromium 系ブラウザと Firefox は 103 レスポンスの preload と preconnect のヒントに対応し、Safari は preconnect に対応しています。

Set-Cookie のように最終レスポンスにのみ適用すべきヘッダーを含めないでください。ブラウザは 103 内のほとんどのヘッダーを無視します。

該当なし

RFC 8297

HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: <https://cdn.example.com>; rel=preconnect

HTTP/1.1 200 OK
Content-Type: text/html

開始したアップロードを後で再開できること、およびその再開先を伝える暫定レスポンスです。

IETF の再開可能アップロードのドラフトに対する IANA の暫定登録。まだ正式な RFC ではありません。

実験的：再開可能アップロードのドラフトを実装したサーバーが、アップロードリソースを示す Location ヘッダーとともに送信します。

ドラフトが RFC として公開されるまでは一般的な用途には向きません。ほとんどのクライアントやプロキシはこのコードを認識しません。

該当なし

draft-ietf-httpbis-resumable-upload

HTTP/1.1 104 Upload Resumption Supported
Upload-Draft-Interop-Version: 6
Location: https://example.com/upload/b530ce8ff

リクエストが成功しました。ボディの内容はメソッドによって異なり、GET ならリソース、POST なら処理の結果です。

GET の通常の成功レスポンス。POST、PUT、PATCH、DELETE で結果を説明するボディを返す場合にも使います。

ボディにエラーメッセージを入れて 200 を返さないでください（「ソフトエラー」）。クライアント、監視ツール、キャッシュ、検索エンジンが見るのはステータスコードであり、JSON の中身ではありません。

デフォルトでキャッシュ可能（ヒューリスティックにキャッシュ可能）

RFC 9110 §15.3.1

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 42, "name": "Ada"}

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

何かを作成する POST（または新しい URL への PUT）の後に使います。新しいリソースを指す Location ヘッダーを含め、ボディには通常そのリソースの説明を入れます。

既存レコードの更新など、新しく何も作成されていない場合には使わないでください（200 または 204 を使います）。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.3.2

HTTP/1.1 201 Created
Location: /users/42
Content-Type: application/json

{"id": 42}

リクエストは処理のために受理されましたが、処理はまだ完了しておらず、失敗する可能性もあります。

キューに入れる処理や非同期処理：動画のエンコード、レポートの生成、一括インポートなど。クライアントがジョブの状態を確認できるリンクを返しましょう。

同期処理の「成功」の意味で使わないでください。このコードは結果について何も約束しないことを明示しています。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.3.3

HTTP/1.1 202 Accepted
Location: /jobs/7f3a
Content-Type: application/json

{"status": "queued"}

成功ですが、変換を行うプロキシがオリジンサーバーの 200 レスポンスを変更しています。

画像を圧縮したり HTML を書き換えたりするプロキシなど、コンテンツを変更する中継サーバーが、オリジンのレスポンスそのままではないことをクライアントに伝えるためにのみ使います。

オリジンサーバーや API は送信すべきではありません。

デフォルトでキャッシュ可能（ヒューリスティックにキャッシュ可能）

RFC 9110 §15.3.4

HTTP/1.1 203 Non-Authoritative Information
Content-Type: image/webp

成功で、意図的にボディがありません。

成功した DELETE、更新後のリソースを返さない PUT や PATCH、フォームの自動保存、CORS のプリフライトレスポンスなど。

ボディを含めてはいけません。クライアントは読み込まず、HTTP/1.1 では余分なボディがその接続上の次のレスポンスを壊してしまいます。返すものがある場合は 200 を使ってください。

デフォルトでキャッシュ可能（ヒューリスティックにキャッシュ可能）

RFC 9110 §15.3.5

HTTP/1.1 204 No Content

成功です。クライアントは文書の表示をリセット（例：送信したフォームをクリア）すべきことを示します。

ユーザーがフォームを送信した直後に次のレコードを入力するようなデータ入力画面。

ブラウザはリセット動作を実装していないため、実際には 204 と同じように動作します。ボディを含めてはいけません。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.3.6

HTTP/1.1 205 Reset Content

サーバーは、クライアントが Range ヘッダーで要求したバイト範囲のみを返しています。

動画や音声のシーク、再開可能なダウンロード、ファイルを並列に分割取得するダウンロードマネージャー。Content-Range を含めます。

リクエストに Range ヘッダーがあり、それに応じる場合以外は送信しないでください。Range を無視する場合は、ボディ全体とともに 200 を送ります。

デフォルトでキャッシュ可能（ヒューリスティックにキャッシュ可能）

RFC 9110 §15.3.7

GET /video.mp4 HTTP/1.1
Range: bytes=0-1023

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-1023/146515
Content-Length: 1024

ボディ（XML）に、複数のリソースそれぞれのステータスが個別に含まれています。

WebDAV

PROPFIND など、多数のリソースを対象とする WebDAV の操作。一部の JSON API はバッチ用エンドポイントに流用しています。

バッチ API では、汎用クライアントが 207 を単なる成功として扱うため、項目ごとの結果を含む 200 を好むチームが多くあります。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 4918 §11.1

HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"

207 レスポンスの中で、あるリソースがすでに前に列挙されているため繰り返さないことを示します（バインディングによるループを防ぎます）。

WebDAV

バインディング（RFC 5842）に対応した WebDAV サーバー。

WebDAV 以外では、トップレベルのレスポンスとして意味を持ちません。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 5842 §7.1

<D:status>HTTP/1.1 208 Already Reported</D:status>

サーバーが GET に対して、リソース全体ではなく、現在のリソースに差分（インスタンス操作）を適用した結果で応答しました。

HTTP の差分エンコーディング（A-IM / IM ヘッダー）。導入例はほとんどありません。

ブラウザは対応していません。通常の API では使わないでください。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 3229 §10.4.1

HTTP/1.1 226 IM Used
IM: vcdiff
ETag: "v2"

リソースに複数の表現があり、クライアント（またはユーザー）がその中から選ぶ必要があります。

まれ：エージェント駆動型のコンテンツネゴシエーション。たとえば、文書を複数の言語や形式で提供し、それぞれへのリンクを示す場合など。

ブラウザは自動では選択しません。言語や形式の選択には、サーバー駆動型のネゴシエーションか、リンクを並べた通常のページのほうが適しています。

デフォルトでキャッシュ可能（ヒューリスティックにキャッシュ可能）

RFC 9110 §15.4.1

HTTP/1.1 300 Multiple Choices
Link: </doc.en.html>; rel=alternate; hreflang=en
Link: </doc.fr.html>; rel=alternate; hreflang=fr

リソースに新しい恒久的な URL があり、Location ヘッダーで示されます。

ドメインの移転、HTTP から HTTPS への移行、スラッグの変更、重複 URL の統合。検索エンジンは評価シグナルを新しい URL に引き継ぎます。

ブラウザは 301 をたどる際に POST を GET に変えることがあります。メソッドを維持する必要がある場合（移動した API エンドポイントなど）は 308 を使ってください。ブラウザは 301 を積極的にキャッシュするので、デプロイ前にテストしましょう。

デフォルトでキャッシュ可能（ヒューリスティックにキャッシュ可能）

RFC 9110 §15.4.2

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-page

リソースは一時的に別の URL にあります。今後も元の URL を使い続けてください。

一時的なリダイレクト：ログインへのリダイレクト、A/B テスト、メンテナンスページ、地域や言語によるリダイレクト。

ブラウザは 302 をたどる際に POST を GET に変えます（RFC が許容する歴史的な挙動）。POST 後に「結果を見に行く」場合は 303 を、メソッドを維持する必要がある場合は 307 を使ってください。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.4.3

HTTP/1.1 302 Found
Location: /login?next=%2Faccount

クライアントを別の URL にリダイレクトし、その URL を GET で取得させます。

Post/Redirect/Get パターン：フォームの POST 後に結果ページへの 303 を返し、ページを再読み込みしてもフォームが再送信されないようにします。

コンテンツの移動には使いません。元の URL が移動したことは何も示しません。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.4.4

HTTP/1.1 303 See Other
Location: /orders/1234

条件付き GET または HEAD（If-None-Match または If-Modified-Since）へのレスポンス：クライアントのキャッシュはまだ有効です。

キャッシュの再検証：このレスポンス自体は保存されませんが、クライアントがすでに持っているキャッシュ済みレスポンスを更新します。

ETag や Last-Modified の日付が一致したときにサーバーや CDN が自動的に返し、変更のないボディの転送を省きます。

ボディを送ってはいけません。条件付きでないリクエストには送らないでください。クライアントには再利用できるものがありません。

該当なし

RFC 9110 §15.4.5

GET /app.js HTTP/1.1
If-None-Match: "33a64df5"

HTTP/1.1 304 Not Modified
ETag: "33a64df5"
Cache-Control: max-age=3600

非推奨。かつては、Location で指定したプロキシ経由でリクエストを再送するようクライアントに指示していました。

なし。セキュリティ上の理由で非推奨となり、ブラウザは無視します。

送信しないでください。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.4.6

HTTP/1.1 305 Use Proxy

予約済み。ドラフトで「Switch Proxy」として使われていましたが、現在は使われていません。

なし。

送信しないでください。

該当なし

RFC 9110 §15.4.7

一時的なリダイレクトで、クライアントは同じメソッドとボディでリクエストを再送する必要があります。

POST、PUT、DELETE リクエストの一時的なリダイレクト（メンテナンスのために移動した API エンドポイントなど）。HSTS により HTTPS が強制される場合も、ブラウザは内部的に 307 を表示します。

恒久的な移動には 308 を使います。「GET で結果を取得しに行く」場合は 303 を使います。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.4.8

HTTP/1.1 307 Temporary Redirect
Location: https://api2.example.com/v1/orders

恒久的なリダイレクトで、クライアントは同じメソッドとボディでリクエストを再送する必要があります。

POST や PUT を受け付ける、恒久的に移動した API エンドポイント。検索エンジンは 301 と同様に扱います。Next.js と Vercel は、恒久的なリダイレクトにデフォルトで 308 を使います。

非常に古いクライアント（Windows 7 以前の Internet Explorer）は理解できません。通常のページ移動なら 301 でも同様に機能します。

デフォルトでキャッシュ可能（ヒューリスティックにキャッシュ可能）

RFC 9110 §15.4.9

HTTP/1.1 308 Permanent Redirect
Location: https://example.com/api/v2/upload

クライアント側のエラー（構文の誤り、不正なフレーミング、不正なパラメーター）のため、サーバーはリクエストを処理しません。

解析できない JSON、必須パラメーターの欠落、型の誤った値。ボディで問題を説明しましょう（RFC 9457 の problem+json がよい形式です）。

形式は正しいがビジネスルールに反する入力には、多くの API が 422 を使います。認証の問題には 401 または 403 を使います。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.5.1

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json

{"title": "Invalid JSON", "detail": "Unexpected token } at position 41"}

リクエストに有効な認証情報がありません。名前に反して、意味は「未認証」です。

トークンがない、トークンの期限切れ、パスワードの誤り。レスポンスには、認証方法を示す WWW-Authenticate ヘッダーを含める必要があります。

ユーザーがログイン済みでも権限がない場合は 403 を使います。WWW-Authenticate なしで 401 を送らないでください。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.5.2

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="api", error="invalid_token"

将来の使用のために予約されています。標準的な意味は定められていません。

一部の API は「利用枠を使い切ったのでプランをアップグレードしてください」や支払いの失敗に使います（Stripe はカードが拒否されたリクエストに 402 を返します）。

クライアントがこのコードを理解することを当てにせず、ボディで問題を説明してください。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.5.3

HTTP/1.1 402 Payment Required
Content-Type: application/json

{"error": "card_declined"}

サーバーはリクエストを理解し、相手が誰かもわかっている（または気にしていない）うえで、実行を拒否しています。

認証済みユーザーに権限がない、IP がブロックされている、ディレクトリ一覧が無効、WAF のルールが作動したなど。再認証しても解決しません。

認証情報がない、または無効な場合は 401 を使います。リソースの存在を明かすこと自体が情報漏えいになる場合は、代わりに 404 を返します。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.5.4

HTTP/1.1 403 Forbidden
Content-Type: application/json

{"error": "You do not have access to this project"}

サーバーにはその URL に対応する現在の表現がないか、存在するかどうかを明かしません。

不明な URL、削除を追跡していない場合の削除済みレコード、権限のないユーザーからリソースを隠す場合。

リソースが以前存在し、完全になくなった場合は、410 がそれを明示します。「見つかりません」と表示する 200 ページ（ソフト 404）を返さないでください。

デフォルトでキャッシュ可能（ヒューリスティックにキャッシュ可能）

RFC 9110 §15.5.5

HTTP/1.1 404 Not Found
Content-Type: text/html

URL は存在しますが、この HTTP メソッドには対応していません。

読み取り専用リソースへの DELETE や、GET 専用ページへの POST。レスポンスには、対応メソッドを列挙した Allow ヘッダーを含める必要があります。

権限の問題（403）や、サーバーがまったく実装していないメソッド（501）には使わないでください。

デフォルトでキャッシュ可能（ヒューリスティックにキャッシュ可能）

RFC 9110 §15.5.6

HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD

サーバーは、リクエストの Accept、Accept-Language、Accept-Encoding ヘッダーに合うレスポンスを生成できません。

JSON しか扱わない API が、代替手段なしで「Accept: application/xml」を受け取った場合。

ほとんどのサーバーは一致しない Accept ヘッダーを無視してデフォルトの形式を返します。そのほうが通常は親切です。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.5.7

HTTP/1.1 406 Not Acceptable
Content-Type: application/json

{"supported": ["application/json"]}

401 と同様ですが、クライアントは間にあるプロキシで認証する必要があります。

フォワードプロキシ（企業のプロキシなど）が Proxy-Authenticate ヘッダーとともに送信します。

オリジンサーバーが送信することはありません。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.5.8

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="corp-proxy"

サーバーが待機できる時間内に完全なリクエストを受け取れなかったため、接続を閉じようとしています。

アイドル状態のキープアライブ接続や遅いアップロードに対してサーバーが送信します。クライアントは新しい接続でリクエストを再試行できます。

バックエンドの処理が遅い場合には使いません。それはゲートウェイでの 504 か、単に遅いレスポンスです。このコードと一緒に「Connection: close」を送ってください。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.5.9

HTTP/1.1 408 Request Timeout
Connection: close

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

すでに存在するメールアドレスでのユーザー作成、他の人が変更したレコードの編集（バージョンの不一致）、空でないフォルダの削除。

If-Match / If-Unmodified-Since の条件が満たされない場合は 412 を、バリデーションエラーには 400 または 422 を使います。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.5.10

HTTP/1.1 409 Conflict
Content-Type: application/json

{"error": "Email already registered"}

リソースは以前ここに存在しましたが、恒久的に削除され、転送先もありません。

販売終了した商品、終了したキャンペーン、削除されたアカウント、廃止された API バージョン。Google は 404 と 410 をほぼ同じように扱いますが、410 のほうが少し早くインデックスから削除されることがあります。

コンテンツが移動した場合は、代わりに 301 でリダイレクトします。恒久的かどうか確信がない場合は 404 を使います。

デフォルトでキャッシュ可能（ヒューリスティックにキャッシュ可能）

RFC 9110 §15.5.11

HTTP/1.1 410 Gone

サーバーは、このリクエストに Content-Length ヘッダーを要求しています。

チャンク形式のアップロードを拒否し、事前にボディのサイズを知る必要があるサーバー。

アプリケーションで必要になることはまれで、通常は Web サーバー自体が返します。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.5.12

HTTP/1.1 411 Length Required

リクエストヘッダーの条件（If-Match、If-Unmodified-Since、書き込み時の If-None-Match）が偽と評価されました。

楽観的並行性制御：クライアントが古い ETag を付けて If-Match を送った場合で、他の誰かが先にリソースを変更したことを意味します。

条件付きヘッダーとは関係のないビジネスルール違反には使わないでください（409 または 422 を使います）。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.5.13

PUT /docs/7 HTTP/1.1
If-Match: "v3"

HTTP/1.1 412 Precondition Failed
ETag: "v4"

リクエストボディが、サーバーが処理できる大きさを超えています。RFC 9110 より前は「Payload Too Large」と呼ばれていました。

上限を超えるアップロード（nginx の client_max_body_size、API の 10 MB 上限など）。上限が一時的なものなら Retry-After を追加します。

URL が長すぎる場合は 414、ヘッダーが大きすぎる場合は 431 を使います。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.5.14

HTTP/1.1 413 Content Too Large
Connection: close

リクエスト対象（URL）が、サーバーが解釈できる長さを超えています。

巨大なクエリ文字列。POST にすべき GET フォームや、パラメーターを追加し続けるリダイレクトループが原因であることがよくあります。

上限をどこまでも引き上げるのではなく、大きな入力はリクエストボディ（POST）に移しましょう。

デフォルトでキャッシュ可能（ヒューリスティックにキャッシュ可能）

RFC 9110 §15.5.15

HTTP/1.1 414 URI Too Long

ボディの形式（Content-Type または Content-Encoding）に対応していないため、サーバーはリクエストを拒否しています。

JSON を受け付けるエンドポイントがフォームデータや XML を受け取った場合や、Content-Type ヘッダーがない場合。Accept-Post または Accept-Patch を含めて、対応形式を示しましょう。

形式は正しいが内容が不正なボディには使いません（400 または 422）。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.5.16

HTTP/1.1 415 Unsupported Media Type
Accept-Post: application/json

Range ヘッダーのバイト範囲がリソースとまったく重なりません。たとえばファイルの終端を超えるバイトを要求した場合です。

ファイルが小さくなった後の再開ダウンロードや、クライアントが終端を超えて要求した場合。Content-Range: bytes */<length> を含めます。

サーバーは不正な Range を単に無視して、ボディ全体とともに 200 を返すこともでき、それも認められています。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.5.17

HTTP/1.1 416 Range Not Satisfiable
Content-Range: bytes */47022

サーバーは、リクエストの Expect ヘッダーの要件を満たせません。

クライアントが「Expect: 100-continue」に対応していないサーバーやプロキシに送った場合や、未知の期待値を送った場合。

このコードを受け取ったクライアントは、Expect ヘッダーなしで再試行すべきです。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.5.18

HTTP/1.1 417 Expectation Failed

418 が「I’m a teapot」というジョークコードとして広く使われていたため、RFC 9110 で予約されています。HTTP での意味は定められていません。

予約済み。1998 年のエイプリルフール RFC 2324（HTCPCP）の「I’m a teapot」として有名です。

イースターエッグとしてのみ。一部のサービスは、拒否したいリクエストにユーモラスに応答するために使います。

実際のエラーには使わないでください。意味を割り当てることができず、クライアントはどう対処すべきかわかりません。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.5.19

HTTP/1.1 418 I'm a teapot

CSRF トークンがない、または期限切れのときに Laravel が返します。通常は、フォームのあるページでセッションがタイムアウトした後に発生します。

Laravel の CSRF ミドルウェアが送信します。ページを再読み込みする、フォームに @csrf を含める、AJAX リクエストで X-CSRF-TOKEN ヘッダーを送る、のいずれかで解決します。

標準のコードではありません。Laravel 以外の API から送らないでください。

該当なし

Laravel（IANA レジストリには未登録）

HTTP/1.1 419 unknown status

旧 Twitter API のレート制限レスポンスで、現在は標準の 429 に置き換えられています。

新規の用途はありません。古いクライアントライブラリで見かけることがあります。Spring はかつて 420「Method Failure」を定義していましたが、現在は非推奨です。

レート制限には 429 を使います。

該当なし

Twitter API v1（IANA レジストリには未登録）

HTTP/1.1 420 Enhance Your Calm

リクエストが、そのホストとスキームに対するレスポンスを生成できないサーバーに届きました。

HTTP/2 の接続の統合がうまくいかなかった場合：ブラウザが同じ証明書でカバーされる別のホスト名に接続を再利用したものの、サーバーがそのホストを提供していない場合です。クライアントは新しい接続で再試行すべきです。

単一サーバー上の通常の未知のホスト名には使いません。その場合は通常 404 か、デフォルトのバーチャルホストになります。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.5.20

HTTP/2 421

リクエストは正しい形式で対応形式でもありますが、内容がバリデーションに通りません。RFC 4918 では「Unprocessable Entity」と呼ばれていました。

フォームや API のバリデーションエラー：メールアドレスになっていないメール、開始日より前の終了日など。Rails、Laravel、FastAPI はデフォルトでこれを使います。

構文の誤り（解析できない JSON）には 400 を使います。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.5.21

HTTP/1.1 422 Unprocessable Content
Content-Type: application/json

{"errors": {"email": ["is invalid"]}}

リソースがロックされているため、リクエストで変更できません。

WebDAV

WebDAV の LOCK のセマンティクス。一部の API は、他の人が編集中のレコードや、ログイン失敗でロックされたアカウントに使います。

WebDAV 以外では、汎用クライアントには 409 のほうが理解されやすいです。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 4918 §11.3

HTTP/1.1 423 Locked

依存していた別の操作が失敗したため、この操作も失敗しました。

WebDAV

WebDAV の PROPPATCH やバッチリクエストで、先の項目が失敗したために試行されなかった項目。

上流サービスの障害には使いません。それらは 502 または 503 です。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 4918 §11.4

HTTP/1.1 424 Failed Dependency

TLS 1.3 のアーリーデータ（0-RTT）で送られたリクエストは、リプレイされる可能性があるため、サーバーは処理しません。

0-RTT を受け付けるものの、アーリーデータ内の非冪等なリクエスト（POST）を拒否する CDN やサーバー。クライアントはハンドシェイク完了後に再試行します。

一般的な「後で再試行」のコードではありません。その場合は Retry-After 付きの 503 を使います。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 8470 §5.2

HTTP/1.1 425 Too Early

サーバーは現在のプロトコルでのリクエストを拒否していますが、Upgrade ヘッダーで指定したプロトコルにアップグレードすれば受け付けます。

TLS や新しいプロトコルを必須とする場合や、WebSocket エンドポイントに通常の HTTP リクエストが来た場合。Upgrade ヘッダーを含める必要があります。

Web サイトの HTTP から HTTPS への移行には、301 または 308 のリダイレクトと HSTS を組み合わせるのが一般的です。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.5.22

HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.3, HTTP/1.1
Connection: Upgrade

更新の消失を防ぐため、サーバーはリクエストが条件付き（If-Match など）であることを要求しています。

PUT、PATCH、DELETE の前に、最後に確認した ETag を If-Match で送るようクライアントに求める API。

前提条件が送られて失敗した場合は 412 を使います。428 は何も送られなかった場合のためのものです。

キャッシュに保存してはならない

RFC 6585 §3

HTTP/1.1 428 Precondition Required
Content-Type: application/json

{"error": "Send If-Match with the current ETag"}

クライアントが一定時間内に送ったリクエストが多すぎます（レート制限）。

API のレート制限、ログイン試行の制限、スクレイピング対策。行儀のよいクライアントがいつ再試行すればよいかわかるよう Retry-After を含めましょう。RateLimit ヘッダーも役立ちます。

サーバーが全員に対して過負荷になっている場合は 503 を使います。Googlebot は 429 を 503 と同様に扱い、クロールの速度を落とします。

キャッシュに保存してはならない

RFC 6585 §4

HTTP/1.1 429 Too Many Requests
Retry-After: 60
Content-Type: application/json

{"error": "Rate limit exceeded: 100 requests per minute"}

ヘッダーが、個別に、または合計で、サーバーにとって大きすぎます。

たいていは、ドメインに蓄積した大きすぎる Cookie や巨大な Authorization トークンが原因です。ユーザー側では Cookie を削除すると解決することがよくあります。

URL が長い場合は 414、ボディが大きい場合は 413 を使います。

キャッシュに保存してはならない

RFC 6585 §5

HTTP/1.1 431 Request Header Fields Too Large

クライアントのセッションが期限切れになり、再ログインが必要です（Outlook Web Access など IIS のアプリ）。

Exchange/OWA 環境で見られます。

自分のアプリでのセッション切れには 401 を使います。

該当なし

Microsoft IIS（IANA レジストリには未登録）

HTTP/1.1 440 Login Time-out

nginx 内部のコード：「return 444;」で、レスポンスを一切送らずに接続を閉じます。

スキャナーからのリクエスト、デフォルトの server ブロックでの未知の Host ヘッダーへのリクエスト、悪質なクライアントの遮断。nginx のログに記録され、クライアントには空の応答が返ります。

クライアントが 444 を受け取ることはないので、クライアントコードで処理するものではありません。

該当なし

nginx（IANA レジストリには未登録）

server {
  listen 80 default_server;
  return 444;
}

Microsoft の拡張：クライアントが特定の操作を行った後にリクエストを再試行すべきことを示します。

一部の Microsoft サービスで見られます（Exchange ActiveSync。Azure Cosmos DB は再試行可能な書き込み競合に 449 を使います）。

標準ではありません。自分の API では 409、または Retry-After 付きの 503 を使います。

該当なし

Microsoft IIS（IANA レジストリには未登録）

HTTP/1.1 449 Retry With

Windows の保護者による制限でページへのアクセスがブロックされました。

保護者による制限が有効な Windows システムで生成されます。

サーバーから送信しないでください。

該当なし

Microsoft（IANA レジストリには未登録）

HTTP/1.1 450 Blocked by Windows Parental Controls

法的な要請（裁判所の命令、政府による検閲、法的理由による地域制限）のため、アクセスが拒否されています。

特定の法域でブロックされたコンテンツ（制裁、GDPR 関連の地域ブロック、削除命令）。rel="blocked-by" 付きの Link ヘッダーで、誰がブロックを課したかを示せます。

通常の権限拒否（403）や、単に自分で削除すると決めたコンテンツ（410）には使いません。

デフォルトでキャッシュ可能（ヒューリスティックにキャッシュ可能）

RFC 7725 §3

HTTP/1.1 451 Unavailable For Legal Reasons
Link: <https://authority.example/>; rel="blocked-by"

アイドルタイムアウトが経過する前にクライアントが接続を閉じた場合に、AWS ALB が記録します。

ALB のアクセスログで見られます。たいていは、ターゲットの処理時間よりタイムアウトが短いクライアントです。

クライアントには送信されません。

該当なし

AWS Elastic Load Balancing（IANA レジストリには未登録）

elb_status_code=460

ALB が 30 個を超える IP アドレスを含む X-Forwarded-For ヘッダーを受け取りました。

たいていは、アドレスを追加し続けるプロキシのループです。

アプリケーションで使うものではありません。

該当なし

AWS Elastic Load Balancing（IANA レジストリには未登録）

HTTP/1.1 463

ヘッダーが large_client_header_buffers を超えた場合の nginx 内部のコードです。クライアントには 400 が返ります。

nginx のログや error_page の設定で使われます。

標準のコードは 431 です。

該当なし

nginx（IANA レジストリには未登録）

error_page 494 /header-too-large.html;

nginx 内部：クライアントが無効なクライアント証明書を提示しました（相互 TLS）。クライアントには 400 として送られます。

mTLS の失敗時のカスタムエラーページ。

実際に送受信されるステータスコードではありません。

該当なし

nginx（IANA レジストリには未登録）

error_page 495 /bad-client-cert.html;

nginx 内部：クライアント証明書が必要なのに提示されませんでした。クライアントには 400 として送られます。

ssl_verify_client が有効な場合のカスタムエラーページ。

実際に送受信されるステータスコードではありません。

該当なし

nginx（IANA レジストリには未登録）

error_page 496 /client-cert-required.html;

nginx 内部：TLS を想定したポートに通常の HTTP リクエストが届きました。クライアントには 400 として送られます。

よく使われる手法は「error_page 497 =301 https://$host$request_uri;」で、こうしたリクエストを HTTPS にリダイレクトします。

実際に送受信されるステータスコードではありません。

該当なし

nginx（IANA レジストリには未登録）

error_page 497 =301 https://$host:$server_port$request_uri;

期限切れ、またはその他の理由で無効なトークンに対して ArcGIS が返します。

ArcGIS のサービスを呼び出す場合にのみ関係します。

自分の API での無効なトークンには 401 を使います。

該当なし

Esri ArcGIS（IANA レジストリには未登録）

HTTP/1.1 498 Invalid Token

nginx がレスポンスを送る前にクライアントが接続を閉じた場合に、nginx が 499 を記録します。

アクセスログで見られます：ユーザーがページを離れた、モバイルクライアントがタイムアウトした、nginx の前にあるロードバランサーのタイムアウトが短いなど。特定のエンドポイントで 499 が多い場合、たいていは処理が遅すぎることを意味します。

クライアントが受け取ることはありません。Esri も 499 を「Token Required」に使っています。

該当なし

nginx（IANA レジストリには未登録）

203.0.113.9 - - [16/Oct/2026:10:12:01 +0000] "GET /report HTTP/1.1" 499 0

サーバーで予期しない状況が発生し、リクエストを処理できませんでした。

未処理の例外やバグ。より具体的な 5xx が当てはまらない場合の汎用的なフォールバックです。

クライアントの誤り（4xx）には使わないでください。本番環境ではボディにスタックトレースを含めず、ログに記録しましょう。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.6.1

HTTP/1.1 500 Internal Server Error
Content-Type: application/problem+json

{"title": "Internal Server Error", "traceId": "4bf92f35"}

サーバーは必要な機能に対応していません。典型的には、まったく認識しない HTTP メソッドです。

未知のメソッドによるリクエスト（通常の Web サーバーへの WebDAV メソッドなど）や、サーバーが意図的にまだ実装していない機能。

メソッドは認識しているが、その URL では許可されていない場合は 405 を使います。

デフォルトでキャッシュ可能（ヒューリスティックにキャッシュ可能）

RFC 9110 §15.6.2

HTTP/1.1 501 Not Implemented

ゲートウェイまたはプロキシが、上流サーバーから不正なレスポンスを受け取りました。

アプリケーションサーバーがクラッシュした、接続を閉じた、不正なデータを返したときに、リバースプロキシやロードバランサー（nginx、Cloudflare、AWS ALB）が送信します。

アプリケーションコードから送る必要はほとんどありません。例外は、呼び出した別のサービスが失敗した API ゲートウェイです。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.6.3

HTTP/1.1 502 Bad Gateway
Server: nginx

サーバーは現在リクエストを処理できません（過負荷またはメンテナンス中）。一時的な状態であることが想定されています。

計画メンテナンス、負荷の抑制、依存サービスの障害。Retry-After を追加しましょう。短期間の 503 なら、検索エンジンはページをインデックスに残します（200 のメンテナンスページや 404 とは異なります）。

サイトを何日も 503 のままにしないでください。返し続ける URL は、Google が最終的にインデックスから削除します。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.6.4

HTTP/1.1 503 Service Unavailable
Retry-After: 3600

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

アプリケーションの処理がプロキシのタイムアウトより長くかかったときに、プロキシやロードバランサーが送信します（nginx の proxy_read_timeout のデフォルトは 60 秒）。

時間のかかるジョブでは、単にタイムアウトを延ばすのではなく、202 を返して非同期で処理しましょう。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.6.5

HTTP/1.1 504 Gateway Timeout
Server: awselb/2.0

サーバーは、リクエストで使われた HTTP のメジャーバージョンに対応していません。

サーバーが扱えないプロトコルバージョンを受け取った場合。

ほとんど見かけません。クライアントは試行錯誤ではなく、ALPN と Alt-Svc で HTTP/2 や HTTP/3 をネゴシエートします。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 9110 §15.6.6

HTTP/1.1 505 HTTP Version Not Supported

サーバーの設定エラー：選ばれたバリアント自体がネゴシエーションを行うよう設定されており、ループが発生しています。

透過的コンテンツネゴシエーション（実験的）

RFC 2295 の透過的コンテンツネゴシエーションを実装したサーバーのみ。

アプリケーションのエラーには使いません。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 2295 §8.1

HTTP/1.1 506 Variant Also Negotiates

サーバーは、リクエストの完了に必要なデータを保存できません。

WebDAV

ディスクやユーザーの容量が一杯になったときの WebDAV やファイルストレージ API。

1 回のアップロードがサイズ上限を超える場合は、413 のほうが明確です。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 4918 §11.5

HTTP/1.1 507 Insufficient Storage

無限ループ（Depth: infinity の WebDAV バインディング）を検出したため、サーバーが操作を停止しました。

WebDAV

WebDAV サーバー。CloudLinux ベースの共有ホスティングでも、アカウントが上限に達したときに 508「Resource Limit Is Reached」を送りますが、これは非標準です。

リダイレクトループには使いません。それはブラウザ自身が報告するクライアント側のエラーです。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 5842 §7.2

HTTP/1.1 508 Loop Detected

ホスティングアカウントが帯域幅の割り当てを超えました。

共有ホスティングのコントロールパネル。

自分のシステムでは 503 または 429 を使います。

該当なし

Apache / cPanel（IANA レジストリには未登録）

HTTP/1.1 509 Bandwidth Limit Exceeded

リクエストが、HTTP 拡張フレームワークにおけるリソースへのアクセスポリシーを満たしていません。

IANA レジストリで廃止扱い：RFC 2774 は Historic に移されました。

現在の用途はありません。拡張フレームワークは広く実装されることはありませんでした。

送信しないでください。

明示的な Cache-Control または Expires がある場合のみキャッシュ可能

RFC 2774 §7

HTTP/1.1 510 Not Extended

ネットワークにアクセスするには、クライアントの認証が必要です（キャプティブポータル）。

ホテル、空港、カフェの Wi-Fi ポータルが、ユーザーがログインするか利用規約に同意するまで通信を横取りする場合。

オリジンサーバーが送信してはいけません。通信を横取りするネットワークプロキシ専用です。

キャッシュに保存してはならない

RFC 6585 §6

HTTP/1.1 511 Network Authentication Required
Content-Type: text/html

<meta http-equiv="refresh" content="0; url=https://login.example.net/">

オリジンが Cloudflare に空、不明、または予期しないレスポンスを返しました。

オリジンのログを確認してください：クラッシュ、接続のリセット、Cloudflare の上限を超えるヘッダー、空の応答など。

Cloudflare のみが送信します。

該当なし

Cloudflare（IANA レジストリには未登録）

HTTP/2 520
server: cloudflare

Cloudflare がオリジンに接続できませんでした：接続が拒否されました。

オリジンの Web サーバーが停止しているか、ファイアウォールが Cloudflare の IP 範囲をブロックしています。

Cloudflare のみが送信します。

該当なし

Cloudflare（IANA レジストリには未登録）

HTTP/2 521
server: cloudflare

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

オリジンの過負荷、ファイアウォールによるパケットの破棄、DNS のオリジン IP の誤り。

Cloudflare のみが送信します。

該当なし

Cloudflare（IANA レジストリには未登録）

HTTP/2 522
server: cloudflare

Cloudflare がオリジンにまったく到達できません。典型的にはルーティングの問題か DNS レコードの誤りです。

DNS の A/AAAA レコードが、到達可能な正しい IP を指しているか確認してください。

Cloudflare のみが送信します。

該当なし

Cloudflare（IANA レジストリには未登録）

HTTP/2 523
server: cloudflare

Cloudflare はオリジンに接続しましたが、オリジンがタイムアウト（デフォルトは 100 秒）内に HTTP レスポンスを返しませんでした。

時間のかかるリクエスト：処理をバックグラウンドジョブに移してポーリングするか、進行状況をストリーミングしましょう。

Cloudflare のみが送信します。

該当なし

Cloudflare（IANA レジストリには未登録）

HTTP/2 524
server: cloudflare

Cloudflare とオリジンの間の TLS ハンドシェイクが失敗しました。

SSL モードが Full または Full (strict) のときに、オリジンが 443 で待ち受けていない、証明書がない、共通の暗号スイートがない、SNI が設定されていないなど。

Cloudflare のみが送信します。

該当なし

Cloudflare（IANA レジストリには未登録）

HTTP/2 525
server: cloudflare

Full (strict) モードで、Cloudflare がオリジンの証明書を検証できませんでした（期限切れ、自己署名、ホスト名の不一致）。

オリジンに有効な証明書か、Cloudflare Origin CA 証明書をインストールしてください。

Cloudflare のみが送信します。

該当なし

Cloudflare（IANA レジストリには未登録）

HTTP/2 526
server: cloudflare

Cloudflare とオリジンの Railgun リスナーとの間の接続の問題です。Cloudflare は Railgun の提供を終了しています。

過去のものです。

送信していたのは Cloudflare のみです。

該当なし

Cloudflare（IANA レジストリには未登録）

HTTP/1.1 527 Railgun Error

Cloudflare の 1xxx エラーページ（1016 Origin DNS error など）とともに返されます。ページに表示される 1xxx のコードが本当の原因です。

ページに表示された 1xxx のエラー番号を調べてください。

CDN やホスティング事業者のみが送信します。

該当なし

Cloudflare（IANA レジストリには未登録）

HTTP/2 530
server: cloudflare

ALB の組み込み認証（OIDC または Cognito）が ID プロバイダーとの間で失敗しました。

ALB リスナールールの IdP の設定を確認してください。

アプリケーションで使うものではありません。

該当なし

AWS Elastic Load Balancing（IANA レジストリには未登録）

HTTP/1.1 561

一部のプロキシが、プロキシの背後での読み取りタイムアウトを示すために使います。

まれ。特定のプロキシ製品で見かけることがあります。

504 を使います。

該当なし

Informal convention（IANA レジストリには未登録）

HTTP/1.1 598

一部のプロキシやクライアントライブラリ（Tornado の HTTP クライアントなど）が、接続タイムアウトに使います。

まれ。

プロキシでは 504 を使います。

該当なし

Informal convention（IANA レジストリには未登録）

HTTP/1.1 599