本文提供ALB轉寄規則的常見情境配置樣本，並介紹網域名稱和路徑的匹配規則、重寫與重新導向的路徑增強配置規則。
常見情境配置樣本
情境一：HTTP強制跳轉HTTPS
將使用者的HTTP請求自動跳轉到HTTPS，確保資料轉送加密。需要為HTTP監聽（連接埠80）添加一條轉寄規則。
參數 | 說明 |
轉寄條件 | 選擇路徑：精確匹配及萬用字元並輸入 |
轉寄動作 | 選擇重新導向至。
|
效果：使用者訪問http://www.example.com/page時，瀏覽器自動跳轉到https://www.example.com/page。
該規則需要配置在HTTP監聽（連接埠80）上。同時，請確保已建立HTTPS監聽（連接埠443）並關聯了有效SSL認證。完整的前提條件和操作步驟，請參見使用ALB將HTTP訪問重新導向至HTTPS。
情境二：同網域名稱按路徑分流到不同後端
同一個網域名稱下，將不同路徑的請求轉寄到不同的伺服器組。例如將API請求和靜態資源請求分別轉寄到不同的後端。
規則1：將/api/*的請求轉寄到API伺服器組。
參數 | 說明 |
轉寄條件 | 選擇路徑：精確匹配及萬用字元並輸入 |
轉寄動作 | 選擇轉寄至，然後選擇API伺服器組。 |
規則2：將/static/*的請求轉寄到靜態資源伺服器組。
參數 | 說明 |
轉寄條件 | 選擇路徑：精確匹配及萬用字元並輸入 |
轉寄動作 | 選擇轉寄至，然後選擇靜態資源伺服器組。 |
ALB按轉寄規則的編號順序逐條匹配。請將更具體的路徑規則排在前面（編號更小），避免被萬用字元規則優先匹配。例如，/api/v2/*應排在/api/*之前。
情境三：多網域名稱轉寄到不同後端
在同一個ALB執行個體上託管多個網域名稱，將不同網域名稱的請求轉寄到各自的後端伺服器組。
規則1：將www.example.com的請求轉寄到Web伺服器組。
參數 | 說明 |
轉寄條件 | 選擇網域名稱：精確匹配及萬用字元並輸入 |
轉寄動作 | 選擇轉寄至，然後選擇Web伺服器組。 |
規則2：將api.example.com的請求轉寄到API伺服器組。
參數 | 說明 |
轉寄條件 | 選擇網域名稱：精確匹配及萬用字元並輸入 |
轉寄動作 | 選擇轉寄至，然後選擇API伺服器組。 |
情境四：去除路徑首碼後轉寄
將請求路徑中的特定首碼去除後轉寄到後端，同時支援匹配首碼後的多層路徑。例如，ALB轉寄www.example.com/api/aaa/bbb/...的訪問請求時，需要在路徑中去除/api部分，同時支援匹配/api後的多層路徑。
重寫在ALB內部完成路徑替換，用戶端瀏覽器地址欄不變；重新導向會向用戶端返回一個新的URL，瀏覽器地址欄會更新為新地址。如果僅需後端收到去除首碼後的路徑，使用重寫；如果需要用戶端感知到URL變化，使用重新導向。
重寫
參數 | 說明 | |
轉寄條件 | 網域名稱 | 精確匹配及萬用字元並輸入 |
路徑 | 正則匹配｜不區分大小寫並輸入 | |
轉寄動作 | 重寫 |
|
轉寄至 | 選擇目標伺服器組。 | |
重新導向
參數 | 說明 | |
轉寄條件 | 網域名稱 | 精確匹配及萬用字元並輸入 |
路徑 | 正則匹配｜不區分大小寫並輸入 | |
轉寄動作 | 重新導向至 |
|
效果：使用者訪問www.example.com/api/aaa/bbb/...時，後端伺服器收到的請求路徑為/aaa/bbb/...。
情境五：裸網域名稱跳轉到www子網域名稱
將裸網域名稱（如example.com）的訪問跳轉到www.example.com，統一入口便於SEO和管理。
參數 | 說明 |
轉寄條件 | 選擇網域名稱：精確匹配及萬用字元並輸入 |
轉寄動作 | 選擇重新導向至。
|
效果：使用者訪問example.com時，瀏覽器自動跳轉到www.example.com，協議和連接埠保持不變。
如果還需要同時將HTTP跳轉到HTTPS，請配合情境一使用。
情境六：萬用字元網域名稱匹配
使用萬用字元網域名稱統一匹配所有子網域名稱，將請求轉寄到同一個伺服器組。
參數 | 說明 |
轉寄條件 | 選擇網域名稱：精確匹配及萬用字元並輸入 |
轉寄動作 | 選擇轉寄至，然後選擇目標伺服器組。 |
效果：a.example.com、b.example.com、tenant1.example.com等所有子網域名稱的請求都會轉寄到同一個伺服器組。
如果需要某個特定子網域名稱轉寄到不同的伺服器組，請將該精準網域名稱規則的編號設定在萬用字元規則之前。ALB不會自動按網域名稱精確程度排序，而是按規則編號順序匹配。
情境七：基於HTTP標題灰階發布
通過HTTP標題實現灰階發布，將帶有特定標題的請求轉寄到新版本伺服器組，其他請求仍然轉寄到舊版本。
規則1（灰階規則，編號靠前）：將攜帶X-Canary: true的請求轉寄到新版本伺服器組。
參數 | 說明 |
轉寄條件 | 選擇HTTP標題，鍵設定為 |
轉寄動作 | 選擇轉寄至，然後選擇新版本伺服器組。 |
規則2（預設規則，編號靠後）：不攜帶該標題的請求繼續轉寄到舊版本伺服器組。可通過監聽的預設轉寄規則實現。
效果：用戶端請求攜帶X-Canary: true標題時，流量轉寄到新版本伺服器組；未攜帶該標題的請求仍轉寄到舊版本伺服器組。
灰階規則的編號必須小於預設規則，確保灰階流量被優先匹配。關於基於Cookie和伺服器組權重的灰階方式，請參見使用ALB實現灰階發布。
轉寄條件的網域名稱配置規則
ALB按轉寄規則編號的優先順序順序逐條匹配，命中即停，不會自動按網域名稱的精確程度排序。此機制與CLB中"精確匹配 > 小範圍通配 > 大範圍通配"的自動排序不同。
例如，同一監聽下有以下兩條規則：
規則編號 | 轉寄條件 |
規則1（編號1） | 網域名稱 = |
規則2（編號2） | 網域名稱 = |
此時訪問www.example.com將匹配規則1（萬用字元），而非規則2（精準網域名稱），因為規則1編號更小。
正確做法：將精準網域名稱規則的編號設定在萬用字元規則之前（即調換為規則1 =www.example.com，規則2 =*.example.com）。
網域名稱配置規則 | 說明 |
精準匹配及萬用字元 |
|
正則匹配 |
|
轉寄條件的路徑配置規則
ALB的路徑匹配規則與Nginx不同，ALB不支援路徑最長相符原則。例如，Nginx的常用配置為location /api，匹配location的方式為最長首碼匹配，ALB的最長首碼匹配需通過萬用字元實現。使用者可以在ALB上配置/api/*（精準匹配及萬用字元）來達到相同的效果。
如果同一監聽下有/api/*和/api/v2/*兩條規則，必須將/api/v2/*的規則編號設定在/api/*之前，否則所有請求都會被/api/*優先匹配。
路徑配置規則 | 說明 |
精準匹配及萬用字元 |
|
正則匹配 |
|
重寫和重新導向中路徑的增強配置規則
轉寄條件的路徑配置Regex後，轉寄動作中的重寫和重新導向的路徑支援Regex替換。
注意事項
轉寄條件中Regex中包含的半形圓括弧
( )需要與轉寄動作中重寫或重新導向路徑中$變數的個數保持一致。轉寄動作中重寫或重新導向的路徑中需要包含
${1}、${2}、${3}中的一個或多個，且這三個變數不支援使用其他字元代替。
替換原理
路徑匹配：用戶端發送請求，並匹配到某一條路徑轉寄規則的Regex。
提取與替換：按照Regex的規範提取，將前三個半形圓括弧
( )提取出來的內容分別儲存至${1}、${2}、${3}中，用於在轉寄動作的重寫或重新導向路徑中替換。拼接：按照轉寄動作中重寫或重新導向路徑的配置，對其中的
${1}、${2}、${3}進行值的替換，最終拼接成重寫或重新導向的實際路徑。
編號
步驟
樣本
1
配置轉寄規則中的轉寄條件和轉寄動作。
轉寄條件路徑：
/app/(.*)/(.*)/settings轉寄動作重寫或重新導向路徑：
/${1}/${2}
2
用戶端發送請求，並匹配路徑。
用戶端發送的請求路徑：
/app/users/profile/settings匹配到的轉寄條件路徑：
/app/(.*)/(.*)/settings
3
提取與替換
按照Regex規範，轉寄條件路徑中的兩個
(.*)分別提取到users和profile，並分別保留至轉寄動作中重寫或重新導向路徑中的${1}和${2}。${1}替換為users${2}替換為profile
4
拼接路徑
後端伺服器接收到的路徑：
/users/profile配置樣本
您可以根據注意事項和替換原理，在控制台上添加轉寄規則。
樣本1：轉寄動作為重寫和轉寄至
以下樣本將路徑
/app/users/profile/settings重寫為/users/profile後轉寄到後端。其中，Regex/app/(.*)/(.*)/settings通過兩個擷取的群組分別提取users和profile，然後在重寫路徑中使用${1}/${2}拼接成最終路徑。配置項
說明
轉寄條件
路徑
選擇正則匹配｜不區分大小寫並輸入Regex
/app/(.*)/(.*)/settings。例如：用戶端請求路徑為
/app/users/profile/settings，將匹配該規則，擷取的群組分別提取users和profile，對應${1}和${2}。轉寄動作
重寫
網域名稱：
${host}路徑：
/${1}/${2}查詢：
${query}
查詢的內容指URL中問號後面的部分。樣本：URL為
www.example.com/test/test1?x=1，查詢的內容為x=1。轉寄至
在伺服器組列表中選擇目標伺服器組。
樣本2：轉寄動作為重新導向
以下樣本將路徑
/app/users/profile/settings重新導向為/users/profile。與樣本1不同的是，重新導向會返回301狀態代碼，瀏覽器地址欄的URL會發生變化。配置項
說明
轉寄條件
路徑
選擇正則匹配｜不區分大小寫並輸入Regex
/app/(.*)/(.*)/settings。例如：用戶端請求路徑為
/app/users/profile/settings，將匹配該規則，擷取的群組分別提取users和profile，對應${1}和${2}。轉寄動作
重新導向至
協議：
${protocol}網域名稱：
${host}連接埠：
${port}路徑：
/${1}/${2}查詢：
${query}狀態代碼：
301
常見問題
如何僅重寫網域名稱而不修改路徑？
如果您需要將請求的網域名稱重寫為另一個網域名稱，但保持路徑和查詢字串不變，可以按照以下方式配置：
轉寄條件：網域名稱設定為原始網域名稱，如
old.example.com。轉寄動作：重寫，網域名稱設定為新網域名稱（如
new.example.com），路徑設定為${path}（保持原路徑），查詢設定為${query}（保持原查詢字串）。同時配置轉寄至目標伺服器組。
如何為路徑添加首碼？
如果您需要在原始路徑前添加版本號碼等首碼，例如將/users/list重寫為/v2/users/list，可以按照以下方式配置：
轉寄條件：路徑正則匹配設定為
^/(.*)。轉寄動作：重寫，路徑設定為
/v2/${1}。同時配置轉寄至目標伺服器組。
配置後，請求/users/list將被重寫為/v2/users/list後轉寄至後端伺服器。
如何去除路徑中的特定首碼？
請參見本文的情境四：去除路徑首碼後轉寄。該情境以/api/*為例，展示了使用正則匹配 + 重寫或重新導向去除首碼的完整配置。
轉寄規則匹配不上/路由不對怎麼排查？
如果配置了轉寄規則但請求沒有按預期路由，可按以下步驟排查：
檢查規則編號順序：ALB按規則編號從小到大逐條匹配，命中即停。如果一條更寬泛的規則編號排在前面，後面更精確的規則將不會被匹配到。
檢查匹配類型：確認使用了正確的匹配類型（精準匹配、萬用字元、正則）。例如，精準匹配
/api不會匹配/api/users，需要使用萬用字元/api/*。檢查多條件組合：一條轉寄規則配置多個轉寄條件時，不同類型的條件之間為"與"（AND）關係，同一類型條件的多個值之間為"或"（OR）關係。詳細說明請參見配置監聽轉寄規則。
查看訪問日誌：通過ALB訪問日誌的
host和request_uri欄位，確認ALB收到的實際請求內容是否與預期一致。
重寫和重新導向有什麼區別？該選哪個？
對比項 | 重寫（Rewrite） | 重新導向（Redirect） |
瀏覽器地址欄 | 不變（使用者無感知） | 變化為新URL |
處理方式 | ALB內部修改請求路徑後轉寄到後端，一次請求完成 | ALB返回3xx狀態代碼，瀏覽器發起第二次請求訪問新URL |
適用情境 | 去除路徑首碼、添加版本號碼等內部路徑調整 | HTTP→HTTPS跳轉、裸域→www跳轉、舊URL遷移 |
是否需要配合轉寄至 | 是，重寫必須同時配置"轉寄至"目標伺服器組 | 否，重新導向獨立生效 |
相關文檔
如果您需要為ALB監聽配置其他監聽轉寄規則，請參見配置監聽轉寄規則。