Skip to content

MS_HostHeader

Jump to bottom
nishi_74322014 edited this page Aug 19, 2026 · 1 revision

ホストヘッダー

概要

補足（Host ヘッダーが HTTP/1.1 で必須になった理由）: HTTP/1.0 では
Host ヘッダーが任意だった。これは、

【HTTP/1.0 の前提】 1 つの IP アドレス = 1 つの Web サイト
  GET /index.html HTTP/1.0
  ↑ 宛先 IP に到達した時点でどのサイトか自明だった

という時代の設計である。
しかし IPv4 アドレスの枯渇により、
1 つの IP で複数サイトを運用する必要が生じた。

【HTTP/1.1】 Host ヘッダーで宛先サイトを明示する（必須）
  GET /index.html HTTP/1.1
  Host: www.example.jp     ← これでサーバがサイトを判別する

これが名前ベースの仮想ホストであり、
本ページの 2 つの用途はいずれもこの仕組みの応用である。

なお、HTTP/2 以降では :authority 疑似ヘッダーが
同じ役割を担う（HTTP/2）。

用途

リバース・プロキシで、外部アクセスを特定のサーバにルーティングする

NAPT

NAPT では、

  • グローバル IP アドレス＋ポートを
  • プライベート IP アドレス＋ポートに

振り分ける。

リバース・プロキシ

リバース・プロキシであれば、ホストヘッダーを見て、
プライベート IP アドレス＋ポートに振り分けることができる。

補足（NAPT とリバース プロキシの決定的な違い）: この対比が
本節の要点である。どの層の情報で振り分けるかが違う。

NAPT リバース プロキシ
層 L4（IP・ポート） L7（HTTP）
判断材料 宛先ポート番号 Host ヘッダー、URL パス
必要なもの サイトごとに別ポート 1 ポートで複数サイト
利用者から見て URL にポート番号が出る 出ない
TLS 素通し 終端できる（＝中身を見て振り分けられる）

つまり、NAPT では

https://example.jp:8443/ → 内部サーバA
https://example.jp:9443/ → 内部サーバB   ← ポート番号がユーザに見える

となってしまうが、リバース プロキシなら

https://a.example.jp/ → 内部サーバA      ← Host ヘッダーで判別
https://b.example.jp/ → 内部サーバB

と、同じ 443 番ポートで振り分けられる。

なお、HTTPS の場合は暗号化されているため、
復号する前に Host ヘッダーは読めない。
そこで **SNI（Server Name Indication）**が使われる
（TLS ハンドシェイクの ClientHello に平文でホスト名を載せる）。
リバース プロキシは SNI で証明書を選び、
復号してから Host ヘッダーで振り分ける、という二段構えになる。

Microsoft 系では
Application Request Routing (ARR)がこの役割を担う。
Azure ではAzureのGW / LB的なモノ。を参照。

単一のサーバ・マシンで複数のWebサイトを運用する方法の一つ

以下の様に、単一のサーバ・マシンで複数の Web サイトを運用する場合の方法の一つとして使用できる。

Webサイト毎にリスニングするポート番号を変更する。

  • 既定は HTTP：80、HTTPS：443
  • 既定値以外のポート番号を使用する場合、
    クライアントは「http://www.example.jp:12345/index.html」のように
    ポート番号を URL に加えなければならない。

単一のサーバ・マシンに複数のIPアドレスを使用する。

NIC 増設は必須でないが、DHCP 運用は不可になる（静的 IP アドレス）。

ホストヘッダー

複数の Web サイトで 1 つのリスニング・ポートを共有し、
ホストヘッダー（HTTP 1.1 準拠）を使用して振り分ける。

  • Web サイトは、着信した Web 要求をホストヘッダー名に基づいて受け付ける。
  • ポート番号を URL に加える必要がないので、ポート番号をユーザに意識させない。
  • ホストヘッダー名をそのイントラネットの名前解決システム（DNS 等）に登録する。

補足（3 方式の比較）: 本節が挙げる 3 つの方式を並べると
選択の基準がはっきりする。

方式 呼び名 長所 短所
ポート番号を変える ポート ベース 設定が最も簡単。DNS 不要 URL にポート番号が出る。ファイアウォールで各ポートを開ける必要
IP アドレスを増やす IP ベース HTTP/1.0 でも動く。SNI 非対応クライアントでも HTTPS が使える IP アドレスを消費。静的 IP が必要
ホストヘッダー 名前ベース 1 IP・1 ポートで無制限。URL が自然 DNS 登録が必要。HTTPS には SNI が必要

現在は名前ベースが標準であり、
IP ベースを選ぶ理由はほぼ無くなった
（SNI 非対応クライアントは事実上消滅しているため）。

IIS での設定上の注意点を挙げておく。

注意 内容
バインドは「IP:ポート:ホスト名」の 3 つ組 3 つとも一致する必要がある
既定サイトの *:80:（ホスト名なし） すべてを受けるため、先に一致してしまうことがある
HTTPS のホストヘッダー IIS 8 以降で SNI に対応（「サーバー名表示を要求する」にチェック）
ワイルドカード *.example.jp の形で指定可能
netsh http show sslcert 証明書とポートの紐付けは HTTP.sys 側にある

なお、名前解決の登録を忘れるのが最も多い失敗である。
ホストヘッダーで振り分ける以上、
クライアントがその名前でアクセスできなければ意味がない。
検証時は hosts ファイルで代用できるが、
本番では DNS への登録が必須になる（DNSサーバ）。

参考

1IPアドレス、複数Webサイト

  • 1 つのサーバの 1 つの IP アドレスに Web サイトを追加する時、
    Listening ポートが重複しないように変更してインストールする。

1NIC、複数IPアドレス

ホストヘッダー

Tags: 移行, Windows, IIS

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally