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

Webサイトにアクセスする時、私たちはURLを打ち込むだけですが、その裏側では壮大な「郵便配達」のようなドラマが繰り広げられています。

皆さんは、「1つのIPアドレス（Webサーバーの住所）」で、「何百ものWebサイト」が同居している不思議に気づいたことはありますか？今回は、現代のインターネットを支える縁の下の力持ち、「HTTP/1.1のHostヘッダー」について、一緒に深掘りしていきましょう。

—

まずは、Webサーバーを「大きなアパート」だと想像してみてください。

IPアドレス（例：192.0.2.1）
これは「アパートの所在地」です。郵便屋さんはこの住所にたどり着くことはできますが、建物に到着したあと、誰宛の荷物かを知る必要がありますよね。
Hostヘッダー
これは「部屋番号と宛名」です。アパート（サーバー）に届いた荷物（リクエスト）に、「この荷物は、301号室の『技術ブログ様』宛ですよ」と書かれたラベル。これこそがHostヘッダーの役割なんです。

HTTP/1.0の頃は、この「部屋番号」の仕組みが未発達でした。しかし、Webが爆発的に普及し、IPアドレスが足りなくなると、「1つの住所（IP）に、たくさんの住人（ドメイン）を詰め込む」必要が出てきました。そこで登場したのがHTTP/1.1の「Hostヘッダー」というルールです。

—

HTTP/1.1の仕様では、ブラウザからのリクエストには必ず「Hostヘッダー」を含めることが義務付けられています。もしこれが欠けていると、サーバーは迷子になってしまいます。

例えば、あなたがサーバー管理者だとして、`example.com` と `sample.net` という2つのサイトを1台のサーバーで運営しているとします。

1. ブラウザからのリクエスト

2. サーバーの困惑

サーバーはどちらを出せばいいか分からず、とりあえず「デフォルト設定のページ」を返すか、エラー（400 Bad Request）を吐き出すことになります。これでは、ユーザーが求めているページにたどり着けませんよね。

—

エンジニアとして現場に出ると、ブラウザの開発者ツールや、`curl` コマンドで通信を確認する場面が必ず来ます。実際にどんなやり取りが行われているか、覗いてみましょう。

GET /index.html HTTP/1.1 # どのファイルが欲しいか？
Host: example.com # 【超重要】どのサイトのファイルか？
User-Agent: Mozilla/5.0 # どんなブラウザを使っているか？

もし、あなたがデバッグ中にHostヘッダーが正しく送られているか確認したいときは、ターミナルでこんなコマンドを打ってみてください。

-v は「詳細（Verbose）を表示する」という意味です
curl -v http://example.com

実行すると、ズラズラと流れる文字列の中に `> Host: example.com` という行が見つかるはずです。これが、サーバーに対する「宛先ラベル」です。

—

現場で「なぜか特定のサイトが表示されない」「設定したはずのドメインなのに、別のサイトの画面が出る」といったトラブルに遭遇したら、まず疑うべきはHostヘッダーです。

プロキシやロードバランサーを挟んでいる場合
中継地点の機器が、気を利かせてヘッダーを書き換えたり、削除してしまったりすることがあります。
IP直接アクセスをしている場合
`curl` などでIPアドレスを直接指定すると、HostヘッダーがIPアドレスになってしまい、サーバー側でドメイン名と一致せずエラーになることがあります。その場合は、このように強制的にヘッダーを付与してテストします。

ヘッダーを偽装（指定）して送るテクニック
curl -H “Host: example.com” http://192.0.2.1/

—

「HTTP/1.1のHostヘッダー」という名前を聞くと難しく感じるかもしれませんが、要は「大きなサーバーという建物の中で、正しい部屋に案内するための名札」です。

インターネットの仕組みは、こうしたシンプルで人間味のあるルールの積み重ねでできています。最初は難解な仕様書に見えても、今回のように「現実世界の郵便物」に例えて考えると、パケットの流れが少しずつ見えてくるはずです。

もし現場で通信がうまくいかないときは、ぜひ「今、サーバーは宛先を正しく理解できているかな？」と想像してみてください。それが、優秀なインフラエンジニアへの第一歩ですよ！