KernelHost Tools HTTP Header Inspector

HTTP Header Inspector

完全なURLを入力してください。KernelHostがFrankfurt FRA01からライブで応答を取得します: ステータスコード、すべてのヘッダー、リダイレクトチェーン、TLS検証、セキュリティヘッダー監査です。

URLをチェック

HTTPヘッダーとは

HTTPヘッダーはWebサーバーが各応答で本文の前に送信するキーバリューペアです。ブラウザのページレンダリング、キャッシュ可否、iframe埋め込み可否、実行スクリプトの可否、HTTPS強制の有無を制御します。

URLをリクエストすると、本Inspectorはステータスコード、すべてのレスポンスヘッダー、リダイレクトチェーン、使用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を1つの監査ブロックで表示します。
  • TLS検証: 証明書、Issuer、有効期間、OpenSSL verifyコード。自己署名や期限切れは即座に判明します。

すべてのWebサイトが設定すべきセキュリティヘッダー

6つのヘッダーで一般的なWeb攻撃ベクトルの大半をカバーできます。すべて設定するとクリックジャッキング、MIMEスニッフィング、XSS、Mixed Contentに対する攻撃面が大幅に縮小します。

  • Strict-Transport-Security(HSTS): HTTPSを強制し、SSL Strippingを排除します。preloadフラグでChromeとFirefoxのpreloadリストへの掲載が可能になります。
  • 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+を取るには6つすべてが必要です。本Inspectorは欠けているものを即座に表示します。

HSTS、CSP、CORSを理解する

HSTS(Strict-Transport-Security)はブラウザに対し、たとえユーザーがhttp://を入力しても今後はこのドメインに対してHTTPSのみを使うよう指示します。一度max-age=63072000(2年)を設定するとサーバーに尋ねずに2年間HTTPS-onlyになります。includeSubDomainsで効果がすべてのサブドメインに及びます。preloadはさらにChromeとFirefoxのpreloadリストへの掲載を可能にします。

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

各リダイレクトは1往復のコストがかかります。http -> https -> www -> /de/というチェーンは合計4ホップで、低速のモバイル接続ではコンテンツのロード開始までに1秒以上かかることがあります。検索エンジンは長いチェーンをマイナス評価し、各ホップでわずかにリンクパワーを失います。

  • 301 vs 302: 301は永続でキャッシュされ、302は一時的です。永続的な移行は必ず301を使ってください。さもないとGoogleが古いURLをインデックスに残します。
  • 直接リンク: 内部リンクは常に最終URLを指すべきで、既知のリダイレクトを指してはいけません。さもないと毎クリックで余計なホップが発生します。
  • ループ検出: 5ホップ超やループはミス構成です。本Inspectorは10リダイレクトで中止し、問題を可視化します。

綺麗に構成されたドメインはリダイレクトが多くて1つ(HTTP -> HTTPSまたは裸 -> www)で、それ以上にはなりません。

Cache-Controlのベストプラクティス

Cache-Controlはブラウザ、CDN、プロキシが応答を再利用してよいかを決めます。よく調整されたCache-Controlはオリジン負荷を減らし、再訪問速度を桁違いに上げ、Core Web Vitalsを直接改善します。

  • 静的アセット: ハッシュ付きバンドルファイル(style.abc123.css)にはpublic, max-age=31536000, immutable。1年キャッシュ、再検証なし。
  • HTMLページ: no-cache, must-revalidate(リクエストごとに検証するが304 Not Modifiedは可)、または短寿命CDNエッジキャッシュ用にs-maxage=60。
  • プライベートコンテンツ: セッション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を公開します。ヘッダーブロックで直接見えます。
  • Cookieフラグの検証: Set-Cookieヘッダーがすべての属性とともに表示されます。セッションCookieにはSecure、HttpOnly、SameSiteが必須です。
  • HTTPS移行の検証: http://入力はhttps://への301とともに、最終応答にHSTSヘッダーが返るべきです。両方ともリダイレクトチェーンと監査で確認できます。
  • Bot検知ルール: WAFは多くx-firewall、x-rate-limit-*、server: cloudflareなどを設定します。Serverヘッダーとヘッダー監査で見えます。
  • TLS問題の切り分け: verifyコード != 0は期限切れまたは自己署名証明書を示唆し、Issuerフィールドで Let's Encrypt、Sectigo、DigiCert、社内CAのいずれかが即座に分かります。

KernelHostは標準でこれらのヘッダーを設定

KernelHostのすべてのWebhostingプランで、NGINXのデフォルトvhostがHSTS、X-Frame-Options、X-Content-Type-Options、Referrer-Policy、Permissions-Policy、保守的なCSPを既に有効にして配信します。顧客ドメインは設定不要で、値は自動的に応答に乗ります。

KernelHost VPSとDedicatedサーバーでは、サーバーチューニングバンドル(自動セットアップスクリプト)が同じデフォルト設定を提供し、NGINXのincludeでvhost単位の上書きも可能です。securityheaders.comでA+に到達するのは、ここでは2分の作業です。

プライバシー

HTTP Header InspectorはKernelHostインフラ(Frankfurt FRA01、ドイツ)上で完全にサーバーサイドで動作します。外部APIなし、サードパーティトラッキングなしです。

  • 入力されたURLは1回のリクエストにのみ使用され、永続化されません。
  • 対象サーバーの応答はブラウザに描画された後、サーバーメモリから破棄されます。
  • レートリミットデータは悪用防止のためクライアントIPの匿名ハッシュを最大60秒のみ保持します。
  • 対象URLへのアウトバウンドリクエストはUser-Agent KernelHost-Header-Inspector/1.0で、Cookieや認証ヘッダーは一切含みません。

よくある質問

なぜブラウザと同じステータスコードが見えないのですか?

サイトによってはUser-AgentやCookie状態に応じて異なる応答を返します。本Inspectorはクリーンなuser-agentでCookieなしで動くため、生のサーバー応答です。ジオブロックやA/Bテストではコードが異なる場合があります。

HEAD応答での405や501の意味は?

405 Method Not Allowedや501 Not Implementedはサーバーがリクエストをブロックしていることを示します。本Inspectorは自動的にGETに切り替えてボディを破棄します。結果行には "HEAD" ではなく "メソッド: GET" と表示されます。

ブラウザは問題ないのにTLS検証が失敗するのはなぜ?

ブラウザはOpenSSLのデフォルト信頼ストアにない、Microsoft、Mozilla、Appleが管理する古いルートも追加で受け入れることがあります。自己署名証明書、社内CA署名、中間証明書の欠落が最も多い原因です。

http://のURLもチェックできますか?

できます。Inspectorはhttp://とhttps://両方を受け付けます。http://にはTLSブロックはありませんが、サーバーのHSTS応答(または欠如)とhttps://への リダイレクトチェーンが見えます。

プライベートIP(192.168、10.x、::1)はサポートされる?

セキュリティ上の理由で、いいえ。リクエスト前にサーバーが公開IPフィルターでホスト名を検証し、RFC1918、loopback、link-local、reservedをブロックして、KernelHost内部インフラへのSSRF攻撃を防ぎます。

Inspectorが追跡する最大リダイレクト深度は?

最大10リダイレクトで、それ以降はcurlが中止します。実務で10ホップ超はほぼループまたはミス構成で、応答にエラーとして報告されます。

ページがCookieを設定しているのにSet-Cookieヘッダーが見えないのはなぜ?

Set-Cookieはサーバーの直接応答にのみ現れ、リダイレクト後には現れません。最終ページが既にリダイレクトホップの中でCookieを設定済みなら、ヘッダーテーブルではなくリダイレクトチェーンに表示されます。さらに多くの現代SPAはJavaScriptログイン時にだけCookieを設定するため、サーバーサイドInspectorは構造上それを見られません。

HTTP/3やQUICは検出されますか?

リクエストはHTTP/1.1またはHTTP/2で実行されます(libcurlビルドに依存し、KernelHostコンテナはHTTP/2)。応答中のalt-svcヘッダーでサーバーがHTTP/3も提供するかが分かりますが、リクエスト自体は確立されたH1/H2接続上で動きます。

KernelHost 全製品

ツール以上のものが必要ですか?商用ホスティングのラインナップをご覧ください。