A website visit is a conversation between a client and a service. The browser sends a request; a web server or application processes it; and the server returns a response. DNS may help the browser find the service, but DNS does not generate the page. Understanding this separation makes common errors easier to diagnose.
Quick answer: the browser constructs an HTTP request for a URL, sends it over a network connection, and receives an HTTP response. The response can be a page, data, a redirect, or an error. A dynamic application may call a database or other services before replying.
The request path
A simplified page load can involve several systems:
- Name resolution: DNS helps the client locate a destination for the host name.
- Connection: the client establishes a network connection to the service. The exact transport depends on the protocol and environment.
- TLS for HTTPS: the client and server negotiate encryption and check the certificate for the requested host.
- HTTP request: the client sends a method, path, headers, and sometimes a body.
- Server or application work: the web server may serve a file, route the request to application code, check authentication, or query a database.
- HTTP response: the service returns a status, headers, and possibly a body.
- Browser rendering: the browser interprets HTML, downloads referenced assets, and runs permitted scripts.
One visible page can require many additional requests for images, stylesheets, scripts, fonts, and API data. A successful first response does not guarantee every asset loaded.
What is inside an HTTP exchange?
A request includes a method such as GET or POST, a path such as /account, headers, and sometimes a body. GET commonly retrieves a representation; POST commonly submits data. Applications must still enforce authorization and validation; a method name alone is not a security boundary.
A response includes a status code, headers, and optionally content. Common groups include:
- 2xx: the request was handled successfully;
200is a common success response. - 3xx: the client is directed elsewhere or can use a cached representation.
- 4xx: the request or access was not accepted;
404means the requested resource was not found, while403commonly indicates access is forbidden. - 5xx: the server or an upstream service encountered a problem;
502and503often point to gateway or availability issues.
Status codes are clues, not complete diagnoses. An application can customize error pages, and a proxy can return a status before a request reaches the origin server.
Static pages, dynamic applications, and databases
A static site can serve files that were prepared before a visitor arrived. It still may use scripts in the browser, but it does not need to generate every page from a database request.
A dynamic site runs application code to build a response. It may read a product, user account, or article from a database; apply permissions; and return HTML or structured data. The database is not normally contacted directly by a browser. Application code mediates access so it can validate input and enforce rules.
A site can combine these approaches. It may serve static assets through a CDN while sending account requests to an application server. This architecture can reduce work on the origin, but it also creates more components to monitor.
HTTPS: the secure connection layer
HTTPS is HTTP carried over TLS. It protects data in transit between the client and the endpoint and helps the client verify that it is communicating with a server presenting a certificate for the requested host. It does not prove that the website’s business claims are true, prevent every phishing attempt, or secure a compromised device or server.
The browser may show a warning if a certificate is expired, mismatched to the host, untrusted, or otherwise invalid. The certificate must cover the exact host being visited. example.com and www.example.com may need both names covered, depending on the certificate and configuration.
How to troubleshoot common responses
| Symptom | Possible area to inspect | First useful check |
|---|---|---|
| Domain does not resolve | DNS records, nameservers, delegation | Query the authoritative zone and compare resolver responses. |
| 404 | URL path, deployment, application route | Confirm the exact path and that the resource or route exists. |
| 403 | Permissions, authentication, server rules | Review access policy and server logs for the request. |
| 500 | Application error or configuration | Inspect application logs and the most recent deploy/config change. |
| 502/503 | Upstream unavailable, proxy, overload | Check origin health, service dependencies, and gateway logs. |
| HTTPS warning | Certificate, hostname, clock, chain | Check the exact hostname and certificate validity/chain. |
| Page partly unstyled | Asset paths, blocked requests, cache | Inspect browser network errors for CSS/JS and mixed content. |
Start at the layer that produced the failure. Check whether DNS resolves, then whether the server responds, then whether the application route works, and finally whether the browser can load all assets. Use timestamps and request IDs where available. Do not repeatedly change DNS when the server is returning an application error.
Operational basics
Keep software patched, restrict administrative access, use least-privilege credentials, and store secrets outside public source files. Back up both data and configuration. Test restore procedures. Use logs that help investigate incidents while limiting personal information to what the service actually needs. Monitor a real user journey, not only whether a process is running.
A deployment checklist should include the production URL, certificate coverage, redirects, response status for important routes, form behavior, database migration, backups, rollback, and cache invalidation. A change is not complete until the service is tested from the user’s perspective.
Frequently asked questions
Is a web server the same as a host? A web server is software or infrastructure that responds to web requests. A host is the provider or environment that runs it.
Does HTTP mean the website is unsafe? HTTP does not encrypt the connection like HTTPS. Do not submit sensitive information over an unencrypted connection. HTTPS still cannot guarantee that a site is honest.
Does a database store every website page? No. Static pages may be files, while dynamic applications may store content or account data in a database.
Why does the homepage work but a page return 404? The homepage route may exist while a specific file or application route does not. Check the path and deployment configuration.
For protocol details, see the IETF specifications HTTP Semantics, RFC 9110 and HTTP/1.1, RFC 9112.