HTTP / Website ReachabilityLevel 1 — BasicHigh severity

HTTP Reachability: Why Won't This Website Load?

Using curl and browser DevTools to see exactly what happens when a website is requested.

Tools required: curl, browser DevTools

Overview

Once DNS and the port are confirmed working, the next layer to check is the actual HTTP response - what status code comes back, and whether the connection even completes.

Step-by-Step Manual Check

1

Request the page with full verbose detail

OSI Layer 7

curl -v shows every phase of the request: DNS, TCP connect, TLS handshake, request headers sent, and response headers received - all in one view.

curl · cross-platform
curl -v https://example.com

Replace with the actual URL. Add -L to follow redirects automatically.

Healthy result

* Connected to example.com (93.184.216.34) port 443
* SSL connection using TLSv1.3
> GET / HTTP/1.1
< HTTP/1.1 200 OK
< content-type: text/html
(a 2xx status code and readable response headers)

Problem result

curl: (7) Failed to connect to example.com port 443: Connection refused
  -- OR --
curl: (28) Connection timed out
  -- OR --
< HTTP/1.1 500 Internal Server Error

What it means

Error (7)/(28) means you never even got an HTTP response - go back to the Ports & Firewall guide, this isn't an application problem yet. A 4xx means the request reached the server but was rejected (client-side issue - auth, bad URL). A 5xx means the server accepted the request but failed while processing it (server/application-side issue).

If unresolved, escalate to: Level 1 — Basic

2

Check the response in a real browser with DevTools open

OSI Layer 7

The Network tab shows the exact same request/response as curl, but also reveals redirect chains, mixed-content warnings, and blocked resources that curl alone won't surface.

Browser DevTools · cross-platform
F12 (or right-click > Inspect) > Network tab > reload the page

Healthy result

The main document request shows Status 200, and the Response tab shows real HTML content.

Problem result

Status shown in red (4xx/5xx), or the request never completes (stuck 'pending'), or a chain of 3xx redirects that never resolves.

What it means

A long redirect chain that never lands on a 200 is a classic 'redirect loop' - often caused by conflicting HTTPS-redirect rules between a CDN and the origin server. 'Pending' forever usually means the server accepted the TCP connection but never sent a response (an application hang, not a network issue).

If unresolved, escalate to: Level 2 — Intermediate

3

Check server logs if you manage the origin (escalation step)

OSI Layer 7

Once you've confirmed the request reaches the server (a real status code comes back, even an error one), the remaining investigation moves to server-side application logs, which requires access most L1/L2 staff won't have.

Server access (SSH/hosting panel) · cross-platform
tail -f /var/log/nginx/error.log   (example for an Nginx-fronted app - adjust path per your stack)

Healthy result

No new error entries appear when you repeat the failing request.

Problem result

A stack trace, database connection error, or out-of-memory message appears exactly when the request fails.

What it means

This confirms the failure is happening inside the application itself, not the network path - hand this off to whoever owns the application code/infrastructure.

If unresolved, escalate to: Level 3 — Expert / Critical

Interpreting the Results

Work outward from the response: no response at all -> network/port problem (see that guide). A response with an error code -> now it's about WHICH code. 4xx = something about the request itself. 5xx = something broke on the server while handling a request it accepted.

Common Causes

SymptomLikely CauseFix
403 ForbiddenA WAF/CDN security rule is blocking the request, or file permissions are wrong on the serverCheck CDN/WAF logs for the specific rule that triggered; verify server file permissions.
502 Bad Gateway / 504 Gateway TimeoutA reverse proxy/CDN can't get a response from the actual application serverCheck whether the origin application server is running and responsive.
Endless redirect loopCDN and origin server both trying to force HTTPS redirects, conflicting with each otherSet the CDN's SSL/TLS mode correctly (e.g. Full/Full Strict) so it stops re-redirecting.

Automated by

Diagnostic Suite - Site Latency Diagnostic (Option 2)

Runs the equivalent curl-based HTTP transaction analysis automatically, including status code classification and a full PDF report.