Requests and responses: what happens when someone opens your site

Loading a page is DNS lookup, then TCP connection, then TLS handshake, then an HTTP request and response, in that order. If a page won't load, the fix is almost always in one of those four places: DNS isn't pointing where you think, the connection can't be established, the server is returning an error code, or the response body itself is broken. Knowing the order these happen in tells you where to look first.

The full round trip

When someone types your domain into a browser, here's what happens, in order:

1. DNS lookup. The browser asks a DNS resolver to translate your domain into an IP address. This is a lookup against records in your DNS Zone Editor (A, AAAA, CNAME, MX and TXT records are managed there). If DNS is misconfigured or hasn't propagated, the browser never learns which server to talk to, and you get a "can't find server" error, not a slow page. This step is also why nameserver changes (edited under Domains, not DNS Zone Editor) take time: resolvers around the world cache answers until each record's TTL expires.
2. TCP connection. Once the browser has an IP, it opens a TCP connection to that server, normally on port 443 for HTTPS or port 80 for plain HTTP. This is a handshake: three packets exchanged to agree the connection is open, before a single byte of your page has been requested.
3. TLS handshake. For HTTPS, the browser and server then negotiate encryption: the server presents its SSL certificate, the browser verifies it against a trusted certificate authority, and they agree on a shared key for the session. A free Let's Encrypt certificate is auto-issued for hosted domains once DNS points at the server, and it renews automatically, so this step is usually invisible. If the certificate is missing, expired, or issued for the wrong domain, the browser blocks the page with a warning before any content loads.
4. HTTP request. With a secure connection open, the browser sends the HTTP request: a method (GET for a normal page load), a path, and headers describing the browser, accepted content types, cookies, and the Referer (the page that sent the visitor here, if any). On most hosting accounts, Hotlink Protection can use that header to block image requests from other sites.
5. Server processing. The server (LiteSpeed, in Flashcloud's case) receives the request, runs it through PHP if the page is dynamic, checks LiteSpeed Cache for a stored copy if not, queries the database if needed, and assembles a response.
6. HTTP response. The server sends back a status code, response headers, and a body: the HTML, image, or other content.

Status codes: what the number means

The three-digit status code at the front of every response tells you which of five categories happened:

• 2xx: success. 200 OK is the normal case. That's your page.
• 3xx: redirect. 301 means moved permanently (search engines transfer ranking to the new URL), 302 means moved temporarily (they don't). A redirect loop, where A sends the browser to B which sends it back to A, shows up as a browser error like "too many redirects," often caused by conflicting rules between your site's .htaccess and a proxy layer in front of it.
• 4xx: the client's request has a problem. 404 Not Found means the path doesn't exist on the server. 403 Forbidden means the server understood the request but refuses it: wrong file permissions, a blocked IP, or a security rule.
• 5xx: the server hit a problem trying to fulfill a valid request. 500 Internal Server Error usually means a PHP script crashed. Check the site's error log (Errors, under Metrics in cPanel, or the equivalent panel in Meridian) to find the line that failed. 502 and 504 point at a backend or upstream timing out rather than your PHP code itself.

Where caching fits in

Not every request reaches your PHP code. LiteSpeed Cache (pre-configured on WordPress installs, alongside Redis object cache) can serve a stored copy of a page directly from the web server, skipping PHP execution. It also skips the database entirely. If your hosting has Cloudflare CDN proxying enabled, an even earlier layer can answer the request from a datacenter close to the visitor, before it reaches your server at all. This is why a change to a page sometimes doesn't appear immediately: you're looking at a cached response, and purging the cache (Manage CDN, or the Cloudflare CDN page's per-domain purge) forces a fresh one.

When to open a ticket

If you're seeing a specific status code you don't understand, a redirect loop, or requests that time out inconsistently, that's a good reason to open a support ticket through the portal. Include the exact URL, the status code or error message, and roughly when it started.