Webサイトのインフラを外から推定する順番

しろまえ殿は、Webサイトの運営基盤を調べるとき、いきなり一つのサービス名へ決め打ちしない。 HTTP、DNS、IP所有者の順に観測し、最後に補助ツールで照合する。

最初はレスポンスを見る

HTTPレスポンス（Webサーバーから返る応答）のヘッダーには、前段のサービスが手がかりを残すことがある。 curl -I https://example.invalid/ のように、本文を取得せずヘッダーだけを見る。

Server、via、x-* のような項目を確認する。 CDN（利用者の近くからコンテンツを配る中継網）やPaaS（アプリ実行環境を提供するサービス）の固有ヘッダーがあれば、候補を絞れる。

ただし、ヘッダーは消したり書き換えたりできる。一つ見つけただけで確定しない。

たとえば、店の看板だけで建物の所有者まで断定しないのと同じだ。看板は入口の手がかりにとどめる。

次にDNS（ドメイン名をIPアドレスへ変換する仕組み）を調べる。 dig example.invalid CNAME と dig example.invalid A で、別名とIPアドレスを確認する。

CNAMEが配信サービスのドメインを指していれば、前段の構成が見えることがある。 Aレコードが複数なら、分散や負荷分散の可能性がある。ただし、DNSだけで実際のサーバー配置を確定してはいけない。

IPが分かったら、WHOIS（IPアドレスの登録情報を調べる仕組み）で所有組織を確認する。ここで分かるのは、通常はアドレス帯の管理者であって、契約者や実サーバーの場所ではない。

結果は「CDNらしい」「クラウド事業者の帯域らしい」「専用サーバーの可能性がある」といった仮説として記録する。確定表現を避けることが大切だ。

ブラウザー拡張や公開調査サービスは、技術スタック（使われているソフトウェア群）の候補をまとめてくれる。便利だが、推定結果である。

しろまえ殿は、レスポンスヘッダー、DNS、WHOISの結果と照合してから採用した。サイトへログインしたり、管理画面を探したりする必要はない。公開情報だけで、読み取り専用の調査に収める。

調査の終わりには、観測事実と推定を分けて書く。その一手間が、誤った事業者名を報告する事故を防ぐ。クルーはこの順番なら、外から見える情報だけで十分に判断材料を作れると確認した。