利用できる設定

Cache Rule を作成するときに設定できる項目です。

Expression Builder で Cache Rule の一致式に使えるフィールドは次のとおりです。

• URI Full - http.request.full_uri
• URI - http.request.uri
• URI Path - http.request.uri.path
• URI Query String - http.request.uri.query
• Cookie - http.cookie
• Hostname - http.host
• Referer - http.referer
• SSL/HTTPS - ssl
• User Agent - http.user_agent
• X-Forwarded-For - http.x_forwarded_for
• Request Headers - http.request.headers
• Cookie value of - http.request.cookies
• File extension - http.request.uri.path.extension

Edit expression を選ぶと、Cache Rules がサポートする追加フィールドを入力できます。対象は次のとおりです。

• cf.bot_management.score
• cf.bot_management.ja3_hash
• cf.bot_management.ja4
• cf.bot_management.verified_bot
• cf.bot_management.static_resource
• cf.bot_management.js_detection.passed
• cf.bot_management.detection_ids
• cf.bot_management.tags
• cf.bot_management.signed_agent
• cf.bot_management.corporate_proxy
• ip.src.asnum

Bot Management フィールドには Bot Management サブスクリプション が必要です。フィールドの型、説明、式の構文は フィールドリファレンス を参照してください。

Cache Rule の式で使える演算子は次のとおりです。

• wildcard
• strict wildcard
• equals
• does not equal
• contains
• does not contain
• matches regex
• does not match regex
• starts with
• ends with
• does not start with
• does not end with
• is in
• is not in
• is in list
• is not in list

Cache eligibility では、一致リクエストをキャッシュしない場合は Bypass cache、Cloudflare にキャッシュを試みさせる場合は Eligible for cache を選べます。

Cache Rule 作成時に Bypass cache を選ぶと、一致する着信リクエストはキャッシュされません。短い期間だけキャッシュをバイパスしたい場合は、代わりに Development Mode を使えます。

Eligible for cache を選ぶと、以下の設定を変更できます。

Edge Cache TTL は、最大キャッシュ TTL（time-to-live）、つまりアセットを Cloudflare のキャッシュから新鮮または配信可能とみなす期間です。主な選択肢は次の 3 つです。

• Use cache control-header if present, bypass cache if not: レスポンスに cache-control ヘッダーがあればその指示に従います。なければキャッシュしません。
• Use cache-control header if present, use default Cloudflare caching behavior if not: レスポンスに cache-control ヘッダーがあればその指示に従います。なければ デフォルトの Edge TTL 設定 に従ってキャッシュします。
• Ignore cache-control header and use this TTL: レスポンスの cache-control ヘッダーを完全に無視し、タイミングのドロップダウンで指定した期間キャッシュします。

加えて、一致する特定のステータスコードの内容を、Cloudflare のグローバルネットワークでどれだけキャッシュするかを選べます。Status Code TTL では、オリジンサーバーからのレスポンスの 1 つ以上のステータスコードに対する TTL 期間を定義できます。Single code、Greater than or equal、Less than or equal、Range に適用できます。ステータスコード TTL は Ignore cache-control header and use this TTL と同様で、レスポンスの cache-control ヘッダーは無視され、Cache Rule で指定した TTL が優先されます。詳細は Status code TTL を参照してください。

"action_parameters": {
    "cache": true,
    "edge_ttl": {
        "status_code_ttl": [
            {
                "status_code_range": {
                    "to": 299
                },
                "value": 86400
            },
            {
                "status_code_range": {
                    "from": 300,
                    "to": 499
                },
                "value": 0  // no-cache
            },
            {
                "status_code_range": {
                    "from": 500
                },
                "value": -1  // no-store
            }
        ],
        "mode": "respect_origin"
    }
}

Browser TTL は、アセットをブラウザーのキャッシュから配信可能とみなす最大 TTL です。

Bypass cache、Respect origin、Override origin のいずれかを選びます。ブラウザー TTL を上書きする場合は、ドロップダウンでクライアントブラウザーがキャッシュしたリソースの有効期間を定義します。詳細は Browser Cache TTL を参照してください。

"action_parameters": {
  "cache": true,
  "browser_ttl" : {
    "mode": "override_origin",
    "default": 1000
  }
}

キャッシュキーは、Cloudflare がキャッシュ内のリソース保存方法を決める基準です。キャッシュキーをカスタマイズすると、リクエスト間で特定のキャッシュエントリを再利用する方法や、エンドユーザー向けにより細かくキャッシュを共有する方法を決められます。

キャッシュキーに明示的な長さ制限はありません。ただし、リクエスト全体のサイズ（キャッシュキーに使うヘッダーを含む）は Cloudflare の リクエスト制限 を超えてはなりません。Cookie など大きな値をキャッシュキーに含めると、リクエストあたりのレイテンシが増えることがあります。カスタムキャッシュキー設定のクエリ文字列パラメータは最大 100 個です。

カスタム Cache Key の定義に使うリクエスト要素を指定し、次のオプションをカスタマイズします。

• Cache deception armor、Cache by device type、Sort query string をオンまたはオフにできます。

Enterprise のお客様には、カスタム Cache Key 向けの追加オプションがあります。

• Query string では、All query string parameters、All query string parameters except と例外の入力、No query parameters except とパラメータの入力、または Ignore query string（Pay-as-you-go のお客様でも利用可）を選べます。

• Headers では、ヘッダー名と値を指定できます。カスタムヘッダーでは値は任意です。ただし次の制限ヘッダーでは、1 から 3 個の具体的な値を含める必要があります。

  • accept
  • accept-charset
  • accept-encoding
  • accept-datetime
  • accept-language
  • referer
  • user-agent

  値を含めずにヘッダーの存在だけを確認するには、Check presence of を使います。Include origin header も選べます。

• Cookie では、Cookie 名と値を含め、別の Cookie の存在を確認できます。

• Host では Use original host と Resolved host を選べます。User では Device type、Country、Language を選べます。Resolved host を使うと、キャッシュキーにはオリジン IP の解決に使ったホスト名が含まれます。resolve override 機能のオンオフによって異なることがあります。

"action_parameters": {
  "cache": true,
  "cache_key": {
    "ignore_query_strings_order": true,
    "cache_deception_armor": true,
    "custom_key": {
      "query_string": {
        "include": [
          "*"
        ]
      },
      "header": {
        "include": [
          "header1"
        ],
        "check_presence": [
          "header_1"
        ],
        "contains": {
          "accept-encoding": ["br", "zstd"]
        }
      },
      "cookie": {
        "include": [
          "cookieName1"
        ],
        "check_presence": [
          "cookie_1"
        ]
      },
      "user": {
        "device_type": true,
        "geo": true,
        "lang": true
      },
      "host": {
        "resolved": false
      }
    }
  }
}

Cache Reserve eligibility では、永続キャッシュである Cache Reserve の対象にするウェブサイトリソースを指定できます。リクエストが一致し、対象条件 も満たすと、Cloudflare はリソースを Cache Reserve に書き込みます。Cache Reserve のアドオンプランが必要です。

このルールで、サイズに基づく Cache Reserve 対象も指定できます。たとえば 100 MB 以上の対象アセットを指定すると、Cloudflare は 100 MB 以上の対象アセットを探し、それらのアセットだけを永続保存します。

"action_parameters": {
  "cache": true
  "cache_reserve": {
    "eligible": true,
    "minimum_file_size": 100000
  }
}

Cloudflare は 80 や 443 など、いくつかの ネットワークポート をデフォルトでサポートします。一部のポート（従来の管理ポート）はサポートされますが、キャッシュ対象外の機密情報の管理に使われるため、キャッシュは無効です。これらの管理ポートでキャッシュしたい Enterprise のお客様は、目的のポートを入力してキャッシュできます。

"action_parameters": {
    "cache": true
    "additional_cacheable_ports": [8443, 8080]
  }
}

オリジンサーバーへの連続した 2 回の読み取り操作のあいだのタイムアウト値を定義します。デフォルト値は 接続制限 の表にあります。オリジンサーバーのタイムアウトによる HTTP 524 エラーを減らしたい場合は、下記の API エンドポイントでこのタイムアウト値を増やしてみてください。

"action_parameters": {
  "cache": true,
  "read_timeout": 900
}

オリジンサーバーから最新コンテンツを更新しているあいだ、Cloudflare が古いコンテンツを配信するかを定義します。古いコンテンツの配信が無効なら、オリジンから最新コンテンツを取得しているあいだ、Cloudflare は古いコンテンツを配信しません。

"action_parameters": {
  "cache": true,
  "serve_stale": {
    "disable_stale_while_updating": true
  }
}

Origin Range Requests では、Cloudflare が大きなファイルをキャッシュ整列したバイトレンジでオリジンから取得できます。Cloudflare はクライアントのレンジを広げ、複数の単一レンジオリジンリクエストを発行することがあります。オリジンは、クライアントの Range ヘッダーと異なるレンジを受け取ることがあります。

この設定はリクエストやレスポンスをキャッシュ可能にしません。レスポンスが保存されなくても、対象の GET に対して Cloudflare はオリジンレンジ取得を使えます。ファイルサイズ制限はリクエストされたレンジではなく、オブジェクト全体に適用されます。Cache Reserve は Origin Range Requests に対応しません。

Cloudflare はオリジンに未エンコードのコンテンツを求めます。オリジンはリクエスト全体で互換のあるレンジ応答を返す必要があります。オリジンが Range を無視して 200 OK を返すと、Cloudflare はその応答を使えますが、ファイル全体をダウンロードする必要があります。オリジンとクライアントの応答要件は Range リクエストの挙動 を参照してください。

"action_parameters": {
  "cache": true,
  "origin_range_requests": {
    "mode": "on"
  }
}

"action_parameters": {
  "origin_range_requests": {
    "mode": "off"
  }
}

Cloudflare キャッシュとオリジンサーバーの間で、バイト単位の等価チェックをオンまたはオフにします。有効にすると、Cloudflare は strong ETag ヘッダー検証を使い、Cloudflare キャッシュとオリジンサーバー上のリソースがバイト単位で同一であることを確認します。無効にすると、Cloudflare は ETag ヘッダーを weak ETag ヘッダーに変換します。

"action_parameters": {
  "cache": true,
  "respect_strong_etags": true
}

オリジンサーバーが送るエラー HTTP ステータスコードから生成される Cloudflare エラーページをオンまたはオフにします。有効にすると、オリジンが発行するエラーページを使えます。

"action_parameters": {
  "cache": true,
  "origin_error_page_passthru": true
}

このオプションが有効なとき、Cloudflare は RFC 7234 ↗ に厳密に従うことを目指します。Enterprise のお客様はこの挙動に従うかを選べます。Free、Pro、Business のお客様ではこのオプションはデフォルトで有効で、無効にできません。

"action_parameters": {
  "cache": true
  "origin_cache_control": true
}

Vary レスポンスヘッダーは、オリジンがリクエストヘッダーに基づいて同じ URL の複数バージョンをキャッシュできるようにします。vary オブジェクトで、オリジンが Vary レスポンスに列挙する各ヘッダーの扱いを設定します。Vary がキャッシュキーに与える影響と正規化の仕組みは Vary を参照してください。

vary オブジェクトは次のキーをサポートします。

vary オブジェクトを省略すると、この Cache Rules の Vary 設定はオフです。Vary: *、Vary for images、圧縮処理など、ほかの Vary 挙動は影響を受けません。vary オブジェクトがある場合、default は必須です。空の vary オブジェクトは無効です。

各ヘッダー設定オブジェクトと default オブジェクトには、normalize、passthrough、bypass のいずれかに設定した action キーが必要です。使い分けは Actions を参照してください。

特定のヘッダー名には追加パラメータを指定できます。

多くの導入では、制限の強い default と明示的なヘッダー単位の設定から始めます。

• 想定外のオリジン Vary ヘッダーのバリアントをキャッシュしないよう、default を bypass にします。
• オリジンが vary すると想定するヘッダーには、明示的な headers エントリを追加します。
• オリジンが生のヘッダー値を必要としない限り、accept、accept-language、accept-encoding には normalize を使います。
• オリジンが提供できるバリアントが正確に分かっているときは、media_types と languages の許可リストを使います。
• 正確な生ヘッダー値で別のキャッシュ版を選ぶ必要があるときにだけ passthrough を使います。
• user-agent、Cookie、ユーザーごとの値を持つリクエストヘッダーなど、カーディナリティの高いヘッダーには bypass を使います。

次の制限と検証ルールが適用されます。

• headers のヘッダー名は小文字である必要があります。
• ヘッダー名に使えるのは文字、数字、アンダースコア、ハイフンです。
• ヘッダー名は 128 文字を超えられません。
• cf- または cf_ で始まるヘッダー名は使えません。
• connection、host、cache-control など、一部の hop-by-hop または cache-control ヘッダーは使えません。
• headers は最大 50 件です。
• accept.media_types は最大 10 件です。
• accept-language.languages は最大 20 件です。
• media_types と languages の値は、空でない印字可能な ASCII である必要があります。

"action_parameters": {
  "cache": true,
  "vary": {
    "default": {
      "action": "bypass"
    },
    "headers": {
      "accept": {
        "action": "normalize",
        "media_types": ["text/html", "application/json"]
      },
      "accept-language": {
        "action": "normalize",
        "languages": ["en", "fr", "de"]
      }
    }
  }
}