すべてのプロダクト
Search

このプロダクト

    Edge Security Acceleration:URL の再書き込み

    ドキュメントセンター

    Edge Security Acceleration:URL の再書き込み

    最終更新日:Mar 01, 2026

    オリジンサーバー上のリソースパスが変更されても、クライアントがアクセスする URL を変更したくない場合は、URL 再書き込みルールを使用できます。これらのルールは Edge Security Acceleration (ESA) の POP (Points of Presence) で設定します。このルールにより、オリジンフェッチの段階で URL のパスとクエリ文字列 (リクエストパラメーター) が自動的に変更されます。その後、ESA は再書き込みされた URL をオリジンサーバーに送信してリソースを取得します。この機能により、フロントエンドのリンクやオリジンサーバーの設定を変更することなく、スムーズな移行と統合が可能になります。

    利用シーン

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

    • API バージョンの適応：ユーザーがリクエストを行った際に、古い API のパスを新しいバージョンに再書き込みする場合。

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

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

    仕組み

    説明

    URL を再書き込みした場合、プリフェッチキャッシュタスクを送信する際は、再書き込み後の URL を使用してプリフェッチを行ってください。

    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 文字を標準化して入力エラーを修正します。たとえば、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：すべてのクエリパラメーターの削除

    • シナリオ：特定の静的リソースについて、すべてのクエリパラメーターを削除してオリジンサーバーの処理効率を向上させます。たとえば、.css で終わるすべての URI からクエリ文字列を削除します。

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

    • 再書き込み設定：

      • 書き換え対象：クエリ文字列

      • 操作：静的。コンテンツフィールドは空のままにします。

    • 結果：

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

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

    例 6：動的パスの簡略化

    • シナリオ：冗長な数字やコードを含む長いパスを短縮します。たとえば、/example/ パスから <code data-tag="code" id="9a285905069nu">123</code> のすべての発生と、それに続く一連の数字を削除します。

    • 一致条件：http.request.uri matches "^/example/(.*)123[0-9]+(.*)$"

    • 再書き込み設定：

      • 書き換え対象：パス

      • 操作：動的

      • 式：regex_replace(http.request.uri,"^/example/(.*)123[0-9]+(.*)$","/example/$1$2")

      image

    • 結果：

      • ユーザーリクエスト：https://example.com/example/tool12300341features

      • オリジンフェッチリクエスト：https://example.com/example/toolfeatures

    関連リファレンス

    注意事項

    ルール関連の機能は、実行優先度、ルールの動作、設定範囲が異なります。詳細については、「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")