すべてのプロダクト
Search

このプロダクト

    Edge Security Acceleration:URL の再書き込み

    ドキュメントセンター

    Edge Security Acceleration:URL の再書き込み

    最終更新日:Nov 21, 2025

    オリジンサーバー上のリソースパスが変更されても、ユーザー向けの URL を同じに保ちたい場合は、URL 再書き込みルールを使用できます。これらのルールは、Edge Security Acceleration (ESA) の Point of Presence (POP) で構成できます。このルールは、オリジンフェッチ段階で URL のパスとクエリ文字列を自動的に変更します。その後、ESA は再書き込みされた URL をオリジンサーバーに送信してリソースを取得します。このメソッドにより、フロントエンドのリンクやオリジンサーバーの構成を変更することなく、スムーズな移行とシームレスな統合が可能になり、業務継続性が確保されます。

    シナリオ

    • オリジンサーバーの移行: オリジンサーバー上のファイルパスが変更されても、ユーザーのアクセスパスは変更したくない場合。

    • API バージョン適応: ユーザーがリクエストしたレガシー API のパスを新しいバージョンに再書き込みする場合。

    • パラメーターの標準化: 異なるクライアントから渡されるパラメーターのフォーマットを統一する場合。

    • パスの美化: 複雑なバックエンドパスを、ユーザー向けのシンプルなパスにマッピングする場合。

    仕組み

    URL の再書き込みはオリジンフェッチプロセスにのみ影響し、ESA の内部リクエスト処理チェーンには影響しません。キャッシュキーは、一貫したキャッシュヒットを保証するために、元の URL から生成されます。再書き込みされた URL は、オリジンサーバーへのオリジンフェッチリクエストにのみ使用されます。これにより、外部パスを同じに保ちながら、柔軟な内部適応が可能になります。

    実行フロー

    1. キャッシュヒットの確認: ユーザーリクエストが ESA POP に到達すると、ESA は元の URL を使用してキャッシュされたリソースを検索します。キャッシュミスが発生した場合、ESA は URL 再書き込みルールを実行して、元の URL をターゲット URL に変更します。

    2. キャッシュミス時のオリジンからのフェッチ: ESA は再書き込みされた URL を使用してオリジンサーバーからリソースをリクエストします。オリジンサーバーが応答し、ESA はコンテンツをキャッシュします。ESA は元の URL をキャッシュキーとして使用します。

    3. キャッシュされたコンテンツをクライアントに返す: ESA はキャッシュされたコンテンツをクライアントに返します。

    実行順序

    URL の再書き込みは、キャッシュヒットの確認後、オリジンフェッチリクエストが送信される前に実行されます。オリジンサーバー選択ルールの後、オリジンフェッチリクエストヘッダー変更ルールの前に実行されます。これにより、後続のヘッダー処理ロジックに影響を与えることなく、オリジンサーバーが決定された後にリクエストパスを柔軟に調整できます。

    URL 再書き込みルールの構成

    1. ESA コンソールで、サイト管理 を選択します。サイト 列で、ターゲットサイトをクリックします。

    2. 左側のナビゲーションウィンドウで、ルール > 変換ルール を選択します。

    3. URL の書き換え タブを選択します。ルールを追加 をクリックし、ルール名 を入力します。

    4. リクエストが以下のルールと一致する場合... エリアで、ユーザーリクエストが一致する必要がある条件を設定します。ルールの構成方法の詳細については、「ルール式のコンポーネント」をご参照ください。

    5. URL の書き換え エリアで、再書き込みする パス と クエリ文字列 を設定し、OK をクリックします。

      再書き込み対象

      操作

      説明

      例

      パス

      保持する

      元のパスを変更しません。

      -

      以下へ書き換える...

      静的

      固定パスに置き換えます (/ で始まる必要があります)。

      /new/path

      動的

      式を使用してパスを動的に生成します。

      concat("/v2", http.request.uri.path)

      クエリ文字列

      保持する

      元のクエリパラメーターを変更しません。

      -

      以下へ書き換える...

      静的

      静的パラメーターに置き換えます (? 文字は含みません)。

      version=new&type=api

      動的

      式を使用してクエリ文字列を動的に生成します。

      concat("version=new&", http.request.uri.query)

    構成例

    例 1: オリジンサーバーのパス移行

    • シナリオ: オリジンサーバー上の /images/ フォルダから /static/img/ フォルダにイメージが移行されます。

    • 一致条件: starts_with(http.request.uri.path, "/images/")

    • 再書き込み構成:

      • 再書き込み対象: パス

      • 操作: 動的

      • 式: regex_replace(http.request.uri.path, "^/images/", "/static/img/")

    • デモ:

      • ユーザーリクエスト: https://example.com/images/logo.png

      • オリジンフェッチリクエスト: https://origin.com/static/img/logo.png

    例 2: API バージョンの適応

    • シナリオ: レガシー API /api/v1/ へのすべてのリクエストは、オリジンフェッチ中に自動的に新しいバージョン /api/v2/ に転送され、バージョン識別子パラメーターが追加されます。

    • 一致条件: starts_with(http.request.uri.path, "/api/v1/")

    • 再書き込み構成:

      • 再書き込み対象: パス、クエリ文字列

      • 操作: 動的

      • パス再書き込み式: regex_replace(http.request.uri.path, "^/api/v1/", "/api/v2/")

      • クエリ文字列再書き込み式: concat("api_version=v2&", http.request.uri.query)

    • デモ:

      • ユーザーリクエスト: https://example.com/api/v1/users?limit=10

      • オリジンフェッチリクエスト: https://origin.com/api/v2/users?api_version=v2&limit=10

    例 3: パラメーターの標準化

    • シナリオ: 異なるクライアントが userid や uid などの異なるパラメーター名を使用します。これらを標準の user_id に再書き込みして統一します。

    • 一致条件: http.request.uri.query contains "userid="

    • 再書き込み構成:

      • 再書き込み対象: クエリ文字列

      • 操作: 動的

      • 式: regex_replace(http.request.uri.query, "userid=", "user_id=")

    • デモ:

      • ユーザーリクエスト: https://example.com/profile?userid=123

      • オリジンフェッチリクエスト: https://origin.com/profile?user_id=123

    例 4: パスの正規化

    • シナリオ: 入力エラーによる連続したスラッシュ (// や /// など) を含む URL を標準化します。

    • 一致条件: http.request.uri.path contains "//"

    • 再書き込み構成:

      • 再書き込み対象: パス

      • 操作: 動的

      • 式: regex_replace(http.request.uri.path, "/+", "/")

    • デモ:

      • ユーザーリクエスト: https://example.com/path//to///resource

      • オリジンフェッチリクエスト: https://origin.com/path/to/resource

    例 5: すべてのクエリパラメーターを削除

    • シナリオ: 特定の静的リソースについて、すべてのクエリパラメーターを削除してオリジンサーバーの処理効率を向上させます。

    • 一致条件: ends_with(http.request.uri.path, ".css")

    • 再書き込み構成:

      • 再書き込み対象: クエリ文字列

      • 操作: 静的、コンテンツフィールドは空のまま

    • デモ:

      • ユーザーリクエスト: https://example.com/style.css?version=1.2.3

      • オリジンフェッチリクエスト: https://origin.com/style.css

    関連リファレンス

    リファレンス

    ルール関連の機能は、実行優先度、ルール動作、構成範囲が異なります。詳細については、「ESA ルールが有効になる仕組み」をご参照ください。

    式のリファレンス

    説明

    ここにリストされている変数と関数は参照用です。式の詳細については、「ルール式のコンポーネント」をご参照ください。

    一般的な変数

    変数

    説明

    例

    http.request.uri.path

    リクエストパス

    /api/user

    http.request.uri.query

    クエリ文字列 (? 文字は含みません)

    id=123&type=user

    http.request.uri

    完全な URI (パス + クエリ)

    /api/user?id=123

    一般的な関数

    関数

    説明

    例

    concat(str1, str2, ...)

    複数の文字列を連結します。

    concat("/v2", http.request.uri.path)

    regex_replace(text, pattern, replacement)

    正規表現を使用してテキストを検索し、置き換えます。

    regex_replace(http.request.uri.query, "userid=", "user_id=")

    starts_with(text, prefix)

    文字列が指定されたプレフィックスで始まるかどうかを確認します。

    starts_with(http.request.uri.path, "/images/")

    ends_with(text, suffix)

    文字列が指定されたサフィックスで終わるかどうかを確認します。

    ends_with(http.request.uri.path, ".html")