多段プロキシのログ：接続元と404応答の読み方
文書番号：2601.00002
要旨
CloudFrontからWorkersを経由してオリジンへ中継した際、各段の接続元ヘッダーがどう変化するかを観測した記録なのだ。二段のログにある応答は404であり、このログが示すのは中継経路への到達なのだ。目的のページ内容を正常に取得できた証拠とは区別するのだ。
構成と設定
クライアント → CloudFront → reverse Worker → origin Worker
単段の転送コードはWorkersプロキシの転送実装に分けるのだ。次の画像は観測時の設定であり、現在の料金・推奨構成を示すものではないのだ。
別の画面確認ではCloudFront経由でサイトのトップが表示されたのだ。この画面と、以下の存在しないパスへの要求ログは異なる確認なのだ。
各段のログで確認できたこと
以下は元ログから関連フィールドを抜粋し、利用者のアドレスをCLIENT_IPへ置換したものなのだ。account、Ray、request ID等の識別子は省いているのだ。
| 観測先 | CF-Connecting-IP | X-Forwarded-For | 応答 |
|---|---|---|---|
| reverse Worker | 3.172.35.133 | CLIENT_IP | 404 |
| origin Worker | 2a06:98c0:3600::103 | CLIENT_IP, 3.172.35.133 | 404 |
3.172.35.133は、確認したCloudFrontの公開IP範囲に含まれていたのだ。これは当時の経路との整合を示すものであり、任意のヘッダー値の本人性を保証するものではないのだ。
Cloudflareは、異なるゾーンへのWorker subrequestのCF-Connecting-IPに固定値2a06:98c0:3600::103を使う仕様を説明しているのだ。この値を固有の利用者や特定Workerの送信元アドレスと解釈しないのだ。
https://developers.cloudflare.com/fundamentals/reference/http-headers/
IP範囲の画像だけでは、Worker subrequestで値が置き換わる条件までは分からないのだ。CloudFrontの最新IP範囲は次の公式データで確認できるのだ：https://ip-ranges.amazonaws.com/ip-ranges.json
観測の限界と設計への反映
X-Forwarded-Forは途中の中継が追記した値を含むため、信頼する入口とオリジンへの直接到達を制御してから解釈するのだ。利用者が持ち込んだ値と中継が付けた値を区別せず、先頭のアドレスで認可を決めないのだ。
この記録は多段経路の一例なのだ。キャッシュ、Cookie、リダイレクト、POST本文、ループ、障害時の戻り方は別の試験が必要なのだ。画面表示、中継到達、目的の内容の取得成功をそれぞれ確認することが結論なのだ。