What Actually Happens When You Enter a URL

1. The Basics

You type an address, press Enter, and a page appears. Between those two moments your computer performs a sequence of independent operations, most of them involving machines owned by other people, in other countries, running software you have never heard of. Any one of them can be slow. Any one of them can fail. And they fail in ways that look identical from the outside: a page that will not load.

Every website problem you will ever debug lives in one of these stages. Knowing which one is most of the work.

This article walks the whole journey once, then walks it again with real tools and real output, and ends inside the browser where most of the time is actually spent. It is the hub article for this section: each stage below is a large subject of its own, and this page is the map that shows how they connect.

The right mental model: this is not one operation. It is eight or nine subsystems in a chain, each with its own failure mode, its own timeout, and its own cache. "The site is down" is not a diagnosis. It is a description of the last link.

1.1 The Whole Journey on One Page

Here is everything, in order. Do not memorise it; the rest of the article takes it apart.

you press Enter
     ↓
 1.  is this even a URL?          browser decides: address or search box
     ↓
 2.  do I already know this?      HSTS list, DNS cache, connection pool,
                                  HTTP cache - any of these can end the
                                  journey here, with no network at all
     ↓
 3.  what is the IP address?      DNS: resolver → root → TLD → authoritative
     ↓
 4.  how do I get there?          routing table → gateway → NAT → hop by hop
                                  and: IPv4 or IPv6? (Happy Eyeballs races them)
     ↓
 5.  open a connection            TCP handshake  (or QUIC, which skips it)
     ↓
 6.  agree on encryption          TLS handshake: SNI names the host,
                                  certificate checked
     ↓
 7.  ask for the page             HTTP request
     ↓
 8.  something does the work      CDN edge, or proxy, or the origin server
     ↓
 9.  the response comes back      status code, headers, then the body
     ↓
10.  the browser builds the page  parse → DOM + CSSOM → layout → paint
     ↓
11.  and does it all again        for every image, stylesheet, script and
                                  font the page asked for

Step 11 is the one people forget. A page is not a document, it is a shopping list. The first response usually contains no images and no styling, only instructions to go and fetch them, and each of those fetches repeats steps 2 to 8.

1.2 What This Buys You

Naming the stages is not trivia. It converts a vague complaint into a location, and every diagnostic tool in this article exists to answer the same question: which stage?

That last row is the useful one. A blank page proves the first five stages worked. Somebody spending an afternoon on DNS because a page renders blank is debugging a stage that has already demonstrably succeeded.

1.3 What a URL Is, Briefly

The address you typed is structured, and the browser reads it in parts:

https://www.example.com:443/shop/socks?colour=red#reviews
│       │               │   │          │           │
scheme  host            port path       query       fragment
        └─── authority ───├────├          ├           ├
                             │          │           └─ NEVER sent
        used to find the     └─────────├              to the server
        server                          │
                             sent to the server in the request

Three parts do three different jobs. The authority tells your computer which machine to talk to. The path and query are what you ask that machine for. The fragment is for the browser alone, and section 7.1 explains why that matters more than it sounds.

The full anatomy of a URL, including the parts that cause encoding bugs, is a subject of its own and gets its own article.

3. A Short History

The journey in section 1.1 was not designed. It accumulated, one layer at a time, and several of its stranger properties are fossils of decisions made when the web was a document-sharing project for physicists.

Before the table, a word about the documents it keeps citing, because this article quotes eleven of them and section 8 tells you to go and read them.

New protocols and features on the internet are proposed, argued over and finally written down in RFCs. The letters stand for Request for Comments - not request for change, and the difference is the whole story. They are published by the IETF, the Internet Engineering Task Force, through the RFC Editor. There are more than nine thousand of them, every one is free to read, and none of them has ever been behind a paywall.

The name is an accident that stuck. RFC 1 was written by Steve Crocker on 7 April 1969, about software for the ARPA Network. Crocker later explained that his group was "informal, junior and unchartered", and that he chose the words deliberately: "I wanted to emphasize these notes were the beginning of a dialog and not an assertion of control." Fifty years on, the documents that define how the entire internet works are still called requests for comments, because nobody wanted to be the person who declared them something grander.

That humility is not only decorative. An RFC has no legal force whatsoever. Nobody is obliged to implement one, and no authority can compel them to. They are followed because a protocol that only you speak is worthless, which turns out to be a stronger incentive than a rule would be.

One property matters more than any of that when you go looking things up. An RFC is never revised. Once published it is frozen, permanently, exactly as written. When the rules change, a new RFC is published with a new number, and it declares in its header what it did to its predecessors:

Obsoletes: 7540      this REPLACES that document entirely
Updates:   2026      this CHANGES part of that document,
                     which otherwise still stands

Which produces the trap worth knowing about, and this article walked into it while being written. RFC 2026 defines how something becomes an internet standard, and describes three maturity levels a specification passes through. Read it today and you would state that confidently and be wrong. RFC 6410, of October 2011, reduced them to two, and says so only in its own header: Updates: 2026. RFC 2026 itself was never touched and still says three.

So the habit to build is small and saves real embarrassment: look at the header before you trust the body. Every RFC page on rfc-editor.org shows, at the top, whether the document has been obsoleted or updated and by what. A specification from 1999 that nobody has superseded is current; one from last year that has already been obsoleted is history. The date tells you nothing on its own.

One last thing that surprises people: not every RFC is a standard. The series also carries Informational, Experimental, Best Current Practice and Historic documents, and every 1 April it carries jokes, formally published and numbered alongside the rest.

Two entries explain more than the rest.

Persistent connections in 1997 are why step 2 of the journey can end it. Before them, every single image on a page meant a fresh connection, complete with handshake. Once a connection could be reused, the whole economics of a page load changed, and every optimisation since has been some version of "do not pay for the connection again".

The 2022 split matters because HTTP stopped being one thing. RFC 9110 defines what a 404 means and what GET promises, independently of how the bytes travel. HTTP/1.1, HTTP/2 and HTTP/3 are now three ways of moving the same semantics, which is why a modern site can serve all three and behave identically on each.

5. Watching It Happen

Everything above can be observed. The commands in this section were run against petermartin.nl while writing this article, and the output is real, so the numbers are one machine on one connection on one day rather than a benchmark.

5.1 The One Command Worth Memorising

curl can report the elapsed time at each stage, which turns the whole journey into five numbers:

$ curl -sS -o /dev/null -w 'dns:      %{time_namelookup}s
connect:  %{time_connect}s
tls:      %{time_appconnect}s
ttfb:     %{time_starttransfer}s
total:    %{time_total}s
http:     %{http_version} %{http_code}
ip:       %{remote_ip}\n' https://petermartin.nl/

dns:      0.023943s
connect:  0.037806s
tls:      0.075484s
ttfb:     0.106997s
total:    0.107034s
http:     2 301
ip:       23.88.98.40

Those are cumulative timestamps, not durations, so the useful numbers are the gaps between them:

DNS lookup            23.9 ms     0      → 23.9
TCP handshake         13.9 ms     23.9   → 37.8
TLS handshake         37.7 ms     37.8   → 75.5
server + first byte   31.5 ms     75.5   → 107.0
                     ─────────
total                107.0 ms   and the page has not started yet

Read that table and the priorities become obvious. The TLS handshake was the single most expensive step, at more than a third of the total, and the server's own work was less than a third. Somebody optimising database queries here would be attacking the smallest number on the list.

That last row deserves one correction, because it is the row people quote. It is not server time. It is the request travelling to the server, the server working, and the first byte travelling back - a full round trip with the server's thinking somewhere inside it.

You can separate the two, because the TCP handshake already measured a round trip for you. It is one exchange out and back, so it is a fair estimate of the network cost of any other exchange to the same host:

fourth gap                    31.5 ms   request + server + response
minus the TCP handshake      -13.9 ms   one round trip, already measured
                            ─────────
the server's actual work    ~17.6 ms

That sharpens the conclusion rather than softening it. The TLS handshake did not merely cost more than the server: at 37.7 ms against roughly 17.6 ms it cost more than twice as much.

One variable makes the arithmetic explicit. time_pretransfer marks the moment curl has finished the handshake and is about to send the request, so adding it isolates the request-send step:

$ curl -sS -o /dev/null -w 'dns:      %{time_namelookup}s
connect:  %{time_connect}s
tls:      %{time_appconnect}s
pre:      %{time_pretransfer}s
ttfb:     %{time_starttransfer}s
total:    %{time_total}s\n' https://petermartin.nl/

dns:      0.001507s
connect:  0.016949s
tls:      0.064378s
pre:      0.064538s
ttfb:     0.101396s
total:    0.101483s

The new line sits 0.16 ms after tls. Across repeated runs that gap stayed consistently under 0.3 milliseconds: writing a request to an already-open, already-encrypted socket costs nothing worth measuring. That is why the shorter command leaves the variable out, and why subtracting the round trip from the fourth gap is a sound estimate of server time rather than a fudge.

One difference from the run in section 5.1 is worth noticing rather than explaining away. DNS took 1.5 ms here instead of 23.9 ms, because by this point the name was already in the cache from the earlier commands. This is section 4.2 happening in front of you, and it is the reason a measurement taken on your fourth attempt flatters the site.

Two warnings before you rely on it. The round trip you subtract is an estimate: TCP and TLS packets can take different paths and a handshake can be delayed by things a later request is not. And it breaks entirely on HTTP/3, where there is no separate TCP handshake to measure, and on a reused connection, where there is no handshake at all.

Now look at the status: 301. The whole 107 ms bought a redirect. Following it costs the rest:

$ curl -sS -o /dev/null -L -w 'final:     %{url_effective}
http:      %{http_version} %{http_code}
redirects: %{num_redirects}
total:     %{time_total}s\n' https://petermartin.nl/

final:     https://petermartin.nl/en/
http:      2 200
redirects: 1
total:     0.265913s

266 ms to get a page, of which 107 ms was spent learning that the page is somewhere else. That is the real cost of a redirect, and it is why redirect chains matter: each hop pays for a request and a response before anything useful happens.

Chains are hard to notice one URL at a time, which is why I look for them with a crawler over the whole site rather than by testing pages I already suspect. Every hop in a chain works correctly on its own, so nothing ever appears broken; they accumulate quietly over years of small structural changes, each one adding a hop to links that were fine before. The pattern to look for is not a slow page but an old internal link that now takes three hops to arrive.

5.2 Watching DNS Delegate

dig +trace refuses to use a resolver's cached answer and walks the chain itself, so you can watch the delegation described in section 4.3:

$ dig -4 +trace +noall +answer petermartin.nl

;; Received 239 bytes from 127.0.0.53#53(127.0.0.53)
;; Received 596 bytes from 170.247.170.2#53(b.root-servers.net)
;; Received 303 bytes from 194.0.25.24#53(ns3.dns.nl)

petermartin.nl.  300  IN  A      23.88.98.40
petermartin.nl.  300  IN  RRSIG  A 13 2 300 ...
;; Received 169 bytes from 172.64.35.58#53(finley.ns.cloudflare.com)

Three hops, exactly as described: a root server, then the .nl registry, then the authoritative nameservers - which in this case are Cloudflare's, telling you where the domain's DNS is hosted without anyone having to say so.

Two details in that output are worth naming. The 300 is the TTL in seconds: how long any resolver may cache this answer, and therefore how long a change to it takes to be seen everywhere. Section 7.3 returns to that. The RRSIG line is a DNSSEC signature, meaning this answer is cryptographically signed and a resolver that checks signatures can detect a forged reply.

Run the command twice and the server names will not match the ones above. That is expected, and it is worth understanding rather than ignoring, because it is the shape of the whole system in one observation.

At each level there is a set of servers, and one gets picked:

root       13 names, a.root-servers.net through m.root-servers.net
.nl         3 names, ns1 / ns3 / ns4.dns.nl
petermartin.nl
            2 names, chelsea and finley.ns.cloudflare.com

six consecutive runs picked:
  e → ns3 → chelsea      k → ns3 → chelsea
  f → ns1 → finley       m → ns4 → chelsea
  e → ns3 → chelsea      l → ns1 → finley

Your configured resolver is used for one thing only, the first line of that output: telling dig who the root servers are. After that dig makes its own queries and follows the referrals itself, choosing a server at each step from a mix of measured response times and deliberate randomness. Fast servers are favoured, but never exclusively.

Even the letter does not identify a machine. b.root-servers.net is a single address, 170.247.170.2, announced from many separate locations around the world by anycast - "making a particular Service Address available in multiple, discrete, autonomous locations, such that datagrams sent are routed to one of several available locations", as RFC 7094 puts it. Whichever instance is nearest in routing terms answers you.

So there is no such thing as the B root server. There are thirteen root names backed by well over a thousand physical instances, which is how a system that sounds absurdly small has absorbed thirty years of growth, and why a root query is fast from almost anywhere.

This also underpins section 7.3. When servers are chosen per query and every answer is cached independently on its own countdown, there is no coordinated wave for anything to propagate across.

5.3 Watching the TLS Handshake

curl -v narrates the handshake message by message:

$ curl -sS -o /dev/null -v https://www.petermartin.nl/ 2>&1 | grep TLS

* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN),  TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):        <-- again?
* TLSv1.3 (IN),  TLS handshake, Server hello (2):
* TLSv1.3 (IN),  TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN),  TLS handshake, Certificate (11):
* TLSv1.3 (IN),  TLS handshake, CERT verify (15):
* TLSv1.3 (IN),  TLS handshake, Finished (20):

Two things are visible here that no diagram would show you.

ALPN is where the HTTP version is decided. The client offers h2 and http/1.1 inside the TLS handshake, and the server picks. That is why the earlier request reported HTTP/2 without any extra negotiation round trip: it was settled during encryption setup.

There are two Client Hellos. That is a HelloRetryRequest: the client guessed which key exchange group the server would want, guessed wrong, and the server asked it to try again. It costs an extra round trip, it is invisible in every dashboard, and it is one concrete reason the TLS number in section 5.1 was the largest on the list. Section 7.5 comes back to it.

5.4 Reading the Response Head

curl -I asks for headers only, which is the fastest way to see what a server is really doing with a URL:

$ curl -sSI https://petermartin.nl/

HTTP/2 301
server: nginx-rc
date: Thu, 27 Aug 2026 10:20:09 GMT
content-type: text/html; charset=utf-8
location: https://petermartin.nl/en/
set-cookie: e4edc00e04a600eeeaa5f4584a67449a=...; path=/; HttpOnly

Four facts in six lines: the connection is HTTP/2, the answer is a permanent redirect, location names the destination, and the server is nginx. There is also a session cookie being set - on a redirect, on a response no human will ever see. Section 7.6 explains why that is worth noticing.

5.5 A Diagnostic Order That Works

Put together, the tools give you a sequence that finds the broken stage in about a minute:

1. dig +short DOMAIN         does the name resolve at all?
                             no answer  → DNS. Stop here.

2. curl -sS -o /dev/null -w '...' URL
                             which gap is large?
                             connect never completes → TCP/firewall
                             tls never completes     → certificate
                             ttfb is the big gap     → the server

3. curl -sSI URL             what status? redirect chain?
                             4xx → your request   5xx → their server

4. browser devtools          only now, for rendering and subresources

The order is the point: each step assumes the previous one succeeded, so you never debug a stage that has already proven itself.

Answering support questions on the Joomla forum taught me to run this before reading the rest of the report, not after. The description of a problem almost always names a stage, and that part is the least reliable thing in it: "the server is down" arrives for expired certificates, "DNS is broken" arrives for pages that render blank, and both reporters watched something real and then guessed at the cause. Two commands settle it before anyone has to be contradicted.

7. Something Most Users Do Not Know

7.1 The Fragment Never Leaves the Browser

Everything after # in a URL is not sent to the server. Ever. RFC 3986 is explicit: "the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user agent".

you request   https://example.com/guide?v=2#installation
server sees   GET /guide?v=2
                             └─ the query IS sent
              #installation  └─ the fragment is NOT

Several practical consequences follow, and each one surprises somebody every year:

• Server logs cannot show fragments, so no server-side analytics can tell you which section of a page people jumped to.
• Redirects cannot inspect them. A rewrite rule matching on # can never fire.
• They survive redirects anyway. The browser re-applies the fragment to whatever URL it lands on, which is occasionally useful and occasionally baffling.
• They are a bad place for secrets in one direction and a deliberate one in another: fragments stay out of server logs, which is exactly why some authentication flows return tokens there.

7.2 Your HTTP-to-HTTPS Redirect Often Never Runs

Most sites redirect http:// to https:// and consider the job done. For a large share of visitors that redirect is never requested, because of HSTS.

When a site sends a Strict-Transport-Security header, the browser records that this host is HTTPS-only for the stated duration. On every later visit the browser rewrites http:// to https:// itself, before any network activity. There is no insecure request to intercept, because there is no request.

It goes further. Browsers ship a preload list of domains hardcoded as HTTPS-only, compiled into the browser binary. For a domain on that list, the very first visit by a user who has never seen the site is already protected.

WITHOUT HSTS   http://  → request → 301 → https:// request
               one insecure request happens, and can be intercepted

WITH HSTS      http://  → browser rewrites internally → https://
               no insecure request exists

PRELOADED      protected on the FIRST EVER visit, before any header
               has been received from the site at all

The catch is the one people discover too late: preloading is difficult to undo. Removal requests are processed slowly, and until they take effect in a released browser version, a domain that can no longer serve HTTPS is unreachable rather than degraded. Preloading is a commitment, not a setting.

7.3 "DNS Propagation" Is Not a Thing

Everyone says it, and the mental model it creates is wrong in a way that causes real mistakes. Nothing propagates. No update travels outward across the internet.

What actually happens is expiry. Every DNS answer carries a TTL - the 300 in section 5.2 - and resolvers keep the answer for that long. When it expires, the next question goes back to the authoritative server and gets the new answer. There is no wave. There are millions of independent countdowns, each started when that particular resolver last asked.

The correct model changes what you do:

• The delay is bounded by the TTL you published before the change, not by any global process. Lower the TTL a day ahead of a migration and the switch takes minutes; lower it at the same time as the change and you have gained nothing, because the old TTL is already out there.
• "It has propagated for me" means only that your resolver's copy expired. Somebody else's has not.
• Checking with dig @8.8.8.8 tells you about one resolver, not about the world.

7.4 One Page Is Not One Journey

The whole article so far describes fetching a single file. A modern page might make sixty to a hundred requests, to perhaps eight or ten different hosts, and each new host repeats DNS, TCP and TLS.

This is why the waterfall in developer tools is shaped the way it is, and why the single most effective performance change is often not making anything faster but removing a host. Self-hosting a font that came from a third-party domain does not just save a download; it deletes an entire DNS-plus-handshake sequence from the critical path.

7.5 The Handshake Can Silently Cost an Extra Round Trip

Section 5.3 caught a real example. TLS 1.3 is designed to complete in one round trip, and it manages that by having the client guess which key exchange group the server will choose and send its key share immediately.

When the guess is wrong, the server replies with a HelloRetryRequest, and the client starts again with the right group. The handshake still succeeds, nothing is logged as an error, and the connection quietly cost twice the round trips it was supposed to.

guess right   ClientHello → ServerHello + Finished     1 round trip
guess wrong   ClientHello → HelloRetryRequest
              ClientHello → ServerHello + Finished     2 round trips

On a local connection this is a few milliseconds. On a mobile connection with 80 ms of latency it is 80 ms added to every new connection, invisible to every monitoring tool that measures only whether TLS succeeded. It is the kind of thing you find only by looking at a handshake directly, which takes one curl -v.

7.6 A Cookie Can Be Set on a Page Nobody Sees

The redirect in section 5.4 set a session cookie. The visitor never sees that response - the browser follows the location immediately - but the cookie is stored all the same.

This matters for two reasons that catch people out. It means a session can begin before any page is delivered, so an application may be creating server-side session storage for visitors and crawlers that never reach a real page. And it means cookie consent logic that runs in the rendered page is already too late: the cookie was set by an HTTP header on a response that never rendered, and no amount of JavaScript on the destination page was consulted.

If you audit a site for cookies by loading pages and reading what appears, you will miss every cookie set this way. Reading the headers on the redirect itself is the only way to see them.

7.7 First Byte Is Not First Paint

Time to first byte is the number most server monitoring reports, and it measures the end of step 8 of ten. It says nothing about whether anything appeared on screen.

TTFB      the first byte of the HTML arrived
          └→ measures DNS + TCP + TLS + server. Nothing else.

FCP       the first pixel of content was painted
          └→ adds CSS, blocking scripts, fonts, layout, paint

LCP       the largest content element finished painting
          └→ usually the number a visitor would call "loaded"

A site can have an excellent TTFB and feel broken, if a render-blocking stylesheet on a third host takes a second to arrive. It can also have a mediocre TTFB and feel instant. Reporting only TTFB measures the half of the journey the server controls, which is convenient for whoever runs the server and not the same thing as the visitor's experience.

7.8 HTTPS Hides Less Than People Think

"The connection is encrypted" is true and is narrower than it sounds. Encryption protects the content of the HTTP exchange. Several things around it stay visible to anyone watching the network.

VISIBLE even on HTTPS
  the IP addresses           routers cannot deliver a packet without them
  the hostname, twice        once in the DNS query, once in the TLS SNI
  the timing and the sizes   how much, how often, in what pattern

ENCRYPTED
  the path and query         /account/orders?id=42
  the headers and cookies
  the request and response bodies

The hostname leaking twice is the part that surprises people. The DNS lookup asks for a name in plain text unless the resolver uses DNS over HTTPS or DNS over TLS, and section 4.7's SNI names the host again inside the handshake, before encryption starts.

Both leaks now have fixes, and both need more than a browser setting. Encrypted DNS moves the first one to an encrypted channel, though it moves the knowledge to the resolver operator rather than removing it. Encrypted Client Hello, published as RFC 9849 in March 2026, encrypts the SNI, but it needs the client, the server and a DNS record to cooperate, so it is a deployment rather than a checkbox.

The honest summary is the one to give a client: HTTPS reliably hides what you did on a site. It does not reliably hide which site you visited.

7.9 Latency Beats Bandwidth, and It Is Not Close

"The site is slow, we should upgrade the connection" is one of the most expensive wrong answers in this field.

Look again at the measurement in section 5.1. Those 107 milliseconds delivered a 301 - a response of a few hundred bytes. Bandwidth was never a factor. Almost the entire budget went on waiting for round trips: one for DNS, one for TCP, one or two for TLS, one for the request and response.

a round trip costs the same whether you send 100 bytes or 100,000
  → a faster connection makes big files arrive sooner
  → it does NOT make a handshake finish sooner

so the wins that matter are the ones that REMOVE round trips:
  connection reuse       no handshake at all
  fewer hosts            no extra DNS + TCP + TLS per domain
  a CDN                  shorter distance, so shorter round trips
  TLS session resumption zero round trips instead of one
  HTTP/3                 merges transport and encryption setup
  no redirect            one entire request and response deleted

Not one of those is about capacity. This is why a site can feel slow on fast office broadband and fine on a phone, and why doubling a server's bandwidth so often changes nothing a visitor notices.

7.10 Knowing Where This Article Stops

• It stops at one request. Real sessions involve cookies, caches warming, service workers answering from local storage, and a browser that has seen your site before.
• It stops at the happy path plus the obvious failures. Captive portals, corporate proxies that terminate TLS, and DNS-level filtering all rewrite the journey in ways that look like faults in your site.
• It stops at the edges of each subject. DNS, TLS certificates, HTTP status codes, caching and the rendering pipeline each have far more to them than one section can carry, and each has its own article in this section.
• It stops at the browser. A crawler or an AI assistant fetching the same URL may run no JavaScript, accept no cookies, and never reach step 9 at all.

9. Common Mistakes

9.1 Ten Myths

9.2 Other Traps to Avoid

• Restarting the web server when DNS is the problem. If the name does not resolve, nothing ever reached the web server.
• Testing a fix in the same browser that cached the problem. Four caches stand between you and the truth; use a private window or another device.
• Changing DNS and the TTL in the same operation, then being surprised the old value persists.
• Adding preconnect to every third-party domain. Each one holds open a connection that may never be used.
• Assuming a certificate covers subdomains. A certificate for example.com does not cover www.example.com unless it says so.
• Reading a redirect chain as one redirect. Each hop is a full request and response; three hops can cost more than the page.
• Blaming the network for a blank page. A blank page arrived, which means the network worked perfectly.
• Breaking a -w format string across lines with a trailing backslash inside single quotes. Single quotes are literal, so the shell does not treat \ plus newline as a continuation. curl receives the backslash and prints a stray \ between every line. Put real newlines inside the quotes instead, or continue the line outside them.
• Testing only over IPv4 when the hostname also has an AAAA record, then being surprised that some visitors cannot connect.
• Deploying to an origin behind a CDN and declaring it live. The edge may keep serving the old copy until its cache expires or you purge it.
• Trusting a single dig against one public resolver as evidence of what everybody sees.
• Forgetting that the browser upgrades bare hostnames to HTTPS, then wondering why a plain HTTP test never reaches the server.