Cloudflare HTTPリクエストヘッダー
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ヘッダーを受け取りたくない場合は、訪問者IPヘッダーの削除マネージド変換を有効にしてください。
同一ゾーンのWorkerサブリクエストでは、CF-Connecting-IPの値はx-real-ip（クライアントのIP）の値を反映します。x-real-ipは、ユーザーがWorkerスクリプト内で変更することができます。
異なる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の擬似IPv4は、すべてのCloudflareドメインに対してIPv6からIPv4への翻訳サービスを提供します。
If Pseudo IPv4 is set to Overwrite Headers - Cloudflare overwrites the existing Cf-Connecting-IP and X-Forwarded-For headers with a pseudo IPv4 address while preserving the real IPv6 address in CF-Connecting-IPv6 header.
このヘッダーは、CDN-Loop ヘッダー ↗と同様に、ループ検出に使用されます。
擬似IPv4がAdd Headerに設定されている場合、Cloudflareは元のIPv6アドレスからハッシュ化されたClass E IPv4アドレスを持つCF-Pseudo-IPv4ヘッダーを自動的に追加します。
True-Client-IPは、オリジンのWebサーバーに元のクライアントIPアドレスを提供します。True-Client-IPはエンタープライズプランでのみ利用可能です。以下の例では、203.0.113.1が元の訪問者IPアドレスです。例えば：True-Client-IP: 203.0.113.1
True-Client-IPとCF-Connecting-IPヘッダーの間には、ヘッダー名以外に違いはありません。一部のエンタープライズ顧客は、レガシーデバイスのためにTrue-Client-IPが必要で、カスタムヘッダー名を読み取るためにファイアウォールやロードバランサーを更新する必要がありません。
リクエストにTrue-Client-IP HTTPヘッダーを追加するには、“True-Client-IP”ヘッダーの追加マネージド変換を有効にしてください。
また、True-Client-IPヘッダーや訪問者のIPアドレスを含む可能性のあるHTTPヘッダーを受け取りたくない場合は、訪問者IPヘッダーの削除マネージド変換を有効にしてください。
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をオリジンに送信します。
一方、リクエストに既にX-Forwarded-Forヘッダーが存在する場合、CloudflareはCloudflareに接続しているHTTPプロキシのIPアドレスをヘッダーに追加します。例えば、元の訪問者IPアドレスが203.0.113.1で、リクエストが2つのプロキシを通じてプロキシされている場合：プロキシAのIPアドレスが198.51.100.101、プロキシBのIPアドレスが198.51.100.102で、Cloudflareにプロキシされる前に、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に追加してから、オリジンにリクエストをプロキシします。
訪問者のIPアドレスをX-Forwarded-Forヘッダーで受け取りたくない場合、または訪問者のIPアドレスを含む可能性のあるHTTPヘッダーを受け取りたくない場合は、訪問者IPヘッダーの削除マネージド変換を有効にしてください。
X-Forwarded-Protoは、CloudflareがオリジンのWebサーバーに接続するために使用するプロトコル（HTTPまたはHTTPS）を識別するために使用されます。デフォルトでは、httpです。特定の暗号化モードでは、接続が暗号化されている場合、このヘッダーがhttpsに変更されることがあります。
受信リクエストの場合、このヘッダーの値はクライアントが使用したプロトコル（httpまたはhttps）に設定されます。クライアントが異なる値を設定した場合、それは上書きされます。
CF-rayヘッダー（別名Ray ID）は、データセンターと訪問者のリクエストに関する情報をエンコードしたハッシュ値です。例えば：CF-RAY: 230b030023ae2822-SJC。
リクエストをCloudflareにプロキシした際に、オリジンのWebサーバーログにCF-Rayヘッダーを追加して、サーバーログのリクエストと一致させることができます。
エンタープライズ顧客は、Cloudflare Logsを通じてすべてのリクエストを確認することもできます。
CF-IPCountryヘッダーには、元の訪問者の国の2文字の国コードが含まれています。
ISO-3166-1 alpha-2コード ↗に加えて、Cloudflareは以下の特別な国コードを使用します：
XX- 国コードデータがないクライアントに使用されます。T1- Torネットワークを使用しているクライアントに使用されます。
このヘッダーをリクエストに追加するには、訪問者のIPアドレスに関する他のHTTPヘッダーと共に、訪問者の位置情報ヘッダーの追加マネージド変換を有効にしてください。
現在、このヘッダーはJSONオブジェクトであり、「scheme」という1つのキーのみを含んでいます。このヘッダーはHTTPまたはHTTPSのいずれかであり、Cloudflareの設定でフレキシブルSSLを有効にする必要がある場合にのみ関連します。例えば：CF-Visitor: { \"scheme\":\"https\"}。
CDN-Loopは、Cloudflareがリクエストがループリクエストとしてブロックされる前にCloudflareのネットワークに入ることができる回数を指定することを可能にします。例えば：CDN-Loop: cloudflare
CF-Workerリクエストヘッダーは、サブリクエストを生成したホストを識別するためにエッジWorkerサブリクエストに追加されます。これは、クロスゾーンWorkerサブリクエストから自分を保護したい場合に便利です。例えば：CF-Worker: example.com。
サーバーログにCF-Workerヘッダーを追加するには、CF-RAYヘッダーを追加するのと同様に、ログフォーマットファイルに$http_cf_workerを追加します：log_format cf_custom "CF-Worker:$http_cf_worker"'
CF-Workerは、fetch()を介して送信されるすべてのWorkerサブリクエストに追加されます。これは、サブリクエストを行うWorkerが所有するゾーンの名前に設定されます。例えば、foo.example.com/*のルートにあるWorkerスクリプトは、すべてのサブリクエストに次のヘッダーを持ちます：
CF-Worker: example.com
このヘッダーの意図された目的は、受信者（例えば、オリジン、ロードバランサー、他のWorkers）が特定のゾーンで生成されたトラフィックを認識、フィルタリング、およびルーティングする手段を提供することです。
受信リクエストの場合、このヘッダーの値は常にKeep-Aliveに設定されます。クライアントがcloseのような異なる値を設定した場合、それは上書きされます。クライアントがHTTP/2またはHTTP/3を使用して接続する場合も同様です。
TCPアプリケーションでSpectrumを使用する場合、これらのヘッダーはHTTPヘッダーであるため、オリジンでは表示されません。これらをアプリケーションで利用したい場合、2つのオプションがあります：
- TCPの代わりにHTTPまたはHTTPS Spectrumアプリを使用する
- プロキシプロトコル機能を使用する