Interpretación HTTP
Qué significan los códigos de estado HTTP en el diagnóstico
Entiende cómo deben interpretarse los códigos de estado HTTP en el diagnóstico web, incluidas las redirecciones, los errores del cliente, los errores del servidor y la diferencia entre una respuesta real y un fallo de capa inferior.
Los códigos HTTP son útiles, pero es fácil usarlos mal. Un 503 no es el mismo problema que un tiempo de espera agotado. Un 403 demuestra que el servidor respondió aunque la página sea inutilizable. Un 301 puede enviar discretamente a los usuarios desde una URL sana hacia un destino roto. En diagnóstico, la pregunta correcta no es “¿qué código es malo?”, sino “¿a qué etapa de la ruta de la solicitud llegamos realmente antes de que apareciera el problema?”.
Un código de estado significa que algo respondió
Si tienes un código HTTP real, la solicitud llegó a una capa capaz de devolver una respuesta HTTP. Eso ya descarta parte de los fallos de capas inferiores.
Las redirecciones merecen tanta atención como los errores
Un 301 o 302 puede mover a un usuario desde una URL sana hasta un destino final roto, así que la cadena importa tanto como el código final.
No tener código puede ser la pista más importante
Si la solicitud falló en DNS, conexión o TLS, la ausencia de un código HTTP dice más que cualquier respuesta del servidor.
01
Cómo encajan los códigos de estado en el diagnóstico
Piensa en los códigos de estado como evidencia de capa de aplicación, no como un veredicto completo de salud por sí solos.
2xx significa que la solicitud terminó correctamente
Suele demostrar que la URL respondió con normalidad desde este servidor, pero no garantiza que el contenido sea exactamente la experiencia que esperaba cada usuario.
3xx significa que la solicitud se está moviendo a otro sitio
En diagnóstico, las redirecciones importan porque el destino puede cambiar la confianza, el rendimiento o la disponibilidad.
4xx significa que el servidor entendió la solicitud, pero la rechazó o la limitó
Sigue siendo una respuesta real. Suele apuntar a políticas de acceso, problemas de ruta, limitación de frecuencia o requisitos de autenticación, no a un sitio muerto.
5xx significa que la ruta del servidor está lo bastante viva como para fallar a la vista
La solicitud llegó a una aplicación, gateway o dependencia upstream, pero la respuesta no fue sana.
02
Códigos habituales y cómo leerlos
Estos son los códigos que más suelen importar en una página pública de diagnóstico.
| Código | Significado habitual | Lectura diagnóstica |
|---|---|---|
| 200 | La solicitud se completó correctamente | La URL funcionó desde este servidor. Si los usuarios siguen quejándose, compara región, navegador, autenticación o comportamiento del lado del cliente. |
| 301 / 308 | Redirección permanente | Revisa con cuidado el destino final. La URL inicial puede estar bien mientras el destino está roto. |
| 302 / 307 | Redirección temporal | Resulta útil cuando el comportamiento cambia entre entornos o campañas porque el destino de la redirección puede depender del contexto. |
| 401 | Se requiere autenticación | El servidor está vivo, pero la solicitud no estaba autorizada. No es una caída pura. |
| 403 | Prohibido | La solicitud llegó a una política o a una regla de la aplicación y fue denegada. Suele deberse a WAF, permisos o restricciones por IP. |
| 404 | No encontrado | El host y la aplicación respondieron, pero la ruta no existía o estaba mal encaminada. |
| 429 | Demasiadas solicitudes | El sitio está vivo, pero hay limitación de frecuencia. El diagnóstico público puede activar este límite en algunos proveedores. |
| 500 | Error interno del servidor | La aplicación falló después de recibir la solicitud. |
| 502 | Bad gateway | Un proxy o borde no recibió una respuesta válida del servicio upstream. |
| 503 | Servicio no disponible | La aplicación o el borde están sobrecargados, en mantenimiento o intencionadamente no disponibles. |
| 504 | Gateway timeout | Una dependencia upstream fue demasiado lenta o no respondió y el gateway agotó el tiempo. |
03
Cuándo el código no es el problema de fondo
A veces el código es real, pero sigue sin ser la capa más importante que conviene investigar.
Las redirecciones pueden ocultar el punto real de fallo
Un 301 desde la URL original puede parecer inocuo hasta que el destino HTTPS final falla por confianza del certificado o por un host distinto.
Un 403 puede venir de una política de borde y no de la aplicación
Las reglas geográficas, la reputación IP, una política WAF o un filtro de bots pueden producir una respuesta aparentemente sana que aun así bloquea al usuario.
Un 5xx aún puede tener contexto DNS, SSL o de plataforma
Si la ruta pasa por varios hosts o proveedores de borde, los datos DNS y TLS que rodean el error pueden seguir explicando por qué el fallo aparece ahí.
04
Las mejores comprobaciones de seguimiento tras ver un código HTTP
Elige la página siguiente según el tipo de código que viste y la duda que todavía te queda.
Es la mejor opción cuando necesitas ver la cadena, la URL final, los encabezados y las fases de tiempo alrededor del código que apareció.
Comprobador webInspección de certificados y TLSUsa el Comprobador SSL tras redirecciones HTTPS sospechosasAyuda cuando una redirección termina en un host que puede tener problemas de certificado, nombre o TLS.
Comprobador SSLPistas de proveedor y bordeUsa el Comprobador de hosting cuando un 5xx parezca relacionado con la plataformaEs útil si los encabezados y los hosts sugieren un CDN, una plataforma gestionada o un comportamiento del borde del proveedor detrás del error.
Comprobador de hostingRespuestas DNS analizadasUsa Consulta DNS cuando los cambios de host formen parte de la historiaÁbrela si las redirecciones o las diferencias entre entornos sugieren que el tráfico puede estar llegando a una infraestructura distinta de la esperada.
Consulta DNS05
Errores frecuentes al leer códigos de estado
Estos atajos eliminan matices útiles del diagnóstico.
- Llamar “caída” a un 403 o a un 404 sin reconocer que el servidor respondió.
- Ignorar la cadena de redirecciones y fijarse solo en el código final.
- Tomar un 429 como prueba de que el sitio está roto en lugar de reconocer una limitación de frecuencia.
- Olvidar que no tener ningún código HTTP puede ser la pista más fuerte de que el fallo ocurrió por debajo de la capa de aplicación.