Depuración de HTTP con curl: salida detallada, desglose de tiempos y conexión forzada a un servidor

Objetivo

Responder tres preguntas con una sola herramienta y sin navegador: qué recibió y qué devolvió el servidor, cuánto tardó cada fase y si un backend concreto se comporta igual que aquel al que apunta la resolución del nombre.

Requisitos previos

curl, la URL y las cabeceras o credenciales que necesite la petición. Un método seguro para destinos de producción (-I para HEAD, o GET en endpoints de solo lectura).

Pasos

1. Ver la conversación: curl -v URL muestra por stderr las cabeceras de la petición y de la respuesta, además de los detalles de la conexión; --trace-ascii - vuelca también los cuerpos y --trace-time añade una marca de tiempo a cada línea. El manual advierte de que las trazas pueden contener credenciales, así que hay que censurarlas antes de compartirlas.
2. Separar las cabeceras del cuerpo: -D - escribe las cabeceras de la respuesta en stdout, -o /dev/null descarta el cuerpo y -sS oculta el indicador de progreso pero conserva los mensajes de error.
3. Localizar la fase lenta con -w (--write-out). El manual define las variables de tiempo como segundos transcurridos desde el inicio: time_namelookup (resolución de nombre terminada), time_connect (conexión TCP establecida), time_appconnect (handshake TLS terminado), time_pretransfer, time_starttransfer (primer byte recibido, que incluye el tiempo de procesamiento del servidor) y time_total. Ejemplo: curl -sS -o /dev/null -w 'dns %{time_namelookup} tcp %{time_connect} tls %{time_appconnect} ttfb %{time_starttransfer} total %{time_total} code %{response_code}\n' URL. Restando valores contiguos se obtiene la duración de cada fase; conviene repetir la medición varias veces, porque la primera ejecución incluye cachés en frío.
4. Apuntar a un servidor concreto detrás de un balanceador de carga, o probar antes de un cambio de DNS: --resolve host:port:addr proporciona la dirección para ese host y puerto (el manual lo describe como un /etc/hosts en la línea de comandos), de modo que SNI, la validación del certificado y la cabecera Host siguen siendo correctos. --connect-to HOST1:PORT1:HOST2:PORT2 redirige únicamente la conexión TCP y deja intactos los nombres usados para TLS y para la petición.
5. Hacer visibles los fallos en scripts: --fail-with-body devuelve el código de salida 22 con estados 400 y superiores y aun así guarda el cuerpo (-f lo descarta); --max-time limita la duración de toda la operación; --retry N reintenta ante errores transitorios.
6. Fijar lo que se compara: --http1.1 o --http2 selecciona el protocolo; --compressed solicita una respuesta comprimida con los algoritmos que curl admite y la descomprime; --json envía un cuerpo JSON con las cabeceras correspondientes.

Resultado esperado

Un comando reproducible cuya salida muestra la petición exacta, el estado y las cabeceras de la respuesta, y un desglose de tiempos que señala si el problema está en DNS, TCP, TLS, el procesamiento del servidor o la transferencia.

Límites y base de verificación

La semántica de las opciones sigue el manual citado; varias opciones indican la versión de curl en la que se introdujeron, por lo que conviene comprobar la versión instalada. Los tiempos reflejan la perspectiva de un único cliente, con su propia caché del resolvedor y su ruta de red; no son mediciones del lado del servidor. No se afirma ninguna cifra.