【入門編】HTTPヘッダーフィールド：Hostヘッダーの必須性とバーチャルホスト – HTTPプロトコル・通信規格実践ガイド

みなさん、こんにちは。ネットワークの深淵を愛するエンジニアとして、今日はインターネットを支える「一番身近で、実は奥深い」仕組み、HTTPの「Hostヘッダー」についてお話ししましょう。

「えっ、HTTP？なんだか難しそう」と思った方、安心してください。実はこの仕組み、私たちが毎日使っている「郵便システム」と全く同じ考え方で動いているんです。一緒に紐解いていきましょう！

—

HTTPの歴史を振り返ると、最初の頃（HTTP/0.9というバージョンですね）は、とてもシンプルでした。

当時は「1つのサーバー（住所）」には「1つのWebサイト（住人）」しか住んでいませんでした。だから、ブラウザはサーバーのIPアドレス（郵便番号と番地）さえわかれば、「とりあえずそこへ行って、何かちょうだい！」と頼めば、決まったページが返ってきたんです。

しかし、インターネットが爆発的に普及すると問題が起きました。「サーバー（住所）が足りない！」という事態です。IPアドレスという資源は貴重です。一軒の家（サーバー）に一人しか住めないのは、あまりに非効率ですよね。

そこで登場したのが「バーチャルホスト」という技術です。
これは、一軒の大きなマンション（1つのIPアドレスを持つサーバー）に、たくさんの住人（複数のWebサイト）が同居する仕組みです。

ここで、ある難問が発生します。郵便配達員（パケット）が「このマンションの101号室に手紙を届けて！」と言っても、マンションの管理人は困ってしまいます。「マンション（IPアドレス）までは来たけど、誰宛の手紙かわからないよ！」と。

そこで、HTTP/1.1というルールで「必須」になったのが、「Hostヘッダー」という名札です。

—

HTTPリクエストを送る際、私たちがブラウザを通じて送っているのは、単なるデータではありません。そこには、このような「名札」が必ず添えられています。

GET /index.html HTTP/1.1
Host: example-blog.com ← ここが「Hostヘッダー」！
User-Agent: Mozilla/5.0…

この `Host: example-blog.com` という一行があるおかげで、サーバー側の管理人は「ああ、これは『example-blog.com』さん宛の郵便ですね。はい、こちらの部屋（ディレクトリ）へどうぞ！」と、正確にコンテンツを届けることができるのです。

もしこのHostヘッダーがなかったら、サーバーは「どのドメインのページを表示すればいいのかわからない！」とパニックになり、エラーを返してしまうことになります。

—

ネットワークの現場でよくあるトラブルに、このHostヘッダーの不一致があります。例えば、開発中にローカル環境へアクセスする際、こんな経験はありませんか？

「IPアドレスでは繋がるのに、ドメイン名でアクセスすると404エラーになる」

これは、サーバーが「そのドメイン名のHostヘッダーを受け取っても、自分の管理下にない」と判断している証拠です。サーバーの設定ファイル（Nginxの例）を見てみましょう。

サーバーの設定（Nginxの例）
server {
listen 80;
# ここに書かれたHostヘッダーと一致する時だけ、このサイトを表示するよ！
server_name example-blog.com;

location / {
root /var/www/my-blog; # このフォルダの中身を返します
}
}

エンジニアとして覚えておいてほしいのは、「サーバーはHostヘッダーを見て、自分のどの引き出しを開けるかを決めている」という点です。デバッグをする際は、まず「正しいHostヘッダーが飛んでいるか？」を疑うだけで、解決までの時間が劇的に短縮されますよ。

—

HTTPのHostヘッダーについて、少し身近に感じていただけたでしょうか？

この小さな一行のヘッダーがあるおかげで、今日のインターネットは限られた資源の中で、何十億ものWebサイトが共存できているのです。

ネットワークの世界に触れ始めたばかりの皆さんが、ブラウザの更新ボタンを押したとき、裏側で「Hostヘッダーという名札」が元気に飛び交っている姿を想像できたら……もう立派なインフラエンジニアの入り口に立っていますよ！

これからも、一緒にネットワークの面白い世界を探求していきましょうね。