MiServe DevTools

Tus pegatinas

Fija aquí tus herramientas. Se guardan en este navegador.

Referencia de códigos de estado HTTP

Los códigos de estado HTTP del 100 al 511, con lo que significa cada uno para un desarrollador y la RFC que lo define, más los códigos no estándar que usan nginx, Cloudflare y otros productos.

78 códigos de estado.

1xx Informativos

El servidor ha recibido la petición y todavía la está procesando. Son respuestas provisionales, enviadas antes de la definitiva.

100 Continue
El servidor ha recibido las cabeceras de la petición y el cliente puede enviar el cuerpo. El cliente lo pide enviando Expect: 100-continue antes de una subida grande. RFC 9110
101 Switching Protocols
El servidor acepta cambiar el protocolo de esta conexión, como pedía la cabecera Upgrade. Así empieza una conexión WebSocket. RFC 9110
102 Processing
El servidor ha aceptado una petición WebDAV y todavía la está procesando, así que el cliente no debe cortar por timeout. La especificación actual de WebDAV ya no lo incluye y casi no se envía. RFC 2518
103 Early Hints
Se envía antes de la respuesta final con cabeceras Link, para que el navegador empiece a precargar recursos o abrir conexiones mientras el servidor prepara la página. RFC 8297

2xx Éxito

La petición se ha recibido, entendido y aceptado.

200 OK
La petición ha tenido éxito. El cuerpo contiene el resultado: el recurso en un GET, o el resultado de la acción en un POST. RFC 9110
201 Created
La petición ha creado un recurso nuevo. La cabecera Location suele indicar su URL. RFC 9110
202 Accepted
La petición se ha aceptado para un procesamiento que aún no ha terminado y que todavía puede fallar. Es lo habitual cuando el trabajo se pone en una cola. RFC 9110
203 Non-Authoritative Information
La petición ha tenido éxito, pero un proxy ha modificado la respuesta que envió el servidor de origen. RFC 9110
204 No Content
La petición ha tenido éxito y no hay cuerpo que enviar. Es habitual en DELETE, y en PUT o PATCH cuando el cliente ya tiene el nuevo estado. RFC 9110
205 Reset Content
La petición ha tenido éxito y el cliente debe restablecer la vista que la envió, por ejemplo vaciando un formulario. No hay cuerpo. RFC 9110
206 Partial Content
El cuerpo contiene solo el rango de bytes que pedía la cabecera Range. Se usa para reanudar descargas y para saltar a otro punto de un vídeo. RFC 9110
207 Multi-Status
El cuerpo es un documento XML con un estado distinto para cada uno de varios recursos. Lo usa WebDAV. RFC 4918
208 Already Reported
Dentro de una respuesta Multi-Status de WebDAV, marca los miembros de un binding que ya se han listado, para que no se repitan. RFC 5842
226 IM Used
El cuerpo es el resultado de aplicar una o más manipulaciones de instancia, como un delta, al recurso actual. Forma parte de la codificación delta en HTTP, que casi nadie implementa. RFC 3229

3xx Redirección

El cliente tiene que dar un paso más para completar la petición, normalmente una petición a otra URL.

300 Multiple Choices
El recurso tiene varias representaciones y el cliente puede elegir una. Casi no se usa, porque no hay una forma estándar de hacer la elección. RFC 9110
301 Moved Permanently
Redirección permanente: el recurso tiene una nueva URL, indicada en la cabecera Location, y los buscadores suelen indexar esa URL en su lugar. Los clientes pueden cambiar POST por GET al seguir la redirección; usa 308 para conservar el método. RFC 9110
302 Found
Redirección temporal: por ahora el recurso está en otra URL, indicada en la cabecera Location. Los clientes pueden cambiar POST por GET al seguir la redirección; usa 307 para conservar el método. RFC 9110
303 See Other
La respuesta está en otra URL, que el cliente debe pedir con GET. Es la redirección habitual tras el POST de un formulario, para que al recargar la página no se vuelva a enviar el formulario. RFC 9110
304 Not Modified
La copia de la caché del cliente sigue vigente, así que no se envía cuerpo. Responde a una petición condicional hecha con If-None-Match o If-Modified-Since. RFC 9110
305 Use Proxy
Al recurso hay que acceder a través del proxy indicado en la cabecera Location. Está obsoleto por motivos de seguridad, y los clientes no deben contar con él. RFC 9110
306 (Unused)
Una versión anterior de la especificación usaba este código. Ya no se usa, y el número sigue reservado. RFC 9110
307 Temporary Redirect
Redirección temporal: el recurso está temporalmente en otra URL, y el cliente debe repetir allí la petición con el mismo método y el mismo cuerpo. RFC 9110
308 Permanent Redirect
Redirección permanente: el recurso tiene una nueva URL permanente, y el cliente debe repetir allí la petición con el mismo método y el mismo cuerpo. RFC 9110

4xx Error del cliente

El fallo está del lado del cliente: la petición está mal formada, no tiene permisos o pide algo que no se puede servir.

400 Bad Request
El servidor no puede procesar la petición porque está mal formada: la sintaxis es incorrecta, el framing del mensaje no es válido o el cuerpo no se puede analizar. RFC 9110
401 Unauthorized
A la petición le faltan credenciales válidas. La cabecera WWW-Authenticate de la respuesta indica cómo autenticarse. A pesar del nombre, el código trata de autenticación, no de permisos. RFC 9110
402 Payment Required
Reservado para uso futuro. Algunas API lo envían cuando una suscripción ha caducado o se ha agotado una cuota de pago. RFC 9110
403 Forbidden
El servidor ha entendido la petición y la rechaza. Si la petición llevaba credenciales, no dan acceso a este recurso, y volver a enviarlas no servirá de nada. RFC 9110
404 Not Found
El servidor no tiene nada en esta URL, o no quiere revelar que lo tiene. El código no dice si la ausencia es permanente. RFC 9110
405 Method Not Allowed
El recurso existe, pero no admite este método. La cabecera Allow lista los métodos que admite. RFC 9110
406 Not Acceptable
El servidor no puede generar una respuesta que cumpla las cabeceras Accept, Accept-Language o Accept-Encoding de la petición. RFC 9110
407 Proxy Authentication Required
Como el 401, pero el cliente tiene que autenticarse ante el proxy, como describe la cabecera Proxy-Authenticate. RFC 9110
408 Request Timeout
El servidor no recibió la petición completa en el tiempo que estaba dispuesto a esperar, y cierra la conexión. RFC 9110
409 Conflict
La petición entra en conflicto con el estado actual del recurso, por ejemplo una edición basada en una versión desactualizada o un duplicado de un valor que debe ser único. RFC 9110
410 Gone
El recurso estuvo aquí y se ha eliminado definitivamente. A diferencia del 404, indica a los clientes y a los buscadores que pueden descartar la URL. RFC 9110
411 Length Required
El servidor rechaza la petición porque no tiene cabecera Content-Length. RFC 9110
412 Precondition Failed
Una condición de If-Match, If-Unmodified-Since o una cabecera similar resultó falsa, así que la petición no se aplicó. Evita sobrescribir un cambio hecho por otra persona. RFC 9110
413 Content Too Large
El cuerpo de la petición supera el tamaño que acepta el servidor, normalmente por un límite de subida en el servidor o en un proxy situado delante. Antes se llamaba Payload Too Large. RFC 9110
414 URI Too Long
La URL es más larga de lo que acepta el servidor. Suele significar que datos que deberían ir en el cuerpo de un POST se han puesto en la query string. RFC 9110
415 Unsupported Media Type
El servidor no acepta el formato del cuerpo de la petición, tal como lo declaran las cabeceras Content-Type o Content-Encoding. RFC 9110
416 Range Not Satisfiable
La cabecera Range pide bytes que quedan fuera del recurso. RFC 9110
417 Expectation Failed
El servidor no puede cumplir el requisito indicado en la cabecera Expect de la petición. RFC 9110
418 I'm a teapot
Una broma del 1 de abril (April Fools' Day) del Hyper Text Coffee Pot Control Protocol, en el que una tetera se niega a preparar café. La RFC 9110 marca el número como no usado y lo mantiene reservado, porque se ha desplegado como broma demasiadas veces para darle otro significado. RFC 2324, RFC 9110
421 Misdirected Request
La petición llegó a un servidor que no está configurado para responder a este nombre de host. Puede pasar cuando un navegador reutiliza una conexión HTTP/2 para otro host; el cliente puede reintentar con una conexión nueva. RFC 9110
422 Unprocessable Content
La sintaxis de la petición es correcta, pero su contenido no es válido, por ejemplo un cuerpo JSON que no pasa la validación. Viene de WebDAV, donde se llamaba Unprocessable Entity. RFC 9110, RFC 4918
423 Locked
El recurso WebDAV está bloqueado, así que no se le puede aplicar el método. RFC 4918
424 Failed Dependency
El método no se ejecutó sobre este recurso WebDAV porque falló otra acción de la que dependía. RFC 4918
425 Too Early
El servidor no procesará una petición que llegó en los early data de TLS, porque podría ser un ataque de repetición. El cliente debe volver a enviarla cuando termine el handshake. RFC 8470
426 Upgrade Required
El servidor rechaza la petición con este protocolo e indica, en la cabecera Upgrade, el protocolo al que debe cambiar el cliente. RFC 9110
428 Precondition Required
El servidor exige que la petición sea condicional, por ejemplo con If-Match, para que una actualización no pueda sobrescribir sin avisar una versión más reciente. RFC 6585
429 Too Many Requests
El cliente ha enviado demasiadas peticiones en un intervalo de tiempo, lo que se conoce como limitación de frecuencia (rate limiting). La cabecera Retry-After puede indicar cuánto esperar. RFC 6585
431 Request Header Fields Too Large
Las cabeceras en conjunto, o una de ellas, superan el tamaño que acepta el servidor. Una causa frecuente es una cookie demasiado grande. RFC 6585
451 Unavailable For Legal Reasons
El servidor deniega el acceso por un requerimiento legal, como una orden judicial. El número hace referencia a la novela Fahrenheit 451. RFC 7725

5xx Error del servidor

La petición puede ser válida, pero el servidor o un gateway situado delante no ha podido atenderla.

500 Internal Server Error
El servidor se encontró con una situación que no esperaba, a menudo una excepción no controlada. La causa hay que buscarla en los logs del servidor. RFC 9110
501 Not Implemented
El servidor no admite la funcionalidad que necesita la petición, por ejemplo un método que no reconoce. RFC 9110
502 Bad Gateway
Un gateway o proxy recibió una respuesta no válida del servidor que tiene detrás. A menudo la aplicación detrás del proxy se ha caído o no está escuchando. RFC 9110
503 Service Unavailable
El servidor no puede atender la petición en este momento, por sobrecarga o mantenimiento. La cabecera Retry-After puede indicar cuándo volver a intentarlo. RFC 9110
504 Gateway Timeout
Un gateway o proxy no recibió a tiempo la respuesta del servidor que tiene detrás. A menudo la aplicación es demasiado lenta o no se puede alcanzar. RFC 9110
505 HTTP Version Not Supported
El servidor no admite la versión principal de HTTP que usó la petición. RFC 9110
506 Variant Also Negotiates
El servidor está mal configurado: la variante elegida por la negociación de contenido transparente está a su vez configurada para negociar, lo que crea un bucle. RFC 2295
507 Insufficient Storage
El servidor no puede almacenar lo que necesita para completar la petición. Está definido para WebDAV. RFC 4918
508 Loop Detected
El servidor detuvo una operación WebDAV porque encontró un bucle infinito al seguir los bindings. RFC 5842
510 Not Extended
A la petición le falta una extensión que el servidor exige. La especificación que definió el código es ahora histórica, y el registro de IANA marca el código como obsoleto. RFC 2774
511 Network Authentication Required
El cliente tiene que autenticarse para acceder a la red. Lo envía un portal cautivo, como la página de inicio de sesión del Wi-Fi de un hotel, y no el sitio que se había pedido. RFC 6585

Códigos no estándar

Estos códigos no están en el registro de IANA. Cada uno pertenece a un servidor o servicio concreto, y su significado solo vale ahí.

419 Page Expired No estándar
Laravel lo envía cuando falta el token CSRF de un formulario o ha caducado. Laravel
444 No Response No estándar
Una configuración de nginx puede devolver 444 para cerrar la conexión sin enviar respuesta. Aparece en el log de nginx, y el cliente no recibe nada. nginx
494 Request Header Too Large No estándar
nginx lo usa internamente cuando las cabeceras de la petición no caben en sus búferes. Al cliente se le envía una respuesta 400. nginx
495 SSL Certificate Error No estándar
nginx lo usa internamente cuando falla la verificación de un certificado de cliente. Salvo que la configuración lo gestione, al cliente se le envía una respuesta 400. nginx
496 SSL Certificate Required No estándar
nginx lo usa internamente cuando el cliente no presentó el certificado que exige el servidor. nginx
497 HTTP Request Sent to HTTPS Port No estándar
nginx lo usa internamente cuando llega una petición HTTP sin cifrar a un puerto que espera HTTPS. nginx
499 Client Closed Request No estándar
nginx lo registra cuando el cliente cerró la conexión antes de que el servidor respondiera. Suele significar que el timeout del cliente es más corto que el tiempo que tarda la aplicación. nginx
509 Bandwidth Limit Exceeded No estándar
Los paneles de control de hosting como cPanel lo envían cuando un sitio ha agotado su cuota de ancho de banda. cPanel
520 Web Server Returned an Unknown Error No estándar
Cloudflare lo envía cuando el servidor de origen devolvió una respuesta vacía, desconocida o inesperada. Cloudflare
521 Web Server Is Down No estándar
Cloudflare lo envía cuando el servidor de origen rechazó su conexión. Cloudflare
522 Connection Timed Out No estándar
Cloudflare lo envía cuando no pudo completar a tiempo una conexión TCP con el servidor de origen. Cloudflare
523 Origin Is Unreachable No estándar
Cloudflare lo envía cuando no pudo alcanzar el servidor de origen, por ejemplo por un registro DNS erróneo o un problema de enrutamiento. Cloudflare
524 A Timeout Occurred No estándar
Cloudflare se conectó al servidor de origen, pero el origen no envió una respuesta HTTP a tiempo. Cloudflare
525 SSL Handshake Failed No estándar
Cloudflare lo envía cuando falla el handshake TLS entre Cloudflare y el servidor de origen. Cloudflare
526 Invalid SSL Certificate No estándar
Cloudflare lo envía cuando no pudo validar el certificado TLS del servidor de origen. Cloudflare

Funciona en tu navegador. Nada de lo que pegas se sube.

Acerca de esta herramienta

Cómo se organizan los códigos de estado

Toda respuesta HTTP empieza con un código de estado de tres cifras. La primera cifra es la clase: 1xx es una respuesta provisional, 2xx indica éxito, 3xx pide al cliente que vaya a otro sitio, 4xx dice que el fallo estaba en la petición y 5xx que estaba en el servidor. Un cliente que recibe un código que no conoce debe tratarlo como el primer código de su clase, así que un 4xx desconocido se trata como un 400.

El texto que sigue al número, como Not Found, es la reason phrase. Solo es una descripción para personas: los clientes deben ignorarla, y HTTP/2 y HTTP/3 ni siquiera la envían. Los nombres de los códigos estándar de esta lista son los del registro de IANA, salvo el del 418, que el registro indica como (Unused).

Códigos que se suelen confundir

401 y 403. 401 significa que el servidor no sabe quién eres, y autenticarte puede servir. 403 significa que el servidor rechaza la petición y que volver a autenticarte no cambiará la respuesta.

301, 302, 307 y 308. 301 y 308 son permanentes; 302 y 307, temporales. Con 301 y 302 un cliente puede convertir un POST en un GET al seguir la redirección; 307 y 308 exigen el mismo método y el mismo cuerpo.

502 y 504. Los dos vienen de un proxy o balanceador de carga situado delante de la aplicación. Con 502 el proxy recibió algo no válido o falló la conexión; con 504 esperó y no recibió nada a tiempo.

404 y 410. 404 dice que aquí no hay nada, quizá solo por ahora. 410 dice que el recurso se ha eliminado definitivamente.

De dónde sale esta lista

Los códigos estándar vienen del HTTP Status Code Registry de IANA. La mayoría están definidos en la RFC 9110, HTTP Semantics, que sustituyó a la RFC 7231 en 2022. Los demás vienen de WebDAV y de extensiones menores, y cada entrada indica su RFC. Se omiten los registros provisionales que todavía son Internet-Drafts. El último grupo reúne códigos que no están registrados, pero que aparecen en los logs y las páginas de error de nginx, Cloudflare y otros productos.

La lista completa forma parte de la página, así que se puede leer sin JavaScript. El campo de búsqueda la filtra en tu navegador.

Preguntas

¿Qué diferencia hay entre 401 y 403?

401 Unauthorized significa que la petición no lleva credenciales válidas, y el cliente puede volver a intentarlo después de autenticarse. 403 Forbidden significa que el servidor ha entendido la petición y la rechaza: las credenciales que se hayan enviado no dan acceso, así que volver a enviarlas no servirá de nada.

¿Una redirección permanente debe usar 301 o 308?

Los dos indican a los clientes y a los buscadores que la URL se ha movido definitivamente. Con 301 un cliente puede cambiar un POST por un GET al seguir la redirección, mientras que 308 exige el mismo método y el mismo cuerpo. Para URL de páginas normales que se piden con GET, los dos se comportan igual.

¿Qué diferencia hay entre 502 y 504?

Los dos los envía un proxy, gateway o balanceador de carga, no la aplicación. 502 Bad Gateway significa que el servidor que tiene detrás dio una respuesta no válida o rechazó la conexión. 504 Gateway Timeout significa que no respondió dentro del tiempo límite del proxy.

¿Es 499 un código de estado HTTP real?

No está registrado en IANA. nginx escribe 499 en su access log cuando el cliente cerró la conexión antes de que se enviara la respuesta, así que ningún cliente lo recibe nunca. Otros productos usan de forma parecida números que no están en el registro, como los 520 a 526 de Cloudflare.

Más herramientas de Red