HTTP 200 OK: qué significa

Qué significa este error y cómo reconocerlo

• Un navegador, cliente de API, monitor de disponibilidad o comprobador HTTP informa de 200 OK.
• La solicitud recibe un cuerpo de respuesta en lugar de un fallo a nivel HTTP.
• La página puede cargarse normalmente o mostrar contenido inesperado a pesar del estado correcto.
• La misma URL puede devolver resultados diferentes según el método, el estado de autenticación, las cabeceras o el cliente.
• Las cabeceras de respuesta pueden revelar información sobre la caché, la autenticación, el proxy, el servidor o el tipo de contenido.
• La resolución DNS y la negociación TLS también pueden haber finalizado correctamente, pero son comprobaciones independientes del estado HTTP.

Causas principales, ordenadas por probabilidad

HTTP 200 normalmente es la respuesta prevista cuando una ruta gestiona correctamente una solicitud. Si resulta inesperado, las explicaciones más probables incluyen:

1. La ruta funciona según la configuración. Es posible que la URL y el método estén destinados a devolver una respuesta correcta.
2. Se comprobó una URL o un método incorrectos. Un comprobador puede estar solicitando otra ruta o utilizando GET, HEAD, POST u otro método distinto del que se está investigando.
3. El cuerpo de la respuesta es incorrecto aunque el estado sea correcto. La lógica de la aplicación, el enrutamiento o los cambios en el despliegue pueden devolver contenido incorrecto con un estado 200.
4. Una caché o un intermediario generó la respuesta. Una CDN, un proxy inverso, un servidor web o un WAF puede servir la respuesta antes de que la solicitud llegue a la aplicación.
5. La autenticación o el contexto del cliente cambiaron el resultado. Las cookies, las cabeceras de autorización y otros detalles de la solicitud pueden afectar a lo que devuelve la aplicación.
6. Las expectativas de monitorización son incorrectas. Un comprobador puede esperar una redirección, una respuesta de autorización, una respuesta de eliminación u otro estado para una ruta cuyo comportamiento configurado es realmente 200.

Cómo solucionarlo

Primero, decide si realmente hay un problema

HTTP 200 OK normalmente no requiere ninguna corrección. Determina qué debía hacer la solicitud y compara esa expectativa con la respuesta completa, no solo con el código de estado.

Para visitantes

1. Confirma la URL exacta, incluida la ruta y los parámetros de consulta.
2. Vuelve a intentarlo una vez si el resultado pudo verse afectado por un problema temporal del cliente o de la conexión.
3. Si la ruta requiere una cuenta, inicia sesión mediante la interfaz normal del sitio en lugar de compartir credenciales con quien esté ayudando a resolver el problema.
4. Comprueba si la página o los datos devueltos son realmente el contenido esperado. Un estado correcto no garantiza que el contenido sea correcto.
5. Si el resultado inesperado persiste, envía al propietario del sitio la URL, la hora aproximada, el contexto del dispositivo o cliente y una descripción de la respuesta. No envíes contraseñas, cookies, cabeceras de autorización ni secretos de API.

Para propietarios de sitios y desarrolladores

1. Captura la solicitud completa. Registra el método HTTP, la URL exacta, las cabeceras de solicitud relevantes, el estado, las cabeceras de respuesta y una muestra segura del cuerpo de la respuesta. Redacta las credenciales, las cookies y los datos personales.
2. Compara el comportamiento esperado con el real. Comprueba si esta ruta y este método deberían devolver 200, y si el cuerpo, el tipo de contenido, el estado de autenticación y el comportamiento de la caché coinciden con esa expectativa.
3. Identifica la capa que produce la respuesta. Determina si la respuesta provino de la CDN, el WAF, el proxy inverso, el servidor web o la aplicación. Las cabeceras, los identificadores de solicitud y los logs pueden ayudar a establecerlo.
4. Relaciona la solicitud con los logs. Busca en la capa responsable usando la marca de tiempo, la ruta, el método y el ID de solicitud cuando esté disponible. Después inspecciona la siguiente capa solo si la solicitud fue reenviada.
5. Revisa los cambios recientes. Compara los despliegues y los cambios en el enrutamiento, la autenticación, la caché, las reglas del proxy y los controladores de la aplicación.
6. Aplica la corrección autorizada más pequeña. Cambia únicamente la configuración o el comportamiento de la aplicación que explique el resultado. Evita cambios generales en permisos, seguridad o caché sin un plan de reversión probado.
7. Vuelve a probar la misma solicitud. Confirma el estado, las cabeceras y el cuerpo; después prueba las rutas y los métodos relacionados para asegurarte de que la corrección no introduce un nuevo problema de enrutamiento o acceso.

Si la respuesta 200 es un problema de monitorización

Comprueba la URL, el método, el tratamiento de redirecciones, el contexto de autenticación y los criterios de éxito del monitor. Actualiza la comprobación únicamente cuando el comportamiento documentado de la ruta sea intencionado; de lo contrario, investiga el componente que devuelve la respuesta inesperada.

Prevención y cómo verificar la solución

• Define el estado, el cuerpo y el comportamiento de autenticación previstos para las rutas web y los métodos de API importantes.
• Monitoriza los códigos de estado junto con el contenido de la respuesta, las cabeceras y la latencia cuando corresponda.
• Prueba URL y métodos representativos después de realizar cambios en la aplicación, el enrutamiento, el proxy, la CDN o la autenticación.
• Mantén bajo control de versiones las reglas de enrutamiento, caché e intermediarios, y documenta las excepciones intencionadas.
• Conserva los identificadores de solicitud y los logs depurados durante el tiempo suficiente para relacionar una solicitud del cliente con la capa que la gestionó.
• Haz que las comprobaciones de monitorización especifiquen claramente la URL, el método, el tratamiento de redirecciones, el contexto de autenticación y los criterios de éxito.

Preguntas frecuentes