How to read curl verbose output
Verbose curl output is a protocol timeline, not noise. Learn its markers and follow one request from address selection through TLS and HTTP without leaking credentials into logs.
Reviewed by the Terminaster editorial team · Updated
What you will take away
- Lines beginning with an asterisk describe curl’s connection and transfer actions.
- Greater-than lines are data curl sends; less-than lines are data curl receives.
- Verbose output goes to standard error, separately from the response body on standard output.
- A successful TCP or TLS step does not prove the eventual HTTP response is successful.
Learn the three markers first
In a typical HTTP verbose trace, `*` lines are informational messages from curl, `>` lines show request headers sent to the server, and `<` lines show response headers received. The response body is not prefixed in the same way.
The trace follows time: name resolution and connection attempts come before TLS details, which come before the HTTP request and response. Find the last completed stage before the error rather than scanning for one alarming phrase.
- `*` — curl information about resolution, connection, TLS, and reuse.
- `>` — request line and request headers sent by curl.
- `<` — response status line and response headers returned.
- `{` and `}` can appear in detailed traces for received and sent data.
Create a trace without printing the body
curl -v --connect-timeout 5 --max-time 20 \
https://example.com/ -o /dev/nullFollow DNS, connect, and TLS in order
Note the destination address and port in each `Trying` line. A trace can attempt more than one address, so do not assume the first DNS answer became the successful connection.
For HTTPS, curl then reports TLS negotiation and certificate verification. Read the subject name, issuer, verification result, and negotiated protocol as evidence. Avoid copying a trace before checking it for tokens, cookies, client certificates, or internal names.
- 1Identify the resolved IPv4 and IPv6 addresses.
- 2Find the address whose connection completed.
- 3Confirm the destination port and any proxy tunnel.
- 4Read the TLS version, certificate verification result, and application protocol.
- 5Only then move to the request and response headers.
Read the HTTP exchange separately
The first `>` line contains the method and request target. The following lines include Host and other request headers. The first `<` line contains the HTTP version and status; response headers follow.
A 301 or 302 does not make curl follow the redirect unless you request that behavior with `-L`. With redirects enabled, the trace may contain multiple request and response blocks. Read each block as one hop.
Follow redirects and keep the trace visible
curl -vL --max-redirs 5 --connect-timeout 5 --max-time 20 \
https://example.com/ -o /dev/nullCapture diagnostics without mixing the body
Because verbose output uses standard error, redirect it separately when you need an artifact. Keep the response body and trace in distinct files, protect them appropriately, and remove sensitive captures when they are no longer needed.
Use `--trace-time` with `--trace-ascii` when ordering and timing are important, but remember that a full trace can expose more payload data than `-v`. Start with the smallest diagnostic output that answers the question.
Separate the response from diagnostics
umask 077
trace_dir=$(mktemp -d)
curl -v --connect-timeout 5 --max-time 20 https://example.com/ \
--output "$trace_dir/response.body" \
2> "$trace_dir/curl.verbose.log"
# Inspect locally and redact before sharing
wc -c "$trace_dir/response.body" "$trace_dir/curl.verbose.log"
# After inspection:
rm -r -- "$trace_dir"Common questions
Frequently asked questions
Why does curl -v output appear when stdout is redirected?
Verbose diagnostics are written to standard error, while the response body normally uses standard output. Redirect `2>` separately when you need to capture the diagnostics.
Does `Connected to` mean the HTTP request succeeded?
No. It means a transport connection was established. TLS, request transmission, HTTP status, response integrity, and application behavior can still fail afterward.
Why are there several request blocks in one curl trace?
Redirects, authentication negotiation, proxies, and retries can produce multiple exchanges. With `-L`, read each response status and Location header before the next request block.
Keep learning
Sources and next steps
Related mental models
HTTP requests with curl
curl is a command-line data-transfer client that uses a URL to select a protocol and exposes options for constructing requests, inspecting transfers, handling failures, and writing response data. For HTTP, its defaults and options map to request methods, fields, content, redirects, and authentication.
TLS and HTTPS
TLS establishes an integrity-protected, encrypted channel and can authenticate one or both peers. In ordinary HTTPS, the client authenticates the server name through certificate validation or another configured trust mechanism; client authentication is optional and application-dependent.
HTTP request and response
HTTP is a stateless application protocol in which a client sends a request containing a method, target, fields, and optional content, and a server returns a response containing a status code, fields, and optional content.