最も一般的なHTTPステータスコード（それぞれに対処する方法）

あなたのページャーは午前2時に鳴ります。アラートのペイロードにはステータスコードが含まれています。次に何をするかは、ほぼ完全に見たコード次第です。

ここがほとんどのHTTPステータスコードガイドが省略する部分です。定義をリストアップし、コードを5つのバケットに分類して終わり。用語集としては役立ちますが、本番環境で502が発生し、経営層がチェックアウトの不具合を尋ねているときにはあまり役に立ちません。

このガイドでは、最もよく見る10のコードに加えていくつかの名誉ある言及を扱います。それぞれについて：意味、本番環境で通常それを引き起こす原因、最初に確認すべきこと。目標は「コードを見た」から「何を修正すべきか分かる」までの時間を短縮することです。

HTTPステータスコードとは？

HTTPステータスコードは、サーバーが毎回のレスポンスと共に返す3桁の数字です。リクエストが成功したか、失敗したか、またはリダイレクトが必要かをクライアントに伝えます。ブラウザのDevToolsネットワークタブ、ロードバランサーのログ、モニタリングアラート、CDNダッシュボードなど、どこでも見られます。このガイドは実際に人を起こすコードに焦点を当てています。

HTTPステータスコードの5つのカテゴリ

コードの最初の桁がレスポンスのクラスを示します：

• 1xx 情報応答。 日常業務ではめったにありません。主にプロトコル交渉に使われます（100 Continue、101 Switching ProtocolsはWebSocketアップグレード用）。
• 2xx 成功。 リクエストは成功しました。200がデフォルト；201はリソース作成を意味し；204はボディなしで成功を意味します。
• 3xx リダイレクション。 リソースは別の場所にあります。ブラウザやクローラはこれを自動的に上限まで追従します。
• 4xx クライアントエラー。 リクエストが間違っています。無効なURL、認証不足、権限拒否、不正なペイロードなど。
• 5xx サーバーエラー。 リクエストは正常でした。サーバーの処理失敗です。

トリアージで最も重要なのは4xxと5xxの分け方です。4xxは「コーラーが何か間違えた」と示し、5xxは「こちらが何か間違えた」と示します。前者はエンドポイント呼び出し元に責任があり、後者はあなたに責任があります。

完全な一覧については、Dotcom-Monitorウィキの完全なHTTPステータスコードリファレンスが仕様に定義されたすべてのコードをリストしています。このガイドの残りは実際にアラートに現れるコードに焦点を当てます。

最も一般的な10のHTTPステータスコード

200 OK

サーバーはリクエストを処理し、期待されるレスポンスを返しました。健全な本番サイトへのリクエストの大多数で見たいコードです。

注意すべき点： 200 OKはページが正しいことの証明ではありません。JavaScriptが静かに失敗して空白ページをレンダリングすることがあります。APIがエラー本文を200で返すこともあります。ログインフォームが200レスポンス内に「無効な認証情報」と表示することも。ステータスコードだけのチェックはこれらを見逃します。実際のブラウザチェックと組み合わせて使いましょう（後述）。

301 Moved Permanently

リソースは新しい恒久的なURLに移動しました。ブラウザはリダイレクトを積極的にキャッシュします。検索エンジンはリンクエクイティの大部分をターゲットに移します。

使いどころ： サイト移行後のURL変更、HTTPからHTTPSへの切り替え、重複パスの統合、古いスラッグの廃止。301がライブでキャッシュされるとロールバックは困難です—ブラウザやクローラは数週間新しい場所を使い続けます。

302 Found (Temporary Redirect)

リソースは一時的に別の場所にあります。ブラウザはリダイレクトをキャッシュせず、検索エンジンは完全なリンクエクイティを渡しません。

注意すべき点： 302は過剰に使われています。フレームワークのデフォルトリダイレクトヘルパーが302を返すため、チームが安易に使うことが多いです。移動が恒久的なら301を使いましょう。HTTPメソッドを保持したい場合（POSTはPOSTのまま）は307か308を使います。Googleは継続的な302をいずれ301として扱いますが、「いずれ」は戦略ではありません。

400 Bad Request

サーバーはリクエストを解析できません。破損したJSON、無効なヘッダー、過大なペイロード、スキーマ違反など。

最初に確認するべきこと： リクエストボディ。APIエンドポイントで400の急増があった場合、通常、クライアントが誤った形のデータ送信を始めたことを示します—消費者側のデプロイ、あなた側のスキーマ変更、またはサードパーティの統合がフォーマットを更新したなど。リクエストペイロードを最後に正常だったバージョンと比較しましょう。

401 Unauthorized

リクエストに認証情報がないか、拒否された認証情報があります。名前とは異なり、問題は認証であり認可ではありません。

最初に確認するべきこと： トークン。以前は正常だったエンドポイントで突然401が増えた場合、トークンの期限切れ、署名鍵のローテーション、OIDCプロバイダーの障害、audienceクレームの変更などが原因であることが多いです。API可用性モニタリングで200が401に置き換わっている場合、認証レイヤーが原因です。

403 Forbidden

認証情報は有効ですが、呼び出し元はこのリソースへのアクセスを許可されていません。問題は認証ではなく認可です。

最初に確認するべきこと： 権限とインフラのルール。IAMポリシーの変更、WAFルールによる正当なトラフィックのブロック、CDNアクセスポリシーの過剰な制限、間違ったユーザーセグメントへのフィーチャーフラグの切り替えで403が発生します。デプロイ直後に403が増えたら、アプリコードより先にポリシーや設定の差分を確認しましょう。

404 Not Found

サーバーはリクエストを理解したが、そのURLにリソースがありません。有名なステータスコードです。

分類すべき2つのシナリオ：

• タイポ、古いブックマーク、脆弱性を探るクローラによる一過性の404。これはバックグラウンドノイズです。
• デプロイ直後のカノニカルURLでの404急増。これは壊れたリリース—ルートが削除された、ビルド成果物が欠落、リダイレクトなしでスラッグ変更が出荷されたなど。ロールバックかホットフィックスを。

カノニカルページでの持続的な404はGoogleによりインデックスから除外されるため、SEOコストがあります。

修正方法

迅速な対応： ページが移動した場合、旧URLから新URLへの301リダイレクトを追加し、ユーザーとクローラが正しい場所にアクセスできるようにします。ページが本当に存在しない場合は、曖昧なホームページリダイレクトではなく正しい404や410を返しましょう。

本質的な修正： 404の原因を監査します。壊れた内部リンクは元から修正、デプロイ後のルート不足はホットフィックス、スラッグの不正なマイグレーションはリダイレクトマップが必要です。定期的に自サイトをクロールしてGoogleより先に死んだリンクを見つけましょう。

500 Internal Server Error

サーバーで未処理の例外が発生しました。すべてを包括する5xxコード。何かが壊れたことを知らせますが何が壊れたかはわかりません。

最初に確認するべきこと： アプリケーションログ。500エラーにはスタックトレースがあるはずです—なければログ記録の改善が先です。一般的な原因：新しくデプロイしたコードパスの未捕捉例外、下流依存性が予期しない形で応答、データベース接続プールの枯渇、メモリ不足による再起動ループ。生産環境で500エラーが持続的に増加したら緊急対応を。

修正方法

迅速な対応： リリース直後にスパイクが始まった場合はロールバック。デプロイ直後に現れた500はデプロイに起因します。

本質的な修正： スタックトレースを読み、問題コードパスを修正し、再発しないよう回帰テストを追加します。原因がリソース制限（接続プール、メモリ、ファイルハンドル）なら上限を上げ、次回到達前にアラートを設定しましょう。

502 Bad Gateway

プロキシ、ロードバランサー、CDNが上流サーバーから無効なレスポンスを受け取りました。プロキシ自体は正常ですが、背後のサーバーが不調です。

最初に確認するべきこと： 上流の健全性。一般的な原因：アプリコンテナがクラッシュしているがロードバランサーがまだルーティングしている、上流がタイムアウトして応答しない、KubernetesポッドがCrashLoopBackOff状態、Nginxワーカーの誤設定、プロキシと上流間の接続リセット。502は多層アーキテクチャで非常に重要な信号であり、「エッジは正常で問題は1ホップ先にある」ことを示します。

修正方法

迅速な対応： 不健康な上流インスタンスを再起動または交換し、ロードバランサーのヘルスチェックが死んだノードを確実に除外していることを確認します。

本質的な修正： なぜ上流が不正な応答を返したのか調査します。プロキシのタイムアウトが上流の実際の応答時間より短いか、ポッドが起動時にクラッシュループしていないか、接続のキープアライブ設定が両側で一致しているかを確認。

503 Service Unavailable

サーバーが一時的にリクエストを処理できません。容量枯渇、メンテナンスモード、オートスケーラーがまだ起動中。

最初に確認するべきこと： リソース飽和とレート制限。トラフィックスパイク時の503はオートスケーラーが追いつけないか接続制限に達したことを示します。通常時の503はプロセスがメンテナンス中かキュー遅延の可能性。プラットフォームによっては上流WAFやアンチボットシステムのレート制限で503を返すこともあるため、アプリが原因と決めつける前に確認が必要です。

修正方法

迅速な対応： Retry-Afterヘッダーを付けて503を返し、健全なクライアントやクローラーがサーバーを過負荷にしないようにします。PHP例：

http_response_code(503);
header('Retry-After: 60');

本質的な修正： 飽和したリソース（データベース接続、ワーカープール、オートスケーラー上限）を見つけてボトルネックを解消します。CDNやWAFのレートリミット起因の場合は上限引き上げか正当な呼び出し元のホワイトリスト化を。

知っておくべきその他のコード

上記の10コードはほとんどの本番トラフィックをカバーします。ただし、現場で十分よく見かける他のコードもあり、オンコールエンジニアは一目でわかるべきです。

• 304 Not Modified. キャッシュがまだ新鮮なときに送信されます。CDN経由のトラフィックで一般的です。304が減少するとキャッシュ制御ヘッダーの変更を示し、かつて節約していたオリジンの帯域を消費していることがあります。
• 307 Temporary Redirect. 302に似ますがHTTPメソッドを保持します。POSTはPOSTのまま。フォーム送信や非冪等API呼び出しのリダイレクトには302ではなく307を使います。
• 308 Permanent Redirect. 301に似ますがHTTPメソッドを保持します。POST、PUT、PATCH、DELETEを扱うAPIエンドポイントの恒久的リダイレクトに現代的選択肢です。
• 429 Too Many Requests. レート制限。上流APIによりスロットルされているか、自分が誰かをスロットルしています。Retry-Afterヘッダーを確認し、尊重しましょう。
• 504 Gateway Timeout. プロキシが上流の応答待ちを放棄しました。502との違いは、上流が悪い応答を返したのではなく、時間内に応答を返さなかったこと。通常は長時間のクエリ、停止したワーカー、遅い下流API。

301 vs 302 vs 307 vs 308

この4つのリダイレクトコードはよく混同されます。違いは2つ：移動が恒久的か、一時的か、HTTPメソッドがリダイレクトを通じて保持されるかどうかです。

恒久的に移動した通常のページは301を使います。POSTをPOSTのままリダイレクトする必要がある場合は、一時的なら307、恒久的なら308を使いましょう。

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

上記のコードは実際のアラートのほとんどをカバーします。四半期に一度現れ調査が必要になる珍しいコードには、標準の完全リストと共に一般的なインフラベンダー独自の非標準コードも示します。

1xx 情報応答

サーバーはリクエストを受け取り処理を続けています。多くのクライアントとプロキシが透過的に処理するため、アプリケーションログで見ることはほとんどありません。

2xx 成功

リクエストは受け入れられ理解されました。200が主力で、その他はAPIや部分的コンテンツ、WebDAV、バッチ処理時に重要です。

3xx リダイレクション

リソースは別の場所にあります、またはキャッシュコピーが有効です。301と302が主流で、307/308はAPI、304はキャッシュパイプラインに重要です。

4xx クライアントエラー

リクエストが間違っています。多くは見かけることはほとんどありませんが、よくある6つは毎日見ます。418や451のような珍しいコードも存在するので、無駄な推測をしないために知っておく価値があります。

5xx サーバーエラー

リクエストは正常でしたが、サーバー側で何かが失敗しました。人を起こす可能性が最も高いコード群です。

非標準およびベンダー固有コード

Cloudflare、Nginx、Microsoft、Akamaiは公式仕様外のコードを返すことがあります。これらはエッジ側の障害を示すため、現場で見分けられる必要があります。

上にないコード範囲（104-199、209-225、227-299、309-399、432-450、452-499、512-599）は未割り当て、非推奨、またはベンダー固有として予約されています。これらのコードはインフラのドキュメントを確認してください。

モニタリングで実際にアラートを出すべきコード

60以上あるコードの中で、多くの本番環境でアラート閾値に達するのはより少数です：

• 200—基本的な比率として。急激な減少は別の問題を示します。
• 301、302、307、308—リダイレクト回数。スパイクは誤設定ルーティングやカノニカルURLの破損を示す。
• 400—不正なリクエスト。通常は消費者側の変更。
• 401、403—認証・権限エラー。しばしばトークン、IAM、WAFの変更。
• 404—リソース欠損。単発はバックグラウンドノイズ；複数はリリース問題。
• 408—クライアントタイムアウト。持続的ならアラートに値。下流遅延のサイン。
• 429—レート制限。恩恵を受けるか、自分がかけているか。
• 500、502、503、504—アプリケーション、上流、容量、ゲートウェイタイムアウト障害。緊急対応。
• 520-526—Cloudflareエッジ障害。Cloudflareの背後なら重要なシグナル。

その他はログには残す価値があるが、滅多に起こっても誰かを起こすほどではありません。

ページのHTTPステータスコードを確認する方法

コードに基づいて行動する前に、コードを確認する必要があります。速い順に3つの方法。

Chrome DevToolsで

1. ページを開く。
2. 任意の場所を右クリックし検証を選択、Networkタブを開く。
3. リロード。最初のドキュメントリクエストのStatus列にコードが表示される。

コマンドラインから

ヘッダーのみのリクエストは本文をダウンロードせずにステータス行を返します：

curl -I https://example.com

レスポンスの最初の行がステータスコード、例えばHTTP/2 200です。

大規模に

単発チェックは現在の状態を教えてくれます。3時に起こる障害を見逃します。断続的障害を捕らえるには複数地域からの定期的チェックが必要であり、これはシンセティックモニタリングにより実現します。

200 OKが嘘をつくとき

ある火曜日午前11時、eコマースチームにページャーが鳴る。コンバージョン率が80%低下。稼働ダッシュボードを確認。すべてのエンドポイントは緑。すべてのステータスコードは200。すべての地域がサイト稼働を報告。

実はサイトは稼働していない。40分前のデプロイでチェックアウトページのJavaScriptバンドルが例外を投げている。HTMLはレンダリングされ、サーバーは200を返し、ステータスコードモニターは200を見てアラートは発動せず。ユーザーは空のカートを見て離脱。

これは純粋なステータスコード監視では検知できない失敗モードです。解決策は多層的：

• 重要なユーザーパス（ホーム、検索、商品、カート、チェックアウト）で実際のブラウザチェックを行う。ブラウザはJavaScriptを実行し、curlスタイルのチェックで見逃すクライアント側エラーを検出。
• 本文レベルの信号を監視：キーワードの存在、要素の可視性、期待されるレスポンス構造。ステータスコードのみを信用しない。
• デプロイとモニタリングを結びつける：リリース後15分以内に緑から赤に変わるチェックには自動でデプロイタグを付与。ポストモーテムで何が変わったかの調査時間を半減。

ソフト404とは？

この問題の一形態には名前があります：ソフト404。ソフト404はユーザーに「ページが見つかりません」と伝えつつ200 OKを返すページです。Googleの推奨は実際の404か410を返すこと。ソフト404はクロール予算を浪費し、インデックスの混乱を招きます。

純粋なステータスコードモニターではソフト404も壊れたチェックアウトも検知できません：コードは200だからです。本文アサーションを行う実際のブラウザチェックが必要です。

HTTPステータスコードとSEOへの影響

検索エンジンはステータスコードを使い、クロール、インデックス化、再訪頻度の判断をします。重要なパターンは3つ：

• 4xxコードは時間経過でインデックスを減らす。 複数回404を返すページは削除されます。ページを削除する場合は404に任せず301リダイレクトを使いましょう。
• 5xxコードはクロール速度を落としランキングを下げる。 Googlebotは持続的な5xxを「このサイトは不健康」と解釈。クロール速度が落ち、インデックス化も遅延し、ランキング低下の原因に。
• 301と302の違いは重要。 301はリンクエクイティを渡す。302は一時的とみなされ渡さないこともある。移動が恒久的なら301を選択。

実用的な教訓：5xxは単なる可用性問題ではなく、持続すればするほどSEOに悪影響を及ぼす問題です。DNS、TCP、TLS、HTTPの各種エラーはそれぞれ異なるSEOコストがあり、どのレイヤーが障害かを知ることでより早いトリアージが可能になります。

アラート過多に溺れずHTTPステータスコードを監視する

HTTPトラフィックを監視するチームは最終的に同じ問題に直面します：アラートが多すぎて信号が足りない。いくつかのベストプラクティスでステータスコード監視を有用かつノイズレスに保ちます。

単一リクエストでなく割合でアラート。 1件の500はノイズ。5分間に50件はインシデント。通常トラフィック量に応じて閾値を設定。

ユーザー向けエンドポイントと内部エンドポイントを分離。 チェックアウトAPIの500は即時通知。誰も使っていない管理エンドポイントの500は業務時間まで待つ。

ユーザー所在地からテスト。 1データセンターのチェックでは地域特有のCDN障害は検知できません。複数地域からのモニタリングネットワークで顧客より先に問題を発見。

ステータスチェックとコンテンツチェックを組み合わせる。 200 OKは出発点。レスポンスに期待する内容が入っていることを検証。

Dotcom-MonitorのWebアプリケーションモニタリングはこれら4つすべてを提供：割合アラート、エンドポイント分割、グローバルロケーション、実ブラウザのコンテンツチェック。API集中環境にはAPIモニタリングがスキーマ検証や応答時間SLOを追加。どちらもアラートパイプラインに統合されており、複数ベンダーの信号を継ぎ接ぎする必要はありません。

まとめ

最も一般的なHTTPステータスコードは数年変わっていません。200、301、404、500、502、503―今週も全て目にするでしょう。変わるのは「コードを見てから原因を直すまでのスピード」です。

この差が良いモニタリングの価値です。ステータスコードだけでは「何かが起きた」ことしかわかりません。多層チェック―ステータス、コンテンツ、実ブラウザ、多地域―で「何が、どこで、次に何をすべきか」がわかります。

それを体験したいなら、Dotcom-Monitorの無料トライアルを試してください。お持ちのエンドポイントの一つを指定して何が見えるか確かめましょう。

よくある質問