- DNS resolution, connection security and HTTP responses are separate stages.
- A page consists of multiple resources.
- Use the Network panel to identify the stage that actually failed.
Start with the address
Consider a made-up visit to https://example.com/articles/. The scheme identifies HTTPS, the hostname identifies the destination, and the path identifies the requested resource. These parts play different roles. Changing a path will not repair a DNS problem, and obtaining an IP address does not establish that the server can provide the page.
The browser may already hold information from an earlier visit. That is why a second load can take a different path from a first load. Caches are part of the explanation, not an exception to it.
Find the destination
DNS provides records associated with names. A client normally asks a recursive resolver, which can answer from its cache or follow the hierarchy to obtain an answer. An A record supplies an IPv4 address; an AAAA record supplies an IPv6 address. There may be multiple answers, and not every visit results in a fresh lookup.
The resolver is not the website. Successfully resolving a name demonstrates only that the relevant name lookup returned a result. The server, network path, application and access controls still need to work.
DNS supplies records associated with the name. A successful answer does not establish application health.
Conceptual illustration. Selecting a step does not send a network request.Establish the connection
For an HTTPS request the client needs a protected connection to the intended service. TLS authenticates the server name through certificate validation and protects the traffic exchanged over that connection. The client must not simply ignore a certificate error to make a connection appear successful.
There are protocol differences: HTTP/1.1 and HTTP/2 commonly use TLS over TCP, while HTTP/3 uses QUIC. A simplified diagram can teach the stages without claiming that every browser opens the same transport sequence for every resource.
Ask for the resource
The browser sends an HTTP request and receives a response. A response includes a status and headers; it may also include a body. The HTML can refer to stylesheets, images and scripts, which require their own resources. A successful HTML response does not guarantee that these other resources arrived or executed correctly.
Open the browser’s developer tools and inspect the Network panel while reloading this page. Select the document first, then an image and the stylesheet. Compare their types, status codes and transfer sizes. You are observing a collection of requests rather than a single download.
Open Developer Tools → Network, reload, and identify one document, one stylesheet and one image. Do not disable browser security settings.
Turn the model into a diagnosis
When something fails, ask which stage has evidence of success and which does not. Is the hostname resolved? Was a protected connection established? Did the document arrive? Did a particular image fail? Did JavaScript report an error?
This sequence does not solve every incident, but it improves the first question. Instead of “the internet is broken,” you can describe the narrowest observed failure and preserve enough evidence for the next investigation.
Read beyond this page.
Recorded source-check date: 10 Sep 2026. A link is not, by itself, evidence that every claim has been independently verified.
Changes & version history
Version 3 · 10 Sep 2026
Scheduled release of checksum-bound AI-assisted editorial review
Version 2 · 10 Sep 2026
Checksum-bound editorial review scheduled for release
Version 1 · 10 Sep 2026
Source-linked private review edition