Comprobador de cabeceras HTTP y redirecciones

Siga una URL salto a salto y lea lo que devuelve: cada redirección de la cadena, el código de estado con el que responde al final y las cabeceras que envía. El mismo recorrido que hace una comprobación de disponibilidad, sin la caché, las cookies ni el servidor de borde de su navegador de por medio.

GET desde nuestra sonda · hasta 10 saltos · solo cabeceras, nunca el cuerpo · nada se guarda

Introduzca una URL para recorrer su cadena.

Qué significa cada código de redirección

El número no es decoración. Le dice a un cliente si debe recordar la nueva dirección y si el método de la petición sobrevive al salto, y equivocarse aquí es la forma en que un formulario que funcionaba empieza a perder datos.

código	guardado en caché por los clientes	el método se conserva	úselo para
301 Moved Permanently	sí, de forma agresiva	no, POST suele convertirse en GET	Una dirección que no va a volver. Difícil de deshacer: los navegadores la conservan.
302 Found	no	no, POST suele convertirse en GET	Un traslado temporal. El que emiten por defecto la mayoría de los frameworks, y el seguro mientras aún lo está decidiendo.
303 See Other	no	no, siempre se convierte en GET	Tras enviar un formulario, para que una recarga no lo envíe dos veces.
307 Temporary Redirect	no	sí	Un traslado temporal en el que un POST debe seguir siendo un POST.
308 Permanent Redirect	sí	sí	Un traslado permanente para una API, donde convertir un POST en GET rompería a quienes la llaman.

Por qué merece la pena leer la cadena

¿Ve ERR_TOO_MANY_REDIRECTS? Siga cómo depurar un bucle de redirecciones, salto a salto para rastrear las respuestas y encontrar la regla de la aplicación o del proxy que devuelve la petición.

Un monitor registra la respuesta al final del recorrido, así que una cadena que funciona es invisible y una que se rompe parece una caída del sitio. Ahí se esconden dos fallos: un bucle, en el que una CDN fuerza HTTPS mientras el servidor de origen devuelve HTTPS a HTTP, y un salto que abandona sin avisar el host con el que empezó, lo que descarta por el camino las cookies y las cabeceras de autorización.

La longitud también cuesta. Cada salto es una conexión nueva, una consulta DNS nueva y, en HTTPS, un handshake nuevo. Tres redirecciones delante de una página de inicio suponen casi un segundo antes del primer byte de contenido real, y lo paga cada visitante y cada comprobación.

Este comprobador valida el certificado en cada salto, igual que un monitor, así que un fallo de TLS aquí es real. Cuando necesite leer un certificado ya caducado o autofirmado, el comprobador de certificados SSL lo lee sin validarlo. Si el problema es el propio nombre, la consulta DNS compara dos resolvedores, y qué demuestran ICMP, TCP y HTTP explica en qué capa está realmente un fallo. Para evaluar a la vez el certificado, las redirecciones HTTPS y las cabeceras de seguridad, use el comprobador de seguridad web.

Preguntas frecuentes

¿Qué causa ERR_TOO_MANY_REDIRECTS?

Dos reglas que creen, cada una, que la otra debería haber terminado el trabajo. La pareja clásica es una CDN que fuerza HTTPS mientras el servidor de origen redirige HTTPS de vuelta a HTTP, de modo que la cadena rebota entre ambos sin fin. La lista de saltos de arriba muestra el ciclo: busque la misma URL dos veces.

¿Qué códigos de redirección conservan el método de la petición?

307 y 308 lo conservan, así que un POST sigue siendo un POST. 301 y 302 no lo garantizan, y en la práctica casi todos los clientes los convierten en GET. 303 siempre se convierte en GET. Si el envío de un formulario deja de funcionar justo después de añadir una redirección, suele ser por esto.

¿Por qué mi navegador muestra algo distinto?

Un navegador responde desde su propia caché, envía sus cookies y puede que le hayan asignado un servidor de borde distinto del nuestro. La primera petición de una sesión es la honesta, y es la que hace esta comprobación: sin cookies, sin caché y con una conexión nueva cada vez.

La comprobación falla aquí, pero el sitio me carga. ¿Por qué?

Normalmente es el certificado. Este comprobador valida la cadena como lo hace un monitor, así que un certificado caducado o un intermedio que falta fallan directamente, mientras que su navegador puede disimularlo gracias a la caché. El comprobador de certificados SSL lee el certificado sin validarlo, y es la herramienta para ese caso.

¿Debe un monitor de disponibilidad seguir las redirecciones?

Sígalas cuando vigile si la gente puede llegar al sitio, porque ese es el recorrido que hace. Desactívelas cuando vigile un endpoint concreto y una redirección signifique que algo ha cambiado: una ruta de API que empieza a responder 302 es un incidente, no un éxito.

¿Qué cabeceras de respuesta importan para la disponibilidad?

Primero el código de estado, y después todo lo que explique uno malo: Retry-After en un 429 o un 503, las cabeceras de caché y de borde que dicen si respondió una CDN en lugar de su servidor de origen, y Location en una redirección. Las cabeceras de seguridad como HSTS no afectan a la disponibilidad, pero la cadena que las establece a menudo sí.

Vigile la cadena, no solo la página de inicio

Una comprobación HTTP recorre estos saltos cada minuto desde cada región que active, y le avisa cuando cambia el estado al final de ellos.

empezar gratis

más herramientas gratuitas: calculadora de SLA · generador de cron · calculadora de presupuesto de errores · generador de avisos de incidentes · consulta DNS · comprobador de certificados SSL · comprobador de caducidad de dominios · comprobador de seguridad web · todas las herramientas