Before the request

Typing a URL and pressing Enter does not send an HTTP request right away. Several layers run first.

DNS translates a hostname like flaviocopes.com into an IP address the network can route to. Without that lookup, the client has nowhere to connect.

Next the browser opens a transport connection. HTTP/1.1 and HTTP/2 ride on TCP. The client and server complete a TCP handshake before any HTTP bytes flow.

For HTTPS, a TLS handshake runs on top of TCP. The connection gets encrypted, and the client checks that the certificate matches the hostname you typed.

Only after those steps does the browser send the first HTTP request.

The sequence sounds slow, but browsers cache DNS answers, reuse open connections, and negotiate modern protocols. A repeat visit to the same site often skips most of the work.

When something breaks, I split the problem by layer:

• DNS answers where the host lives.
• TCP carries raw bytes between endpoints.
• TLS protects those bytes and proves server identity.
• HTTP defines the messages on top.

A DNS failure looks like “server not found” before HTTP even starts. A TLS failure shows a certificate warning. An HTTP failure returns a status code after the connection succeeds.

Check DNS from your terminal:

dig +short flaviocopes.com A

You should get one or more IP addresses back. If that command fails, no amount of HTTP debugging on your app will help until DNS is fixed.

Add -v to curl to watch the full stack:

curl -v -o /dev/null https://flaviocopes.com/

You will see DNS resolution, TLS negotiation, then the HTTP request and response. That verbose log is my first stop when a site loads in the browser but fails from a script.

Try this on your own project: run dig on your production hostname, then curl -v against the same URL. Note how much happens before the status line appears.