HTTP Status Codes
Search 40+ HTTP status codes by number, name or scenario and see the meaning, common causes and fixes.
How to use
- Type a number, or a scenario word such as CORS, timeout or cache, to jump to the right entry.
- Use the class buttons to show only 1xx through 5xx. Combine with search to narrow further.
- Open any entry to read what the code means, what usually causes it and how to fix it.
- Press Copy inside an entry to take the number and name into a ticket or chat.
- A status code is a clue. Check the body, headers and server logs before drawing conclusions.
FAQ
Who owns a 4xx versus a 5xx error?
Why does a CORS error show no status code?
How do 301 and 302 differ for SEO?
Is 304 an error?
How to use
- Search by number
If you know the code, type the digits. The list filters as you type, with no paging to fight through.
- Search by scenario
When only the symptom is clear, try CORS, upload, timeout or cache. The keyword list covers common wording and both names.
- Filter by class
Pick 4xx or 5xx to see one family. Combine with search to separate client parameter problems from gateway failures.
- Open the three parts
Each entry explains the meaning, the usual causes and the fix, so you can match it against the case in front of you.
- Copy into a ticket
The copy button takes the number and name into a ticket, chat or commit message, which removes a round of explanation.
About this tool
An HTTP status code is the first sentence back to the client. The three digits fall into five families: 1xx still working, 2xx succeeded, 3xx look elsewhere, 4xx the request is wrong and 5xx the server failed. Reading that first digit tells you whether to open the front-end code or the server log. The right direction saves most of the debugging time, and a wrong code sends everyone to the wrong file while hiding the failure from monitoring.
This page covers 45 codes that show up in daily work, each with meaning, common causes and a fix. The data ships inside the page script, so search and filtering run locally and work offline, and keywords are never logged. Keywords include Chinese scenario words and English names, so rate limit and 限流 both find 429. Entries stay in numeric order for browsing, and opening one closes the previous entry so the page does not grow into a wall of text.
How it works
Status code semantics live in RFC 9110. The first digit sets the family and the last two are just labels. Methods carry meaning too: GET, PUT and DELETE should be idempotent, so repeating them leaves the same state, while POST makes no such promise. A 301 or 308 is permanent and cached for a long time, which makes a mistake hard to undo. A 302 or 307 is temporary, and 307 keeps the original method. A 201 should carry Location, and a 204 means success with no body. People mix up 401 and 403, but the first means unauthenticated and the second means authenticated without permission.
During an incident the code only makes sense with context. A gateway 502 means it received an unreadable response from upstream, so the backend process or port is the likely fault. A 504 means upstream was too slow, which points at slow queries and thread pools. An API that returns 200 for business failures breaks monitoring and retries, because clients must parse the body to learn the outcome. Log the status, latency and request ID together so one request can be traced end to end. Grouping metrics by status code quickly shows whether one upstream is failing or clients are sending bad parameters.
When to use it
- API integration
The front end reports a failure while the backend log shows nothing. The Network panel narrows it down: 401 means the token is missing, 422 means a field failed validation, 502 means the gateway never reached the backend. Three owners, three fixes, and no guessing in chat while unrelated logs pile up.
- Nginx returning 502
After a deploy the whole site returns 502 while static files still load. The Nginx error log points at an upstream port with nothing listening, so the PHP-FPM process is down. Restart it and add a health check to catch the next crash, then review the upstream timeout and retry settings.
- A site migration
Section URLs are changing and old links still have backlinks. Redirect each old address straight to the new one with 301, avoid chains and keep the rules for at least a year. Pages with no replacement should return 410 rather than a blank page. That also lets search engines drop the stale entries sooner.
Tips & tricks
- Note the status code first, then read the body and headers, and only then open the server log. Reversing that order lets the log pull you off course.
- A 502 or 504 from a reverse proxy points at the upstream service, not at the proxy itself.
- When designing an API, let status codes describe transport outcomes and keep business errors in the body. Mixing the two confuses every client.
Things to watch
- Returning 200 for everything
If business failures also return 200, monitoring sees success and retries or circuit breakers never fire. Let status codes describe the transport result and put business errors in the body. One rule then serves both the client and the dashboard.
- Confusing 401 and 403
Returning 403 for an expired token leaves the client unsure whether to refresh or ask an admin. Use 401 with WWW-Authenticate for missing credentials and 403 for a real permission problem. Separate handling keeps the user-facing message accurate as well.
- Leaking stack traces
A 500 that includes database hosts and a stack trace both leaks information and confuses users. Return a stable error shape with a request ID and keep the details in the server log. The ID still lets support trace the failure without exposing internals.