HTTPステータスコード 一覧｜全コードの原因と対処・curl実例つき

HTTPステータスコードとは、サーバーがリクエストの結果を3桁の数字で返すもので、先頭の数字（1〜5）で「情報・成功・リダイレクト・クライアント側の問題・サーバー側の問題」の5種類に分かれます。 数字の意味がわかると、エラー画面を見た瞬間に「自分の操作を見直すのか、サーバー側の復旧を待つのか」を判断できます。

この記事では、IANAのHTTPステータスコード登録簿（2025-09-15更新版）とRFC 9110で確認した全コードを、意味・よくある原因・対処つきの1枚の表にまとめました。さらに、nginx 1.24とNode.js 22で代表的なコードを実際に返し、curl -iの出力をそのまま掲載しています。閲覧者向けと開発者向けの対処を分け、混同しやすいコードの比較表、CDNやロードバランサー独自のコード、Google検索への影響も公式情報で確認しています。

HTTPステータスコードの早見表（クラス別）

よく出会うコードの「ひと言で」早見表です。

HTTPステータスコード全一覧（意味・原因・対処）

IANAの登録簿（最終更新2025-09-15）に登録されているコードをすべて掲載し、よく出会うものに★を付けました。名称はIANA／RFC 9110の表記です。「対処」は閲覧者・開発者の両方に役立つ最初の一手を書いています。

1xx 情報

2xx 成功

3xx リダイレクト

4xx クライアント側の問題

5xx サーバー側の問題

IANAに未割り当ての番号（例：419、420、499、520など）は、製品やサービスが独自に使っているものです。後半の「CDN・ロードバランサー独自のコード」で整理します。

実際に返して確かめる（nginx＋Node.jsのcurl -i実例）

nginx 1.24.0（Ubuntu）をリバースプロキシにし、上流にNode.js 22の小さなアプリを置いて、代表的なコードを実際に返しました。 以下はすべて実際の出力です（Dateは実行時刻、長いHTMLは一部省略）。

検証に使った設定（コピペ用）

# nginx.conf（抜粋）ポート7202で待ち受け、上流Nodeは7203
http {
  limit_req_zone $binary_remote_addr zone=perip:1m rate=1r/s;
  server {
    listen 127.0.0.1:7202;
    root /path/to/html;
    client_max_body_size 1k;                                  # 413の確認用に小さく
    location = /old-page      { return 301 /page.html; }
    location = /campaign      { return 302 /page.html; }
    location = /api/v1/items  { return 308 /api/items; }
    location = /removed       { return 410; }
    location = /admin         { deny all; }                   # 403
    location = /limited       { limit_req zone=perip nodelay; limit_req_status 429;
                                proxy_pass http://127.0.0.1:7203; }
    location = /down          { proxy_pass http://127.0.0.1:7204; }   # 何も動いていないポート
    location /api/            { proxy_pass http://127.0.0.1:7203; }
    location = /slow          { proxy_pass http://127.0.0.1:7203; proxy_read_timeout 1s; }
    location = /maintenance   { proxy_pass http://127.0.0.1:7203; }
  }
}

// app.js（Node.js 22、外部ライブラリなし）
const http = require('http');
http.createServer((req, res) => {
  if (req.url === '/slow') { setTimeout(() => res.end('late\n'), 3000); return; }
  if (req.url === '/api/items' && req.method === 'POST') {
    let body = '';
    req.on('data', c => body += c);
    req.on('end', () => {
      let data;
      try { data = JSON.parse(body); } catch {
        res.writeHead(400, { 'Content-Type': 'application/json' });
        return res.end(JSON.stringify({ error: 'invalid JSON' }) + '\n');
      }
      if (!data.name) {
        res.writeHead(422, { 'Content-Type': 'application/json' });
        return res.end(JSON.stringify({ error: 'name is required' }) + '\n');
      }
      res.writeHead(201, { 'Content-Type': 'application/json', 'Location': '/api/items/42' });
      res.end(JSON.stringify({ id: 42, name: data.name }) + '\n');
    });
    return;
  }
  if (req.url === '/api/me') {
    res.writeHead(401, { 'WWW-Authenticate': 'Bearer realm="api"', 'Content-Type': 'application/json' });
    return res.end(JSON.stringify({ error: 'token required' }) + '\n');
  }
  if (req.url === '/maintenance') {
    res.writeHead(503, { 'Retry-After': '120', 'Content-Type': 'text/plain' });
    return res.end('maintenance\n');
  }
  if (req.url === '/api/crash') { throw new Error('boom'); }   // 502の確認用
  res.writeHead(200, { 'Content-Type': 'text/plain' });
  res.end('ok\n');
}).listen(7203, '127.0.0.1');

301・302・308：Locationヘッダーで転送先を返す

$ curl -i http://localhost:7202/old-page
HTTP/1.1 301 Moved Permanently
Server: nginx/1.24.0 (Ubuntu)
Content-Type: text/html
Content-Length: 178
Location: http://localhost:7202/page.html

$ curl -i http://localhost:7202/campaign
HTTP/1.1 302 Moved Temporarily
Location: http://localhost:7202/page.html

$ curl -i -X POST http://localhost:7202/api/v1/items
HTTP/1.1 308 Permanent Redirect
Location: http://localhost:7202/api/items

nginxは302の理由句をMoved Temporarily（本文のタイトルは302 Found）と返しました。理由句（数字の後ろの英語）は実装によって異なり、意味を持つのは数字だけです。プログラムでは必ず数字で判定します。

304：キャッシュの再検証が成功した

$ curl -i http://localhost:7202/index.html
HTTP/1.1 200 OK
Content-Length: 15
Last-Modified: Tue, 29 Sep 2026 04:11:13 GMT
ETag: "6abb3a61-f"

<h1>hello</h1>

$ curl -i -H 'If-None-Match: "6abb3a61-f"' http://localhost:7202/index.html
HTTP/1.1 304 Not Modified
Last-Modified: Tue, 29 Sep 2026 04:11:13 GMT
ETag: "6abb3a61-f"

304は本文を返さず「手元のキャッシュを使ってよい」と伝える成功の合図です。エラーではありません。

400・422・201：APIの入力チェック

$ curl -i -X POST -H 'Content-Type: application/json' -d '{bad' http://localhost:7202/api/items
HTTP/1.1 400 Bad Request
Content-Type: application/json

{"error":"invalid JSON"}

$ curl -i -X POST -H 'Content-Type: application/json' -d '{}' http://localhost:7202/api/items
HTTP/1.1 422 Unprocessable Entity
Content-Type: application/json

{"error":"name is required"}

$ curl -i -X POST -H 'Content-Type: application/json' -d '{"name":"pen"}' http://localhost:7202/api/items
HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/items/42

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

Node.js 22は422の理由句を旧名のUnprocessable Entityで返しました（RFC 9110での名称はUnprocessable Content）。ここでも数字が同じなら意味は同じです。

HTTPのリクエスト自体が壊れているとき（例：HTTP/1.1でHostヘッダーがない）は、アプリに届く前にnginxが400を返します。

$ curl -i --http1.1 -H 'Host:' http://127.0.0.1:7202/
HTTP/1.1 400 Bad Request
Content-Type: text/html
Content-Length: 166
Connection: close

401・403・404・405・410

$ curl -i http://127.0.0.1:7202/api/me
HTTP/1.1 401 Unauthorized
Content-Type: application/json
WWW-Authenticate: Bearer realm="api"

{"error":"token required"}

$ curl -i http://localhost:7202/admin
HTTP/1.1 403 Forbidden

$ curl -i http://localhost:7202/nothing
HTTP/1.1 404 Not Found

$ curl -i -X POST http://localhost:7202/index.html
HTTP/1.1 405 Not Allowed

$ curl -i http://localhost:7202/removed
HTTP/1.1 410 Gone

401には「どう認証すればよいか」を示すWWW-Authenticateヘッダーを付けるのがRFC 9110の定めです。

413・429：大きすぎる・多すぎる

$ head -c 5000 /dev/zero | curl -i -X POST --data-binary @- http://localhost:7202/api/items
HTTP/1.1 413 Request Entity Too Large
Content-Type: text/html
Content-Length: 192
Connection: close

$ for i in 1 2 3; do curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:7202/limited; done
200
429
429

nginxのlimit_reqは既定で503を返すため、429にしたいときはlimit_req_status 429;を指定します。今回の検証では、/limitedをreturn 200で書いたときは制限がかからず、proxy_passに変えると429になりました。returnはlimit_reqより前の段階で応答を返すためです。

502・504・503：上流（アプリ）側の問題

$ curl -i http://localhost:7202/down
HTTP/1.1 502 Bad Gateway

nginxのerror.log:
connect() failed (111: Connection refused) while connecting to upstream,
  upstream: "http://127.0.0.1:7204/down"

$ curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:7202/api/crash
502

nginxのerror.log:
upstream prematurely closed connection while reading response header from upstream

Node.jsのログ:
  if (req.url === '/api/crash') { throw new Error('boom'); }
                                  ^
Error: boom

$ curl -i http://localhost:7202/slow
HTTP/1.1 504 Gateway Time-out

nginxのerror.log:
upstream timed out (110: Connection timed out) while reading response header from upstream

$ curl -i http://localhost:7202/maintenance
HTTP/1.1 503 Service Unavailable
Content-Type: text/plain
Retry-After: 120

maintenance

同じ「アプリの問題」でも、つながらない・途中で切れた＝502、待ったが返ってこない＝504と分かれます。例外で上流のプロセスが終了すると、その後のリクエストもすべて502（Connection refused）になりました。502・504はブラウザの画面ではなく、プロキシ（nginx）のerror.logを見ると原因の文が書かれています。

499：クライアントが先に切断した（nginx独自）

$ curl -s --max-time 0.5 http://127.0.0.1:7202/slow; echo "exit=$?"
exit=28

nginxのaccess.log:
127.0.0.1 - - [29/Sep/2026:13:11:36 +0900] "GET /slow HTTP/1.1" 499 0 "-" "curl/8.5.0"

499はクライアントに返されるコードではなく、nginxがログに記録する独自の値です。応答が遅くて利用者やクライアントが待ちきれなかったことを示すため、504と並んで「処理時間」の調査の手がかりになります。

混同しやすいコードの比較表

リダイレクト：301・302・303・307・308

ページの移転は301、APIのように「POSTのまま転送したい」なら307／308と覚えると迷いません。RFC 9110では301・308はキャッシュしてよい（ヒューリスティックにキャッシュ可能）とされています。一時的な転送に301を使うと、ブラウザが古い転送を覚え続けることがあるため、期間限定の転送は302／307にします。

401と403（要点）

判断の起点は「ログインし直せば解決するか」です。

404と410

移転先があるなら404／410ではなく301にします。移転先のないページは、404と410のどちらでもGoogleのインデックスから削除されます。

400と422

APIでは400に統一する方針もよく採られます。チームで方針をそろえ、本文にどの項目が問題かを返すことが大切です。

409と412

「条件付きリクエストのヘッダーで判定した」なら412、「業務上の状態が矛盾する」なら409です。

429と503

500・502・503・504

閲覧者向けの対処と開発者向けの対処

同じコードでも、画面を見ている人とサイトを運営する人ではできることが違います。

閲覧者の対処が「待つ」しかない5xxは、運用側がRetry-Afterやメンテナンス画面で見通しを示すと親切です。

CDN・ロードバランサー・Webサーバー独自のコード

IANAに登録されていないコードは、製品・サービスごとに意味が決まっています。 公式ドキュメントで確認したものをまとめます。

CDNやロードバランサーの5xxは「利用者 ⇔ CDN」と「CDN ⇔ オリジン」のどちらで起きたかを示しています。Cloudflareの52x台はオリジン側を調べると解決の近道です。

ステータスコードとSEO（Google検索への影響）

Google検索セントラルのドキュメント「HTTPステータスコード、ネットワークエラー、DNSエラーがGoogle検索に与える影響」の内容を要約します。

SEOで押さえたいポイントは次の4つです。

• URLを変えたら301（または308）で新URLへ転送し、内部リンクも新URLに直す
• 存在しないページは404／410を返す（「見つかりません」画面を200で返すとソフト404になる）
• メンテナンスは503＋Retry-Afterで一時的な停止だと伝え、長引かせない
• クロールを抑えたいときに401や403を使わない（Googleは429以外の4xxはクロール頻度に影響しないとしている）

ステータスコードの確認方法

よくある質問

Q. ステータスコードの後ろの英語（理由句）が記事と違います。 A. 理由句は実装ごとに異なり、意味を持つのは数字だけです。今回の実行でも、nginxは302をMoved Temporarily、Node.jsは422をUnprocessable Entityと返しました。HTTP/2では理由句そのものが送られません。

Q. 502と504はどちらがサーバーの問題ですか？ A. どちらもプロキシの先（上流）のサーバー側です。502は「接続できない・応答が壊れている」、504は「待ったが時間内に応答がない」です。nginxのerror.logにConnection refusedやupstream timed outなど理由が記録されます。

Q. 404と410はどちらを使えばよいですか？ A. 通常は404で十分です。意図的に終了したページを明示したいときは410を使えます。Googleはどちらも4xxとしてインデックスから削除します。移転先があるなら301にします。

Q. 418 I'm a teapotは使えますか？ A. IANAの登録簿では418は「(Unused)」として予約されています。ジョークとして知られていますが、実際のシステムでは意味の定まったコードを使うのが確実です。

まとめ

• 先頭の数字で分類：1xx情報、2xx成功、3xx転送、4xxクライアント側、5xxサーバー側
• 全コードはIANA登録簿とRFC 9110が基準。未登録の番号（499、52x、46xなど）は製品独自の意味
• 意味を持つのは数字だけ。理由句はnginxやNode.jsで表記が異なる
• 502は「つながらない・切れた」、504は「時間切れ」。原因はプロキシのerror.logに書かれる
• 転送は恒久なら301／308、一時なら302／307。POSTを保つなら307／308
• SEOでは301で転送、404／410で削除を明示、メンテナンスは503＋Retry-After
• 閲覧者と開発者で対処を分けると、問い合わせや調査が速くなる

株式会社RJCでは、Webサービスの開発や運用の現場で、ログやステータスコードから原因をたどる知識を仲間と共有しています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。