HTTP / HTTPS Check

Send an HTTP request to a URL and inspect the response status, headers, and timing.

TL;DR

An HTTP check sends a real HTTP or HTTPS request to a URL and reports the status code, response headers, redirect chain, and timing breakdown. It is the most accurate single test of whether a website or API endpoint is actually working from a given location.

What it is

HTTP is the protocol of the web. Almost every public-facing service speaks it, either directly (websites, REST APIs, webhooks) or as a transport for richer protocols (GraphQL, WebSockets upgrade, gRPC over HTTP/2).

An HTTP check goes beyond reachability. It performs a full request and answers questions like: did the server respond? What status code came back? How long did each stage take? Where did the request get redirected? What security and caching headers does the response carry?

How it works

An HTTP request, simplified:

1. DNS resolution of the hostname (A or AAAA record lookup)
2. TCP connection to the resolved IP on the chosen port (80 for HTTP, 443 for HTTPS)
3. TLS handshake, if HTTPS, negotiating cipher suite and certificate validation
4. Request send: client transmits the request line, headers, and (for POST/PUT) a body
5. Time to first byte: server processes the request and starts streaming a response
6. Response receive: client reads status line, headers, and body
7. Connection close or keepalive

The check measures each stage separately, so you can see whether a slow response is caused by DNS, network connection, TLS setup, server processing, or download.

HTTP status code categories

When to use it

• Confirm a website or API returns the expected status code
• Diagnose slow page loads by breaking timing down into DNS, connect, TLS, TTFB, and download
• Verify redirect chains (HTTP to HTTPS, www to apex, country-specific redirects)
• Inspect security headers (HSTS, CSP, X-Frame-Options, etc.)
• Validate cache headers and CDN behaviour
• Detect geo-blocking or regional CDN failures
• Confirm certificate chains and HTTPS are working before deeper TLS analysis
• Validate webhooks and API endpoints respond as expected from external networks

Running it on networktoolkit.io

Select http_check, enter a URL, and the request runs from each of our distributed workers with per-worker results. Sample output:

URL:           https://example.com/
Worker:        lhr-01 (London)

Resolved IP:   93.184.216.34 (IPv4)
Status:        200 OK
HTTP version:  HTTP/2
TLS:           TLS 1.3, X25519, AES_256_GCM_SHA384

Timing breakdown:
  DNS lookup:         14 ms
  TCP connect:        12 ms
  TLS handshake:      38 ms
  Time to first byte: 95 ms
  Content download:   18 ms
  Total:             177 ms

Selected response headers:
  content-type:               text/html; charset=UTF-8
  cache-control:              max-age=604800
  strict-transport-security:  max-age=31536000
  x-content-type-options:     nosniff

For a request that redirects:

URL:           http://example.com/
Status chain:  301 -> 200

Step 1:
  http://example.com/
  301 Moved Permanently
  Location: https://example.com/

Step 2:
  https://example.com/
  200 OK

Reading the results

Common scenarios

Limitations & gotchas

• A 200 OK does not mean the page is correct. The server returned success, but the body could still contain an error message rendered as a 200 — a common mistake in SPAs and APIs.
• CDNs hide origin behaviour. A cached response can return 200 OK even when the origin is down. Cache headers reveal this; Age and X-Cache are useful.
• Bot detection and WAFs may treat external test workers as suspicious and return 403, 503, or CAPTCHA challenges.
• HTTP/3 over QUIC uses UDP and may be blocked on networks that filter it; some workers may fall back to HTTP/2.
• Body content is read only enough to measure timing. Full content inspection is not the goal; use a dedicated synthetic monitoring tool for content checks.

Security & privacy notes

HTTP checks emit the same kind of traffic as a normal browser. Security headers worth checking on production sites:

• Strict-Transport-Security: forces HTTPS on future requests
• Content-Security-Policy: restricts where scripts and assets can load from
• X-Content-Type-Options: nosniff: prevents MIME sniffing
• Referrer-Policy: controls Referer header behaviour
• Permissions-Policy: restricts browser features available to the page

For HTTPS endpoints, an HTTP check tells you whether TLS works at all. For deeper certificate inspection, use the SSL check.

Standards & references

• RFC 9110 — HTTP Semantics
• RFC 9111 — HTTP Caching
• RFC 9112 — HTTP/1.1
• RFC 9113 — HTTP/2
• RFC 9114 — HTTP/3
• RFC 6797 — HTTP Strict Transport Security (HSTS)
• IANA HTTP Status Code Registry

FAQ

What is the difference between HTTP and HTTPS?

HTTP is the plaintext protocol on port 80. HTTPS is HTTP wrapped in TLS, usually on port 443. HTTPS provides confidentiality, integrity, and server authentication. Modern best practice is HTTPS everywhere; HSTS prevents downgrade to plaintext.

Why does my site return 200 from one region but 403 from another?

Geo-blocking, WAF rules, or country-specific access policies. The body of the 403 often hints at the cause; common patterns are Cloudflare's challenge pages, AWS WAF's default block page, and origin-level country bans.

My TTFB is slow but everything else is fast. What does that mean?

TTFB is the time the server takes to start responding. Slow TTFB points to backend processing: database queries, downstream API calls, cold starts on serverless platforms, or thread starvation in the application.

What is a healthy response time for a web page?

For a static page or CDN-served content, under 200 ms total is excellent. Under 500 ms is good. Over 1000 ms feels slow to users. Dynamic API responses depend entirely on the workload.

Should I be worried about a 502 Bad Gateway?

Usually yes if it persists. 502 means the upstream server failed to respond properly to a proxy or CDN in front of it. Brief 502s during deployments are normal; sustained 502s are an origin outage.