Inspect a request with verbose output

A single curl command hides a lot of work: a DNS lookup, a TCP connection, a TLS handshake, a request, a response. When something misbehaves, you need to see which of those stages went wrong. Verbose mode exposes all of them.

Inspect one HTTPS request:

curl -v https://example.org/ -o /dev/null

The body is discarded with -o /dev/null for a cleaner trace, so everything left on screen is diagnostics.

Read the prefixes

Every verbose line starts with a marker that tells you who said what. Lines beginning with > are sent headers, lines beginning with < are received headers, and lines beginning with * describe curl events like name resolution and TLS negotiation.

* Host example.org:443 was resolved.
* Connected to example.org port 443
* SSL connection using TLSv1.3
> GET / HTTP/2
> Host: example.org
> User-Agent: curl/8.7.1
< HTTP/2 200
< content-type: text/html

Follow the order: address resolution, connection, TLS negotiation, request, response, then connection reuse or closure. That sequence is your debugging map. A failure during the * lines is a network or TLS problem and never reached the server. A > request followed by an unexpected < status means the server received you and disagreed.

Use it to answer real questions

Verbose output settles arguments that guessing cannot. Did curl actually send the header you added? Look for it in the > lines. Which protocol version was negotiated? It is in the * and > lines. Is the connection being reused across requests? Run two URLs in one command and look for a Re-using existing connection event.

Redact before you share

Verbose output can expose authorization headers, cookies, and other secrets, because it prints every header exactly as sent. Before pasting a trace into a ticket, chat, or blog post, redact those values. The habit matters: the whole point of -v is that nothing is hidden, and that includes things that should stay hidden from other people.