Skip to content

非公式本サイトは非公式の日本語ドキュメントであり、Cloudflare 公式サイトではありません。最新情報はdevelopers.cloudflare.comをご確認ください。

Request Header Transform Rules

最終更新 Markdown で表示Agent セットアップ

Request Header Transform Rules（リクエストヘッダー変換ルール）を使い、オリジンサーバー（Web サイトまたはアプリケーションをホストするサーバー）へ送る HTTP リクエストのヘッダーを操作します。

flowchart LR
accTitle: ヘッダー変更の図
accDescr: Header transform rules は、オリジンサーバーへ送るヘッダー（リクエストヘッダーの変更）またはサイト訪問者へ送るヘッダー（レスポンスヘッダーの変更）を変えられます。

A[訪問者]
B((Cloudflare))
C[(オリジンサーバー)]

A -.-> B == "リクエストヘッダーの<br> 変更を含む" ==> C
C -.-> B -. "レスポンスヘッダーの<br> 変更を含む" .-> A

style A stroke-width: 2px
style B stroke: orange,fill: orange,color: black
linkStyle 0,2,3 stroke-width: 1px
linkStyle 1 stroke-width: 3px

サイト訪問者へ送る レスポンス の HTTP ヘッダーを変更するには、Response Header Transform Rules を参照してください。

Request Header Transform Rules では、次ができます。

  • HTTP リクエストヘッダーの値をリテラル文字列に設定します。既存の値を上書きするか、ヘッダーが無い場合はリクエストへ追加します。
  • 式（リクエストのプロパティから値を計算する式）に従って HTTP リクエストヘッダーの値を設定します。既存の値を上書きするか、ヘッダーが無い場合はリクエストへ追加します。
  • リクエストから HTTP ヘッダーを削除します。

リクエストヘッダー変換ルールは、ダッシュボード、API、または Terraform で作成できます。

より複雑な request header modifications には、Snippets の利用を検討してください。

注意点

  • 名前が x-cf- または cf- で始まる HTTP リクエストヘッダーは、変更または削除できません。例外は cf-connecting-ip HTTP リクエストヘッダーで、これは削除できます。

  • プロトコル準拠のため、禁止ヘッダー名 ↗（Accept-Encoding など）を持つリクエストヘッダーの変更または削除は、Request Header Transform Rules では原則として許可されません。

  • x-forwarded-for、true-client-ip、x-real-ip、x-forwarded-proto など、サイト訪問者の IP アドレスまたは初期プロトコルの識別に広く使われるヘッダーの値は変更できません。オリジンへ届くリクエストで x-real-ip のようなヘッダーにカスタム値が必要な場合は、Cloudflare Snippets または Cloudflare Workers を使い、fetch() サブリクエストでヘッダーを設定します。値は構文的に有効な IP アドレスである必要があります。この回避策はクロスゾーンのサブリクエストでは動きません。Cloudflare は IP なりすまし防止のため、値を内部の Cloudflare アドレスに無条件で置き換えます。

  • Request Header Transform Rule で x-forwarded-for ヘッダーを削除しても、Cloudflare のバックエンドプロキシが（訪問者の IP アドレス付きで）再追加します。プロキシはすべてのルールフェーズのあとに動くため、リクエストがオリジンサーバーへ届く前に再追加されます。Managed Transforms も同様です。ただし、リクエストを Cloudflare Workers が処理する場合 — Workers は キャッシュより前に実行 されます — x-forwarded-for リクエストヘッダーは存在しません。プロキシがまだ再追加していないためです。

  • cookie HTTP リクエストヘッダーの値は設定または変更できませんが、これらのヘッダーは削除できます。cookie HTTP リクエストヘッダーを削除するルールを設定すると、一致するリクエストのすべての cookie ヘッダーが削除されます。

  • 既存の HTTP リクエストヘッダーの値を、空文字列（""）または未定義値になる式で変えた場合、その HTTP リクエストヘッダーは 削除されます。

  • HTTP リクエストヘッダーの削除操作は、指定した名前のリクエストヘッダーをすべて削除します。

  • 現在、変更できない HTTP リクエストヘッダーは限られています。妥当なユースケースがあれば、Cloudflare は一部の制限を外すことがあります。検討のため コミュニティに投稿 ↗ してください。

  • JSON Web Token (JWT) 内のクレーム を使うには、先に API Shield でトークン検証設定を行う必要があります。

  • リクエストヘッダー変換ルールは順番に実行され、後のルールは前のルールによる変更を上書きできます。

  • リクエストフィールドとレスポンスフィールドの値は、各 フェーズ 内で不変です。リクエストヘッダー変換ルールが定義される http_request_late_transform フェーズも同様です。そのため、後続のリクエストヘッダー変換ルールは、フィルター式の評価時に、前のルールが変えた値ではなく元のフィールド値を使います。詳細は ルール評価時のフィールド値 を参照してください。

実行順

Rules 機能の実行順序は次のとおりです。

上記の各種ルールは Page Rules より優先されます。Page Rules と上記の Rules 製品の両方に一致する場合、Page Rules は上書きされます。

一般的に、終了しないアクション では、同じ フェーズ 内のルールによる最後の変更が優先されます（後のルールは、前のルールによる変更を上書きできます）。一方、終了アクション（Block、Redirect、またはチャレンジアクションのいずれか）では、ルールの評価が止まり、そのアクションがすぐに実行されます。

たとえば、Redirect アクションを持つ複数のルールが一致した場合、Cloudflare は常に最初に一致したルールの URL リダイレクトを使います。また、異なる Cloudflare 製品（Single Redirects と Bulk Redirects）で URL リダイレクトを設定している場合、ルールが一致すれば、先に実行される製品が適用されます（この場合は Single Redirects）。

製品の実行順序については、フェーズ一覧 を参照してください。

トラブルシューティング

Request Header Transform Rules のトラブルシューティングでは、Cloudflare Trace を使い、特定の URL でルールが発動するかどうかを確認します。

役に立ちましたか？