What happens when you type a URL

First the browser parses the URL: scheme (https), host (engineer-atlas.dev), an implied port (443), path and query. It checks HSTS and its own caches — if it has a fresh cached response it may not touch the network at all. Then it needs an IP for the host: the browser cache, the OS resolver cache (and /etc/hosts), then a recursive resolver (from DHCP or configured, e.g. 1.1.1.1) which, on a miss, walks root → .dev TLD → the authoritative nameserver and caches the answer for its TTL. Both A (IPv4) and AAAA (IPv6) are asked for; the browser races them (Happy Eyeballs) and prefers IPv6 when it connects first.

With an address, the OS opens a TCP connection: it consults the routing table (longest-prefix match — is the destination on-link or via the default gateway?), resolves the gateway’s MAC via ARP (IPv4) or Neighbor Discovery (IPv6), and sends a SYN. Every router on the path does the same lookup and forwards; the destination replies SYN-ACK, the client ACKs — one round trip before any data. If the SYN is dropped by a firewall the client just retransmits until it times out; if nothing listens the server’s kernel sends RST and you get "connection refused" instantly.

For HTTPS, the TLS handshake runs next: the client sends its supported versions, cipher suites, a key share and the hostname (SNI); the server picks parameters, returns its key share and certificate chain; the client validates the chain up to a root it trusts, checks the name and dates, and both derive the session keys. TLS 1.3 does this in one round trip; a resumed session can send data in the first flight. Then the browser sends the HTTP request — over HTTP/2 if ALPN negotiated it, as a stream on that one connection — with headers, cookies, and compression preferences.

On the server side the packet is usually received by a load balancer or reverse proxy (which may terminate TLS), routed to an application process, which reads the request from its socket, does its work (database, cache), and writes a response. The response travels back, the browser parses status and headers (redirect? cache it? set cookies?), decompresses the body, starts parsing HTML progressively, discovers stylesheets, scripts and images, and issues more requests — reusing the same connection — while building the DOM, computing styles and layout, and painting.

What matters is that each rung has its own failure: DNS returns NXDOMAIN or a stale address; the route is missing; the SYN is dropped (timeout) or refused (RST); the certificate expired at midnight; the proxy returns 502 because the upstream is down. "The site is down" is never one thing.