CDN オリジンルーティング

CDN のルーティングには、クライアントが接続する場所と、エッジが接続するオリジンという 2 つの別々の判断があります。DNS とエニーキャストがエッジロケーションを選び、 そのエッジの設定がオリジンを選んで上流リクエストを構成します。これらの判断を分離 すると、障害を診断しやすくなります。

エッジでのリクエスト識別 #

クライアントは https://www.example.com/docs のような URL から開始します。DNS は エッジアドレスを返し、TLS SNI がハンドシェイク中に www.example.com を識別し、 HTTP リクエストは Host: www.example.com（HTTP/2 と HTTP/3 では同等の :authority フィールド）を持ちます。CDN はこのホスト名とパスを使ってディストリビューションと キャッシュ動作を選択します。

IP アドレスだけではオリジンの識別情報になりません。共有リバースプロキシは 1 つの アドレスで多数のドメインをホストするため、直接テストには想定するホスト名を含める 必要があります。

curl --resolve www.example.com:443:203.0.113.10 \
  https://www.example.com/health

--resolve は特定のアドレスを選択しながら、SNI と HTTP のために URL のホスト名を 保持します。手動でヘッダーだけを指定した生の IP URL を送るより安全で、実際の動作を より正確に表します。

正しい上流ホストを転送する #

オリジンは受信したホストを使って仮想ホストを選択したり、リダイレクトを生成したり、 テナントポリシーを適用したりすることがあります。CDN は閲覧者のホストを保持する、 オリジンのホスト名に置き換える、設定済みの値を転送する、のいずれかを選べます。 意図的に選択してください。

viewer:  https://www.example.com/account
edge:    GET /account  Host: origin.internal.example.net
origin:  routes by Host and returns a response

オリジンの TLS 証明書が origin.internal.example.net を対象としている場合、CDN は 上流 SNI と証明書検証にその名前を使う必要があります。オリジンが必要とする場合は www.example.com を HTTP Host として転送できますが、TLS 検証を弱めてはなりません。

ルーティングとキャッシュの予期しない動作を避ける #

キャッシュキー、オリジン選択ルール、転送ヘッダーの整合性を保ちます。/api/* を API オリジンへ、/* をオブジェクトストレージへ送る場合は、より具体的なルールを 優先させます。テナントやロケールがレスポンスを変える場合にだけキャッシュキーへ 含め、より明確になる場合は別のホスト名または動作を使用します。

オリジンを直接のトラフィックから保護し、閲覧者と上流の両方のリクエスト ID を 記録します。CDN 経由でリダイレクト、WebSocket、ヘルスチェック、エラーパスを テストしてください。内部ネットワークから動作するオリジンでも、DNS、SNI、 ファイアウォール、転送ホストの違いによりエッジでは失敗する可能性があります。