Loading...

Fundamentos · 7 min de lectura

Códigos de estado HTTP: léelos como "quién rechazó, y dónde"

Toda referencia enumera lo que significan los códigos. Casi ninguna dice qué máquina los emite — y en un sitio detrás de un CDN, esa es la pregunta que reduce la depuración de una tarde a un minuto. Esta es la lista desde el punto de vista del proxy.

Actualizado

Códigos de estado HTTP: léelos como "quién rechazó, y dónde"

Las clases, en breve

2xx — funcionó. 200 OK es la respuesta normal. 204 No Content es una petición exitosa sin nada que devolver, común en las API. 206 Partial Content es una petición de rango, que es como funcionan el salto en vídeos y las descargas reanudables.

3xx — ve a otro sitio. 301 es permanente y traspasa las señales de posicionamiento; 302 es temporal y no lo hace. 304 Not Modified es el silencioso: el cliente ya tiene una copia válida, así que el cuerpo no se envía en absoluto. Un sitio sano sirve muchos 304.

4xx — la petición fue rechazada. 400 está mal formada, 401 necesita credenciales, 403 es un rechazo deliberado, 404 no se encuentra, 410 ha desaparecido a propósito, 429 son demasiadas peticiones.

5xx — falló el lado del servidor. 500 es un error no gestionado, 502 es una conversación rota con la máquina de detrás, 503 es un rechazo temporal, 504 es un timeout esperando a la máquina de detrás.

Qué salto produjo el código

Una petición detrás de un CDN pasa por al menos tres lugares que pueden responderla: el edge, el servidor web de tu origen, y tu aplicación. Cada uno puede producir códigos que los otros no pueden.

Solo el edge puede producir: un acierto de caché servido mientras el origen está caído, un 502 o 504 sobre tu origen, un 403 de una regla del WAF o un bloqueo geográfico, y un 503 diciendo que no hay ningún servicio configurado para el hostname.

Solo el servidor web de tu origen produce: 403 por permisos de archivo o una regla de denegación, 404 para una ruta que no existe en disco, 413 para un cuerpo más grande de lo que acepta.

Solo tu aplicación produce: 401 y 403 según quién ha iniciado sesión, 422 por validación, 500 por una excepción no gestionada.

Así que la primera pregunta de diagnóstico no es "qué significa 502" sino "¿llegó esta petición a mi origen siquiera?". Si no aparece en el registro de acceso del origen, nada de lo que cambies en el origen le va a afectar.

Leer las cabeceras para encontrar el salto

La respuesta te dice quién la gestionó, si miras las cabeceras en lugar de la página.

curl -sI https://example.com/

Una cabecera de estado de caché — en cdn.com.tr, X-Proxy-Cache-MT con HIT o MISS — significa que el edge procesó la petición. Un HIT significa que no se consultó el origen en absoluto, algo que vale la pena saber cuando estás probando un cambio y sigues viendo el comportamiento antiguo.

Aquí viven dos trampas. La primera: curl -I envía una petición HEAD, y algunos servidores y middleware se comportan de forma distinta para HEAD que para GET, así que una cabecera que aparece con -I puede estar ausente en un GET real y viceversa. Cuando importe, usa curl -sD - -o /dev/null con un GET normal. La segunda: una respuesta de error cacheada se seguirá sirviendo después de que arregles la causa. Si el código no cambia después de una solución, purga la ruta antes de seguir depurando.

Los códigos que merece la pena configurar a propósito

301 vs 302. Usa 301 cuando el traslado es permanente — consolida el posicionamiento de la URL antigua en la nueva. Un 302 mantiene la URL antigua como la canónica, que es lo que quieres para una redirección de campaña temporal y no lo que quieres después de una reestructuración del sitio. Las redirecciones se cachean en el edge, así que una equivocada sobrevive al despliegue que la introdujo.

404 vs 410. Los dos dicen "aquí no está". Un 410 dice "y no va a volver", lo que hace que la URL se descarte del índice más rápido. Para páginas de producto retiradas, 410 es el código honesto.

503 con Retry-After. Durante el mantenimiento, este es el par que mantiene pacientes a los rastreadores. Una página de mantenimiento servida con 200 les dice que tu aviso de mantenimiento es tu contenido.

429 para los rate limits. Más honesto que 503 cuando el rechazo trata de la rapidez con la que este cliente está preguntando. No todos los stacks lo envían por defecto — el rate limiting de nginx devuelve 503 a menos que se configure lo contrario.

Los códigos de estado en los que realmente vas a invertir tiempo

En la práctica, tres códigos acaparan la mayor parte del tiempo de depuración en un sitio detrás de un proxy, y cada uno tiene su propia guía:

**502 Bad Gateway** — el edge no pudo obtener una respuesta utilizable de tu origen. Cuatro causas: conexión rechazada, cierre prematuro, fallo de la negociación TLS, respuesta mal formada.

**403 Forbidden** — algo rechazó a propósito. Cinco posibles responsables: tu origen, una regla del WAF, un bloqueo por país o red, la protección hotlink, una lista de IP. Un ID de referencia en la página de error es lo que convierte el adivinar en buscarlo.

**503 Service Unavailable** — un rechazo temporal: sobrecarga, mantenimiento, un rate limit, o un edge sin ningún origen configurado para ese hostname.

El cuarto, 504, es el gemelo de timeout del 502 y se trata en la guía del 502, porque distinguirlos es la mayor parte del trabajo.

Preguntas frecuentes sobre códigos de estado HTTP

¿Qué códigos de estado afectan realmente al SEO?

Los que cambian lo que se indexa: 301 consolida una URL en su destino, 302 no lo hace, 404 y 410 retiran una URL siendo 410 más rápido, y un 5xx prolongado acaba descartando la página. Un 200 servido en una página de error es el que hace daño silenciosamente, porque el texto del error se indexa como contenido.

¿Por qué obtengo un código distinto con curl que con mi navegador?

Las peticiones son distintas. Tu navegador envía cookies, un user agent diferente y una cabecera Accept; curl normalmente no envía nada de eso. En un sitio con un WAF o un bypass por cookie de sesión, esas diferencias cambian la decisión. Compara peras con peras antes de concluir nada.

¿Es 304 un error?

No, es el mejor resultado tras un acierto de caché: el cliente ya tiene una copia válida y el servidor no envía ningún cuerpo. Muchos 304 en tus registros significa que las peticiones condicionales están funcionando.

¿Qué significa un 000 o un estado vacío en mi monitorización?

Que no hubo ninguna respuesta HTTP que leer: el DNS no resolvió, la conexión TCP falló, o el TLS no negoció. Es un problema de conectividad y no de aplicación, y vale la pena distinguirlo de un 5xx en cualquier sistema de alertas que tengas.