Déboguer HTTP avec curl : sortie détaillée, décomposition des temps et forçage de la connexion

Objectif

Répondre à trois questions avec un seul outil et sans navigateur : qu'est-ce que le serveur a reçu et renvoyé, combien de temps a pris chaque phase, et un backend précis se comporte-t-il comme le nom résolu le laisse penser ?

Prérequis

curl, l'URL, et tous les en-têtes ou identifiants dont la requête a besoin. Une méthode sûre pour des cibles de production (-I pour HEAD, ou GET sur des points d'accès en lecture seule).

Étapes

1. Voir la conversation : curl -v URL affiche les en-têtes de requête et de réponse ainsi que les détails de connexion sur stderr ; --trace-ascii - déverse aussi les corps, et --trace-time horodate chaque ligne. Le manuel avertit que les traces peuvent contenir des identifiants, donc les expurger avant de les partager.
2. Séparer les en-têtes du corps : -D - écrit les en-têtes de réponse sur stdout, -o /dev/null élimine le corps, -sS masque l'indicateur de progression tout en conservant les messages d'erreur.
3. Localiser la phase lente avec -w (--write-out). Le manuel définit les variables de temps comme des secondes depuis le début : time_namelookup (résolution de nom terminée), time_connect (TCP connecté), time_appconnect (poignée de main TLS terminée), time_pretransfer, time_starttransfer (premier octet reçu, ce qui inclut le temps de traitement du serveur) et time_total. Exemple : 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. Soustraire les valeurs voisines pour obtenir les durées par phase et répéter l'opération plusieurs fois, car la première exécution inclut des caches froids.
4. Cibler un serveur précis derrière un répartiteur de charge, ou tester avant un changement DNS : --resolve host:port:addr fournit l'adresse pour cet hôte et ce port (le manuel l'appelle un /etc/hosts en ligne de commande), de sorte que SNI, la validation du certificat et l'en-tête Host restent corrects. --connect-to HOST1:PORT1:HOST2:PORT2 ne redirige que la connexion TCP et laisse inchangés les noms utilisés pour le TLS et la requête.
5. Rendre les échecs visibles dans les scripts : --fail-with-body renvoie le code de sortie 22 pour un statut 400 ou plus tout en conservant le corps (-f l'élimine) ; --max-time borne l'opération entière ; --retry N réessaie les erreurs transitoires.
6. Fixer ce qui est comparé : --http1.1 ou --http2 choisit le protocole ; --compressed demande une réponse compressée avec les algorithmes que curl prend en charge et la décompresse ; --json envoie un corps JSON avec les en-têtes correspondants.

Résultat attendu

Une commande reproductible dont la sortie montre la requête exacte, le statut et les en-têtes de la réponse, et une décomposition des temps qui pointe vers le DNS, le TCP, le TLS, le traitement serveur ou le transfert.

Limites et base de vérification

La sémantique des options suit le manuel cité ; plusieurs options indiquent la version de curl qui les a introduites, donc vérifier la version installée. Les temps décrivent le point de vue d'un client, y compris son propre cache de résolveur et son propre chemin réseau ; ce ne sont pas des mesures côté serveur. Aucun chiffre n'est avancé.