KernelHost Tools HTTP Header Inspector

HTTP Header Inspector

Enter a full URL. KernelHost fetches the response live from Frankfurt FRA01: status code, all headers, redirect chain, TLS verify and security header audit.

Check URL

What is an HTTP header

HTTP headers are key value pairs that a web server sends with every response, before the actual content. They control how a browser renders the page, whether it may cache it, whether it may embed it in iframes, which scripts it may run, and whether it must enforce HTTPS.

When a URL is requested, this inspector returns the status code, every response header, the full redirect chain, the HTTP protocol used, the verified TLS certificate, and a security audit of the most important protection headers.

  • Status code: 200 OK, 301 Redirect, 404 Not Found, 500 server error, and so on. The color badge shows the class at a glance.
  • Redirect chain: Every hop from HTTP to HTTPS, from www to bare domain, every tracker redirect is exposed.
  • Security headers: HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy in one audit block.
  • TLS verification: Certificate, issuer, validity and the OpenSSL verify code. Self-signed or expired certs become obvious instantly.

Which security headers every website should set

Six headers cover the majority of common web attack vectors. Setting all six dramatically shrinks the attack surface against clickjacking, MIME-sniffing tricks, XSS and mixed content.

  • Strict-Transport-Security (HSTS): Forces HTTPS, prevents SSL stripping, with the preload flag eligible for the Chrome and Firefox preload lists.
  • Content-Security-Policy (CSP): Whitelist what scripts and styles may load. The toughest XSS defense available in the browser.
  • X-Frame-Options: DENY or SAMEORIGIN against clickjacking, alternatively frame-ancestors in the CSP.
  • X-Content-Type-Options: nosniff: Prevents browsers from guessing the Content-Type and, for example, executing an uploaded image as JavaScript.
  • Referrer-Policy: strict-origin-when-cross-origin is the default that protects privacy without breaking analytics.
  • Permissions-Policy: Turns off camera, microphone, geolocation, USB if the page does not need them.

A securityheaders.com score of A or A+ requires all six. This inspector shows instantly which one is missing.

Understanding HSTS, CSP and CORS

HSTS (Strict-Transport-Security) tells the browser to use HTTPS only for this domain from now on, even if the user types http://. Once set with max-age=63072000 (two years), the site is HTTPS-only for two years without asking the server. includeSubDomains extends this to every subdomain. preload additionally enables inclusion in the Chrome and Firefox preload lists.

CSP (Content-Security-Policy) is a whitelist: only explicitly allowed resource sources may load. default-src 'self' blocks everything outside the own origin. script-src, style-src, img-src, connect-src, frame-src specify exceptions. nonce or hash based CSPs additionally allow inline scripts safely. A correctly tuned CSP is the strongest XSS defense the web offers.

CORS (Cross-Origin Resource Sharing) is not protection but permission: Access-Control-Allow-Origin states which foreign origins may read the response. Misconfigured (Access-Control-Allow-Origin: * combined with cookies) it opens a hole; configured correctly it allows safe API calls from your own SPA.

Redirect chains and SEO

Every redirect costs one round-trip. A chain http -> https -> www -> /de/ sums up to four hops and can take more than a second on a slow mobile connection before the actual content even begins to load. Search engines additionally penalize long chains and lose a small fraction of link equity at each hop.

  • 301 vs 302: 301 is permanent and cached, 302 is temporary. Permanent migration redirects must use 301, otherwise Google keeps the old URL indexed.
  • Link directly: Internal links should always point at the final URL, never at a known redirect, otherwise every click pays an unnecessary hop.
  • Loop detection: More than 5 hops or loops are misconfigurations. The inspector aborts after 10 redirects and makes the problem visible.

A cleanly structured domain has at most one redirect (HTTP -> HTTPS, or bare -> www), never more.

Cache-Control best practices

Cache-Control decides whether browsers, CDNs and proxies may reuse a response. A well-tuned Cache-Control reduces origin load, speeds up repeat visits by orders of magnitude and directly improves Core Web Vitals.

  • Static assets: public, max-age=31536000, immutable for hashed bundle files (style.abc123.css). One year of cache, no revalidation.
  • HTML pages: no-cache, must-revalidate (every request validates but 304 Not Modified is allowed), or s-maxage=60 for short-lived CDN edge caching.
  • Private content: private, no-store for responses with session cookies or personalized content. Never let a shared cache store these.
  • ETag and Last-Modified: Provide validators for the 304 Not Modified response. They save bandwidth and are set for free by the webserver (NGINX, Apache).

Common debugging scenarios

From real practice, this is what the header inspector is actually used for:

  • Check CDN cache status: Cloudflare exposes cf-cache-status (HIT, MISS, BYPASS), Fastly uses x-cache, KeyCDN x-cache. Visible directly in the header block.
  • Verify cookie flags: Set-Cookie headers are listed with every attribute. Secure, HttpOnly, SameSite must be set for session cookies.
  • Verify HTTPS migration: An http:// input must yield a 301 to https:// plus an HSTS header in the final response. Both visible in the redirect chain and the audit.
  • Bot detection rules: WAFs often set x-firewall, x-rate-limit-* or server: cloudflare. Visible in the server header and the header audit.
  • Isolate TLS problems: A verify code != 0 suggests expired or self-signed certificates; the issuer field reveals immediately whether Let's Encrypt, Sectigo, DigiCert or an internal CA is in use.

KernelHost sets these headers out of the box

Every KernelHost web hosting plan ships its NGINX default vhost with HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and a conservative CSP already on. Customer domains do not need to configure anything, the values arrive automatically.

On KernelHost VPS and dedicated servers our server tweak bundle (auto-setup script) ships the same default configuration, plus per-vhost overrides via NGINX includes. Reaching A+ on securityheaders.com is a two-minute job there.

Privacy

The HTTP Header Inspector operates fully server-side on KernelHost infrastructure (Frankfurt FRA01, Germany). No external APIs, no third-party tracking.

  • URLs you enter are used solely for the single request and are not persistently stored.
  • The target server's response is rendered in your browser and discarded from server memory afterwards.
  • Rate-limit data only holds an anonymous hash of the client IP for up to 60 seconds, to prevent abuse.
  • The outbound request to the target URL carries the User-Agent KernelHost-Header-Inspector/1.0 and no cookies or auth headers whatsoever.

Frequently asked questions

Why do I not see the same status code as my browser?

Some sites return different responses depending on user-agent or cookie state. The inspector uses a clean user-agent without cookies, that is the raw server response. With geo blocks or A/B tests the code may differ.

What does 405 or 501 mean for a HEAD response?

405 Method Not Allowed or 501 Not Implemented means the server blocks HEAD requests. The inspector then switches automatically to GET and discards the body. The result row reads "Method: GET" instead of "HEAD".

Why does TLS verification fail when my browser shows no problem?

Browsers often accept older roots or additional Microsoft/Mozilla/Apple curated roots that are not in the OpenSSL default trust store. Self-signed certificates, internally signed certs, or a missing intermediate are the most common causes.

Can I check http:// URLs as well?

Yes. The inspector accepts both http:// and https://. With http:// there is no TLS block, but you see the server's HSTS response (or lack thereof) and the redirect chain to the https:// variant.

Are private IPs supported (192.168, 10.x, ::1)?

No, for security reasons. The server checks every hostname against a public-IP filter before the request (RFC1918, loopback, link-local and reserved are blocked), to prevent SSRF attacks against internal KernelHost infrastructure.

What is the maximum redirect depth the inspector follows?

Up to 10 redirects, then curl aborts. More than 10 hops in practice almost always indicates a loop or misconfiguration and is reported as an error in the response.

Why do I not see a Set-Cookie header even though the page sets cookies?

Set-Cookie appears only in the immediate server response, not after a redirect. If the final page set the cookie earlier (during a redirect hop), it appears in the redirect chain rather than in the header table. Many modern SPAs additionally set cookies only via JavaScript login, which a server-side inspector cannot see by design.

Are HTTP/3 or QUIC detected?

The request runs over HTTP/1.1 or HTTP/2 (depending on the libcurl build, the KernelHost container uses HTTP/2). An alt-svc header in the response indicates whether the server additionally offers HTTP/3, but the request itself runs over the established H1/H2 connection.

All KernelHost Products

Need more than just tools? Take a look at our commercial hosting lineup.