Complete HTTP Error Code Reference: What Each Status Code Means and How to Fix It

HTTP 400 is returned when the server cannot process a request due to malformed syntax, invalid framing, or deceptive request routing. The server received the TCP connection and the HTTP message, but the message itself violates the HTTP/1.1 or HTTP/2 protocol specification in a way the server refuses to handle.

Common causes include invalid characters in the URL (unencoded spaces or special characters), an oversized request header that exceeds the server’s configured limit (client_header_buffer_size in nginx), a malformed Content-Type header that does not match the body payload, or a corrupt multipart form boundary. In API contexts, 400 typically means the JSON or XML body failed schema validation — a missing required field, wrong data type, or invalid enum value.

Resolve a 400 by inspecting the exact request being sent: URL-encode all special characters, verify Content-Type matches the body format, reduce header size, and validate the request body against the API schema. If you are a site owner receiving unexpected 400s, check your reverse proxy’s header buffer limits and any WAF (Web Application Firewall) rules that may be rejecting legitimate traffic.

HTTP 401 means the request lacks valid authentication credentials for the target resource. Despite its name, 401 is specifically an authentication failure, not an authorization failure. The server is saying: “I don’t know who you are. Provide credentials and try again.”

A 401 response must include a WWW-Authenticate header specifying the authentication scheme required (e.g., Bearer, Basic, Digest). The client can retry the same request with a valid Authorization header and may succeed. This is the critical behavioral difference from 403 — 401 is recoverable by providing credentials; 403 is not.

Common causes: expired JWT token, missing Authorization: Bearer header, revoked API key, session cookie expiry, or an OAuth token with insufficient scope for the requested endpoint.

HTTP 403 means the server understood the request and identified the requester, but refuses to authorize access regardless of credentials. This is an authorization failure: the server knows who you are, and has decided you are not permitted to access this resource — not now, not with different credentials.

403 differs from 401 in that retrying with different credentials will not help — the denial is based on identity or role, not missing authentication. A 403 does not include a WWW-Authenticate header. It may also be returned deliberately to mask the existence of a resource (returning 403 instead of 404 prevents enumeration attacks where attackers probe for hidden endpoints).

Common causes: insufficient role permissions (e.g., a non-admin user accessing an admin endpoint), IP allowlist enforcement, CORS policy blocking cross-origin access, file system permissions preventing the web server from reading a file, or a CDN/WAF geo-blocking rule.

HTTP 404 means the server cannot locate a resource at the requested URL, but makes no claim about whether the resource ever existed or might exist in the future. The absence is ambiguous — the resource may have moved, may return, or may never have existed. The server is not committing to permanence.

Google’s crawlers treat 404 as a soft signal: they will revisit the URL periodically for weeks or months before fully de-indexing it, in case the resource returns. This crawl budget consumption matters at scale — a site with thousands of 404 URLs wastes crawl budget that could be spent on live content. For site owners, a 404 on a URL that previously ranked should be addressed immediately: either restore the content, issue a 301 redirect to the most relevant live page, or return 410 to signal permanence.

HTTP 410 explicitly declares that the requested resource has been permanently and intentionally removed with no forwarding address. Unlike 404, 410 communicates intent: the server knows the resource existed, knows it was deleted, and is asserting it will not return. This semantic precision is why 410 matters more than 404 in specific scenarios.

Search engines treat 410 as a hard signal: Googlebot de-indexes a 410 URL significantly faster than a 404, typically within days rather than weeks. This makes 410 the correct response when permanently deleting content you do not want re-crawled — expired promotions, discontinued products, removed user accounts, or GDPR-deleted content. 410 also eliminates the “soft 404” ambiguity that causes crawlers to waste time rechecking URLs.

Use 410 when: permanently deleting indexed content, removing product pages for discontinued items, complying with right-to-erasure requests, or retiring old API endpoints. Use 404 only when the missing resource is temporary or its absence is genuinely unknown.

HTTP 429 is returned when the client has sent more requests than the server’s rate limiting policy permits within a defined time window. Rate limiting protects origin infrastructure from abuse, scraping, brute-force authentication attacks, and traffic spikes that would otherwise exhaust connection pools or database query capacity.

The 429 response should include a Retry-After header specifying either the number of seconds to wait or an HTTP-date after which the client may retry. Rate limits are enforced at multiple layers simultaneously: at the origin application (per-user, per-API-key, per-endpoint), at the reverse proxy or API gateway (per-IP), and at the CDN edge (Cloudflare Rate Limiting rules). A 429 from Cloudflare’s edge means the request never reached your origin server — a 429 from the origin means it did reach the server and was refused by application logic.

If you are an API consumer hitting 429 errors, implement exponential backoff with jitter: wait min(base * 2^attempt + random_jitter, max_wait) seconds between retries. If you are a site owner seeing unexpected 429s on your own traffic, check CDN rate limiting rules for overly aggressive IP-level thresholds and ensure authenticated users get higher quota allocations than anonymous traffic.

HTTP 500 is the server’s generic catch-all for any unhandled exception or unexpected condition that prevents it from fulfilling a valid request. It is the server-side equivalent of an unhandled exception in application code: something went wrong that the application did not anticipate and did not handle gracefully.

500 is distinct from 502–504 in a critical way: a 500 originates at the application layer of the origin server itself, not at a proxy or gateway. The web server process (nginx, Apache) is running, the application framework (Django, Rails, Laravel, Express) received the request, but the application code threw an uncaught exception, encountered a null pointer, failed a database query, ran out of memory, or hit a misconfigured environment variable. The TCP connection to the origin succeeded; it’s the application logic that crashed.

Diagnose a 500 by checking application logs immediately after the error (stack traces, error messages), verifying database connectivity and query execution time, checking for recent code deployments or configuration changes, and confirming environment variables and secrets are correctly populated. Use DownCheck to determine if the 500 is affecting all users globally or is isolated to specific request patterns — a global 500 indicates a broken deployment; a partial 500 may indicate a database connection pool exhaustion or a specific code path failure.

HTTP 502 is returned by a reverse proxy (nginx, Cloudflare, AWS ALB, Traefik) when the upstream origin server returns an invalid, malformed, or empty response that violates HTTP protocol specification. The proxy itself is operational and handling client connections normally; the problem is in the response it received from the upstream server sitting behind it.

Understanding 502 requires understanding the two-leg connection model: the client connects to the proxy (leg 1), and the proxy connects to the origin server (leg 2). A 502 means leg 2 failed — not leg 1. The proxy successfully accepted the client’s request, forwarded it upstream, but received back either nothing (crashed origin process), an HTTP protocol violation, a TCP connection reset (RST packet), or a response with an unparseable status line. Common upstream failures that trigger 502: the application server process (gunicorn, puma, node) crashed and is not responding on its socket; a Docker container exited unexpectedly; the upstream returned an invalid HTTP response headers; or the upstream is returning a response too slowly and the proxy has already given up (in which case you would more typically see a 504).

Resolve a 502 by checking the origin server process status (systemctl status nginx, pm2 status, container health), reviewing application crash logs for the timestamp of the first 502, verifying the proxy upstream configuration points to the correct host and port, and confirming the origin’s firewall allows connections from the proxy IP. Use DownCheck’s multi-probe tool to determine if the 502 is global or isolated to specific CDN edge nodes.

HTTP 503 means the server is temporarily unable to handle the request, but is deliberately communicating this unavailability rather than silently failing. Unlike 500 (unexpected crash) or 502 (proxy receiving garbage), 503 is an intentional response — the server knows it cannot serve the request and is saying so explicitly. This means the server software is still operational enough to respond, but is choosing to reject incoming requests.

Three distinct conditions produce 503, and diagnosing which one matters for the fix. Overload: the server’s worker process pool, connection queue, or database connection limit is exhausted — new requests are being shed. nginx returns 503 when its upstream worker pool is full (upstream no live upstreams while connecting to upstream). Scheduled maintenance: the operator has intentionally taken the service offline and configured the server to return 503 with a Retry-After header indicating when it will return. DDoS mitigation: Cloudflare and other CDNs return 503 as part of Under Attack Mode, rejecting traffic that fails challenge verification. A 503 during a known DDoS matches the third pattern; a 503 following a traffic spike matches the first.

Resolve a load-induced 503 by scaling horizontally (adding more origin instances), increasing the worker process count, optimizing slow database queries that are holding connections open, or enabling request queuing with a backpressure mechanism. A maintenance 503 resolves when the maintenance window ends. A DDoS-triggered 503 requires verifying whether legitimate traffic is also being blocked and adjusting CDN challenge sensitivity thresholds accordingly.

HTTP 504 occurs when a reverse proxy or CDN edge node forwards a request to the upstream origin server and receives no complete response within the configured timeout threshold. The proxy made the connection to the upstream (unlike 502, where the upstream responded invalidly), but the upstream either accepted the connection and then went silent, or completed the TCP handshake but never sent HTTP response headers within the time limit.

The root cause is almost always in the upstream’s processing time, not in network latency. The two dominant causes are: a slow database query blocking the application thread that is handling the request, causing it to hold the connection open without sending a response while the query runs; and a downstream microservice call the origin is waiting on that is itself experiencing latency or failure. A 10-second nginx timeout with a 12-second database query will produce a 504 every time. The application code is alive; it is just not finishing fast enough. Network-layer 504s occur when there is packet loss or high latency between the proxy and origin data center — this produces a 504 where the upstream TCP connection itself times out before HTTP headers are exchanged.

Diagnose a 504 by correlating its timestamp with slow query logs in the database, checking application performance monitoring (APM) for the slowest endpoint traces, verifying network latency between proxy and origin via traceroute or VPN path analysis, and reviewing upstream connection timeout settings in the proxy configuration (proxy_read_timeout in nginx). Increasing the timeout is a short-term fix — the correct resolution is optimizing the slow operation, adding indexes, caching query results, or implementing async processing for long-running tasks.