HTTP 422 Unprocessable Content — Reverse Proxy & Gateway Troubleshooting
HTTP 422 Unprocessable Content indicates that the server parsed the Content-Type (such as application/json) and syntax without error, but semantic domain validation rejected the payload fields.
| Status Code | 422 Unprocessable Content |
|---|---|
| Specification / Origin | RFC 9110 ยง15.5.21 |
| Failure Layer | API Schema & Validation Layer |
| Retry Safety | Do not blind-retry without fixing request syntax, auth, or origin certificate |
Interactive HTTP 422 Live Probe & Log Command Builder
Enter your target endpoint below to generate copy-ready curl latency breakdown probes and origin bypass tests:
Related diagnostics: Nginx & Caddy Proxy Generator → · X.509 SSL Certificate Decoder → · Offline JWT Expiry Inspector →
Production Root Causes & Remediation Guide
Frameworks like FastAPI (Pydantic), Rails, and Kubernetes admission webhooks emit 422 when required JSON fields are missing, data types mismatch, CIDR strings fail validation, or enum values fall outside allowed schemas.
Step-by-Step Engineering Fix
Validate outgoing JSON payloads against the OpenAPI/JSON Schema contract, inspect detailed field-level error arrays in the 422 response body, and confirm Content-Type: application/json headers are set.
Recommended Nginx / Reverse-Proxy Configuration Snippet
# Inspect exact validation error payload returned by FastAPI / REST APIs
curl -sS -X POST https://api.example.com/v1/items -H 'Content-Type: application/json' -d '{}' | jq .
Frequently Asked Questions (HTTP 422)
When should REST APIs return HTTP 422 instead of HTTP 400?
Use HTTP 400 when raw JSON syntax is broken or unparseable, and HTTP 422 when the JSON parses cleanly but fails business or schema validation rules.
Which infrastructure layer generates HTTP 422 Unprocessable Content?
HTTP 422 (RFC 9110 ยง15.5.21) typically originates at the API Schema & Validation Layer layer. HTTP 422 Unprocessable Content indicates that the server parsed the Content-Type (such as application/json) and syntax without error, but semantic domain validation rejected the payload fields.
Should API clients automatically retry HTTP 422 responses?
Do not blind-retry HTTP 422 without fixing the underlying request payload, authentication token, or origin TLS certificate first.
Browse All 25 Gateway, Proxy & Cloud HTTP Error Guides
HTTP 400 (Bad Request) HTTP 401 (Unauthorized) HTTP 403 (Forbidden) HTTP 404 (Not Found) HTTP 405 (Method Not Allowed) HTTP 408 (Request Timeout) HTTP 413 (Content Too Large) HTTP 422 (Unprocessable Content) HTTP 429 (Too Many Requests) HTTP 431 (Request Header Fields Too Large) HTTP 499 (Client Closed Request) HTTP 500 (Internal Server Error) HTTP 501 (Not Implemented) HTTP 502 (Bad Gateway) HTTP 503 (Service Unavailable) HTTP 504 (Gateway Timeout) HTTP 507 (Insufficient Storage) HTTP 511 (Network Authentication Required) HTTP 520 (Web Server Returned an Unknown Error) HTTP 521 (Web Server Is Down) HTTP 522 (Connection Timed Out) HTTP 523 (Origin Is Unreachable) HTTP 524 (A Timeout Occurred) HTTP 525 (SSL Handshake Failed) HTTP 526 (Invalid SSL Certificate)