Opening a website combines every earlier layer. The path differs by browser, protocol, CDN, and architecture, but this model explains most request failures.
What Happens When You Open a Website?
1. Parse the URL and Find the Destination
For https://nikh.im/articles, the browser identifies HTTPS as the scheme, nikh.im as the hostname, and /articles as the path. It checks caches and asks DNS for address information when necessary.
URL parsed -> DNS lookup -> Destination IP -> Route selected -> Default gateway
2. Leave the Local Network
If the destination is outside the local subnet, the operating system sends frames toward the gateway. In a typical IPv4 home network, NAT translates the private source endpoint to a public one. Packets then cross the ISP and other routed networks; routing policy determines suitable next hops rather than one permanent path.
3. Establish Transport and Security
HTTP/1.1 or HTTP/2 normally uses TCP to destination port 443. HTTP/3 uses QUIC over UDP. HTTPS authenticates the server and creates encrypted traffic keys through TLS before protected HTTP messages flow.
4. Enter the Server Network
What Happens Inside a Server Environment
Internet -> Firewall or edge -> Load balancer -> Reverse proxy or API gateway -> Application -> Cache, database, queue, or service
- Firewall
- Allows intended traffic while blocking unwanted network access.
- Load balancer
- Distributes traffic among healthy application instances.
- Reverse proxy
- Receives requests for backends and can terminate TLS, route paths, compress, or limit traffic.
- API gateway
- Adds API routing, authentication, quotas, transformations, and observability.
Nginx might listen publicly on 443 and forward to a Node.js process on private port 3000. The client knows only the public hostname; the proxy owns internal routing.
5. Process the Application Request
GET /api/products/100
AuthenticateValidateCheck cacheQuery databaseApply business rulesReturn { "id": 100, "name": "Laptop", "price": 75000 }One browser request can create many downstream calls between applications, databases, queues, and services. Each may introduce its own DNS lookup, connection, packets, and response.
6. Return and Render
The response travels back through the proxy, load balancer, network, NAT device, operating system, and browser. Parsing HTML can reveal CSS, JavaScript, fonts, and images, triggering more requests. Connection reuse and multiplexing reduce repeated setup.
Complete End-to-End Packet Flow
- DNS failure means the name did not produce usable address information.
- Connection refused means nothing accepted the connection or a device actively rejected it.
- Connection timeout can indicate blocking, routing, loss, or an unresponsive endpoint.
- 502 means a gateway received an invalid upstream response.
- 504 means a gateway waited too long for an upstream response.
Debug by boundary
Ask how far the request progressed: DNS, routing, connection, TLS, proxy, application, or downstream dependency.
Series
How Internet Requests Actually WorkAn eight-part beginner series tracing internet communication from an HTTP request through DNS, IP, ports, transport protocols, packets, network devices, server infrastructure, security, and troubleshooting.
HTTP Requests: Methods, URLs, Headers, and Bodies
Start at the application layer and understand what a browser or API client is actually asking for.
DNS, Domain Names, and IP Addresses
Follow the lookup that turns a human-friendly hostname into a network destination.
Public IP, Private IP, NAT, and Ports
See how local devices reach the internet and how operating systems identify each service and flow.
TCP vs UDP
Compare reliable byte streams with simpler datagrams and understand where each transport fits.
Packets, Network Layers, Switches, and Routers
Learn how data is encapsulated and moved across local links and routed networks.
The Complete Website Request Journey
Put the layers together from the browser to production infrastructure and back again.
HTTPS, TLS, and HTTP Status Codes
Understand secure transport, certificate checks, and the response codes used during debugging.
Troubleshooting, Localhost, Cloud, and Containers
Apply the model with diagnostic tools and carry it into cloud and container environments.
Nikhlesh Yadav is a Technical Lead and Solution Architect with 12+ years of experience across cloud-native systems, distributed platforms, AI integrations, Web3, and cyber security.
Read full profile