Debugging HTTP with curl: verbose output, timing breakdown and forcing the connection

Goal

Answer three questions with one tool and no browser: what did the server receive and return, how long did each phase take, and does one specific backend behave the same as the name resolves to?

Prerequisites

curl, the URL, and any headers or credentials the request needs. A safe method for production targets (-I for HEAD, or GET on read-only endpoints).

Steps

1. See the conversation: curl -v URL prints request and response headers and connection details on stderr; --trace-ascii - also dumps bodies, and --trace-time stamps each line. The manual warns that traces can contain credentials, so redact before sharing.
2. Separate headers from body: -D - writes response headers to stdout, -o /dev/null discards the body, -sS hides the progress meter but keeps error messages.
3. Locate the slow phase with -w (--write-out). The manual defines the timing variables as seconds from the start: time_namelookup (name resolution done), time_connect (TCP connected), time_appconnect (TLS handshake done), time_pretransfer, time_starttransfer (first byte received, which includes the server's processing time) and time_total. Example: 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. Subtract neighbouring values for per-phase durations and repeat several times, since the first run includes cold caches.
4. Target one server behind a load balancer, or test before a DNS change: --resolve host:port:addr supplies the address for that host and port (the manual calls it a command-line /etc/hosts), so SNI, certificate validation and the Host header stay correct. --connect-to HOST1:PORT1:HOST2:PORT2 redirects only the TCP connection and leaves the names used for TLS and the request unchanged.
5. Make failures visible in scripts: --fail-with-body returns exit code 22 on status 400 and above while still saving the body (-f discards it); --max-time bounds the whole operation; --retry N retries transient errors.
6. Pin what is being compared: --http1.1 or --http2 selects the protocol; --compressed requests a compressed response with the algorithms curl supports and decompresses it; --json sends a JSON body with the matching headers.

Expected result

A reproducible command whose output shows the exact request, the response status and headers, and a timing breakdown that points at DNS, TCP, TLS, server processing or transfer.

Limits and test basis

Option semantics follow the cited manual; several options list the curl version that introduced them, so check the installed version. Timings describe one client's view, including its own resolver cache and network path; they are not server-side measurements. No numbers are claimed.