HTTP Status Codes: The Complete List With Fixes (2026)

A checkout fails after a gateway change. Your test reports 504, while the browser reports ERR_CONNECTION_RESET. Those are not interchangeable: one is an HTTP response and the other may occur before any HTTP response exists. The number helps only after you identify who emitted it.

HTTP status codes fall into five classes. Capture the exact request, headers, and body; locate the origin, proxy, CDN, gateway, or client that produced the result; then make a reproducible assertion. This is the complete IANA registry-based list of assigned codes and ranges, with a practical first check.

Use this HTTP status-code troubleshooting checklist first

1. Reproduce the exact request. Save method, URL, query, body, and authentication state. Why: request shape separates malformed input from auth or routing failures.

2. Capture the response. Save status, headers, body, timestamp, correlation ID, and client. Why: this evidence connects the result to the responsible logs.

3. Locate the emitter. Establish whether the origin, proxy, CDN, API gateway, or client answered. Why: you cannot fix a gateway 502 in an endpoint handler.

4. Read action headers. Check Location, Allow, WWW-Authenticate, Retry-After, Content-Type, Content-Range, ETag, and Last-Modified. Why: they often specify the protocol’s next action.

5. Make the smallest safe retest. Use known-good credentials and minimal input; retry only when the operation and server policy permit it. Why: replaying a non-idempotent operation can duplicate work.

6. Add a regression assertion. Assert status, decisive headers, and body schema or invariant. Why: a green status can still carry an error page or wrong representation.

Get the Mobile Testing Playbook Used by 800+ QA Teams

Discover 50+ battle-tested strategies to catch critical bugs before production and ship 5-star apps faster.

Email addressGet Instant Access

100% Free. No spam. Unsubscribe anytime.

HTTP status codes at a glance

IANA’s registry assigns status values, while RFC 9110 defines core HTTP semantics. IANA also labels temporary, unused, obsolete, and unassigned entries; never invent a meaning for an unassigned number.

Complete 1xx status codes

Complete 2xx status codes

Complete 3xx status codes

Keep crawler behavior separate from HTTP semantics

Google’s crawler guidance treats 301 as a strong signal, 302 as weak, 307 like 302, and 308 like 301 for Google’s systems. That does not redefine the protocol for your client. Google also says a 2xx result does not guarantee indexing; test meaningful content to catch a 200 error page that becomes a soft 404.

Complete 4xx status codes

401 versus 403: 401 lacks acceptable authentication and should be read with WWW-Authenticate; 403 recognizes the identity but refuses the action. Test missing, expired, malformed, and insufficient-scope credentials separately.

404 versus 410: 404 does not establish permanence. A 410 says the resource is intentionally gone. Assert the lifecycle behavior your API documents.

Complete 5xx status codes

For 502 and 504, Cloudflare’s documentation says to establish whether Cloudflare or the origin generated the response. For 503 and 429, Retry-After can be a date or delay; MDN documents its use with temporary unavailability and redirects. Cap retries and never blindly replay a non-idempotent request.

NGINX 499 is an implementation-specific log status

NGINX 499 is not a standard HTTP response. An NGINX maintainer explanation describes it as a client closing a request before NGINX generated a response, often while it waited for an external result. Investigate client disconnects, upstream latency, and timeout alignment.

Debug an HTTP status code in Chrome DevTools

1. Open Network before reproducing. You need the request capture.

2. Trigger the same action. Reload or repeat the call with the same state.

3. Select the request row. Record Status, Type, Initiator, Size, and Time.

4. Inspect Headers, Response, Initiator, and Timing. Find input differences, redirects, and slow phases.

5. Save a test fixture. Preserve method, URL, auth, headers, body, and expected assertions.

Chrome’s Network panel documentation covers these views. If you need to formalize the fixture, see this guide to writing test cases.

Test status codes in API and mobile-app workflows

Define method, URL, authentication state, headers, query/body, expected status, expected headers, and expected body schema or invariant. Add a valid case, the relevant negative case, and a bounded-retry assertion where temporary failure is expected.

In mobile testing, assert the backend result alongside the visible UI outcome. Quash is our product; its mobile API-testing guide describes combining app actions, backend validations, and run evidence. Whatever tool you use, a passing UI does not prove the backend accepted the intended request.

HTTP status code versus browser or network error

A browser error is not automatically an HTTP status code. Chrome lists ERR_NAME_NOT_RESOLVED, ERR_CONNECTION_TIMED_OUT/ERR_TIMED_OUT, ERR_CONNECTION_RESET, ERR_CONNECTION_REFUSED, and ERR_EMPTY_RESPONSE in its error-message help. If no HTTP response arrived, record the browser error, DNS or connection evidence, timestamp, URL, and network context instead.

Conclusion

Use the registry to establish what a number can mean, but let the captured request and emitting layer decide the fix. When you can reproduce the failure and assert the status, headers, and body together, you have a diagnosis the next release can verify.

FAQ

What is the most common HTTP status code?

There is no universal answer. It depends on redirect handling, final-response counting, connection failures, and the population measured. A 2026 Enterno study explains why a monitoring sample is not the whole web.

What is the difference between 4xx and 5xx?

A 4xx says the request does not meet the target’s contract; a 5xx says a server, gateway, or upstream could not fulfil an apparently valid request. Either class can come from an intermediary.

Should every error be retried?

No. Consider method safety, idempotency, server policy, the status, and Retry-After. Use bounded retries only for conditions your contract defines as temporary.

Is 499 a standard HTTP status code?

No. It is an NGINX-specific log status, not an assigned IANA HTTP status code.

Does 200 guarantee indexing?

No. Google says a 2xx result does not guarantee indexing, and an error-like page served with 200 can be classified as a soft 404.