Cloudflare は、すべての HTTP リクエストヘッダーをオリジン Web サーバーへ渡し、次に示す追加ヘッダーを付けます。
受信リクエストでは、このヘッダーの値は常に accept-encoding: br, gzip に設定されます。クライアントが accept-encoding: deflate など別の値を設定していても上書きされ、元の値は request.cf.clientAcceptEncoding で参照できます。
CF-Connecting-IP は、Cloudflare に接続しているクライアントの IP アドレスをオリジン Web サーバーへ伝えます。
このヘッダーは、Cloudflare のエッジからオリジン Web サーバーへのトラフィックにだけ送られます。
訪問者の元の IP アドレスをログに残す方法は、元の訪問者 IP を復元する を参照してください。
CF-Connecting-IP や、訪問者の IP アドレスを含む可能性のある HTTP ヘッダーを受け取らない場合は、Remove visitor IP headers Managed Transform を有効 にします。
同一ゾーン内の Worker サブリクエストでは、CF-Connecting-IP の値は x-real-ip（クライアントの IP）を反映します。x-real-ip は、Worker スクリプト内でユーザーが変更できます。
ある Cloudflare ゾーンから別の Cloudflare ゾーンへのクロスゾーンサブリクエストでは、セキュリティ上の理由で CF-Connecting-IP の値は Worker クライアント IP アドレス '2a06:98c0:3600::103' になります。
Cloudflare の顧客ではないゾーン向けの Worker サブリクエストでは、CF-Connecting-IP と x-real-ip の両方にクライアントの IP アドレスが入ります。変更できるのは x-real-ip ヘッダーだけです。
Worker サブリクエストが発生しない場合、cf-connecting-ip にはクライアントの IP アドレスが入り、x-real-ip ヘッダーは削除されます。
Cloudflare は、追加設定やハードウェアなしで、すべてのドメインに 無料の IPv6 サポート を提供します。IPv6 への移行を支援するため、Cloudflare の Pseudo IPv4 は、すべての Cloudflare ドメイン向けに IPv6 から IPv4 への変換サービスを提供します。
Pseudo IPv4 が Overwrite Headers に設定されている場合、Cloudflare は既存の Cf-Connecting-IP および X-Forwarded-For ヘッダーを疑似 IPv4 アドレスで上書きし、実際の IPv6 アドレスは CF-Connecting-IPv6 ヘッダーに保持します。
このヘッダーは、CDN-Loop ヘッダー ↗ と同様に、ループ検出に使います。
Pseudo IPv4 が Add Header の場合、Cloudflare は元の IPv6 アドレスからハッシュした Class E の IPv4 アドレスを、CF-Pseudo-IPv4 ヘッダーとして自動で追加します。
True-Client-IP は、元のクライアント IP アドレスをオリジン Web サーバーへ伝えます。True-Client-IP は Enterprise プランでのみ利用できます。次の例では、203.0.113.1 が元の訪問者 IP アドレスです。例: True-Client-IP: 203.0.113.1
True-Client-IP と CF-Connecting-IP の違いは、ヘッダー名だけです。レガシー機器を使う一部の Enterprise のお客様は、ファイアウォールやロードバランサーをカスタムヘッダー名に合わせて更新しないよう、True-Client-IP を必要とします。
リクエストに True-Client-IP HTTP ヘッダーを追加するには、Add "True-Client-IP" header Managed Transform を有効 にします。
True-Client-IP や、訪問者の IP アドレスを含む可能性のある HTTP ヘッダーを受け取らない場合は、Remove visitor IP headers Managed Transform を有効 にします。
X-Forwarded-For は、プロキシサーバーと元の訪問者の IP アドレスを保持します。Cloudflare へ送られたリクエストに既存の X-Forwarded-For ヘッダーがなかった場合、X-Forwarded-For の値は CF-Connecting-IP ヘッダーと同じになります。
たとえば、元の訪問者 IP アドレスが 203.0.113.1 で、Cloudflare へ送られたリクエストに X-Forwarded-For ヘッダーがない場合、Cloudflare はオリジンへ X-Forwarded-For: 203.0.113.1 を送ります。
一方、Cloudflare へのリクエストにすでに X-Forwarded-For ヘッダーがある場合、Cloudflare は Cloudflare に接続している HTTP プロキシの IP アドレスをヘッダーに追加します。たとえば、元の訪問者 IP アドレスが 203.0.113.1 で、リクエストが Cloudflare へ届く前にプロキシ A（IP 198.51.100.101）とプロキシ B（IP 198.51.100.102）を経由した場合、Cloudflare はオリジンへ X-Forwarded-For: 203.0.113.1,198.51.100.101,198.51.100.102 を送ります。プロキシ A は元の訪問者の IP アドレス（203.0.113.1）を X-Forwarded-For に追加してプロキシ B へ送り、プロキシ B はプロキシ A の IP アドレス（198.51.100.101）を X-Forwarded-For に追加して Cloudflare へ送ります。最後に Cloudflare は、プロキシ B の IP アドレス（198.51.100.102）を X-Forwarded-For に追加してオリジンへ送ります。
X-Forwarded-For ヘッダーや、訪問者の IP アドレスを含む可能性のある HTTP ヘッダーで、訪問者の IP アドレス（および中間プロキシの IP アドレス）を受け取りたくない場合は、Remove visitor IP headers Managed Transform を有効 にします。X-Forwarded-For ヘッダーについては、この Managed Transform は、Cloudflare が少なくとも別の CDN 経由でプロキシされたリクエストを受け取ったときだけ、ヘッダー値から訪問者 IP を削除します。この場合、Cloudflare は最後のプロキシの IP アドレスだけを残します。
前の例のように、リクエストが Cloudflare を経由する前に 2 回プロキシ（プロキシ A と B）された場合、Remove visitor IP headers を有効にすると、Cloudflare はオリジンへ X-Forwarded-For: 198.51.100.102 を送り、プロキシ B（Cloudflare の直前の最後のプロキシ）の IP アドレスだけを残します。詳細は Visitor IP address in the x-forwarded-for HTTP header を参照してください。
X-Forwarded-Proto は、訪問者が Cloudflare への接続に使ったプロトコル（HTTP または HTTPS）を識別します。デフォルトのプロトコルは https です。訪問者が別の 暗号化モード を選んだ場合を除きます。
受信リクエストでは、このヘッダーの値はクライアントが使ったプロトコル（http または https）に設定されます。クライアントが別の値を設定していても上書きされます。
Cf-Ray ヘッダー（Ray ID とも呼ばれます）は、データセンターと訪問者のリクエストに関する情報を符号化したハッシュ値です。例: Cf-Ray: 230b030023ae2822-SJC。
レスポンスヘッダーとして表示されるとき、Cf-Ray ヘッダーはリクエストを処理したデータセンターを識別します。データセンターの所在地に対応する 3 文字のコードで表されます。
Cf-Ray ヘッダーはアップストリームのオリジンにも送られ、接続元のデータセンターを反映するよう変更されることがあります。これは、リクエストが Argo Smart Routing または Argo Tiered Caching 経由でルーティングされた場合に起きます。この場合、Cf-Ray ヘッダーの 3 文字コードは、入口のデータセンターではなく、オリジンに接続しているデータセンターを示します。
Cf-Ray ヘッダーをオリジン Web サーバーのログに追加 すると、Cloudflare へプロキシされたリクエストとサーバーログのリクエストを突き合わせられます。
Enterprise のお客様は、Cloudflare Logs ですべてのリクエストを確認でき、入口データセンターに関するデータも含みます。
CF-IPCountry ヘッダーには、元の訪問者の国を表す 2 文字の国コードが入ります。
ISO-3166-1 alpha-2 コード ↗ に加えて、Cloudflare は次の特別な国コードを使います。
XX- 国コードデータがないクライアントに使います。T1- Tor ネットワークを使うクライアントに使います。
このヘッダーと、訪問者の IP アドレスの位置情報を含むほかの HTTP ヘッダーをリクエストに追加するには、Add visitor location headers Managed Transform を有効 にします。
現在、このヘッダーは JSON オブジェクトで、scheme というキーだけを含みます。値は HTTP または HTTPS で、Cloudflare の設定で Flexible SSL を有効にする必要がある場合にだけ意味があります。例: CF-Visitor: { \"scheme\":\"https\"}。
CDN-Loop により、Cloudflare はリクエストがループとしてブロックされるまでに、Cloudflare のネットワークへ何回入れるかを指定できます。例: CDN-Loop: cloudflare。
SSL for SaaS を SaaS プロバイダー所有のゾーン で使っている場合、HTTP ヘッダーは cf-connecting-o2o: 1 に設定されます。
CF-Worker リクエストヘッダーは、エッジ Worker のサブリクエストに追加され、サブリクエストを発生させたホストを識別します。例: CF-Worker: example.com。
CF-RAY ヘッダーと同様に、サーバーログへ CF-Worker ヘッダーを追加できます。ログフォーマットファイルに $http_cf_worker を追加します。例: log_format cf_custom "CF-Worker:$http_cf_worker"'
CF-Worker は、fetch() 経由で送られるすべての Worker サブリクエストに追加されます。値は、サブリクエストを行う Worker を所有するゾーン名です。たとえば、example.com の foo.example.com/* ルート上の Worker スクリプトでは、すべてのサブリクエストに次のヘッダーが付きます。
CF-Worker: example.comこのヘッダーの目的は、受信側（オリジン、ロードバランサー、ほかの Worker など）が、特定ゾーン上の Worker が生成したトラフィックを認識し、フィルターし、ルーティングできるようにすることです。
受信リクエストでは、このヘッダーの値は常に Keep-Alive に設定されます。クライアントが close など別の値を設定していても上書きされます。クライアントが HTTP/2 または HTTP/3 で接続した場合も同様です。
Spectrum を TCP アプリケーションで使う場合、これらは HTTP ヘッダーであるため、オリジンでは見えません。アプリケーションで使いたい場合は、次の 2 つの選択肢があります。
- TCP ではなく、HTTP または HTTPS の Spectrum アプリを使う
- Proxy Protocol 機能 を使う
Cloudflare は、訪問者へ返すレスポンスから一部の HTTP ヘッダーを削除し、Cloudflare 固有の HTTP ヘッダーを追加します。
Cloudflare は、オリジンサーバーからのレスポンスにある HTTP ヘッダーを訪問者へ渡します。ただし、次のヘッダーは除きます。
X-Accel-BufferingX-Accel-CharsetX-Accel-Limit-RateX-Accel-RedirectAlt-Svc
Cloudflare は、訪問者へ送るレスポンスに、次の HTTP ヘッダーを追加します。
訪問者へ返される Cf-Ray の値は、オリジンサーバーへ送られた Cf-Ray の値と同じです。
取り得るすべての Cf-Cache-Status 値の一覧は、Cloudflare cache responses にあります。