KernelHost Tools HTTP Header Inspector

HTTP Header Inspector

输入完整 URL,KernelHost 从 Frankfurt FRA01 实时取回响应:状态码、所有响应头、重定向链、TLS 校验和安全头审计。

检查 URL

什么是 HTTP Header

HTTP Header 是 Web 服务器在每次响应中、在正文之前发送的键值对。它决定浏览器如何渲染页面、是否可缓存、是否可被嵌入 iframe、可执行哪些脚本,以及是否必须强制 HTTPS。

请求一个 URL 时,本检查器返回状态码、全部响应头、完整重定向链、所用 HTTP 协议、已校验的 TLS 证书,以及最重要安全头的审计。

  • 状态码: 200 OK、301 Redirect、404 Not Found、500 Server Error 等。颜色徽章一目了然。
  • 重定向链: 从 HTTP 到 HTTPS、从 www 到裸域、每一次跟踪重定向都会被暴露。
  • 安全头: HSTS、CSP、X-Frame-Options、X-Content-Type-Options、Referrer-Policy、Permissions-Policy 在一个审计区块。
  • TLS 校验: 证书、Issuer、有效期和 OpenSSL verify 码。自签名或过期会立刻显形。

每个网站都该设置的安全头

六个 Header 覆盖大多数常见 Web 攻击向量。全部设置可大幅缩小针对点击劫持、MIME 嗅探、XSS 与 mixed content 的攻击面。

  • Strict-Transport-Security(HSTS): 强制 HTTPS,杜绝 SSL Stripping。带 preload 标志后可加入 Chrome 与 Firefox 的预加载列表。
  • Content-Security-Policy(CSP): 白名单允许加载的脚本与样式来源,是浏览器中最强的 XSS 防御。
  • X-Frame-Options: DENY 或 SAMEORIGIN 防点击劫持,也可在 CSP 中用 frame-ancestors 替代。
  • X-Content-Type-Options: nosniff: 防止浏览器猜测 Content-Type,例如把上传的图片当 JavaScript 执行。
  • Referrer-Policy: strict-origin-when-cross-origin 是默认值,既保护隐私又不破坏分析。
  • Permissions-Policy: 页面不需要时,关闭摄像头、麦克风、地理位置和 USB。

在 securityheaders.com 取得 A 或 A+ 评分,需要全部六个都设置。本检查器即时显示哪一个缺失。

理解 HSTS、CSP 与 CORS

HSTS(Strict-Transport-Security)告诉浏览器从此对该域名只用 HTTPS,即便用户输入 http:// 也是。一旦 max-age=63072000(两年)已设,站点两年内无需询问服务器即始终 HTTPS-only。includeSubDomains 把效力扩展到每个子域,preload 还可申请加入 Chrome 与 Firefox 的预加载列表。

CSP(Content-Security-Policy)是白名单:仅允许显式列出的资源来源加载。default-src 'self' 拒绝同源以外一切。script-src、style-src、img-src、connect-src、frame-src 提供例外。基于 nonce 或 hash 的 CSP 还能安全允许 inline 脚本。配置正确的 CSP 是 Web 上最强的 XSS 防御。

CORS(Cross-Origin Resource Sharing)不是防护而是许可:Access-Control-Allow-Origin 表明哪些外部源可读取响应。配置错误(Access-Control-Allow-Origin: * 配合 Cookie)会打开漏洞;配置正确则允许你自己的 SPA 安全调用 API。

重定向链与 SEO

每个重定向都消耗一次往返。一条 http -> https -> www -> /de/ 链共四跳,在慢速移动网络上可能在内容开始加载前就花掉超过一秒。搜索引擎也会对长链做出负面评价,每跳损失少量链接权重。

  • 301 vs 302: 301 是永久且会被缓存,302 是临时。永久迁移必须用 301,否则 Google 会保留旧 URL 在索引里。
  • 直接链接: 内部链接应始终指向最终 URL,绝不指向已知的重定向,否则每次点击都白白多一跳。
  • 循环检测: 超过 5 跳或形成循环就是误配置。本检查器在 10 个重定向后中止,并把问题暴露出来。

结构干净的域名最多有一次重定向(HTTP -> HTTPS 或裸域 -> www),不应更多。

Cache-Control 最佳实践

Cache-Control 决定浏览器、CDN 与代理是否可复用响应。调好了能减轻源站负载、把回访速度提升数量级,并直接改善 Core Web Vitals。

  • 静态资源: 对带哈希的 bundle 文件(style.abc123.css)使用 public, max-age=31536000, immutable。一年缓存,不再校验。
  • HTML 页面: no-cache, must-revalidate(每次校验,但允许 304 Not Modified),或 s-maxage=60 用于短期 CDN 边缘缓存。
  • 私有内容: 对带 Session Cookie 或个性化内容的响应使用 private, no-store。绝不能让共享缓存存这些。
  • ETag 与 Last-Modified: 为 304 Not Modified 提供校验器。能省带宽,且由 Web 服务器(NGINX、Apache)免费设置。

常见调试场景

实战中本 Header Inspector 真正用于的场景:

  • 检查 CDN 缓存状态: Cloudflare 暴露 cf-cache-status(HIT、MISS、BYPASS),Fastly 用 x-cache,KeyCDN 用 x-cache。在 Header 区块直接可见。
  • 校验 Cookie 标志: Set-Cookie 头会列出全部属性。Session Cookie 必须设 Secure、HttpOnly、SameSite。
  • 验证 HTTPS 迁移: http:// 输入必须返回到 https:// 的 301,最终响应里还应有 HSTS。两者在重定向链与审计中都可见。
  • Bot 检测规则: WAF 常设置 x-firewall、x-rate-limit-* 或 server: cloudflare。可在 Server 头与 Header 审计中看到。
  • 排查 TLS 问题: verify 码 != 0 提示证书过期或自签名;Issuer 字段立刻能看出是 Let's Encrypt、Sectigo、DigiCert 还是内部 CA。

KernelHost 默认设置这些 Header

KernelHost 每个 Webhosting 套餐的 NGINX 默认 vhost 已开启 HSTS、X-Frame-Options、X-Content-Type-Options、Referrer-Policy、Permissions-Policy 与一份保守的 CSP。客户域名无需任何配置,值会自动出现在响应中。

在 KernelHost VPS 与独立服务器上,我们的服务器调优集合(自动安装脚本)提供同样的默认配置,并支持通过 NGINX include 在 vhost 级别覆盖。想在 securityheaders.com 拿 A+,两分钟即可搞定。

隐私

HTTP Header Inspector 完全在 KernelHost 基础设施(Frankfurt FRA01,德国)上服务端运行,不调用外部 API,无第三方追踪。

  • 你输入的 URL 仅用于本次单次请求,不持久化存储。
  • 目标服务器响应在浏览器中渲染后即从服务器内存中丢弃。
  • 速率限制数据仅保留客户端 IP 的匿名哈希,最多 60 秒,用于防滥用。
  • 对目标 URL 的出站请求 User-Agent 为 KernelHost-Header-Inspector/1.0,不携带任何 Cookie 或鉴权头。

常见问题

为什么我看到的状态码与浏览器不同?

有些站点会根据 User-Agent 或 Cookie 状态返回不同响应。本检查器使用干净的 User-Agent 且无 Cookie,是原始服务器响应。遇到地理屏蔽或 A/B 测试时,状态码可能不同。

HEAD 响应得到 405 或 501 是什么意思?

405 Method Not Allowed 或 501 Not Implemented 表示服务器拦截 HEAD 请求。本检查器会自动改用 GET,再丢弃响应体。结果行会显示 "方法:GET" 而不是 "HEAD"。

为什么 TLS 校验失败但浏览器没问题?

浏览器常额外接受 Microsoft、Mozilla、Apple 维护的旧根证书,而这些不在 OpenSSL 默认信任库里。自签名证书、内部 CA 签发证书或缺失中间证书是最常见原因。

可以检查 http:// URL 吗?

可以。本检查器接受 http:// 与 https://。http:// 没有 TLS 区块,但你能看到服务器的 HSTS 响应(或缺失)以及到 https:// 的重定向链。

支持私有 IP(192.168、10.x、::1)吗?

出于安全原因,不支持。请求前服务器会用公网 IP 过滤器校验主机名(RFC1918、loopback、link-local 与 reserved 全部拦截),以防对 KernelHost 内部基础设施的 SSRF 攻击。

本检查器最多跟随多少次重定向?

最多 10 次重定向,超过后 curl 中止。实战中超过 10 跳几乎总是循环或误配,会作为错误返回。

为什么页面设置了 Cookie 我却看不到 Set-Cookie?

Set-Cookie 仅出现在服务器的当次直接响应里,不会出现在重定向之后。如果最终页面在重定向跳转中已经设置了 Cookie,它会出现在重定向链里而非 Header 表。此外许多现代 SPA 仅在 JavaScript 登录时设置 Cookie,服务端检查器天然看不到。

能识别 HTTP/3 或 QUIC 吗?

请求经 HTTP/1.1 或 HTTP/2 发起(取决于 libcurl 版本,KernelHost 容器为 HTTP/2)。响应中的 alt-svc 头可表明服务器是否额外提供 HTTP/3,但本次请求仍走已建立的 H1/H2 连接。

所有 KernelHost 产品

不只是工具?看看我们的商业托管方案。