コンテンツにスキップ

ページルール移行ガイド

Cloudflareは、新しい実装に対してページルールの代わりに最新のルール機能を使用することを検討することを推奨しています。この移行ガイドの推奨事項に従って、新しいルール製品について学び、今日からそれらを採用し始める方法を学んでください。

ページルールの移行

Cloudflareは、2025年に既存のページルールを移行する計画です。自分自身のルールを移行する必要はありません。Cloudflareがこのプロセスを処理します。ただし、移行前に異なるページルール設定と新しいルール機能との対応関係を理解することは有益です。これにより、Cloudflareアカウントで新しいタイプのルールを実装する際に慣れることができます。

新しいルール製品を探求し、使用を開始して、その強化された機能と特長を活用することをお勧めします。この移行ガイドは、ページルールの移行に関する追加情報で今後数ヶ月で更新されます。一部の指示は、構成の展開を簡素化し、このプロジェクトの一環として新しい機能をリリースするにつれて変更される可能性があります。Cloudflareユーザーは、移行が行われる前に、Cloudflareアカウントに設定されたページルールの移行に関するメール更新を受け取ります。事前の通知なしに、あなたの代わりに移行や変更を行うことはありません。

コンテキスト

Cloudflareのページルールには、URLパターンに基づいてのみトリガーされることや、パフォーマンス上の理由からゾーンごとに125ルールに制限されるなど、いくつかの基本的な制限があります。また、複数のページルールが同じリクエストに適用される場合、デバッグが複雑になります。

2022年、私たちはブログ投稿ページルールの未来で、ページルールが専用製品のスイートに置き換えられることを発表しました。これらの製品は、すべて最高の品質で構築され、ユーザーの手により多くの力を与えることを目的としています。新しいルール製品 — 構成ルール圧縮ルールオリジンルールリダイレクト、および変換ルール — は現在一般に利用可能(GA)であり、すでに数万のCloudflare顧客に採用されています。

最新のルール機能の改善点には以下が含まれます:

  • 新しいエンジン: 新しいルール機能は、ルールセットエンジンによって動かされており、多様な構成を提供し、多くのHTTPリクエストおよびレスポンスフィールドをサポートする堅牢な言語を使用しています。
  • 改善されたスケーラビリティ: 改善されたスケーラビリティのおかげで、Cloudflareプランには増加したクォータがあります。
  • 簡単なトラブルシューティング: 各ルールが独立して動作するため、ルールの実行がより予測可能になり、トラブルシューティングが簡素化されます。さらに、Cloudflare Traceはルールの相互作用を理解するのに役立ちます。
  • 改善された一貫性: 新しいルール機能は、一貫性を確保し、製品間で共通のフィールドと機能を共有し、シームレスな体験と予測可能なTerraform構成を提供します。

重要な違い

ルール機能の評価および実行順序は、ページルールとは異なります:

  • Workersによって処理されるリクエストは、ページルールのアクションを抑制しますが、最新のルール機能のアクションは抑制しません。
  • 最初に一致したページルールが適用されます(ファーストマッチとも呼ばれます)。対照的に、キャッシュルールのような他のルールはスタッカブルです。これは、複数の一致するルールを組み合わせて同じリクエストに適用できることを意味します(ラストマッチ)。たとえば、複数のキャッシュルールが同じURLに一致する場合、それらのキャッシュルールに設定された機能がすべて順番に適用されます。詳細については、キャッシュドキュメントの順序と優先順位およびオリジンルールFAQを参照してください。
  • ページルールは、顧客が選択した順序で適用される異なる製品のための複数の構成を含むことができます。対照的に、最新のルール機能は固定の順序で評価され、顧客は製品フェーズ内でルールの順序を定義できます。詳細については、ルールセットエンジンのドキュメントを参照してください。
  • 最新のルール機能はページルールに優先します。たとえば、同じパスに対してキャッシュ設定を定義するページルールとキャッシュルールがある場合、キャッシュルールが優先されます。

キャッシュルールの動作変更

ページルールとキャッシュルールの間には動作の変更があります:キャッシュルールでキャッシュ対象を選択すると、キャッシュすべての機能がデフォルトで有効になります。

ページルールで持っていたのと全く同じ動作を維持する必要がある場合は、追加の構成を行う必要があります。詳細については、キャッシュドキュメントのページルールからの移行を参照してください。

ページルールのURLをフィルター式に変換する

ページルールを移行する際には、ルール言語を使用してページルールのURLに相当するフィルター式を書く必要があります。

ルールフィルター式は、ページルールのURLとは異なる方法で構築されます。フィルター式では、フィールド関数、および演算子など、ルール言語のさまざまな要素を使用できます。

最新のルールに移行する際には、ページルールのURLを適応させる必要があります。ルール言語では、ワイルドカードマッチングのためにwildcardおよびstrict wildcard演算子(それぞれ大文字小文字を区別しない演算子と大文字小文字を区別する演算子)を使用します。エンタープライズおよびビジネス顧客は正規表現を使用できますが、ページルールの元のURLを正規表現に適応させる必要もあります。

ワイルドカードを使用した完全なURIの一致

ページルールのURLマッチングは、URIスキーム(例:https://)やリクエストのクエリ文字列を考慮しません。これらはルールURLに含まれていない限り、考慮されません。ただし、フィルター式で使用されるhttp.request.full_uriフィールドには、URIスキームとクエリ文字列(リクエストに含まれている場合)が含まれます。ページルールURLに相当するフィルター式を書く際には、完全なURIでワイルドカードマッチングを行うことを検討するかもしれません。URIスキームやクエリ文字列に関係なく一致を確認するには、ワイルドカードを含むリテラル文字列の先頭と末尾に*ワイルドカードを追加できます。

たとえば、ページルールのURLexample.com/*/downloads/*.txtを使用している場合、最新のルール機能では、http.request.full_uri wildcard *example.com/*/downloads/*.txt*のような式を使用して、任意のスキームと任意のクエリ文字列に一致させることができます。

または、完全なURIフィールドの代わりに、個々のホスト名およびURIパスフィールドで一致させることもできます。たとえば、http.host eq "example.com" and http.request.uri.path wildcard "/*/downloads/*.txt"のようにします。これは、ページルールのURLからフィルター式への変換の例を示す表で採用された変換方法です。

ページルールのURLからフィルター式への例変換

以下の表は、最も一般的なページルールのURLとそれに相当するフィルターを示しています:

対象とコンポーネント
ページルールURLの例
ルール言語を使用したフィルター式
ルートドメインのインデックスページのみ
(ドメイン + パス)
example.com/http.host eq "example.com" and http.request.uri.path eq "/"
特定のドメイン上のすべてのもの
(ドメイン)
example.com/*http.host eq "example.com"
特定のドメイン上のすべてのサブドメインとURL
(ドメイン)
*example.com/*http.host contains "example.com"
サブドメインとそのURLのみ
(ドメイン)
*.example.com/*http.host contains ".example.com"
特定のドメインのサブドメイン上の特定のファイル
(ドメイン + パス)
*.example.com/*wp-login.phpends_with(http.host, ".example.com") and ends_with(http.request.uri.path, "wp-login.php")
ドメインのディレクトリまたはそのサブディレクトリ内の特定のファイル拡張子
(ドメイン + パス)
example.com/archives/*.ziphttp.host eq "example.com" and starts_with(http.request.uri.path, "/archives/") and http.request.uri.path.extension eq "zip"
ドメインの任意のサブディレクトリ内の特定のファイル拡張子
(ドメイン + パス)
example.com/*/downloads/*.txthttp.host eq "example.com" and not starts_with(http.request.uri.path, "/downloads/") and http.request.uri.path contains "/downloads/" and http.request.uri.path.extension eq "txt"
特定のサブドメインのすべてのコンテンツを含む特定のディレクトリ
(ドメイン + パス)
*cdn.example.com/file/*http.request.full_uri contains "cdn.example.com/file/"
すべてのドメイン上の特定のURL
(パス)
*/images
(必要 Cloudflare for SaaS)
http.request.uri.path eq "/images"
すべてのドメイン上の特定のディレクトリとそのサブディレクトリ
(パス)
*/images/*
(必要 Cloudflare for SaaS)
starts_with(http.request.uri.path, "/images/")
任意のディレクトリ内の特定のファイル
(パス)
*/wp-login.php
(必要 Cloudflare for SaaS)
ends_with(http.request.uri.path, "/wp-login.php")
すべてのドメイン上の特定のクエリ文字列
(パス)
*/*?country=GB
(必要 Cloudflare for SaaS)
http.request.uri.query eq "country=GB"
すべてのドメイン上のクエリ文字列の一部
(パス)
*/*?*country=GB*
(必要 Cloudflare for SaaS)
http.request.uri.query contains "country=GB"

機能対応表

次の表は、異なるページルール設定が他のルール機能にどのように移行されるかをまとめたものです。この表と次のセクションを参照して、特定のページルール設定を実装する新しい方法について学び、既存のページルールを手動で移行する方法を学ぶことができます。

Page Rules settingNew implementation uses…Migration/Replacement instructions
Always Use HTTPSRedirect Rules (Single Redirects)Migrate Always Use HTTPS
Browser Cache TTLCache RulesMigrate Browser Cache TTL
Browser Integrity CheckConfiguration RulesMigrate Browser Integrity Check
Bypass Cache on CookieCache RulesMigrate Bypass Cache on Cookie
Cache By Device TypeCache RulesMigrate Cache By Device Type
Cache Deception ArmorCache RulesMigrate Cache Deception Armor
Cache LevelCache RulesMigrate Cache Level
Cache on CookieCache RulesMigrate Cache on Cookie
Cache TTL by status codeCache RulesMigrate Cache TTL by status code
Custom Cache KeyCache RulesMigrate Custom Cache Key
Disable AppsConfiguration RulesMigrate Disable Apps
Disable PerformanceN/A (deprecated)Replace Disable Performance
Disable RailgunN/A (deprecated)N/A
Disable SecurityN/A (deprecated)Replace Disable Security
Disable ZarazConfiguration RulesMigrate Disable Zaraz
Edge Cache TTLCache RulesMigrate Edge Cache TTL
Email ObfuscationConfiguration RulesMigrate Email Obfuscation
Forwarding URLRedirect Rules (Single Redirects)Migrate Forwarding URL
Host Header OverrideOrigin RulesMigrate Host Header Override
IP Geolocation HeaderTransform Rules (Managed Transforms)Migrate IP Geolocation Header
MirageConfiguration RulesMigrate Mirage
Opportunistic EncryptionConfiguration RulesMigrate Opportunistic Encryption
Origin Cache ControlCache RulesMigrate Origin Cache Control
Origin Error Page Pass-thruCache RulesMigrate Origin Error Page Pass-thru
PolishConfiguration RulesMigrate Polish
Query String SortCache RulesMigrate Query String Sort
Resolve OverrideOrigin RulesMigrate Resolve Override
Respect Strong ETagsCache RulesMigrate Respect Strong ETags
Response BufferingN/A (deprecated)N/A
Rocket LoaderConfiguration RulesMigrate Rocket Loader
Security LevelConfiguration RulesMigrate Security Level
True Client IP HeaderTransform Rules (Managed Transforms)Migrate True Client IP Header
SSLConfiguration RulesMigrate SSL
Web Application FirewallN/A (deprecated)N/A

Migrate Always Use HTTPS

Context:

あなたは、example.comのすべてのサブドメインとexample.comドメイン自体に対して、HTTPからHTTPSへの自動リダイレクトを行うページルールを設定しました:

  • URL *example.com/*
  • Setting: Always Use HTTPS

How to migrate:

  1. 単一リダイレクトを作成して、example.comを含む任意のホスト名に対してHTTPリクエストを常にHTTPSにリダイレクトします:

    • 受信リクエストが一致する場合: カスタムフィルター式

      • 表現ビルダーを使用して:
        Hostname contains "example.com" AND SSL/HTTPS is off
      • 表現エディターを使用して:
        (http.host contains "example.com" and not ssl)
    • その場合:

      • Type: Dynamic
      • Expression: concat("https://", http.host, http.request.uri.path)
      • Status code: 301
  2. 既存のページルールをオフにし、作成したリダイレクトの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

Migrate Automatic HTTPS Rewrites

Context:

あなたは、example.comのすべてのサブドメインとexample.comドメイン自体に対して、自動HTTPSリライトをオンにするページルールを設定しました:

  • URL: *example.com/*
  • Setting: Automatic HTTPS Rewrites
  • Value: On

How to migrate:

  1. 設定ルールを作成して、example.comを含む任意のホスト名に対してHTTPリンクを常にHTTPSにリライトします:

    • 受信リクエストが一致する場合: カスタムフィルター式

      • 表現ビルダーを使用して:
        Hostname contains "example.com"
      • 表現エディターを使用して:
        (http.host contains "example.com")
    • その場合の設定は:

      • Setting: Automatic HTTPS Rewrites
      • Value: On
  2. 既存のページルールをオフにし、作成した設定ルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

Migrate Browser Cache TTL

Context:

あなたは、example.comのすべてのサブドメインとexample.comドメイン自体に対して、ブラウザキャッシュTTLを1日に調整するページルールを設定しました:

  • URL: *example.com/*
  • Setting: Browser Cache TTL
  • Enter Browser Cache TTL: a day

How to migrate:

  1. キャッシュルールを作成して、example.comを含む任意のホスト名に対してブラウザキャッシュTTLを1日に調整します:

    • 受信リクエストが一致する場合: カスタムフィルター式

      • 表現ビルダーを使用して:
        Hostname contains "example.com"
      • 表現エディターを使用して:
        (http.host contains "example.com")
    • その場合:

      • Cache eligibility: Eligible for cache
      • Browser TTL: Override origin and use this TTL
      • Input time-to-live (TTL): 1 day
  2. 既存のページルールをオフにし、作成したキャッシュルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

Migrate Browser Integrity Check

Context:

あなたは、example.comのすべてのサブドメインとexample.comドメイン自体に対して、ブラウザ整合性チェックをオンにするページルールを設定しました:

  • URL: *example.com/*
  • Setting: Browser Integrity Check
  • Value: On

How to migrate:

  1. 設定ルールを作成して、example.comを含む任意のホスト名に対してボットや脅威から保護するためにブラウザ整合性チェックをオンにします:

    • 受信リクエストが一致する場合: カスタムフィルター式

      • 表現ビルダーを使用して:
        Hostname contains "example.com"
      • 表現エディターを使用して:
        (http.host contains "example.com")
    • その場合の設定は:

      • Setting: Browser Integrity Check
      • Value: On
  2. 既存のページルールをオフにし、作成した設定ルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

クッキーによるキャッシュバイパスの移行

コンテキスト:

example.comのすべてのサブドメインとexample.comドメイン自体に対して、クッキーによるキャッシュバイパスを有効にするページルールを設定しました。

  • URL: *example.com/*
  • 設定: クッキーによるキャッシュバイパス
  • 値を入力: test_cookie

移行方法:

  1. キャッシュルールを作成して、example.comを含む任意のホスト名のリクエストに対してクッキーtest_cookieを含むもののキャッシュをバイパスします。

    • 受信リクエストが一致する場合: カスタムフィルター式

      • エクスプレッションビルダーを使用:
        Hostname contains "example.com" AND Cookie contains "test-cookie"
      • エクスプレッションエディターを使用:
        (http.host contains "example.com" and http.cookie contains "test-cookie")
    • その後:

      • キャッシュの適格性: キャッシュをバイパス
  2. 既存のページルールをオフにし、作成したキャッシュルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

デバイスタイプによるキャッシュの移行

コンテキスト:

example.comのすべてのサブドメインとexample.comドメイン自体に対して、デバイスタイプによるキャッシュを有効にするページルールを設定しました。

  • URL: *example.com/*
  • 設定: デバイスタイプによるキャッシュ
  • : オン

移行方法:

  1. キャッシュルールを作成して、example.comを含む任意のホスト名のユーザーエージェントまたはデバイスタイプに基づいてコンテンツをキャッシュします。

    • 受信リクエストが一致する場合: カスタムフィルター式

      • エクスプレッションビルダーを使用:
        Hostname contains "example.com"
      • エクスプレッションエディターを使用:
        (http.host contains "example.com")
    • その後:

      • キャッシュの適格性: キャッシュの対象
      • 設定: キャッシュキー
        • デバイスタイプによるキャッシュ: オン
  2. 既存のページルールをオフにし、作成したキャッシュルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

キャッシュデセプションアーマーの移行

コンテキスト:

example.comのすべてのサブドメインとexample.comドメイン自体に対して、キャッシュデセプションアーマーを有効にするページルールを設定しました。

  • URL: *example.com/*
  • 設定: キャッシュデセプションアーマー

移行方法:

  1. キャッシュルールを作成して、example.comを含む任意のホスト名に対してキャッシュデセプション攻撃から保護します。

    • 受信リクエストが一致する場合: カスタムフィルター式

      • エクスプレッションビルダーを使用:
        Hostname contains "example.com"
      • エクスプレッションエディターを使用:
        (http.host contains "example.com")
    • その後:

      • キャッシュの適格性: キャッシュの対象
      • 設定: キャッシュキー
        • キャッシュデセプションアーマー: オン
  2. 既存のページルールをオフにし、作成したキャッシュルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

キャッシュレベルの移行(すべてキャッシュ)

コンテキスト:

example.comのすべてのサブドメインとexample.comドメイン自体に対して、すべてのアセットのキャッシュを有効にするページルールを設定しました。

  • URL: *example.com/*
  • 設定: キャッシュレベル
  • キャッシュレベルを選択: すべてキャッシュ

移行方法:

  1. キャッシュルールを作成して、example.comを含む任意のホスト名のキャッシュレベルを調整します。

    • 受信リクエストが一致する場合: カスタムフィルター式

      • エクスプレッションビルダーを使用:
        Hostname contains "example.com"
      • エクスプレッションエディターを使用:
        (http.host contains "example.com")
    • その後:

      • キャッシュの適格性: キャッシュの対象
  2. 既存のページルールをオフにし、作成したキャッシュルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

クッキーによるキャッシュの移行

コンテキスト:

example.comのすべてのサブドメインとexample.comドメイン自体に対して、クッキーtest-cookieを含むレスポンスのキャッシュを有効にするページルールを設定しました。

  • URL: *example.com/*
  • 設定: クッキーによるキャッシュ
  • 値を入力: test-cookie

移行方法:

  1. キャッシュルールを作成して、example.comを含む任意のホスト名のレスポンスに対してクッキーtest_cookieを含むものをキャッシュします。

    • 受信リクエストが一致する場合: カスタムフィルター式

      • エクスプレッションビルダーを使用:
        Hostname contains "example.com" AND Cookie contains "test-cookie"
      • エクスプレッションエディターを使用:
        (http.host contains "example.com" and http.cookie contains "test-cookie")
    • その後:

      • キャッシュの適格性: キャッシュの対象
  2. 既存のページルールをオフにし、作成したキャッシュルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

ステータスコードによるキャッシュTTLの移行

コンテキスト:

example.comのすべてのサブドメインとexample.comドメイン自体に対して、200から599のステータスコードを持つすべてのレスポンスを1日キャッシュするページルールを設定しました。

  • URL: *example.com/*
  • 設定: ステータスコードによるキャッシュTTL
  • ステータスコードまたは範囲を入力: 200-599
  • オプションを選択: 1日

移行方法:

  1. キャッシュルールを作成して、example.comを含む任意のホスト名に対して200から599のステータスコードを持つレスポンスを1日キャッシュします。

    • 受信リクエストが一致する場合: カスタムフィルター式

      • エクスプレッションビルダーを使用:
        Hostname contains "example.com"
      • エクスプレッションエディターを使用:
        (http.host contains "example.com")
    • その後:

      • キャッシュの適格性: キャッシュの対象
      • 設定: エッジTTL
        • キャッシュコントロールヘッダーが存在する場合はそれを使用し、存在しない場合はCloudflareのデフォルトのキャッシュ動作を使用
        • ステータスコードTTL:
          • 範囲: 範囲
          • から: 200
          • まで: 599
          • 期間: 1日
  2. 既存のページルールをオフにし、作成したキャッシュルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

カスタムキャッシュキーの移行

コンテキスト:

あなたは、example.comのすべてのサブドメインとexample.comドメイン自体に対して、すべてのクエリ文字列パラメータのカスタムキャッシュキーを設定するページルールを構成しました:

  • URL: *example.com/*
  • 設定: カスタムキャッシュキー
    • クエリ文字列: すべてのクエリ文字列パラメータ

移行方法:

  1. キャッシュルールを作成して、example.comを含む任意のホスト名に対してすべてのクエリ文字列パラメータのカスタムキャッシュキーを設定します:

    • 受信リクエストが一致する場合: カスタムフィルター式

      • エクスプレッションビルダーを使用:
        Hostname contains "example.com"
      • エクスプレッションエディターを使用:
        (http.host contains "example.com")
    • その後:

      • キャッシュの適格性: キャッシュの対象
      • 設定: キャッシュキー
        • クエリ文字列: すべてのクエリ文字列パラメータ
  2. 既存のページルールをオフにし、作成したキャッシュルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

アプリの無効化の移行

コンテキスト:

あなたは、example.comのすべてのサブドメインとexample.comドメイン自体に対して、Cloudflareアプリ(非推奨)を無効にするページルールを構成しました:

  • URL: *example.com/*
  • 設定: アプリを無効にする

移行方法:

  1. 構成ルールを作成して、example.comを含む任意のホスト名に対してCloudflareアプリ(非推奨)を無効にします:

    • 受信リクエストが一致する場合: カスタムフィルター式

      • エクスプレッションビルダーを使用:
        Hostname contains "example.com"
      • エクスプレッションエディターを使用:
        (http.host contains "example.com")
    • その後の設定は:

      • 設定: アプリを無効にする
  2. 既存のページルールをオフにし、作成した構成ルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

パフォーマンスの無効化の置き換え

このページルールの設定は、Mirage、Polish、およびRocket Loaderを無効にしました。関連するCloudflare機能を個別にオンまたはオフにすることは、構成ルールを使用して引き続き可能です。

コンテキスト:

あなたは、example.comのすべてのサブドメインとexample.comドメイン自体に対してパフォーマンスの無効化(非推奨)を持つページルールを構成しました:

  • URL: *example.com/*
  • 設定: パフォーマンスの無効化

置き換え方法:

  1. 構成ルールを作成して、example.comを含む任意のホスト名に対してMirage、Polish、およびRocket Loaderを無効にします:

    • 受信リクエストが一致する場合: カスタムフィルター式

      • エクスプレッションビルダーを使用:
        Hostname contains "example.com"
      • エクスプレッションエディターを使用:
        (http.host contains "example.com")
    • その後の設定は:

      • Mirage: オフ
      • Polish: オフ
      • Rocket Loader: オフ
  2. 既存のページルールをオフにし、作成した構成ルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

セキュリティの無効化の置き換え

このページルールの設定は、Email Obfuscation、Rate Limiting(以前のバージョン)、Scrape Shield、URL(ゾーン)ロックダウン、およびWAF管理ルール(以前のバージョン)を無効にします。関連するCloudflare機能を個別にオンまたはオフにすることは、構成ルールおよびWAFカスタムルールを使用して引き続き可能です。

コンテキスト:

あなたは、example.comのすべてのサブドメインとexample.comドメイン自体に対してセキュリティの無効化(非推奨)を持つページルールを構成しました:

  • URL: *example.com/*
  • 設定: セキュリティの無効化

この設定は、Cloudflareのセキュリティ機能のサブセットを無効にしました:Email Obfuscation、Rate Limiting(以前のバージョン)、Scrape Shield、URL(ゾーン)ロックダウン、およびWAF管理ルール(以前のバージョン)。

置き換え方法:

  1. 構成ルールを作成して、1つ以上のセキュリティ機能を無効にします:

  2. 必要に応じて、WAF例外を作成して、許可リストにあるIPアドレスからのリクエストに対してWAF管理ルールセットの1つ以上のルールをスキップします。

  3. 既存のページルールをオフにし、作成したルールの動作を検証します。

  4. テストが成功した場合、既存のページルールを削除します。

Zarazの無効化の移行

コンテキスト:

あなたは、example.comのすべてのサブドメインとexample.comドメイン自体に対してZarazを無効にするページルールを構成しました:

  • URL: *example.com/*
  • 設定: Zarazを無効にする

移行方法:

  1. 構成ルールを作成して、example.comを含む任意のホスト名に対してZarazを無効にします:

    • 受信リクエストが一致する場合: カスタムフィルター式

      • エクスプレッションビルダーを使用:
        Hostname contains "example.com"
      • エクスプレッションエディターを使用:
        (http.host contains "example.com")
    • その後の設定は:

      • 設定: Zarazを無効にする
  2. 既存のページルールをオフにし、作成した構成ルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

エッジキャッシュTTLの移行

コンテキスト:

あなたは、example.comのすべてのサブドメインとexample.comドメイン自体に対してエッジキャッシュTTLを調整するページルールを構成しました:

  • URL: *example.com/*
  • 設定: エッジキャッシュTTL
  • エッジキャッシュTTLを入力: 1日

移行方法:

  1. キャッシュルールを作成して、example.comを含む任意のホスト名に対してCloudflareエッジでのキャッシュリソースのTTLを1日に調整します:

    • 受信リクエストが一致する場合: カスタムフィルター式

      • エクスプレッションビルダーを使用:
        Hostname contains "example.com"
      • エクスプレッションエディターを使用:
        (http.host contains "example.com")
    • その後:

      • キャッシュの適格性: キャッシュの対象
      • 設定: エッジTTL
        • キャッシュ制御ヘッダーを無視し、このTTLを使用
        • 入力の生存時間(TTL): 1日
  2. 既存のページルールをオフにし、作成したキャッシュルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

Email Obfuscationの移行

コンテキスト:

あなたは、example.comのすべてのサブドメインとexample.comドメイン自体に対してEmail Obfuscationを無効にするページルールを構成しました:

  • URL: *example.com/*
  • 設定: Email Obfuscation
  • : オフ

移行方法:

  1. 構成ルールを作成して、example.comを含む任意のホスト名に対してEmail Obfuscationをオフにします:

    • 受信リクエストが一致する場合: カスタムフィルター式

      • Expression Builderを使用:
        Hostname contains "example.com"
      • Expression Editorを使用:
        (http.host contains "example.com")
    • その場合、設定は:

      • 設定: Email Obfuscation
        • : Off
  2. 既存のページルールをオフにし、作成した構成ルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

転送URLの移行

例 #1: wwwをルートドメインにリダイレクト

コンテキスト:

www.example.comexample.comにすべてのURIパスで恒久的にリダイレクトするページルールを設定しました:

  • URL: www.example.com/*
  • 設定: 転送URL
  • ステータスコードを選択: 301 - 恒久的リダイレクト
  • 宛先URL: https://example.com/$1

移行方法:

  1. 単一リダイレクトを作成して、www.example.comからexample.comへのリクエストを恒久的にリダイレクトします:

    • 受信リクエストが一致する場合: カスタムフィルター式

      • Expression Builderを使用:
        Hostname equals "www.example.com"
      • Expression Editorを使用:
        (http.host eq "www.example.com")
    • その場合:

      • タイプ: ダイナミック
      • : concat("https://example.com", http.request.uri.path)
      • ステータスコード: 301
  2. 既存のページルールをオフにし、作成したリダイレクトの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

例 #2: 古いパスのすべてのページを新しいパスにリダイレクト

コンテキスト:

example.com/old-pathexample.com/new-pathに恒久的にリダイレクトするページルールを設定しました:

  • URL: example.com/old-path/*
  • 設定: 転送URL
  • ステータスコードを選択: 301 - 恒久的リダイレクト
  • 宛先URL: https://example.com/new-path/$1

移行方法:

  1. 単一リダイレクトを作成して、example.com/old-pathからexample.com/new-pathへのリクエストを恒久的にリダイレクトします:

    • 受信リクエストが一致する場合: カスタムフィルター式

      • Expression Builderを使用:
        Hostname equals "example.com" AND URI Path starts with "/old-path/"
      • Expression Editorを使用:
        (http.host eq "example.com" and starts_with(http.request.uri.path, "/old-path/"))
    • その場合:

      • タイプ: ダイナミック
      • : concat("/new-path/", substring(http.request.uri.path, 10))
        (ここで10(開始バイト値)は/old-path/の長さです)
      • ステータスコード: 301
  2. 既存のページルールをオフにし、作成したリダイレクトの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

ホストヘッダーオーバーライドの移行

コンテキスト:

example.comドメイン自体とその任意のサブドメインに対して、Host HTTPヘッダーをexample.saas-provider.comに変更するページルールを設定しました:

  • URL: *example.com/*
  • 設定: ホストヘッダーオーバーライド
  • 値を入力: example.saas-provider.com

移行方法:

  1. オリジンルールを作成して、example.comを含む任意のホスト名に対してHostヘッダーをexample.saas-provider.comに変更します:

    • 受信リクエストが一致する場合: カスタムフィルター式

      • Expression Builderを使用:
        Hostname contains "example.com"
      • Expression Editorを使用:
        (http.host contains "example.com")
    • その場合:

      • オリジンパラメータを設定:
        • ホストヘッダー > 書き換え先: example.saas-provider.com
  2. 既存のページルールをオフにし、作成したオリジンルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

IPジオロケーションヘッダーの移行

コンテキスト:

example.comドメイン自体とその任意のサブドメインに対して、CF-IPCountry HTTPヘッダーを追加するページルールを設定しました:

  • URL: *example.com/*
  • 設定: IPジオロケーションヘッダー
  • : On

移行方法:

  1. 訪問者の位置情報ヘッダーを追加マネージド変換をオンにする — すべてのリクエストにCF-IPCountryおよび他の位置情報ヘッダーを追加する変換ルール機能です。
  2. 既存のページルールをオフにし、マネージド変換の動作を検証します。
  3. テストが成功した場合、既存のページルールを削除します。

ミラージュの移行

コンテキスト:

example.comドメイン自体とその任意のサブドメインに対してミラージュをオフにするページルールを設定しました:

  • URL: *example.com/*
  • 設定: ミラージュ
  • : Off

移行方法:

  1. 構成ルールを作成して、example.comを含む任意のホスト名に対してミラージュをオフにします:

    • 受信リクエストが一致する場合: カスタムフィルター式

      • Expression Builderを使用:
        Hostname contains "example.com"
      • Expression Editorを使用:
        (http.host contains "example.com")
    • その場合、設定は:

      • 設定: ミラージュ
        • : Off
  2. 既存のページルールをオフにし、作成した構成ルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

オポチュニスティック暗号化の移行

コンテキスト:

example.comドメイン自体とその任意のサブドメインに対してオポチュニスティック暗号化をオフにするページルールを設定しました:

  • URL: *example.com/*
  • 設定: オポチュニスティック暗号化
  • : Off

移行方法:

  1. 構成ルールを作成して、example.comを含む任意のホスト名に対してオポチュニスティック暗号化をオフにします:

    • 受信リクエストが一致する場合: カスタムフィルター式

      • Expression Builderを使用:
        Hostname contains "example.com"
      • Expression Editorを使用:
        (http.host contains "example.com")
    • その場合、設定は:

      • 設定: オポチュニスティック暗号化
        • : Off
  2. 既存のページルールをオフにし、作成した構成ルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

オリジンキャッシュコントロールの移行

コンテキスト:

example.comのすべてのサブドメインとexample.comドメイン自体に対して、オリジンキャッシュコントロールをオフにするページルールを設定しました:

  • URL: *example.com/*
  • 設定: オリジンキャッシュコントロール
  • : オフ

移行方法:

  1. キャッシュルールを作成して、example.comを含む任意のホスト名のエッジキャッシュ動作を決定します:

    • 受信リクエストが一致する場合: カスタムフィルター式

      • エクスプレッションビルダーを使用:
        Hostname contains "example.com"
      • エクスプレッションエディターを使用:
        (http.host contains "example.com")
    • その後:

      • キャッシュの適格性: キャッシュの対象
      • 設定: オリジンキャッシュコントロール
        • オリジンキャッシュコントロールを有効にする: オフ
  2. 既存のページルールをオフにし、作成したキャッシュルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

オリジンエラーページパススルーの移行

コンテキスト:

example.comのすべてのサブドメインとexample.comドメイン自体に対して、オリジンエラーページパススルーをオンにするページルールを設定しました:

  • URL: *example.com/*
  • 設定: オリジンエラーページパススルー
  • : オン

移行方法:

  1. キャッシュルールを作成して、example.comを含む任意のホスト名のエッジキャッシュ動作を決定します:

    • 受信リクエストが一致する場合: カスタムフィルター式

      • エクスプレッションビルダーを使用:
        Hostname contains "example.com"
      • エクスプレッションエディターを使用:
        (http.host contains "example.com")
    • その後:

      • キャッシュの適格性: キャッシュの対象
      • 設定: オリジンエラーページパススルー
        • オリジンエラーページパススルーを使用: オン
  2. 既存のページルールをオフにし、作成したキャッシュルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

ポリッシュの移行

コンテキスト:

example.comのすべてのサブドメインとexample.comドメイン自体に対して、ポリッシュをオフにするページルールを設定しました:

  • URL: *example.com/*
  • 設定: ポリッシュ
  • : オフ

移行方法:

  1. 設定ルールを作成して、example.comを含む任意のホスト名に対してポリッシュをオフにします:

    • 受信リクエストが一致する場合: カスタムフィルター式

      • エクスプレッションビルダーを使用:
        Hostname contains "example.com"
      • エクスプレッションエディターを使用:
        (http.host contains "example.com")
    • その後の設定は:

      • 設定: ポリッシュ
        • 値を選択: オフ
  2. 既存のページルールをオフにし、作成した設定ルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

クエリ文字列ソートの移行

コンテキスト:

example.comのすべてのサブドメインとexample.comドメイン自体に対して、クエリ文字列ソートをオンにするページルールを設定しました:

  • URL: *example.com/*
  • 設定: クエリ文字列ソート
  • : オン

移行方法:

  1. キャッシュルールを作成して、example.comを含む任意のホスト名のキャッシュ目的でクエリ文字列パラメータをソートします:

    • 受信リクエストが一致する場合: カスタムフィルター式

      • エクスプレッションビルダーを使用:
        Hostname contains "example.com"
      • エクスプレッションエディターを使用:
        (http.host contains "example.com")
    • その後:

      • キャッシュの適格性: キャッシュの対象
      • 設定: キャッシュキー
        • クエリ文字列をソート: オン
  2. 既存のページルールをオフにし、作成したキャッシュルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

リゾルブオーバーライドの移行

コンテキスト:

example.comのすべてのサブドメインとexample.comドメイン自体に対して、オリジンをexample.saas-provider.comに変更するページルールを設定しました:

  • URL: *example.com/*
  • 設定: リゾルブオーバーライド
  • 値を入力: example.saas-provider.com

移行方法:

  1. オリジンルールを作成して、example.comを含む任意のホスト名に対してオリジンをexample.saas-provider.comにオーバーライドします:

    • 受信リクエストが一致する場合: カスタムフィルター式

      • エクスプレッションビルダーを使用:
        Hostname contains "example.com"
      • エクスプレッションエディターを使用:
        (http.host contains "example.com")
    • その後:

      • DNSレコード > オーバーライド先: example.saas-provider.com
  2. 既存のページルールをオフにし、作成したオリジンルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

ストロングETagの尊重の移行

コンテキスト:

example.comのすべてのサブドメインとexample.comドメイン自体に対して、バイト単位の同等性チェックをオンにするページルールを設定しました:

  • URL: *example.com/*
  • 設定: ストロングETagの尊重
  • : オン

移行方法:

  1. キャッシュルールを作成して、example.comを含む任意のホスト名に対してストロングETagを尊重します:

    • 受信リクエストが一致する場合: カスタムフィルター式

      • エクスプレッションビルダーを使用:
        Hostname contains "example.com"
      • エクスプレッションエディターを使用:
        (http.host contains "example.com")
    • その後:

      • キャッシュの適格性: キャッシュの対象
      • 設定: ストロングETagの尊重
        • ストロングETagヘッダーを使用: オン
  2. 既存のページルールをオフにし、作成したキャッシュルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

ロケットローダーの移行

コンテキスト:

example.comのすべてのサブドメインとexample.comドメイン自体に対して、ロケットローダーをオフにするページルールを設定しました:

  • URL: *example.com/*
  • Setting: Rocket Loader
  • Value: Off

移行方法:

  1. Rocket Loaderを無効にするための設定ルールを作成する example.comを含む任意のホスト名に対して:

    • 受信リクエストが一致する場合: カスタムフィルター式

      • Expression Builderを使用:
        Hostname contains "example.com"
      • Expression Editorを使用:
        (http.host contains "example.com")
    • 設定は次のとおりです:

      • Setting: Rocket Loader
        • Value: Off
  2. 既存のページルールを無効にし、作成した設定ルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

セキュリティレベルの移行

コンテキスト:

example.comおよびそのすべてのサブドメインに対して、ページルールの設定セキュリティレベルを_攻撃を受けています_に設定しました:

  • URL: *example.com/*
  • Setting: Security Level
  • Select Security Level: I’m Under Attack

移行方法:

  1. セキュリティレベルを_攻撃を受けています_に設定するための設定ルールを作成する example.comを含む任意のホスト名に対して:

    • 受信リクエストが一致する場合: カスタムフィルター式

      • Expression Builderを使用:
        Hostname contains "example.com"
      • Expression Editorを使用:
        (http.host contains "example.com")
    • 設定は次のとおりです:

      • Setting: Security Level
        • Select Security Level: I’m Under Attack
  2. 既存のページルールを無効にし、作成した設定ルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

True Client IPヘッダーの移行

コンテキスト:

example.comおよびそのすべてのサブドメインに対して、すべてのリクエストにTrue-Client-IP HTTPヘッダーを追加するページルールを設定しました:

  • URL: *example.com/*
  • Setting: True Client IP Header
  • Value: On

移行方法:

  1. すべてのリクエストにTrue-Client-IPヘッダーを追加するAdd “True-Client-IP” header管理変換をオンにする — これは変換ルールの機能です。
  2. 既存のページルールを無効にし、管理変換の動作を検証します。
  3. テストが成功した場合、既存のページルールを削除します。

SSLの移行

コンテキスト:

example.comおよびそのすべてのサブドメインに対して、ページルールの設定SSLを_厳格_に設定しました:

  • URL: *example.com/*
  • Setting: SSL
  • Select SSL/TLS encryption mode: Strict

移行方法:

  1. SSLを_厳格_に設定するための設定ルールを作成する example.comを含む任意のホスト名に対して:

    • 受信リクエストが一致する場合: カスタムフィルター式

      • Expression Builderを使用:
        Hostname contains "example.com"
      • Expression Editorを使用:
        (http.host contains "example.com")
    • 設定は次のとおりです:

      • Setting: SSL
        • Select SSL/TLS encryption mode: Strict
  2. 既存のページルールを無効にし、作成した設定ルールの動作を検証します。

  3. テストが成功した場合、既存のページルールを削除します。

移行されない設定

以下のページルール設定は、他のタイプのルールに移行されません:

  • パフォーマンスの無効化 (この設定は廃止予定)
  • Railgunの無効化 (この設定は廃止予定、Railgunはもはや利用できません)
  • セキュリティの無効化 (この設定は廃止予定)
  • レスポンスバッファリング (この設定は廃止予定)
  • Webアプリケーションファイアウォール (この設定は廃止予定、以前のバージョンのWAF管理ルールは廃止予定)

その他のすべてのページルール設定は2025年に移行されます。

さらなるリソース

フィードバックがある場合は、コミュニティスレッドを参照してください。