HTTP Status Code Explorer
Search common HTTP status codes, compare lookalike failures such as 401 vs 403 vs 422, and keep a sharper debugging checklist next to the raw response you are investigating.
401 Unauthorized
4xxAuthentication is missing, expired, or invalid for this request.
The token is absent, malformed, expired, signed for the wrong audience, or dropped by a proxy.
- Confirm the Authorization header is actually reaching the server.
- Check token expiry, issuer, audience, and environment-specific secrets.
よくある問題
401 と 403 の違いは何ですか？
`401 Unauthorized` レスポンスは、通常、認証情報自体が欠落している、期限切れ、形式不正、または受け入れられないことを意味します。`403 Forbidden` は、呼び出し元は認証されているが、その操作に必要な権限、スコープ、プラン、または所有権が不足していることを意味します。
API デバッグにおいて 400 と 422 をどう考えればよいですか？
`400 Bad Request` は、サーバーがリクエストの構造自体を正しくパースまたは解釈できなかった信号として扱います。`422 Unprocessable Entity` は、構造はパースできたが、ペイロードがバリデーションやドメインルールに違反している信号として扱います。
429 の問題と 503 の問題をどう見分けますか？
`429 Too Many Requests` レスポンスは、まずレート制限、クォータ、およびリトライ挙動を確認すべきであることを示します。`503 Service Unavailable` は、サービスの一時的な不安定さ、依存関係の負荷、メンテナンス、またはプラットフォーム全体の飽和を示唆します。
API リクエストが失敗したとき、ステータスコードのどこを最初に確認すべきですか？
まず、クライアント側のエラー（`4xx`）かサーバー側のエラー（`5xx`）かを切り分けます。これにより調査パスが即座に変わるからです。次に、構文、認証、権限、バリデーション、スロットリング、または不安定な上流サービスのどれが問題かを絞り込みます。
ワークフロー
HTTP ステータスコード検索 / APIデバッグ とは？
HTTP ステータスコード検索ツールは、生の API エラーをより有用なデバッグシーケンスに変換するのに役立ちます。ステータスコードを単なる静的な参照表として扱うのではなく、`401` と `403`、`400` と `422`、`429` と `503` といったよく似たコードを比較しながら、次に確認すべきポイントを常に手元に置くことができます。
これは、インシデント対応や日常的な API デバッグで特に役立ちます。一つのコードがチームを誤った方向に導いてしまうことがよくありますが、このツールでは各コードに現実的な本番シナリオと短いチェックリストを添えることで、そのズレを最小限に抑えます。
HTTP ステータスコード検索 / APIデバッグ の使い方
コード、タイトル、または `timeout`、`forbidden`、`validation` といった症状で検索し、`2xx`、`3xx`、`4xx`、`5xx` のフィルターで絞り込みます。ステータスを選択すると、その意味、現実的な本番シナリオ、次に行うべき確認、および混同されやすい類似コードが表示されます。
結果をチームメンバーと共有したい場合は、「サマリーをコピー」を使用して、チケットや Slack、引き継ぎノートに最適なコンパクトな解説とチェックリストを取得できます。
使用例
例：
API のログイン呼び出しが、ステージング環境では 401 を返し、本番環境では 403 を返す場合。
ツールの使い方：
1. 401 を開き、ヘッダーの欠落、トークンの期限切れ、発行者（Issuer）またはオーディエンス（Audience）の問題を確認します。
2. 403 と比較し、トークンは有効だがロール（Role）やスコープ（Scope）が不足していないかを確認します。
3. サマリーをコピーして、これが「認証（Authentication）」の問題なのか「認可（Authorization）」の問題なのかについてチームの認識を合わせます。活用例
1. 盲目的に認証ロジックを変更する前に、`401`、`403`、`404` を比較する。
2. 形式不正なリクエスト（`400`）とバリデーション失敗（`422`）を区別する。
3. レート制限インシデント（`429`）と一時的なサービス低下（`503`）を切り分ける。
4. API 停止時の切り分けにおいて、より迅速なインシデントノートを作成する。
よくある質問
通常の HTTP ステータスコード表と何が違うのですか？
一般的な表は定義を教えるだけですが、本番環境でエンジニアが実際に何と何を混同しやすいかまでは教えてくれません。このツールは、現実的なシナリオ、実用的なチェックポイント、そして誤ったデバッグ方向に進みやすい類似コードを提示します。
このツールは実際のレスポンスボディを検査しますか？
いいえ。このツールはコードの解釈と切り分けのガイダンスに特化しており、ペイロードのパースは行いません。レスポンスボディ自体の形式不正が疑われる場合は、JSON バリデーターなどのツールと併用してください。
フロントエンドだけでなくバックエンドチームにも役立ちますか？
はい。フロントエンドチームはネットワークエラーを迅速に推論するために、バックエンドチームはサポートチケットやインシデント報告、API レビューの際の迅速なチェックリストとして活用できます。