HTTP 4xxクライアントエラー：意味、診断、解決方法

このエラーの意味と見分け方

ブラウザー、APIクライアント、自動化されたリクエストが、400から499までのHTTPステータスを受け取ります。レスポンスには、短いエラーページ、JSONエラーオブジェクト、説明用ヘッダーが含まれる場合や、有用なボディがない場合があります。

よく見られるレスポンスは次のとおりです。

• 400 Bad Request: サーバーは受信したリクエストを処理できません。
• 401 Unauthorized: リソースに対する認証がない、無効である、または必要です。
• 403 Forbidden: リクエストは理解されていますが、アクセスは許可されていません。
• 404 Not Found: 要求されたリソースまたはルートが見つかりません。
• 405 Method Not Allowed: リソースは使用されたHTTPメソッドに対応していません。
• 409 Conflict: リクエストがリソースの現在の状態と競合しています。
• 410 Gone: リソースは意図的に利用できなくなっています。
• 413 Content Too Large: リクエストボディが設定または文書化された上限を超えています。
• 429 Too Many Requests: クライアントがレートまたはクォータの上限を超えています。

同じステータスでも、アプリケーション、リバースプロキシ、CDN、Web Application Firewallのどれが生成したかによって見え方が異なる場合があります。

可能性の高い順の主な原因

よくある原因（診断の順序）

1. 不正な形式または無効なリクエスト — 400: 無効な構文、正しくエンコードされていないURL、無効なJSON、誤ったコンテンツタイプ、必須データの欠落により、処理できないことがあります。
2. 認証情報の欠落または無効な認証 — 401: 認証情報がない、期限切れの認証情報が含まれている、またはエンドポイントが受け付けない認証情報を使用している可能性があります。
3. 権限不足またはセキュリティポリシー — 403: 認証は済んでいても認可されていない、またはIPルール、CDN、WAF、プロキシ、アプリケーションのポリシーによってアクセスが拒否されている可能性があります。
4. 誤ったルートまたはリソースの状態 — 404または410: URLが間違っている、デプロイにそのルートが含まれていない、リソースが移動した、または所有者が意図的に削除した可能性があります。
5. サポートされていないHTTPメソッド — 405: エンドポイントの契約では別のメソッドが許可されているのに、クライアントがGET、POST、PUT、PATCH、DELETEを使用しています。
6. 状態またはバージョンの競合 — 409: 要求された変更が、リソースの現在の状態、既存のオブジェクト、または別の更新と競合している可能性があります。
7. リクエストが上限を超過 — 413: ボディ、アップロード、またはエンコードされたリクエストが、アプリケーションまたは中間プロキシの適用する上限を超えています。
8. リクエスト過多 — 429: クライアントがレート制限、同時実行数制限、またはクォータを超えています。

CDN、WAF、リバースプロキシは、リクエストがオリジンに到達する前に4xxレスポンスを生成できます。この場合、見かけ上のアプリケーションエラーは、より前段のネットワークレイヤーに由来している可能性があります。

修正方法

1. 正確なレスポンスを取得する

数値ステータス、完全なURL、HTTPメソッド、タイムスタンプ、リクエストタイプ、関連するレスポンスヘッダーを記録します。APIリクエストでは、サニタイズしたコンテンツタイプ、リクエストサイズ、相関IDまたはリクエストIDも記録します。パスワード、APIキー、Cookie、アクセストークンは記録または共有しないでください。

既知の正常なリクエストがある場合は、そのレスポンスと比較します。レスポンスボディとヘッダーから、オリジンのアプリケーション、プロキシ、CDN、WAFのどれが応答元かを確認します。

2. リクエストの契約を確認する

400の場合は、URLエンコード、必須パラメーター、JSONまたはフォームの構文、コンテンツタイプ、必須フィールドを検証します。サーバー設定を変更するのではなく、クライアントがエンドポイントに文書化された形式で送信していることを確認します。

405の場合は、エンドポイントで許可されているメソッドを確認し、クライアントがリダイレクトに従っていないか、API操作にブラウザー向けのURLを使用していないかを確認します。提供されている場合は、Allowレスポンスヘッダーを確認します。

409の場合は、現在のリソースの状態を調べます。オブジェクトがすでに存在する、読み取り後に変更された、または要求された状態遷移が利用できない可能性があります。書き込みを無条件に繰り返すのではなく、アプリケーションの競合処理またはバージョン管理の動作に従います。

3. 識別情報とアクセスを確認する

401の場合は、認証が存在し、有効であり、エンドポイントが要求する形式で送信されていることを確認します。期限切れの場合は、承認された手順で新しい認証情報を取得します。認証情報をチケット、ログ、トラブルシューティング用コマンドに貼り付けないでください。

403の場合は、認証された識別情報に必要なロールまたはリソース権限があることを確認します。サイト所有者は、認可ルール、IP制限、WAFまたはCDNのポリシー、環境固有のアクセス制御を確認してください。URL自体がポリシーに一致した場合を除き、URLを変更しても403は解決しません。

4. ルーティングとリソースの状態を確認する

404の場合は、スペル、必要に応じて大文字と小文字、パスプレフィックス、ホスト名、デプロイ環境、末尾パスの動作を確認します。アプリケーションのルーティング、リバースプロキシの転送、リソースが実際に存在するかを確認します。

410の場合は、所有者が別の見解を示さない限り、意図的な削除を示すシグナルとして扱います。代替リソースがある場合は、リンクまたはクライアントをそのリソースに更新します。同じURLを単純に再試行しないでください。

5. リクエストサイズを確認する

413の場合は、リクエストボディまたはアップロードのサイズを測定し、文書化された上限と比較します。クライアント、リバースプロキシ、CDN/WAF、アプリケーションの各レイヤーを確認してください。最も小さい上限によってレスポンスが生成される可能性があります。まずはペイロードを小さくするか、文書化されたアップロード方法を使用します。

上限の引き上げには、承認、キャパシティの確認、設定変更の調整が必要です。これにより、リソース消費や大容量リクエストを悪用されるリスクが増加する可能性があります。

6. レート制限に安全に対処する

429の場合は、不要なリトライを停止し、同時実行数とリクエスト頻度を下げ、Retry-Afterが存在する場合はそれに従います。適切な場合は、上限付きの指数バックオフとクライアント側キャッシュを使用します。

サイト所有者は、制限の対象範囲（ユーザー、トークン、IP、ルート、サービス）を特定し、変更前にクォータ設定とトラフィックパターンを確認してください。

7. 応答したレイヤーを特定する

サイト所有者は、タイムスタンプ、パス、メソッド、リクエストIDを、アプリケーション、リバースプロキシ、CDN、セキュリティの各ログと照合してください。オリジンに一致するリクエストがない場合は、まずCDN、WAF、プロキシを調査します。

承認済みのオリジンへの直接テストと公開パスで、レスポンスヘッダー、ボディ形式、サーバー識別子を比較します。承認なくセキュリティ制御を回避しないでください。

8. 具体的な変更を再テストする

レスポンスの原因となったリクエストまたはルールを変更してから再テストします。期待される成功ケースだけでなく、認証されていない識別情報、サイズ超過のペイロード、頻繁すぎるリクエストなど、関連する失敗ケースも確認します。デプロイまたはポリシー変更後は4xxの傾向を監視し、リグレッションを検出します。

予防と修正確認

• エンドポイントのメソッド、必須フィールド、認証要件、レスポンスコード、リクエストサイズの上限、レート制限の動作を文書化します。
• 内部リンクと外部リンクを最新の状態に保ち、ルートを変更する際はリダイレクトや削除をテストします。
• 認可境界、サポート対象のメソッド、不正な入力、リソース状態の競合について自動テストを実施します。
• 本番リリース前に、リクエストサイズとクライアントのリトライ動作を検証します。
• 429レスポンスに遭遇する可能性があるクライアントでは、上限付きバックオフ、キャッシュ、リクエストの重複排除を使用します。
• ルート、ステータス、クライアント、応答レイヤー別に4xx率を監視し、リンク切れ、権限のリグレッション、クライアントの変更を区別できるようにします。
• アプリケーション、プロキシ、CDN、セキュリティの各レイヤーで、相関IDとサニタイズ済みログを利用できる状態にします。

よくある質問