curl
one request, fully visiblecurl sends a single request and, with -v, narrates each layer on the way: the address chosen, the TCP connection, the TLS negotiation and certificate, then the request and response headers. It is a browser with nothing hidden — no cache, no cookies, no retries unless you ask.
A page that will not load has failed at one particular layer — and curl -v says which.
At the terminal
Read the session first, then the notes: each numbered line in the output is answered by the note with the same number.
What the numbered lines are telling you
The name was resolved before this line. "Trying" is the TCP connection attempt; a hang here is a routing or firewall problem.
SYN, SYN-ACK, ACK all succeeded. From here down, any failure is above the transport layer.
TLS 1.3 with an AEAD cipher. An old version here is a server that needs attention.
Name, validity dates and issuer all checked out. A failure stops the request before any HTTP is sent.
The request line and headers, exactly as they went out. This is where to confirm a header or token is really being sent.
The status first, then the response headers. The body follows after a blank line.
Switches
A switch changes how the command behaves. These are the ones used day to day; man curl lists the rest. Single-letter switches can usually be joined, so -l -a may be written -la.
-I- Fetch the response headers only, with a HEAD request.
-v- Verbose: show the connection, the TLS handshake and every header sent and received.
-L- Follow redirects to the final location.
-o FILE- Save the response to this file. -O uses the name from the URL.
-s- Silent: no progress meter. Add -S to still show errors.
-H "NAME: VALUE"- Add a request header.
-X METHOD- Use this request method: POST, PUT, DELETE.
-d DATA- Send this data as the request body — makes the request a POST.
-k- Skip certificate verification. For testing only.
Variations worth knowing
The same tool, pointed at a narrower question. These four cover most of what it is reached for day to day.
curl -sI https://example.comResponse headers only, with the progress meter silenced.
curl -L -o page.html https://example.comFollows redirects and saves the body to a file.
curl --resolve example.com:443:192.0.2.20 https://example.comSends the request to a specific address while keeping the right hostname and certificate check — testing one server behind a load balancer.
curl -w "%{time_connect} %{time_starttransfer}\n" -so /dev/null https://example.comPrints how long the connection and the first byte took, and nothing else.
In cybersecurity
curl runs wherever a shell does, which makes it both the standard test tool and the standard download tool for attackers. Its flags can also quietly switch off the protection TLS provides.
--insecure skips certificate verification, so the request can be intercepted by anyone on the path. It does not belong in a script.
"curl … | sh" runs whatever the server sends at that moment. Download, read, then run.
A password in -u or in the URL lands in shell history and in the process list. Use a netrc file or a prompt.
An application that fetches a user-supplied URL can be pointed at internal addresses. curl is how that is demonstrated.
Missing Strict-Transport-Security or a permissive CORS header shows up in one -I request.
An outbound POST from a server that has no reason to make one is worth an alert.