What do HTTP errors 400, 401, 403, 404, 429 and 500 mean
Published on 2026-10-21 by frfrand
Guía práctica de códigos de respuesta HTTP para saber qué falla entre navegador, API, autenticación y servidor.
HTTP status codes indicate how a server responded to a request. A 404 usually means it did not find the requested resource; a 500 indicates an internal error while processing it. Understanding them allows diagnosing a website without guessing which component failed.
The number matters less than the family
2xx codes indicate success. 3xx codes relate to redirects. 4xx codes point to problems related to the client's request, and 5xx codes indicate that the server could not fulfill it.
That does not mean any 4xx is anyone's fault: a poorly designed API can also respond with an incorrect code.
400: Bad Request
A 400 Bad Request appears when the server cannot or will not process a request due to a problem it considers to be the client's.
Imagine you send a JSON with invalid syntax or parameters impossible to interpret. The server can return 400, ideally with a message explaining which field to check.
But do not use 400 as a generic response for any error. Distinguishing situations helps a lot those who use your API.
401 vs 403: a common confusion
401 Unauthorized has a somewhat misleading historical name: it usually indicates that the request lacks valid credentials to access the resource.
403 Forbidden indicates that the server understood the request but refuses to fulfill it. A person might be correctly identified and not have permissions to query an invoice.
Think of it this way: 401 is "I need valid credentials" and 403 is "you don't have access to this operation". In both cases there are nuances and particular authentication mechanisms.
404: resource not found
The classic 404 Not Found does not prove that the entire server is down. A route may be missing, a page may have been deleted, or an incorrect URL may be used.
Sometimes an API returns 404 deliberately to avoid revealing whether a private resource exists that someone does not have access to. This may be appropriate if it is contemplated by the security policy.
Before chasing a deployment error, check the exact URL, the HTTP method, and the routes actually registered by the application.
429: too many requests
A 429 Too Many Requests appears when a request limit has been exceeded. It may be temporary and accompanied by information on when to retry.
It does not necessarily mean that the website has a bug. It may be the expected response from a system that protects resources.
A responsible integration reduces frequency, respects server indications, and avoids retrying hundreds of times per second.
500: the server failed
A 500 Internal Server Error indicates that an unexpected problem occurred while the server was handling the request.
It can be a code error, an incorrect dependency, an incomplete configuration, or many other causes. The code alone does not say which one.
To investigate it, you have to review the application logs and the corresponding request. Avoid showing full traces with passwords or secret variables to visitors.
What about the famous 502, 503, and 504?
A 502 Bad Gateway usually indicates that a proxy or intermediary received an invalid response from another server. A 503 Service Unavailable indicates temporary unavailability or overload. A 504 Gateway Timeout indicates that the intermediary did not receive the necessary response in time.
These differences matter when you use Nginx in front of a backend. A 502 can point to a crashed process, while a 504 can appear when the backend takes too long.
How to investigate without wasting time
First, reproduce the problem and note down URL, method, code, and time. Then identify which component generated the response: browser, proxy, backend, or external service.
If you use several services, correlate records and requests. An HTTP error is a clue, not the complete diagnosis.
How does this look in ArduMaker?
In an application deployed on an ArduMaker VPS, HTTP codes can help you decide whether to review permissions, routes, Nginx, or backend processes. The platform makes it easy to operate the services, but interpreting the code remains essential.
In summary: 401 is not 403, and 502 is not 504. Understanding those differences avoids fixing the wrong part of the system.
Sources: HTTP status codes on MDN · HTTP Semantics RFC 9110.