Systems troubleshooting guide9 min read

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/null

Follow 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.

  1. 1Identify the resolved IPv4 and IPv6 addresses.
  2. 2Find the address whose connection completed.
  3. 3Confirm the destination port and any proxy tunnel.
  4. 4Read the TLS version, certificate verification result, and application protocol.
  5. 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/null

Capture 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