Azure帳號購買優惠 Azure CDN重定向規則怎麼寫

Azure帳號購買優惠 第一章：先搞清楚你要的到底是哪一種「重定向」

很多人一開始做 Azure CDN 的重定向規則，會把三件事混在一起：重定向（redirect）、改寫（rewrite）、以及連同快取策略一起處理的行為。它們的核心差別在於「回應給用戶端的結果」以及「你把 URL 改成什麼樣」。先分清楚，才不會在後面一直猜為什麼不生效。

重定向：CDN 回應用戶端一個狀態碼（301/302/307/308 之類）和一個 Location。瀏覽器會再發起下一次請求到新網址。使用者看到的網址也可能變成新網址。

改寫：CDN 在「到來源站」之前把請求路徑調整，但用戶端地址通常不變。用戶端不會因為改寫而自動跳轉。

快取/回源行為：有些需求其實不是要跳轉，而是要讓特定路徑走不同快取規則或不同來源。

本篇文章重點放在你標題提到的「Azure CDN 重定向規則怎麼寫」：也就是讓 CDN 回應重定向，或用規則把請求引導到另一個路徑。

第二章：在開始寫規則前，先列出需求

重定向規則不是寫越多越好，而是把需求描述清楚。你至少要回答這些問題：

• 要重定向哪些 URL？ 例如只要重定向 /old/*，還是整站都要。
• 匹配條件是什麼？ 只看路徑？還是要看 query string？是否要根據 header 判斷？
• 要改成什麼樣的目標？ 目標是絕對網址、站內新路徑，還是保留原始路徑的一部分。
• 要用哪個狀態碼？ 301 表示永久移除（對 SEO 很重要）；302/307/308 則影響快取與行為。
• 目標是否需要保留 query 參數？ 很多人會忘記保留，導致登入、追蹤、或前端路由出問題。

把需求寫成一句話，後面規則就會變得可落地。舉例：

「當使用者請求 https://example.com/legacy/* 時，把它 301 轉到 https://example.com/new/*，並保留原本的 query string。」

第三章：Azure CDN 重定向規則的基本思路

實務上你會在 CDN 設定某個「規則集」或「規則」中，建立：

• 條件（Conditions）：符合什麼請求才觸發。
• 動作（Actions）：觸發後做什麼事，例如 Redirect。
• 狀態碼（Status code）：301/302/307/308。
• 目標（Destination）：要跳到哪個網址或路徑。

雖然不同 CDN 服務（如 Azure Front Door、Azure CDN Standard from Verizon、或其他節點）在介面與細節上會有差異，但核心邏輯都一樣：先判斷，再決定回應。

下面用「可套用的規則寫法觀念」教你怎麼思考，避免你看到選項就直接亂填。

第四章：規則寫作模板（從簡單到複雜）

4.1 單一固定路徑：把 /old 替換成 /new

需求：使用者打到 /old，永遠改到 /new。

條件很簡單：匹配路徑等於 /old（通常要注意前導斜線）。動作選 Redirect，狀態碼可用 301。

目標網址：你可以寫成「站內路徑」或「完整網址」，依你介面支援。若要站內路徑，一般會像這樣：

• 條件：Path equals '/old'
• 動作：Redirect to '/new'
• 狀態碼：301

這個例子成功後，你才有基礎理解整套邏輯。

4.2 路徑前綴重定向：/old/* → /new/*

這是最常見的遷移需求：把一整段路徑搬家。

需求：/old/blog/123 → /new/blog/123。

關鍵在於「要把被匹配的尾巴接回去」。所以你需要使用 CDN 規則的通配符或群組（不同平台叫法不同）。常見用法是：

• 匹配：'/old/*'
• 目標：'/new/*'（並確保 * 的部分被保留）

實務上你會遇到兩種狀況：

• 如果你的目標沒有正確引用通配內容，跳到的可能只是一個固定路徑（例如永遠跳到 /new）。
• 如果你的規則順序不對，某個更一般的規則先命中，導致專用規則根本沒機會執行。

因此建議你建立規則後立即做測試（下一章會教你怎麼測）。

4.3 以查詢參數為條件：當特定 query 才重定向

有時你只想在某些情境跳轉，例如：當 query 包含 token=xxx 才導向新流程；或舊版系統用特定參數觸發。

這類需求的寫法重點是：

• 條件不只看 Path，也要看 Query 中的特定鍵值。
• 重定向目標要決定是否「保留全部 query」或「只保留某些鍵」。

如果你的平台預設不保留 query，你就需要在 Redirect 目標中明確引用 query。反過來，如果平台預設保留，你也要確保沒有重複拼接導致兩次參數。

建議你在測試時特別用兩種 URL 驗證：

• 沒有 query 的版本
• 有完整 query 的版本

避免上線後才發現某些行為依賴 query。

4.4 301 vs 302/307：選錯會怎樣

狀態碼並不是形式問題。它會影響：

• 瀏覽器與中介快取是否會記住你的跳轉結果
• 搜尋引擎如何理解「永久搬遷」
• 某些 HTTP 方法（POST/PUT）在 302/307/308 的行為差異

一般建議：

• 站內網址永久改版：用 301
• 短期導流或測試：用 302 或 307
• Azure帳號購買優惠 保留方法語意：若涉及 POST/PUT，通常 307/308 更能維持行為一致

你不需要一次全懂，但要知道「你選的是什麼意圖」。如果你是做遷移，通常 301 比較符合 SEO 與使用者預期。

第五章：常見規則寫法錯誤（以及怎麼避開）

5.1 忘記規則順序：上游規則搶先命中

很多 CDN 都是「第一個匹配就執行」或「按優先順序判斷」。你可能寫得完全正確，但因為另一條更寬的規則先命中，結果你期待的重定向沒有發生。

Azure帳號購買優惠 解法：

• 把最具體的規則放在前面（例如 /old/blog/* 比 /old/* 更具體）
• 用命名與註解清楚每條規則的目的
• 測試時用一個「會被具體規則命中的」URL

5.2 大小寫與斜線：/Old 與 /old 行為不一致

Azure帳號購買優惠 路徑匹配是否大小寫敏感，常常取決於底層規則引擎與平台設定。有些情境看起來「同一個路徑」其實會匹配不到。

解法：

• 確認你的平台對 Path 比對是否區分大小寫
• 若你無法確保一致，盡量把使用者輸入導向到同一個規範（例如強制小寫）

如果你做的是網站遷移，請記得測試：大小寫不同但語意相同的 URL。

5.3 遺失 query string：跳轉後登入或追蹤失效

這是最常見的實戰坑。你寫了重定向，但目標 URL 沒有包含 query，導致原本攜帶的參數丟失。

解法：

• 確認平台預設是否保留 query
• 如需保留，明確配置「保留全部 query」或引用必要參數
• 測試至少包含兩種 query：空 query 與完整 query

5.4 形成重定向迴圈：/a → /b 且 /b → /a

迴圈不一定是你主動寫的，有時是兩個規則在不同條件下都會觸發，結果互相跳。

解法：

• 在規則設計階段就畫出 URL 的轉換流程
• 避免用過於寬的條件（例如只要包含某字就跳）
• 測試時用「多跳前後」確認不會無限跳轉

第六章：一套你可以直接套用的實例（含測試方式）

下面用一個真實感很強的遷移案例，讓你看見「規則怎麼寫」以及「如何驗證」。

假設你把舊網站的內容路徑從：

/legacy/products/{slug}?ref=campaign

搬到：

/products/{slug}?ref=campaign

並且你希望：

• 所有 /legacy/products/* 都用 301
• 保留 query string（至少保留 ref 與其他參數）
• 如果路徑不是 legacy/products，就不要處理

6.1 規則的條件（Condition）

你需要限制匹配範圍：只針對 /legacy/products/ 開頭的路徑。若平台支援通配符或路徑參數，就用它。

• 條件：Path 前綴 equals '/legacy/products/'（或使用 '/legacy/products/*'）

這樣就能避免對 /legacy/other/* 之類的路徑誤傷。

6.2 規則的動作（Action）：重定向目標如何寫

你要把尾巴接到 /products/。

• Azure帳號購買優惠 目標：'/products/{matched_tail}'

在大多數規則引擎裡，{matched_tail} 就是通配符或群組捕獲的部分。你需要確保目標 URL 的那段能引用到捕獲結果。

此外，query string 要保留。通常做法是：

• 如果平台有「保留 query」選項：打開
• 如果平台沒有：就需要在目標中加入 query 的引用模板

最終效果應該是：

• 請求：/legacy/products/abc?ref=campaign&x=1
• 回應：301 Location: /products/abc?ref=campaign&x=1

6.3 狀態碼的選擇

遷移通常用 301。因為你想告訴瀏覽器與搜尋引擎，舊路徑已永久移除，新路徑是正確答案。

如果你只是臨時導流，才改成 302 或 307。

6.4 實測：別只看「有沒有跳」，要看「跳到哪裡」

測試我建議用三組 URL：

• 標準案例：/legacy/products/abc?ref=campaign&x=1
• 只有必要 query：/legacy/products/abc?ref=campaign
• 沒有 query：/legacy/products/abc

你需要檢查三件事：

• 狀態碼是否正確（301）
• Azure帳號購買優惠 Location 的路徑與參數是否正確
• 是否有意外的重定向迴圈

如果你有辦法查看 CDN 的回應頭更好。否則用瀏覽器開發者工具也能看到。

第七章：更進階的需求：保留主機、改寫子網域、或改成絕對網址

當你做的不只是站內路徑搬遷，可能還會牽涉到子網域或完整網址。這時候最容易寫錯。

7.1 目標是站內路徑還是完整 URL？

如果你要把 /legacy 到新域名（例如把 example.com 搬到 newsite.com），你通常要寫完整 URL。

判斷方式：

• Azure帳號購買優惠 只在同一個網域內搬路徑：寫站內路徑即可（例如 /products/abc）
• 要換網域或換協定：寫完整目標（例如 https://newsite.com/products/abc）

站內路徑寫錯時，可能仍會跳到你原來的網域；而完整 URL 寫錯則可能造成跨網域跳轉失敗或導向錯誤。

7.2 保留原本的查詢參數：只保留部分參數

有些情況你不希望保留全部 query，例如來源參數太多、或其中某些參數不應暴露到新系統。這時你要選擇「白名單保留」。

作法通常是：

• 目標 URL 只拼上你允許的 query 鍵
• Azure帳號購買優惠 其他 query 不帶過去

這種寫法需要你非常確定新系統依賴哪些參數。否則你可能讓某些功能在新站不可用。

第八章：部署與除錯：讓規則真正上線可控

規則部署不是寫完就結束。你要讓它能被追蹤、能被回滾、能被快速定位。

8.1 分階段上線：先小範圍再擴大

不要一口氣把整個站的 /old/* 全部改好再等運氣。建議你：

• 先用最小匹配範圍測通（例如只測 /legacy/products/abc）
• 確認 Location、query、狀態碼都正常後，再擴到整個前綴
• 最後才做更寬的規則（例如所有 /legacy/*）

8.2 使用日誌或觀測手段定位問題

重定向失敗通常不是「規則完全沒作用」，而是「匹配不對」或「目標拼接不對」。你需要能觀察：

• 是否命中該規則
• 重定向的目標 URL 是否如預期
• 瀏覽器端是否仍有其他行為（例如前端路由）干擾

如果你的環境能看到 CDN 的請求日誌，優先用它。否則就以瀏覽器開發者工具為起點。

8.3 快取觀點：重定向也可能被快取影響

有些情況下，重定向回應會被快取或被瀏覽器緩存。你上線後立刻修改規則時，可能出現「看起來沒變」的錯覺。

你可以採取：

• 用無快取的方式測試（例如使用隱私視窗或清除快取）
• 理解 301 可能被更長時間記住；如果你正處於調整期，先用 302 或臨時狀態碼更安全

第九章：把規則寫得乾淨可維護，而不是堆疊

規則一多就會亂。想避免未來維護成本爆炸，你可以遵循幾個寫法準則：

• 每條規則都只做一件事：例如只處理 /legacy/products/* 的遷移，不要同時處理 /legacy/blog/*。
• 使用一致的命名：例如 RedirectLegacyProducts_301。
• Azure帳號購買優惠 在條件上盡量具體：具體匹配既能避免誤傷，也更好除錯。
• 避免重複規則：如果兩條規則效果相同，合併成一條。

尤其當你團隊協作時，清楚的規則結構就是對未來的投資。

第十章：常用規則清單（你可能很快就用得上）

下面整理一些常見模式，你可以把它們當成檢查清單。實際寫入時依你的 CDN 介面語法調整。

• 固定重導：/old → /new（301/302）
• 前綴重導：/old/* → /new/*（保留尾巴）
• 限定 query：當 query 含某鍵值才重導
• Azure帳號購買優惠 保留 query：Location 帶上原 query 或啟用保留選項
• Azure帳號購買優惠 只保留部分 query：白名單拼接到目標
• 避免迴圈：確認新目標不會被同一套規則再次命中

如果你把每一次需求都對應到其中一種模式，寫規則會快很多。

第十一章：最後的落地建議

你真的要掌握「Azure CDN 重定向規則怎麼寫」，關鍵不是記住某個按鈕長什麼樣，而是建立正確的思維流程：

• 先定義要匹配哪些 URL，以及要怎麼命名結果（新路徑是什麼規則）。
• 再確認狀態碼的意圖（永久還是臨時）。
• 最後把 query 與規則順序當成高風險點重點測試。

當你做到這三點，就能把重定向規則從「猜測」變成「可預期的工程」。

結語：你可以從一條最簡單的重導開始

如果你現在還不確定怎麼寫，建議從最簡單的開始：先做 /old → /new 的 301。確認回應的狀態碼與 Location 正確，再把匹配擴成 /old/*，最後才處理 query 保留與條件判斷。這樣你每一步都能驗證，整個遷移就不會變成不可控的賭局。