What Actually Happens When You Click a Link?

You type a URL into the address bar — or click a link in an email — and a fraction of a second later the page is on your screen. Almost nothing about that feels mysterious until something breaks, at which point you discover that a lot just happened, and any one of those things could be the reason it didn’t work.

This is the first article in the Networking from Scratch series. The whole pathway is built so you can read it in order, no prior experience required. By the end of this one you’ll have a working mental model of every major piece of the puzzle — we’ll spend the rest of the series zooming in on each piece. The example we’ll use throughout: you click a link to https://infotechninja.com.

The eight things that happen, in order

The browser tab spins for somewhere between 150 and 800 milliseconds. In that window:

1. Your computer figures out the IP address of the server (DNS).
2. It figures out where to physically send the first packet (default gateway + ARP).
3. That packet hops through several routers across the internet.
4. It arrives at the destination server.
5. Your computer and the server agree to start a conversation (TCP handshake).
6. They agree on encryption keys (TLS handshake).
7. Your browser sends the actual request and the server replies (HTTP).
8. The browser turns the reply into pixels on your screen.

That’s the whole show. Let’s walk through it slowly.

Step 1 — DNS: turning a name into an address

Computers don’t actually use names to find each other. They use numbers called IP addresses. Names like infotechninja.com exist because humans are bad at memorising numbers and good at remembering words. The whole job of DNS (the Domain Name System) is to translate the one into the other.

When you click a link, your computer asks: “What’s the IP for infotechninja.com?” The answer travels back as something like 203.0.113.42 (an IPv4 address) or 2606:4700:30::6815:abcd (an IPv6 address). From this point forward, your computer is talking to that number; the name has done its job.

The lookup itself is layered. Your computer first checks its own short-term memory (the OS resolver cache), then asks a DNS server it’s configured to use — usually one your home router or your ISP provides, although tools like Cloudflare’s 1.1.1.1 or Google’s 8.8.8.8 are popular alternatives. If that server doesn’t already know the answer, it walks the global DNS tree starting from the root servers, then the .com servers, then the servers that hold the infotechninja.com records, and returns the answer back down the chain.

You’ll meet DNS in much more detail later in the series. The thing to take away here is the role: DNS is the phone book of the internet. If DNS breaks, every step that follows fails — not because the network is broken, but because nobody knows the address.

Try it yourself

# Windows / macOS / Linux all have a version of this:
nslookup infotechninja.com
# or, on Linux/macOS:
dig infotechninja.com

Step 2 — The default gateway, and ARP

Now your computer has an IP address to send to. But that server isn’t plugged into your living room wall. It’s somewhere else — a data centre on another continent, possibly. So how does the very first packet leave your machine?

The answer is: it goes to your default gateway — usually your home router or the router on your office network. The default gateway is the “exit door” for any traffic that isn’t bound for somewhere on your local network.

Your computer figures out whether the destination is local or not by comparing the destination IP against its own subnet (more on subnets in a later article). If the answer is “not local,” it sends the packet to the gateway. If it’s “local,” it sends the packet straight to that machine.

Either way, your computer needs one more piece of information: the MAC address of whatever it’s about to hand the packet to. MAC addresses are hardware-level identifiers baked into network adapters — they’re what the physical Ethernet or Wi-Fi layer uses to deliver a frame to the right device on the same network. Your computer asks “who has IP X?” using a protocol called ARP (Address Resolution Protocol), and the answer comes back: “here’s the MAC address.”

Now your computer can wrap the packet in an Ethernet frame addressed to that MAC and send it down the wire (or the Wi-Fi). The frame leaves your machine.

Step 3 — Routing across the internet

Your default gateway receives the frame, strips the Ethernet wrapper off, looks at the destination IP, and asks the same question your computer just asked: “is this local to me?” If yes, deliver locally. If no, hand it to my default route — whatever that is.

That “next router” might be your ISP’s edge router. It might be one of several upstream networks. Each router along the way only has to make one decision: “based on the destination IP, what’s the next router I should hand this to?” They keep doing that until the packet lands at a router that does have a direct path to the destination.

This is the single most important idea in networking, and it’s worth saying out loud: no router knows the whole path. Each one only knows its next hop. The packet finds its way to the destination because every router along the way knows enough to make the next correct decision.

You can watch this happen live:

# Windows
tracert infotechninja.com

# macOS / Linux
traceroute infotechninja.com

Each line of the output is one router along the path. A typical packet from a home internet connection to a hosted website crosses 10–20 routers. The packet itself doesn’t care; it just keeps getting handed off until it arrives.

Step 4 — The server receives the packet

At some point a router has a direct connection (or a very short hop) to the network the destination server lives on. The packet is delivered down that final stretch and lands on the server’s network adapter. The server’s operating system pulls the packet up through its own layers and hands the contents to whatever program is listening on the right port — the web server, in our case.

You may have noticed nothing’s actually been said yet. We just got a packet to the right machine. Now we have to start an actual conversation.

Step 5 — The TCP handshake

Most internet traffic uses a protocol called TCP (Transmission Control Protocol) when it needs reliable, ordered delivery — web pages, file transfers, email. TCP is the thing that makes sure data arrives intact and in the right order, even when individual packets get lost or arrive out of order along the way.

Before any actual content moves, TCP requires a quick three-step handshake to set up the connection. It looks like this:

You    --SYN-->     Server   "Hi, want to talk?"
You    <-SYN/ACK-   Server   "Yes, I'm here, do you confirm?"
You    --ACK-->     Server   "Confirmed, let's go."

This whole exchange is three packets and takes one round-trip. After it, both sides agree they have a working connection and they can start exchanging real data. The handshake also includes the port number — for HTTPS that’s 443, for plain HTTP that’s 80. Ports are how a single server can run many different services at the same time without confusion (port 22 is SSH, 25 is mail, 53 is DNS, 443 is HTTPS, and so on).

Step 6 — The TLS handshake (the “S” in HTTPS)

Almost every modern website uses HTTPS, which means the actual web traffic is encrypted. That requires another short exchange before any HTTP request goes out: the TLS handshake.

What happens during this handshake:

• Your browser tells the server which TLS versions and cipher suites it supports.
• The server picks one and sends back its certificate — a signed document that says “I am infotechninja.com, here’s my public key, and here’s a chain of signatures from a trusted Certificate Authority that proves I’m allowed to call myself that.”
• Your browser verifies the certificate against its built-in list of trusted CAs.
• The two sides agree on a fresh symmetric encryption key for this single session.

From this point on, every byte that crosses the wire is encrypted with that session key. Anyone in the middle — your ISP, the coffee shop’s Wi-Fi, a curious router operator — can see that you’re talking to infotechninja.com, but not what you’re saying. Modern TLS 1.3 does this whole exchange in one round-trip, and resumed connections can do it in zero.

Step 7 — The actual HTTP request and response

Now — finally — your browser sends the request that started this whole journey. It looks something like this (I’ve simplified it):

GET / HTTP/1.1
Host: infotechninja.com
User-Agent: Mozilla/5.0 ...
Accept: text/html,application/xhtml+xml
Accept-Encoding: gzip, br
Cookie: ...

The server reads that, figures out which page you want, and replies:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Encoding: br
Server: Apache
Cache-Control: max-age=3600

<!DOCTYPE html>
<html> ... </html>

That 200 at the top is the status code — 200 OK means “here’s your content.” You’ve seen its less-friendly cousins: 404 Not Found, 500 Internal Server Error, 301 Moved Permanently, and so on. The numbers are grouped by category: 2xx is success, 3xx is redirection, 4xx means the client did something wrong, 5xx means the server did.

The HTML body that comes back is rarely the only thing the browser needs. It usually references CSS files, JavaScript, images, fonts — each of which triggers another HTTP request. Modern browsers do this in parallel over the same connection (HTTP/2 and HTTP/3 multiplex multiple requests onto one TCP / QUIC connection), which is why a typical page load is dozens of requests but only one or two underlying connections.

Step 8 — The browser renders the page

Once the HTML, CSS, JavaScript, and images are in, the browser’s rendering engine kicks in. It parses the HTML into a tree, applies the CSS to figure out what each element should look like, runs any JavaScript that might modify either, lays everything out, and finally paints pixels. This stage is fast on modern hardware — usually tens of milliseconds — but it’s the only part the user actually sees, which is why “the page is slow” is sometimes a frontend problem and sometimes a network problem.

And that’s the whole journey. Click to pixel.

Total time, roughly

What can go wrong, and which step is at fault

Now that you have a mental model of the stages, you can read failure modes more carefully. A few common ones, mapped to the step that broke:

• “This site can’t be reached / DNS_PROBE_FINISHED_NXDOMAIN” — Step 1 failed. DNS couldn’t resolve the name. Either the domain doesn’t exist, your DNS server is down, or your DNS settings are pointing somewhere broken.
• “Default gateway not found” / can’t reach anything outside your LAN — Step 2 broken. Your computer doesn’t have a working route off the local network.
• Loads slowly only sometimes / random timeouts — usually Step 3. A router somewhere along the path is congested or flapping.
• “Connection refused” — you reached the server (Step 4) but nothing was listening on the port you tried (Step 5 never started). The server is up but the service isn’t.
• “Your connection is not private” / NET::ERR_CERT_* — Step 6. The TLS certificate didn’t verify — expired, name mismatch, untrusted CA, or someone’s actively trying to MITM you.
• 404, 500, 502, 503 — Step 7. The server received your request and answered, just not with what you wanted.
• Page loads but looks broken — Step 8. CSS or JavaScript failed; the HTML probably arrived fine.

Most “the internet is broken” complaints are actually a single specific stage being broken. Knowing which stage saves enormous amounts of debugging time.

What we’ll cover next

Each of the next articles in this pathway zooms in on one of the stages above:

• Addresses — how IPv4 and IPv6 actually work, and the subnetting math you’ll need.
• DHCP and ARP — how your machine got its IP address in the first place, and how it finds its neighbours.
• Routing vs switching — the difference between the “next hop on my LAN” problem and the “next hop across the internet” problem.
• Cables, Wi-Fi, and the physical layer — what’s actually carrying these packets.
• TCP, UDP, and QUIC — the transport protocols, and when each one is the right choice.
• DNS deep dive — everything that quietly happens in Step 1.
• Security — what an attacker can do at each step, and how the real internet defends against it.

If something in this article didn’t quite click, don’t worry — that’s the point of the rest of the pathway. The goal here was to give you a single coherent picture of what’s going on when you click a link. Now you can read the rest knowing how each piece fits.

Up next: IPv4 addressing without panic — the math, the gotchas, and a real example that finally makes subnet masks click.