Nginx、.htaccess、CDN 規則還是 Edge Redirects：重新導向該放在哪裡？

Nginx、Apache .htaccess、CDN 規則、應用程式 middleware 和 edge redirects 都能把一個 URL 導到另一個 URL。真正的問題不是哪一層可以做 redirect，而是當這條規則牽涉 SEO、廣告參數、客戶確認、上線窗口和 rollback 責任時，哪一層最適合擁有它。

一條固定 301 放在 server config 可能很合理。幾萬列網站遷移 map、換網域時要保留 path 和 UTM、或同一個 LINE/QR/廣告連結要依國家和裝置導到不同 destination，就不應該藏在五套設定裡。

這篇文章適合正在做 WordPress、Shopify、WooCommerce、headless storefront、品牌網域整併、跨境電商改版，或清理多年累積 Nginx、.htaccess、CDN 規則與 CMS 外掛的團隊。

決策原則

把 redirect 放在負責團隊能安全審查、測試、發布、監控和 rollback 的那一層。

許多 redirect 問題不是語法錯，而是所有權分散：

• 工程團隊擁有 Nginx 或 app middleware
• 主機商或代理商修改 Apache .htaccess
• SEO 團隊擁有 migration map 和搜尋風險
• 行銷團隊擁有廣告連結、UTM、LINE、QR code 和 affiliate links
• CDN 設定擁有 HTTPS、root/www 和 hostname 正規化
• 客戶或業務 owner 確認商品、分類和活動目標頁

每一層都能 redirect 時，瀏覽器最後可能仍然到達頁面。但團隊很難說清楚哪條規則觸發、為什麼多了一個 hop、哪一層弄丟 query、哪個 change 應該回滾。

先畫出真實 routing path

移動任何規則之前，先畫出 request 的實際路徑。常見既有架構可能像這樣：

1. DNS 把 hostname 指向 CDN 或 edge network
2. CDN 規則處理 HTTPS、root/www、舊 hostname 或地區 path
3. edge routing 處理 campaign links、branded links 或 migration map
4. Nginx 或 Apache 執行 server-level rewrite
5. .htaccess、WordPress、WooCommerce、Shopify 或 CMS 外掛執行其他 redirect
6. 應用程式 middleware 判斷帳號、商品、語言、價格或功能 route

最安全的層不一定是最早執行的層，而是最能擁有這條規則意圖的層。HTTPS 和 hostname 正規化可以靠近網路層；客戶確認過的 migration map 更需要可審查、可匯入、可驗證、可回滾的 workflow。

server config 適合的情境

Nginx 或 Apache 主設定仍然適合小而穩定、由同一個工程團隊負責的 redirect。

危險訊號不是 Nginx 或 Apache，而是營運責任已經超出伺服器部署流程。如果 SEO、行銷、客服、代理商或客戶需要檢視規則，把它藏在伺服器檔案裡就不再是好的 system of record。

為什麼 .htaccess 不適合當 migration system

.htaccess 是 Apache 的分散式設定。當團隊沒有主設定權限時，它很有用。但這種彈性在網站遷移時會變成風險。

redirect program 常見問題包括：

• 規則按目錄分散，無法像完整 map 一樣審查
• per-directory rewrite 的 path 語義和 server config 範例不同
• 主機面板、FTP、CMS 或外掛可能繞過正式 release flow 修改規則
• 排障時必須知道最終 response 前哪些目錄檔案被載入

Apache 官方文件也建議：如果有主設定權限，通常應避免 .htaccess。對遷移而言，治理比語法更重要：redirect map 需要 owner、review status、import history 和 rollback。

共享主機或舊 WordPress 可能沒有更好選擇。但不要把 .htaccess 當成 migration map、campaign links、國家/裝置 routing 或商品目錄變更的長期管理系統。

CDN 規則什麼時候足夠

CDN redirect rules 適合簡單、穩定、確實屬於網路層的邏輯。

典型例子：

• apex 到 www，或 www 到 apex
• HTTP 到 HTTPS
• 一兩條固定網域轉址
• 舊 hostname 下線
• 平台團隊擁有的維護 redirect

當規則開始需要商業語境時，CDN 規則就會變得侷限：CSV 匯入、客戶審查、path exception、query preservation、rule-level analytics、國家/裝置條件、batch rollback。這時 redirect 已經不是 network normalization，而是 traffic infrastructure。

edge redirects 更清楚的情境

當 redirect 需要的不是單純執行，而是一套營運 workflow，edge routing 通常更適合。

適合移到 edge 的情境：

• 可審查的 bulk import 和 migration map
• path、query string、UTM 保留策略
• 依國家、裝置、語言、header、cookie、campaign routing
• rule-level hit counts 和 analytics
• snapshot publishing 和 rollback
• SEO、行銷、工程、代理商、客戶共同審查
• 不經 origin deploy 快速修正高風險 URL

不是所有 redirect 都必須移到 edge。重點是：高變更、高風險、多團隊參與的 redirect，不應該只存在於少數人看得懂的 server file、CMS 外掛或 CDN 小規則裡。

用 ownership matrix 分類

移動規則前，先依意圖和風險分類。

這個矩陣能避免把所有 redirect 當成同一種設定。伺服器擁有的 canonical redirect，和客戶簽核過的 migration map，風險完全不同。

移動前先驗證行為

把 redirect 從一層移到另一層，可能改善治理，也可能意外改變行為。請把它當成一次 migration。

移動前至少記錄：

• source URL
• 目前最終 destination
• 目前 status code
• hop 數
• query string 和 UTM 行為
• cookie、header、device、country 條件
• rule owner
• rollback path

接著用 Redirect Checker 測試代表 URL，尤其是 SEO landing pages、廣告 URL、LINE/QR 連結和帶 query 的 path。如果包含換網域，請搭配 如何重新導向網域但保留 path 和 UTM 參數。如果舊架構已經有多跳，也先檢查 Redirect Chains and Loops。

常見失敗模式

把一個意圖拆成多個 hop

http://old.example.tw/pricing
  -> https://old.example.tw/pricing
  -> https://www.old.example.tw/pricing
  -> https://www.new.example.tw/pricing

每一步單獨看都可能合理。合在一起就是更慢的訪問、更難的排障，以及更多遺失參數的機會。

讓 CMS 外掛覆蓋基礎設施規則

WordPress、ecommerce 或 CMS 外掛可能在 CDN 或 server 已經決策之後再做一次 redirect。如果這些規則要保留，就要有明確邊界，並納入 QA。

用 regex 取代審查

regex 可以減少大量 exact rows，但過寬的 pattern 也會捕捉本該明確決定的 URL。pattern 要錨定，用真實 path 測試，高價值例外要保留在可見規則中。

忘記 analytics 所有權

如果 redirects 在 server config，而 reporting 在活動試算表裡，團隊無法回答哪條規則觸發、哪個國家點擊、哪個裝置失敗、哪個 destination 回 404。

UrlEdge 放在哪裡

UrlEdge 適合 redirect 從伺服器小設定變成 traffic infrastructure 的階段。

實務流程：

1. 在 Console 保存 source rule、owner、status code、path policy、query policy 和 notes
2. 用 Bulk URL Management 匯入大型 map
3. 用 Advanced Redirect Rules 處理 wildcard 和 regex
4. 需要條件 destination 時，用 Geo Redirects 或 Device Targeting
5. 用 Redirect Checker 驗證高風險 URL
6. 把審查過的 snapshot 發布到 edge，並保留 rollback

UrlEdge 的 data plane 運行在 Cloudflare-backed edge infrastructure 上。已發布的 domain configuration 會靠近 visitor request 執行；Console 則保留為 review、governance 和 analytics 的介面。這讓團隊能把脆弱 redirect 從 Nginx、.htaccess、CDN 規則和 CMS 外掛中移出，而不用把 origin app 變成 routing control panel。

FAQ

edge routing 一定比 Nginx 快嗎？

不一定。單純 server redirect 可以很快。edge routing 的價值在於降低 origin dependency，更重要的是為高變更 redirect 提供可審查、可監控、可 rollback 的營運模型。

.htaccess redirect 應該立刻刪除嗎？

不要。先理解它們目前做什麼，並確認能在新層重現行為。優先處理 migration、campaign、query、重複意圖和高價值 URL 相關規則。

CDN rules 和 UrlEdge 可以共存嗎？

可以。關鍵是 ownership。CDN 可以負責簡單 hostname 或 protocol 正規化；UrlEdge 負責 migration map、branded links、conditional routing、analytics 和 rollback。

應該先移哪些 redirect？

先移變更頻繁、涉及多團隊、需要 analytics、影響 SEO 或 campaign 的規則。穩定、低風險的 server rules，可以等有明確營運理由再移。

參考資料

• Nginx: ngx_http_rewrite_module
• Apache HTTP Server: .htaccess files
• Apache HTTP Server: mod_rewrite
• Cloudflare Rules: Redirects
• MDN: Redirections in HTTP