Un pequeño kit de herramientas para depurar redirecciones y encabezados HTTP en producción

El problema de depurar HTTP en producción

La mayoría de los problemas HTTP son invisibles en el navegador. Una cadena de redirecciones falla en silencio, un encabezado de caché tiene un carácter incorrecto, una política CORS bloquea una solicitud sin explicación. Las herramientas de desarrollo del navegador te muestran el resultado de la conversación, pero a menudo ocultan el intercambio sin procesar que causó el problema.

Esto importa sobre todo en producción, donde no puedes añadir registros ni reiniciar servicios para ver qué cambió. Necesitas herramientas que te muestren la conversación HTTP real: encabezados de solicitud, encabezados de respuesta, códigos de estado, destinos de redirección, tiempos. Estas son las cinco herramientas que hacen ese trabajo de forma fiable, más las técnicas del navegador que las complementan.

curl: la base

curl es la primera herramienta a la que recurrir porque te muestra exactamente lo que envió el servidor, sin interpretación del navegador de por medio.

Para ver los encabezados de respuesta sin el cuerpo:

curl -I https://example.com

Para seguir redirecciones y ver cada paso:

curl -L -v https://example.com

La opción -v (verbose) muestra la solicitud y la respuesta completas, incluidos todos los encabezados. La opción -L sigue redirecciones automáticamente. Juntas, te muestran toda la cadena de redirecciones, que es donde viven la mayoría de los problemas en producción.

Para ver solo las ubicaciones de redirección:

curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" -L https://example.com

Esto es útil cuando necesitas verificar una cadena de redirecciones sin el ruido de los encabezados completos. La opción -w da formato a la salida para mostrar solo el código de estado y la siguiente URL de la cadena.

curl también te permite enviar encabezados personalizados, algo esencial para probar el comportamiento de CDN, la autenticación o endpoints de API:

curl -H "Authorization: Bearer token" -H "Accept: application/json" https://api.example.com

httpie: curl con mejores valores predeterminados

httpie es una herramienta de Python que hace lo que hace curl, pero con una sintaxis más fácil de recordar y una salida más fácil de leer. No es un reemplazo —curl es más potente y está instalado en más lugares—, pero para comprobaciones rápidas, httpie es más ágil.

Para ver encabezados:

http HEAD https://example.com

Para seguir redirecciones:

http --follow --all https://example.com

La opción --all muestra cada respuesta de la cadena de redirecciones, no solo la final. Es el equivalente de curl -L -v, pero la salida está codificada por colores y es más fácil de revisar.

Para enviar JSON:

http POST https://api.example.com name=value

httpie asume JSON de forma predeterminada, lo que ahorra escritura cuando estás probando APIs. También formatea la respuesta, lo que facilita detectar encabezados mal formados o valores inesperados.

Browser DevTools: pestaña Network

La pestaña Network del navegador es donde deberías empezar si el problema solo ocurre en el navegador. Te muestra la misma información que curl, pero también te muestra la interpretación del navegador: si bloqueó una solicitud, cómo gestionó la caché, si envió cookies.

Para ver los encabezados completos de solicitud y respuesta, haz clic en cualquier solicitud en la pestaña Network y luego mira la sección Headers. La vista "Raw" muestra los encabezados exactamente como se enviaron, sin formato.

Para ver cadenas de redirecciones, busca solicitudes con códigos de estado 3xx. El navegador las agrupa bajo la solicitud final, pero puedes expandirlas para ver cada paso. Ahí encontrarás bucles de redirección, encabezados Location ausentes o redirecciones que apuntan al dominio equivocado.

Para ver los tiempos, mira la pestaña Timing de cualquier solicitud. Esto te muestra cuánto tiempo pasó el navegador en la búsqueda DNS, la conexión TCP, el handshake TLS y la espera del servidor. Si una redirección es lenta, la pestaña de tiempos te dice si el problema es latencia de red o procesamiento del servidor.

Una limitación: el navegador oculta algunos encabezados por motivos de seguridad. Los encabezados Set-Cookie son visibles, pero los valores reales de las cookies se redactan. A veces los encabezados Authorization se ocultan por completo. Si necesitas verlos, usa curl.

mitmproxy: el proxy de interceptación

mitmproxy es una herramienta de Python que se sitúa entre tu navegador y el servidor, y te muestra cada solicitud y respuesta en tiempo real. Es más compleja que curl, pero es la única herramienta que te muestra lo que el navegador realmente envía, incluidos los encabezados que el navegador añade automáticamente.

Para iniciarla:

mitmproxy

Luego configura tu navegador para usar localhost:8080 como proxy HTTP. mitmproxy te mostrará cada solicitud en una interfaz de terminal. Puedes inspeccionar encabezados, editar solicitudes antes de que se envíen o reproducir solicitudes con parámetros distintos.

Esto es útil para depurar problemas que solo ocurren en el navegador: solicitudes preflight de CORS, gestión de cookies o solicitudes que fallan cuando ciertos encabezados están presentes. También es útil para probar cómo se comporta tu sitio detrás de un proxy corporativo o una VPN, porque mitmproxy puede simular esos entornos.

La desventaja es la complejidad de configuración. Necesitas instalar un certificado raíz para que mitmproxy pueda interceptar tráfico HTTPS, y necesitas configurar tu navegador para usar el proxy. Para comprobaciones rápidas, curl es más rápido. Para depuración profunda, mitmproxy merece el tiempo de configuración.

webpagetest: perspectiva de producción

WebPageTest es un servicio gratuito que carga tu página desde navegadores reales en distintas ubicaciones y te muestra la conversación HTTP completa. Es más lento que curl, pero te muestra lo que experimentan los usuarios reales, incluido el comportamiento de CDN, la resolución DNS y la negociación TLS.

Las vistas "Request Headers" y "Response Headers" te muestran exactamente lo que el navegador envió y recibió. La vista "Waterfall" te muestra los tiempos de cada solicitud, incluidas las redirecciones. Ahí encontrarás problemas que solo ocurren en ciertas regiones o en ciertas redes.

WebPageTest también te muestra la cadena de redirecciones del documento principal, que es donde viven la mayoría de los problemas de redirección. Si tu sitio redirige de http:// a https://, luego de www. a sin www., y después de / a /en/, WebPageTest te muestra los tres pasos y cuánto tardó cada uno.

Para herramientas que te ayudan a validar y optimizar estos fundamentos de HTTP, Wux Webtools ofrece varias utilidades que se ejecutan por completo en tu navegador, incluidos analizadores de encabezados y comprobadores de redirecciones que respetan tu privacidad al procesarlo todo del lado del cliente.

Cuando los encabezados mienten

Los problemas HTTP más difíciles son aquellos en los que el servidor envía encabezados contradictorios. Un encabezado Cache-Control dice no-cache, pero un encabezado Expires dice que el recurso es válido durante un año. Un encabezado Location apunta a una URL relativa, pero el encabezado Content-Location apunta a otro sitio. El navegador tiene que adivinar en cuál confiar, y distintos navegadores adivinan de forma distinta.

Cuando esto ocurre, necesitas ver los encabezados sin procesar en el orden en que el servidor los envió. curl -v hace esto. mitmproxy también. Las DevTools del navegador a veces reordenan los encabezados para mejorar la legibilidad, lo que oculta el problema.

Otro problema común: encabezados que añade una CDN o un balanceador de carga, no tu aplicación. Si estás depurando un problema de caché, necesitas saber si el encabezado Cache-Control vino de tu app o de la CDN. curl te muestra el resultado final, pero no te dice de dónde salió cada encabezado. Para eso, necesitas evitar la CDN (accediendo directamente al servidor de origen) y comparar los encabezados.

El problema del bucle de redirección

Los bucles de redirección son el problema HTTP más común en producción. Ocurren cuando dos servidores no están de acuerdo sobre a dónde debe apuntar una URL: la CDN redirige al origen, el origen redirige de vuelta a la CDN. O el balanceador de carga redirige HTTP a HTTPS, pero la app redirige HTTPS de vuelta a HTTP porque no ve el encabezado X-Forwarded-Proto.

Para depurarlo, necesitas ver la cadena de redirecciones completa, incluido el encabezado Location en cada paso. curl -L -v hace esto, pero se detiene después de 50 redirecciones para evitar bucles infinitos. Si estás llegando a ese límite, tienes un bucle de redirección.

La solución suele ser un cambio de configuración: indicar a la app que confíe en el encabezado X-Forwarded-Proto, o indicar a la CDN que deje de redirigir solicitudes que ya son HTTPS. Pero no puedes arreglarlo hasta que veas el bucle, y el navegador no te mostrará más que unas pocas redirecciones antes de rendirse.

Qué comprobar primero

Cuando algo se rompe en producción, comprueba esto en orden:

1. Código de estado: ¿Es el que esperabas? Un 301 es permanente, un 302 es temporal, un 307 conserva el método HTTP. Si estás viendo el código equivocado, el problema está en tu configuración de redirecciones.

1. Encabezado Location: ¿Apunta al lugar correcto? ¿Es una URL absoluta o relativa? Las URL relativas se resuelven contra la URL actual, lo que puede producir resultados inesperados si la URL base no es la que crees.

1. Encabezados de caché: ¿El navegador está almacenando la redirección en caché? Una redirección 301 se almacena en caché de forma predeterminada, lo que significa que una redirección mal configurada puede romper tu sitio durante horas incluso después de corregirla. Revisa los encabezados Cache-Control y Expires para ver durante cuánto tiempo recordará el navegador la redirección.

1. Encabezados CORS: Si la solicitud es cross-origin, ¿el servidor envía el encabezado Access-Control-Allow-Origin correcto? Si no, el navegador bloqueará la solicitud y verás un error CORS en la consola. Los encabezados de respuesta del servidor son el único lugar donde corregirlo: no puedes evitarlo en el navegador.

1. Tiempos: ¿Cuánto tardó la solicitud? Si es lenta, ¿es latencia de red o procesamiento del servidor? Las DevTools del navegador y WebPageTest muestran desgloses de tiempos que te indican dónde se fue el tiempo.

Para profundizar en cómo ha cambiado el comportamiento del navegador en torno a la privacidad y los encabezados, consulta qué cambió para las cookies en 2026 y qué hacer al respecto, que cubre las implicaciones de encabezados y consentimiento de las actualizaciones recientes de los navegadores.

Puntos clave

• curl -L -v te muestra la cadena de redirecciones completa y todos los encabezados, sin interpretación del navegador
• La pestaña Network del navegador te muestra lo que el navegador hizo con la respuesta, incluidas las decisiones de caché y CORS
• mitmproxy te muestra lo que el navegador envió, incluidos los encabezados que el navegador añade automáticamente
• WebPageTest te muestra lo que experimentan los usuarios reales, incluido el comportamiento de CDN y las diferencias regionales
• Los bucles de redirección y los encabezados contradictorios son los problemas de producción más comunes, y son invisibles sin inspección HTTP sin procesar

FAQ

Q: ¿Por qué curl muestra encabezados distintos a los del navegador?

A: Porque el navegador añade encabezados automáticamente (User-Agent, Accept, Cookie) y sigue sus propias reglas de caché y CORS. curl envía solo lo que le indicas que envíe. Para ver lo que el navegador realmente envía, usa mitmproxy o las DevTools del navegador.

Q: ¿Cómo depuro una redirección que solo ocurre para algunos usuarios?

A: Comprueba si la redirección depende de los encabezados que envía el usuario: User-Agent, Accept-Language, Cookie o dirección IP (mediante X-Forwarded-For). Usa curl para enviar los mismos encabezados que envió el usuario, o usa WebPageTest para cargar la página desde la ubicación del usuario.

Q: ¿Cuál es la diferencia entre las redirecciones 301 y 302?

A: Un 301 es permanente y le indica al navegador que almacene la redirección en caché (a veces para siempre). Un 302 es temporal y le indica al navegador que no la almacene en caché. Si no tienes claro cuál usar, usa 302; siempre puedes cambiarlo a 301 más adelante.

Q: ¿Por qué mi redirección funciona en curl pero no en el navegador?

A: Probablemente porque el navegador está almacenando en caché una redirección antigua, o porque el navegador está bloqueando la redirección debido a reglas de CORS o de contenido mixto. Revisa la consola de DevTools del navegador en busca de errores, y revisa los encabezados Cache-Control para ver si el navegador está usando una respuesta en caché.

Q: ¿Cómo veo los encabezados que añade una CDN?

A: Usa curl para acceder a la URL de la CDN y luego usa curl de nuevo para acceder directamente al servidor de origen (evitando la CDN). Compara los encabezados. Los que solo aparecen en la primera respuesta vinieron de la CDN.

<!-- tool-cta:start -->

💡 Prueba esto: Al investigar problemas de redirección, Redirect Checker rastrea toda la cadena y muestra los códigos de estado y los encabezados en cada salto.

<!-- tool-cta:end -->

Fuentes

• documentación de curl — Referencia oficial de las opciones de línea de comandos y el comportamiento de curl
• documentación de HTTPie — Guía de la sintaxis y funciones de httpie
• MDN Web Docs: HTTP redirections — Explicación completa de los códigos de estado de redirección HTTP y su comportamiento
• documentación de WebPageTest — Cómo interpretar los resultados y encabezados de WebPageTest