Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

網址對應總覽

Google Cloud 應用程式負載平衡器和 Cloud Service Mesh 會使用名為「網址對應」的 Google Cloud設定資源，將 HTTP(S) 要求轉送至後端服務或後端 bucket。

舉例來說，使用外部應用程式負載平衡器時，您可以根據單一網址對應中設定的規則，將要求轉送至不同目的地：

將 https://example.com/video 的要求轉送至某個後端服務。
將 https://example.com/audio 的要求轉送至其他後端服務。

將 https://example.com/images 的要求轉送至 Cloud Storage 後端 bucket。

將任何其他主機和路徑組合的要求轉送至預設後端服務。

網址對應適用於下列 Google Cloud 產品：

外部應用程式負載平衡器 (全域、區域和傳統模式)
內部應用程式負載平衡器 (跨區域和區域模式)
Cloud Service Mesh：使用負載平衡 API 部署 Cloud Service Mesh 時

網址對應資源分為全域和區域性兩種。

全域urlMaps用於全域外部應用程式負載平衡器、傳統版應用程式負載平衡器、跨區域內部應用程式負載平衡器和 Cloud Service Mesh。
regionUrlMaps 適用於區域性外部應用程式負載平衡器、區域性內部應用程式負載平衡器和 Cloud Service Mesh。

使用的資源類型取決於產品的負載平衡配置。

產品	負載平衡架構	網址對應資源類型	支援的目的地
全域外部應用程式負載平衡器	`EXTERNAL_MANAGED`	全球	後端服務、後端 bucket
傳統版應用程式負載平衡器	`EXTERNAL`	全球	後端服務、後端 bucket
區域性外部應用程式負載平衡器	`EXTERNAL_MANAGED`	區域	後端服務、後端 bucket
跨區域內部應用程式負載平衡器	`INTERNAL_MANAGED`	全球	後端服務、後端 bucket
區域性內部應用程式負載平衡器	`INTERNAL_MANAGED`	區域	後端服務、後端 bucket
Cloud Service Mesh	`INTERNAL_SELF_MANAGED`	全球	後端服務
Cloud Service Mesh	`INTERNAL_SELF_MANAGED`	區域	後端服務

並非所有產品都支援所有網址對應功能。與全域外部應用程式負載平衡器、區域性外部應用程式負載平衡器、內部應用程式負載平衡器和 Cloud Service Mesh 搭配使用的網址對應，也支援多項進階流量管理功能。如要進一步瞭解這些差異，請參閱「負載平衡器功能比較：轉送和流量管理」。此外，區域性網址對應也可以是 App Hub 應用程式中指定為服務的資源。

網址對應的運作方式

要求送達負載平衡器時，負載平衡器會根據網址對應中定義的規則，將要求轉送至特定後端服務或後端 bucket。

後端服務代表一組後端，也就是應用程式或微服務的執行個體。後端 bucket 是 Cloud Storage bucket，通常用於託管靜態內容，例如圖片。

Cloud Service Mesh 的可能目的地如下：

預設後端服務
非預設後端服務

此外，應用程式負載平衡器也支援下列功能：

預設後端 bucket
非預設後端 bucket

例如，假設您的設定如下：

單一 IP 位址：
- 傳送至貴組織的所有要求都會傳送至相同的 IP 位址和負載平衡器。
- 流量會根據要求網址導向不同的後端服務。
兩個網域：
- example.net 託管訓練影片。
- example.org 代管貴機構的網站。
四組伺服器：
- 一個用於託管機構網站 (後端服務：org-site)。
- 一個用於託管整體訓練影片網站 (後端服務：video-site)。
- 一個用於託管高畫質 (HD) 訓練影片 (後端服務：video-hd)。
- 一個託管標準畫質 (SD) 訓練影片 (後端服務：video-sd)。

您希望發生以下情況：

傳送至 example.org (或 example.net 以外的任何網域) 的要求會傳送至 org-site 後端服務。
傳送至 example.net 的要求，如果不符合更具體的路徑，則會傳送至 video-site 後端服務。
將 example.net/video/hd/* 的要求轉送至 video-hd 後端服務。
將 example.net/video/sd/* 的要求轉送至 video-sd 後端服務。

/video/* 的 --path-rule 會比對 /video/test1 和 /video/test2 等 URI。不過，這項路徑規則與路徑 /video 不符。

如果負載平衡器收到網址中含有 /../ 的要求，負載平衡器會移除 .. 前方的路徑區段來轉換網址，並以轉換後的網址回應。舉例來說，如果傳送 http://example.net/video/../abc 的要求，負載平衡器會傳回 302 重新導向至 http://example.net/abc 的回應。大多數用戶端會發出要求至負載平衡器傳回的網址 (在本例中為 http://example.net/abc)，藉此做出回應。這項 302 重新導向不會記錄在 Cloud Logging 中。

網址對應可讓您設定這類主機和路徑轉送。

負載平衡器命名

如果是應用程式負載平衡器，負載平衡器的名稱一律與網址對應名稱相同。每個 Google Cloud 介面的行為如下：

Google Cloud 控制台。如果您使用Google Cloud 控制台建立應用程式負載平衡器，系統會自動為網址對應指派您輸入的負載平衡器名稱。
Google Cloud CLI 或 API。如果使用 gcloud CLI 或 API 建立應用程式負載平衡器，請在建立網址對應時輸入自選名稱。這個網址對應名稱會顯示在Google Cloud 控制台中，做為負載平衡器的名稱。

如要瞭解 Proxy 網路負載平衡器和直通式網路負載平衡器的命名方式，請參閱「後端服務總覽：負載平衡器命名」。

網址對應元件

網址對應是一組 Google Cloud 設定資源，可將網址要求導向後端服務或後端 bucket。網址對應會使用處理的每個網址的主機名稱和路徑部分，來執行這項操作：

「主機名稱」是網址的網域名稱部分，例如網址 http://example.net/video/hd 的主機名稱部分是 example.net。
「路徑」是網址中主機名稱和選用通訊埠編號後面的部分，例如網址 http://example.net/video/hd 的路徑部分是 /video/hd。

使用基本網址對應的負載平衡器設定。 — 使用基本網址對應的負載平衡器設定 (按一下即可放大)。

這張圖表顯示負載平衡設定物件的結構，以及彼此之間的關係。

您可以使用下列網址對應設定參數，控管哪些後端服務或後端 bucket 會接收傳入要求：

預設後端服務或預設後端 bucket。建立網址對應時，您必須指定預設後端服務或預設後端 bucket，但不能同時指定兩者。這個預設值代表後端服務或後端 bucket，除非有適用的主機規則，否則 Google Cloud 會將任何主機名稱的網址要求導向該服務或 bucket。

注意： Cloud Service Mesh 不支援後端 bucket。
主機規則 (hostRules)：主機規則會將傳送至一或多個相關聯主機名稱的要求，導向至單一路徑比對器 (pathMatchers)。網址的主機名稱部分會與主機規則設定的主機名稱集完全比對，或使用規則運算式比對。在網址對應主機和路徑規則中，如果省略主機，規則會比對任何要求的主機。如要將 http://example.net/video/hd 的要求導向路徑比對器，您需要一項至少包含主機名稱 example.net 的主機規則。該主機規則也可以處理其他主機名稱的要求，但會將這些要求導向相同的路徑比對器。

如要將要求導向不同的路徑比對器，則必須使用不同的主機規則。網址對應中的兩項主機規則不得包含相同的主機名稱。

您可以在主機規則中指定萬用字元 *，比對所有主機名稱。舉例來說，如果網址為 http://example.org、http://example.net/video/hd 和 http://example.com/audio，只要在主機規則中指定 *，即可比對 example.org、example.net 和 example.com 這三個主機名稱。您也可以指定萬用字元 *，比對部分主機名稱。舉例來說，主機規則 *.example.net 會與主機名稱 news.example.net 和 finance.example.net 進行比對。

通訊埠編號。傳統版應用程式負載平衡器處理通訊埠編號的方式，與其他應用程式負載平衡器不同。如果是傳統版應用程式負載平衡器，比對主機規則時，系統只會考量網址中的主機名稱。舉例來說，example.net 對通訊埠 8080 和通訊埠 80 的要求符合主機規則 example.net。如果是其他應用程式負載平衡器，您可以使用主機規則參數指定通訊埠編號。例如，如要將 example.net 要求導向通訊埠 8080，請將主機規則設為 example.net:8080。

注意： 負載平衡器不會驗證網址中的主機名稱值。用戶端可以為 hostname 設定任意值，例如設定 Host 標頭。請勿使用主機名稱欄位為應用程式實作存取控管。
路徑比對器 (pathMatchers)：路徑比對器是主機規則參照的設定參數。定義網址路徑部分與應處理要求的後端服務或後端 bucket 之間的關係。路徑比對器包含兩個元素：
- 路徑比對器預設後端服務或路徑比對器預設後端 bucket。每個路徑比對器至少須指定一個預設後端服務或預設後端 bucket，但不能同時指定兩者。這個預設值代表後端服務或後端 bucket，Google Cloud 會將網址要求導向至該服務或 bucket，前提是網址的主機名稱與路徑比對器相關聯的主機規則相符，且網址路徑與路徑比對器中的任何路徑規則都不相符。
- 路徑規則：您可以為每個路徑比對器指定一或多個路徑規則，這些規則是鍵/值組合，可將網址路徑對應至單一後端服務或後端 bucket。
  
  靈活的模式比對運算子可讓您使用萬用字元語法，比對網址路徑的多個部分，包括部分網址和尾碼 (副檔名)。如需根據複雜的網址路徑轉送流量及執行重寫作業，這些運算子就非常實用。您也可以將一或多個路徑元件與具名變數建立關聯，然後在重寫網址時參照這些變數。使用具名變數，即可在要求傳送至來源前，重新排序及移除網址元件。詳情請參閱「路徑規則中的萬用字元、規則運算式和動態網址」。
  
  如需更進階的轉送功能，例如將特定網址的流量導向多項服務，可以使用路由規則，而非路徑規則。
- 路由規則。如需進階流量轉送功能 (例如根據網址路徑、HTTP 標頭和查詢參數轉送流量)，可以使用路由規則，做為路徑規則的替代方案。
  
  您可以使用彈性的模式比對運算子和具名變數，設定路由規則。如需根據複雜的網址路徑轉送流量及執行重寫作業，這些運算子就非常實用。詳情請參閱「路由規則路徑範本中的萬用字元和模式比對運算子」。
  
  您也可以設定路由規則，比對與傳入要求中的路徑、查詢參數或標頭相符的規則運算式。詳情請參閱「路由規則中的規則運算式」。
  
  如要進一步瞭解轉送規則的設定選項，請參閱「進階型主機、路徑與轉送規則」。

主機名稱和主機規則關係

一個主機名稱只能參照一項主機規則。
一項主機規則可以處理多個主機名稱。

主機規則和路徑比對器關係

多項主機規則可以參照單一路徑比對器。
主機規則只能參照一個路徑比對器。

網址和後端關係

每個不重複的網址只會導向一個後端服務或後端 bucket。因此：

Google Cloud 會使用網址的主機名稱部分，選取單一主機規則及其參照的路徑比對器。
在路徑比對器中使用路徑規則時，您無法為相同路徑建立多個路徑規則。舉例來說，/videos/hd 的要求無法導向多個後端服務或後端 bucket。後端服務可以在不同可用區和區域中，擁有後端執行個體群組或後端網路端點群組 (NEG)，您也可以建立使用 Multi-Regional Storage 級別的後端 bucket。

如要將不重複網址的流量導向多項服務，可以使用路由規則，而非路徑規則。如果您為路徑比對器設定標頭或參數比對的路由規則，系統會根據網址上的標頭或查詢參數內容，將不重複的網址導向多個後端服務或 bucket。

同樣地，對於區域性外部應用程式負載平衡器和 Cloud Service Mesh，路由動作上的加權後端服務可以根據加權後端服務設定的權重，將相同的網址導向多個後端服務或 bucket。

網址對應和通訊協定

只要目標 HTTP Proxy 和目標 HTTPS Proxy 都參照網址對應，您就能使用相同的網址對應、主機規則和路徑比對器，處理用戶端提交的 HTTP 和 HTTPS 要求。

最簡單的網址對應

最簡單的網址對應僅有預設的後端服務或預設的後端值區，不含任何主機規則，也沒有路徑比對器。預設後端服務或預設後端 bucket (視您定義的項目而定) 會處理所有要求的網址。

如果您定義預設後端服務， Google Cloud 會根據後端服務的設定，將要求導向其後端執行個體群組或後端 NEG。

網址對應，除了預設規則外，沒有其他規則。 — 除了預設規則外，沒有其他規則的網址對應 (按一下即可放大)。

作業順序

針對要求網址中的指定主機名稱和路徑， Google Cloud 會使用下列程序，將要求導向網址對應中設定的正確後端服務或後端 bucket：

如果網址對應「不」包含網址主機名稱的主機規則，Google Cloud 會將要求導向網址對應的預設後端服務或預設後端 bucket，具體取決於您定義的項目。
如果網址對應包含的主機規則含有網址的主機名稱，系統會參考該主機規則參照的路徑比對器：
- 如果路徑比對器包含與網址路徑完全相符的路徑規則， Google Cloud 會將要求導向該路徑規則的後端服務或後端 bucket。
- 如果路徑比對器「不」包含與網址路徑完全相符的路徑規則，但包含以 /* 結尾的路徑規則，且其前置字元與網址路徑的「最長部分」相符，則 Google Cloud會將要求導向該路徑規則的後端服務或後端 bucket。舉例來說，如果網址對應包含兩個路徑比對器規則 /video/hd/movie1 和 /video/hd/*，且網址包含確切路徑 /video/hd/movie1，系統就會比對該路徑規則。
- 如果上述條件皆不成立， Google Cloud 會將要求導向路徑比對器的預設後端服務或預設後端 bucket，具體取決於您定義的項目。

網址對應設定限制

以下各節說明網址對應元件的特定設定限制。

主機和路由規則中的規則運算式比對器

主機規則可讓您比對網址的主機名稱部分，以及主機規則設定的主機名稱。您可以選擇在 hostRules[].hosts[] 欄位中使用特定主機名稱或萬用字元 *，與傳入要求中的主機名稱進行比對。

路由規則可讓您定義比對規則，比對傳入要求中路徑、查詢字串或標頭的規則運算式。路由規則支援在下列網址對應欄位中使用規則運算式：

pathMatchers[].routeRules[].matchRules[].regexMatch：用於比對傳入要求路徑的規則運算式。
pathMatchers[].routeRules[].matchRules[].headerMatches[].regexMatch：包含述詞的規則運算式，與傳入要求的標頭相符。
pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].regexMatch：規則運算式，包含與傳入要求查詢參數相符的述詞。

只要符合任何 matchRules，系統就會判定要求與 routeRule 相符。不過，特定 matchRule 中的述詞具有 AND 語意。也就是說，matchRule 中的所有述詞都必須相符，要求才會與規則相符。

其他使用注意事項：

規則運算式僅適用於下列產品：
- 區域性內部應用程式負載平衡器
- 跨區域內部應用程式負載平衡器
- 區域性外部應用程式負載平衡器
- 全域外部應用程式負載平衡器
傳統版應用程式負載平衡器不支援規則運算式。
您必須使用 RE2 語法建構規則運算式。如需網址對應中允許的限制和運算子完整清單，請參閱「網址對應的 RE2 規格」。
規則運算式比對會耗用大量記憶體，且會造成要求處理延遲。如果選擇使用規則運算式比對，在規劃部署作業時，必須考量效能降低的問題。舉例來說，如果網址對應只有一個規則運算式，負載平衡器延遲時間預計會增加 100 微秒/要求。如果網址對應有 5 個要比對的規則運算式，則每個要求的延遲時間預計會增加 200 微秒。

範例 1：使用規則運算式比對路徑

如果路徑在移除來源網址提供的任何查詢參數和錨點後，符合 regexMatch 指定的規則運算式，則視為相符。舉例來說，在下列網址對應範例中，路由規則規則運算式 /videos/hd.* 會套用至路徑為 /videos/hd-abcd?key=245 的網址。

defaultService: projects/example-project/global/backendServices/org-site
name: rule-match-url-map
hostRules:
- hosts:
  - '*' # Match any host
  pathMatcher: video-matcher
- hosts:
  - example.net
  pathMatcher: video-matcher
pathMatchers:
- name: video-matcher
  # Optional: default service for this path matcher if no routeRules match
  defaultService: projects/example-project/global/backendServices/video-site
  routeRules:
  - priority: 100000
    matchRules:
    - regexMatch: /videos/hd.*
    routeAction:
      weightedBackendServices:
      - backendService: projects/example-project/global/backendServices/video-hd
        weight: 100

以下是範例網址對應關係中各欄位的說明：

defaultService：如果網址對應中沒有其他規則符合傳入要求，則指定要使用的預設後端服務。
name：將 rule-match-url-map 這個名稱指派給這項網址對應設定。
hostRules：定義規則清單，用於比對傳入要求的主機標頭。第一項規則會比對任何主機 (*)，並將流量導向名為 video-matcher 的 pathMatcher。第二項規則會特別比對主機 example.net，並將流量導向名為 video-matcher 的路徑比對器。
pathMatchers：定義已命名路徑比對器的清單。
name：定義名為 video-matcher 的路徑比對器。
defaultService：設定這個路徑比對器的預設服務。如果要求符合指向 video-matcher 的主機規則，但不符合其中的任何 routeRules，就會使用這項服務。
routeRules：包含要比對網址路徑的規則清單。
priority：將這項規則的優先順序設為 100000。系統會依優先順序值 (由小到大) 評估規則。
matchRules：包含這項路由規則的比對條件。
regexMatch：這項條件會檢查網址路徑是否與規則運算式 /videos/hd.* 相符 (例如「/videos/hd」和「/videos/hd-caching」)。
routeAction：指定符合 matchRules 中所有條件時要採取的動作。
weightedBackendServices：根據權重，在一系列後端服務之間分配流量。
backendService：指定要將流量轉送至哪個後端服務。
weight：將這項後端服務的權重設為 100。由於這是清單中唯一的服務，因此會收到符合這項 routeRule 的 100% 流量。

下列網址對應顯示不使用 routeAction 的類似範例。

defaultService: projects/example-project/global/backendServices/video-site
name: path-matcher-videos
routeRules:
  matchRules:
  - regexMatch: /videos/hd.*
  priority: 100000
  service: projects/example-project/global/backendServices/video-hd

範例 2：使用規則運算式比對標頭

如果標頭值符合 regexMatch 指定的規則運算式，系統就會判定標頭相符。舉例來說，在下列網址對應範例中，標頭名稱規則運算式 .*Android.*-hd 會套用至含有標頭 User-Agent:123Androidabc-hd 的要求。

defaultService: projects/example-project/regions/us-central1/backendServices/default-backend-service
name: header-match-url-map
hostRules:
- hosts:
  - '*'  # Match any host
  pathMatcher: header-matcher
pathMatchers:
- name: header-matcher
  # Optional: default service for this path matcher if no routeRules match
  defaultService: projects/example-project/regions/us-central1/backendServices/default-backend-service
  routeRules:
  - priority: 1
    matchRules:
    - headerMatches:
      - headerName: User-Agent
        regexMatch: .*Android.*-hd
    # This prefix match applies to the path part of the URL
    - prefixMatch: /video/
    # service: can be used instead of routeAction if no other actions are needed
    service: projects/example-project/regions/us-central1/backendServices/video-backend-service
    # Alternatively, use routeAction to specify the service:
    # routeAction:
    #   weightedBackendServices:
    #   - backendService: projects/example-project/regions/us-central1/backendServices/video-backend-service
    #     weight: 100

以下是範例網址對應關係中各欄位的說明：

defaultService：如果網址對應中沒有其他規則符合傳入要求，則指定要使用的預設後端服務。
name：將這項網址對應設定命名為 header-match-url-map。
hostRules：定義一組規則，用於比對傳入要求的 Host 標頭。這項規則會比對任何主機 (「*」)，並將流量導向名為 header-matcher 的 pathMatcher。
pathMatchers：定義已命名路徑比對器的清單。
name：定義名為 header-matcher 的路徑比對器。
defaultService：設定這個路徑比對器的預設服務。如果要求符合主機規則，但不符合這個路徑比對器中的任何 routeRules，就會使用這項服務。
routeRules：包含規則清單，可根據標頭和路徑比對傳入的要求。
priority：將這項規則的優先順序設為 1。系統會依優先順序值 (由小到大) 評估規則。
matchRules：包含一系列條件，必須全部符合，規則才會比對成功。
headerMatches：根據要求標頭指定條件。
headerName：尋找 User-Agent 標頭。
regexMatch：檢查 User-Agent 標頭值是否與規則運算式 .*Android.*-hd 相符。這會比對表示 Android 裝置的使用者代理程式，以及包含「-hd」的字串。
prefixMatch：設為 /video/，這項條件會檢查網址路徑是否以「/video/」開頭。
service：如果符合所有 matchRules 條件，流量就會導向這個後端服務。
註解排除的 routeAction 區段顯示指定後端服務的另一種方式，如果您需要設定其他路徑動作 (例如網址重寫、標頭轉換或加權後端服務)，就必須採用這種方式。

範例 3：使用規則運算式比對查詢參數

如果路徑與查詢參數的值符合 regexMatch 指定的規則運算式，系統就會判定查詢參數相符。舉例來說，在下列網址對應範例中，查詢參數規則運算式 /im.*/.*.html 會套用至含有查詢參數 (例如 /images/random_page.html?param1=param_value_123abc-hd) 的網址。

defaultService: projects/example-project/regions/us-central1/backendServices/sample-bs
name: query-match-url-map
hostRules:
- hosts:
  - '*'  # Match any host
  pathMatcher: query-matcher
pathMatchers:
- name: query-matcher
  # Optional: default service for this path matcher if no routeRules match
  defaultService: projects/example-project/regions/us-central1/backendServices/sample-bs
  routeRules:
  - priority: 1
    matchRules:
    - queryParameterMatches:
      - name: param1   #parameter name in query
        regexMatch: param_value_.*-hd
    # This regexMatch applies to the path part of the URL
    - regexMatch: /im.*/.*.html
    # Directs traffic to this service if all conditions in matchRules are met
    service: projects/example-project/regions/us-central1/backendServices/sample-images-bs

以下是範例網址對應關係中各欄位的說明：

hostRules：新增規則來比對所有主機 (*)，並將流量導向名為 query-matcher 的 pathMatcher。
pathMatchers：定義名為 query-matcher 的路徑比對器。
routeRules：將提供的 routeRules 區塊放在 query-matcher 中。
priority：將這項規則的優先順序設為 1。系統會依優先順序值 (由小到大) 評估規則。
matchRules：包含 routeRules 的條件。
queryParameterMatches：檢查名為「param1」的查詢參數是否符合規則運算式 param_value_.*-hd。
regexMatch：/im.*/.*.html 規則運算式會套用至網址路徑 (例如 /images/random_page.html)，位於查詢字串之前。
service：指定在 matchRules 內所有條件皆為 true 時，要使用的後端服務。

路由規則的規則運算式網址重寫

您可以使用規則運算式模式重寫動作 (regexRewrite)，在將要求轉送至後端之前，替換或移除網址路徑元件，藉此重寫網址路徑。

您可以使用下列欄位指定規則運算式：

pathMatchers[].routeRules[].routeAction.urlRewrite.regexRewrite.pathPattern：RE2 語法中的規則運算式，用於比對及擷取傳入要求路徑的部分。
pathMatchers[].routeRules[].routeAction.urlRewrite.regexRewrite.pathSubstitution：用於在將要求傳送至後端服務前，重新建構路徑的字串。您可以使用命名語法 \g<name> (適用於 (?<name>re) 等命名群組) 或編號語法 (例如 \1 或 \2)，參照 pathPattern 中的擷取群組。

RE2 擷取群組的運作方式

RE2 擷取群組是規則運算式中以括號 (...) 括住的部分，用於儲存相符文字，以便日後使用或擷取。這類規則可擷取路徑區隔，並在網址傳送至後端前重寫網址。

擷取群組是在 pathPattern 欄位中定義，格式為 (?<name>re) 或 (?P<name>re)，其中 name 是指派給要取代的網址路徑擷取部分的變數名稱，re 則是用於比對該部分的規則運算式模式。接著，系統會使用 \g<name> 格式，在 pathSubstitution 欄位中參照擷取的群組進行替換。

例如：

傳入用戶端要求網址路徑：/api/users/21334/profile.json
pathPattern：/api/users/(?<id>\d+)/(?<path>[a-z]+\.json)
pathSubstitution：/users/\g<id>/\g<path>
傳送至後端的路徑：/users/21334/profile.json

請注意，以 (?<name>re) 格式編寫的擷取群組會同時編號和命名。您可以使用名稱 \g<name> 或編號 \1 來參照這些物件。

其他使用注意事項：

規則運算式網址重寫功能僅適用於下列產品：
- 區域性內部應用程式負載平衡器
- 跨區域內部應用程式負載平衡器
- 區域性外部應用程式負載平衡器
- 全域外部應用程式負載平衡器
傳統版應用程式負載平衡器不支援規則運算式。
您必須使用 RE2 語法建構規則運算式。如需網址對應中允許的限制和運算子完整清單，請參閱「網址對應的 RE2 規格」。
每項路由規則只能指定一項網址重寫動作。regexRewrite 無法與 pathPrefixRewrite 或 pathTemplateRewrite 搭配使用。
pathSubstitution 欄位最多支援八個擷取群組，且必須在 pathPattern 欄位中定義。
pathPattern 和 pathSubstitution 欄位的長度上限皆為 250 個字元。

範例：使用規則運算式擷取群組重寫網址

以下範例說明如何設定網址對應，使用具名擷取群組擷取要求路徑的部分內容，並將其替換為新路徑。

在本範例中，傳入的要求網址 (例如 /region/us-central1/bucket/my-bucket/stage/dev/object.pdf) 會先重寫為 /us-central1/my-bucket-dev/object.pdf，再透過 Proxy 傳送至後端服務。

defaultService: projects/example-project/regions/us-central1/backendServices/default-bs
name: regex-rewrite-url-map
pathMatchers:
- name: region-matcher
  defaultService: projects/example-project/regions/us-central1/backendServices/default-bs
  routeRules:
  - matchRules:
    - prefixMatch: /region/
    priority: 1
    service: projects/example-project/regions/us-central1/backendServices/rewrite-bs
    routeAction:
      urlRewrite:
        regexRewrite:
          pathPattern: "/region/(?<reg>[a-z0-9-]+)/bucket/(?<bkt>[a-z0-9-]+)/stage/(?<stg>[a-z0-9-]+)/object\\.pdf"
          pathSubstitution: "/\\g<reg>/\\g<bkt>-\\g<stg>/object.pdf"

以下說明範例網址對應中使用的欄位：

defaultService：指定預設後端服務，如果沒有其他 routeRules 與傳入要求相符，要求就會轉送至該服務。
name：：使用者定義的網址對應名稱。
routeRules：定義流量比對和轉送方式的規則清單。系統會按照優先順序評估規則。
matchRules：必須符合的條件陣列，才能套用這項規則。
prefixMatch：比對網址路徑的開頭。在修正後的範例中，這可確保規則只會套用至開頭為 /region/ 的路徑。
priority：決定規則評估順序的整數。數字越小越優先。
service：如果符合這項規則的 matchRules 並執行轉送動作，流量會轉送至這個後端服務。
routeAction：指定要求符合 matchRules 時要採取的動作。
urlRewrite：定義網址在代理至後端服務前應如何修改。
regexRewrite：使用規則運算式設定網址重寫。
pathPattern：用於比對傳入網址路徑的規則運算式 (使用 Google RE2 語法)。使用 (?<name>re) 格式的命名擷取群組，可用於擷取部分路徑。在範例中，"/region/(?<reg>[a-z0-9-]+)/bucket/(?<bkt>[a-z0-9-]+)/stage/(?<stg>[a-z0-9-]+)/object\\.pdf" 會擷取區域 (reg)、bucket 名稱 (bkt) 和階段名稱 (stg)。
pathSubstitution：用於重建路徑的字串。它會使用 \g<name> 語法，參照模式中的具名擷取群組。在範例中，"/\\g<reg>/\\g<bkt>-\\g<stg>/object.pdf" 使用擷取的 reg、bkt 和 stg 值來建構新路徑：/us-central1/my-bucket-dev/object.pdf。

路徑規則和前置字元比對中的萬用字元、規則運算式和動態網址

路徑規則 (pathMatchers[].pathRules[]) 只能在正斜線字元 (/) 後方加入萬用字元 (*)。舉例來說，/videos/* 和 /videos/hd/* 是有效的路徑規則，但 /videos* 和 /videos/hd* 則無效。
路徑規則不使用規則運算式或子字串比對。PathTemplateMatch 可使用簡化的路徑比對運算子。舉例來說，/videos/hd 或 /videos/hd/* 的路徑規則不適用於路徑為 /video/hd-abcd 的網址。不過，/video/* 的路徑規則會套用至該路徑。
前置字元比對 (pathMatchers[].routeRules[].matchRules[].prefixMatch) 不會將 * 視為萬用字元，而是視為常值字元。
路徑比對器 (以及一般的網址對應) 不提供類似 Apache <LocationMatch> 指令的功能。如果應用程式會產生具有共同前置字元的動態網址路徑 (例如 /videos/hd-abcd 和 /videos/hd-pqrs)，且您需要將傳送至這些路徑的要求傳送至不同的後端服務，則可能無法使用網址對應執行這項操作。如果只有少數幾個可能的動態網址，您或許可以建立路徑比對器，並設定一組有限的路徑規則。如果是較複雜的情況，您必須在後端執行路徑式規則運算式比對。

路由規則路徑範本中的萬用字元和模式比對運算子

靈活的模式比對運算子可讓您使用萬用字元語法，比對網址路徑的多個部分，包括部分網址和尾碼 (副檔名)。如需依據複雜的網址路徑轉送流量及執行重寫作業，這些運算子就非常實用。您也可以將一或多個路徑元件與具名變數建立關聯，然後在重寫網址時參照這些變數。使用命名變數，即可在要求傳送至來源前，重新排序及移除網址元件。

只有下列產品支援使用萬用字元進行模式比對：

全域外部應用程式負載平衡器

區域性外部應用程式負載平衡器
區域性內部應用程式負載平衡器

跨區域內部應用程式負載平衡器
Cloud Service Mesh

以下範例會為電子商務應用程式轉送流量，該應用程式具有購物車資訊和使用者資訊的獨立服務。您可以設定 routeRules，使用彈性的模式比對運算子和命名變數，在重寫網址後，將使用者的專屬 ID 傳送至使用者帳戶詳細資料頁面，並將使用者的購物車資訊傳送至購物車處理服務。

  pathMatchers:
    - name: cart-matcher
      routeRules:
        - description: CartService
          matchRules:
            - pathTemplateMatch: '/xyzwebservices/v2/xyz/users/{username=*}/carts/{cartid=**}'
          service: cart-backend
          priority: 1
          routeAction:
            urlRewrite:
              pathTemplateRewrite: '/{username}-{cartid}/'
    - name: user-matcher
      routeRules:
        - description: UserService
          matchRules:
            - pathTemplateMatch: '/xyzwebservices/v2/xyz/users/*/accountinfo/*'
          service: user-backend
          priority: 1

當用戶端要求 /xyzwebservices/v2/xyz/users/abc@xyz.com/carts/FL0001090004/entries/SJFI38u3401nms?fields=FULL&client_type=WEB (同時包含使用者資訊和購物車資訊) 時，會發生以下情況：

要求路徑與 cart-matcher pathMatcher 中的 pathTemplateMatch 相符。{username=*} 變數與 abc@xyz.com 相符，{cartid=**} 變數與 FL0001090004/entries/SJFI38u3401nms 相符。
查詢參數會從路徑中分割，路徑會根據 pathTemplateRewrite 重新編寫，而查詢參數會附加至重新編寫的路徑。我們只能使用與 pathTemplateRewrite 中定義 pathTemplateMatch 時相同的變數。
重寫的要求會傳送至 cart-backend，並附上重寫的網址路徑：/abc@xyz.com-FL0001090004/entries/SJFI38u3401nms?fields=FULL&client_type=WEB。

如果用戶端改為要求 /xyzwebservices/v2/xyz/users/abc%40xyz.com/accountinfo/abc-1234 (僅包含使用者和帳戶資訊)，則會發生以下情況：

要求路徑與 user-matcher pathMatcher 中的 pathTemplateMatch 相符。第一個 * 符合 abc%40xyz.com，第二個 * 符合 abc-1234。
要求會傳送給user-backend。

下表列出路徑範本模式的語法。

運算子	相符
*``**	單一路徑區隔，不含周圍的路徑分隔符 `/` 字元。
``**	比對零或多個字元，包括多個路徑區段之間的任何路徑分隔符號 `/` 字元。如果包含其他運算子，`**` 運算子必須是最後一個運算子。
*`{name}` 或 `{name=}`**	與一個路徑區段相符的具名變數。比對單一路徑區隔，不包括周圍的路徑分隔符 `/` 字元。
*`{name=news/}`**	明確比對兩個路徑區段的具名變數：`news` 和 `*` 萬用字元區段。
*`{name=/news/}`*	與三個路徑區隔相符的具名變數。
`{name=}`**	與零或多個字元相符的具名變數。如有，則必須是最後一個運算子。

使用這些運算子進行彈性模式比對時，請注意下列事項：

您可以在單一模式中合併多個運算子。
查詢參數會從路徑中分割出來，路徑會根據 pathTemplateRewrite 重新編寫，而查詢參數會附加至重新編寫的路徑。
要求不會經過百分比編碼正規化。舉例來說，如果網址包含百分比編碼斜線字元 (%2F)，系統不會將其解碼為未編碼形式。
每個變數名稱 (例如 {segment} 或 {region}) 在同一個模式中只能出現一次。多個變數名稱相同則無效，會遭到拒絕。
變數名稱區分大小寫，且必須是有效的 ID。如要檢查變數名稱是否有效，請確認名稱符合規則運算式 ^[a-zA-Z][a-zA-Z0-9_]*$。
- {API}、{api} 和 {api_v1} 都是有效的 ID。他們找出三個不同的變數。
- {1}、{_api} 和 {10alpha} 不是有效的 ID。
每個範本模式最多只能有五個運算子。

如要在要求傳送至來源前執行選用的網址重寫作業，可以使用定義來擷取路徑的相同變數。舉例來說，定義 urlRewrite 時，您可以參照、重新排序或省略 pathTemplateRewrite 欄位中的變數。

使用變數和運算子彈性比對網址重寫模式時，請注意下列事項：

重寫網址時，如果變數並非重寫網址的一部分，則可省略。
在任何重寫作業之前，您可以檢查回應標頭，在來源端識別用戶端傳送的網址。原始用戶端網址會填入 x-client-request-url 標頭和 x-envoy-original-path 標頭。

外部應用程式負載平衡器的網址對應工作流程範例

以下範例說明網址對應的作業順序。這個範例只會設定現有傳統版應用程式負載平衡器的網址對應。為求概念簡單，本教學課程僅使用後端服務，但您也可以改用後端 bucket。如要瞭解如何建立負載平衡器的其他元件，請參閱「建立傳統版應用程式負載平衡器」。

如要進一步瞭解如何使用路徑比對器和主機規則建立及設定網址對應，請參閱 gcloud compute url-maps create 說明文件。

為負載平衡器建立網址對應，並指定預設後端服務。這個範例會建立名為 video-org-url-map 的網址對應，參照名為 org-site 的現有後端服務。
```
gcloud compute url-maps create video-org-url-map \
    --default-service=org-site
```
建立名為 video-matcher 的路徑比對器，並設定下列特性：
- 預設後端服務是 video-site，這是現有的後端服務。
- 新增路徑規則，將要求導向確切的網址路徑 /video/hd 或網址路徑前置字串 /video/hd/*，並傳送至名為 video-hd 的現有後端服務。
- 新增路徑規則，將要求導向確切網址路徑 /video/sd 或網址路徑前置字串 /video/sd/*，並傳送至名為 video-sd 的現有後端服務。
```
gcloud compute url-maps add-path-matcher video-org-url-map \
    --path-matcher-name=video-matcher \
    --default-service=video-site \
    --path-rules=/video/hd=video-hd,/video/hd/*=video-hd,/video/sd=video-sd,/video/sd/*=video-sd
```

為 example.net 主機名稱建立主機規則，並參照 video-matcher 路徑比對器。

gcloud compute url-maps add-host-rule video-org-url-map \
    --hosts=example.net \
    --path-matcher-name=video-matcher

video-org-url-map 網址對應應如下所示：

gcloud compute url-maps describe video-org-url-map

creationTimestamp: '2021-03-05T13:34:15.833-08:00'
defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/org-site
fingerprint: mfyJIT7Zurs=
hostRules:
- hosts:
  - '*'
  pathMatcher: video-matcher
- hosts:
  - example.net
  pathMatcher: video-matcher
id: '8886405179645041976'
kind: compute#urlMap
name: video-org-url-map
pathMatchers:
- defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-site
  name: video-matcher
  pathRules:
  - paths:
    - /video/hd
    - /video/hd/*
    service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-hd
  - paths:
    - /video/sd
    - /video/sd/*
    service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-sd
selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/urlMaps/video-org-url-map

video-org-url-map 網址對應會以下列方式，將要求的網址導向後端。

網址對應，包含路徑規則、路徑比對器和主機規則。 — 含有路徑規則、路徑比對器和主機規則的網址對應 (按一下可放大)。

下表說明上圖所示的要求處理程序。

主機名稱	網址路徑	選取的後端服務	選取理由
主機名稱： `example.org`和所有其他與 `example.net`不同的主機名稱	所有路徑	`org-site`	主機名稱不在網址對應的任何主機規則中，因此要求會導向網址對應的預設後端服務。
主機名稱： `example.net`	`/video` `/video/examples`	`video-site`	由於沒有 `/video/` 或 `/video/*` 的路徑規則，要求會傳送至預設後端服務。`example.net` 的主機規則參照了路徑比對器，但該路徑比對器沒有任何適用於這些路徑的路徑規則。
主機名稱： `example.net`	`/video/hd` `/video/hd/movie1` `/video/hd/movies/movie2` 其他開頭為 `/video/hd/*` 的網址	`video-hd`	`example.net` 的主機規則會參照路徑比對器，其路徑規則會將與 `/video/hd` 完全相符或開頭為 `/video/hd/*` 的網址路徑要求導向 `video-hd` 後端服務。
主機名稱： `example.net`	`/video/sd` `/video/sd/show1` `/video/sd/shows/show2` 其他開頭為 `/video/sd/*` 的網址	`video-sd`	`example.net` 的主機規則會參照路徑比對器，其路徑規則會將與 `/video/sd` 完全相符或開頭為 `/video/sd/*` 的網址路徑要求導向 `video-sd` 後端服務。

網址重新導向

網址重新導向會將網域訪客從一個網址重新導向至另一個網址。

「預設網址重新導向」不以傳入要求是否符合任何特定模式為條件。舉例來說，您可以使用預設網址重新導向，將「任何」主機名稱重新導向至您選擇的主機名稱。

建立網址重新導向的方法有幾種，如下表所示。

方法	設定
網址對應的預設網址重新導向	頂層`defaultUrlRedirect`
路徑比對器的預設網址重新導向	`pathMatchers[].defaultUrlRedirect[]`
路徑比對器的路徑規則網址重新導向	`pathMatchers[].pathRules[].urlRedirect`
路徑比對器路由規則的網址重新導向	`pathMatchers[].routeRules[].urlRedirect`

在 defaultUrlRedirect 或 urlRedirect 中，pathRedirect 一律會按照下列方式運作：

整個要求路徑會替換為您指定的路徑。

在 defaultUrlRedirect 或 urlRedirect 中，prefixRedirect 的運作方式取決於您的使用方式：

如果使用 defaultUrlRedirect，prefixRedirect 實際上是前置字串，因為比對到的路徑一律為 /。
如果您在路徑比對器的路由規則或路徑規則中使用 urlRedirect，prefixRedirect 會根據路徑規則或路由規則中定義的要求路徑比對方式，做為前置字元替換。

重新導向範例

下表提供一些重新導向設定範例。右側資料欄則顯示預設網址重新導向的 API 設定。

您想要	使用預設網址重新導向
HTTP 重新導向至 HTTPS 將 http://host.name/path 重新導向至 https://host.name/path	kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True
HTTP 轉 HTTPS + 主機重新導向將 http://<任意主機名稱>/<路徑> 重新導向至 https://www.example.com/<路徑>	kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True hostRedirect: "www.example.com"
HTTP 轉 HTTPS + 主機重新導向 + 完整路徑重新導向將 http://<任意主機名稱>/path 重新導向至 https://www.example.com/newPath	kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True hostRedirect: "www.example.com" pathRedirect: "/newPath"
HTTP 轉 HTTPS + 主機重新導向 + 前置字元重新導向將 http://<任意主機名稱>/<原始路徑> 重新導向至 https://www.example.com/newPrefix/<原始路徑>	kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True hostRedirect: "www.example.com" prefixRedirect: "/newPrefix"

下列部分程式碼片段會為每個 API 資源加上註解：

defaultUrlRedirect:
   redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
   httpsRedirect: True # True if you want https://, false if you want http://
   hostRedirect: "new-host-name.com" # Omit to keep the requested host
   pathRedirect: "/new-path" # Omit to keep the requested path; mutually exclusive to prefixRedirect
   prefixRedirect: "/newPrefix" # Omit to keep the requested path; mutually exclusive to pathRedirect
   stripQuery: False # True to omit everything in the URL after ?
   ...

後續步驟

如要新增、驗證、測試、列出或刪除網址對應，請參閱「使用網址對應」。
如要瞭解 Cloud Service Mesh 的路由規則對應關係，請參閱「Cloud Service Mesh 路由規則對應關係總覽」。

網址對應總覽 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

網址對應的運作方式

負載平衡器命名

網址對應元件

主機名稱和主機規則關係

主機規則和路徑比對器關係

網址和後端關係

網址對應和通訊協定

最簡單的網址對應

作業順序

網址對應設定限制

主機和路由規則中的規則運算式比對器

範例 1：使用規則運算式比對路徑

範例 2：使用規則運算式比對標頭

範例 3：使用規則運算式比對查詢參數

路由規則的規則運算式網址重寫

RE2 擷取群組的運作方式

範例：使用規則運算式擷取群組重寫網址

路徑規則和前置字元比對中的萬用字元、規則運算式和動態網址

路由規則路徑範本中的萬用字元和模式比對運算子

外部應用程式負載平衡器的網址對應工作流程範例

網址重新導向

重新導向範例

後續步驟

網址對應總覽