前言
其實CF系列教程我原本想在第九部"Zero Trust"就結束的，畢竟在易經中，九被稱為“大數”，表示天地之間最大、最圓滿的數字，所謂九重天、九九歸一、九九八十一難等等，因此，在第九部結束，乃是暗合天意，也顯得我很有文化～。
但是，關於CF提供的多種重定向方式，確實還是很有價值的，特別是"重定向規則"後來推出的"動態重定向"，能使用函數表達式靈活的構造跳轉目標的URL，這和"頁面規則"的重定向功能(支持通配符及基於通配符的捕獲組)配合，又能玩出不少花樣來了，所以想了想，忍住了在第九部結束的衝動，還是寫了這第十部作為CF系列教程的最終章。
不過，在"十"結束也不差，佛教中有"九天十地"的說法(十地代表佛教中修行者境界)，第十地「法雲地」的菩薩，已經具足圓滿智慧、慈悲和一切善巧方便，距離成佛僅一步之遙。
剛好我研究過"般若波羅蜜多心經"和"金剛經"，在"十"結束，乃是與我佛有緣～。
另：不知道還有多少人記得"九天十地，十九人魔"？
什麼是重定向(HTTP重定向)？
重定向(Redirect是指在存取一個網頁或資源時，將使用者自動引導到另一個指定的網頁或資源的過程。重定向通常發生在以下幾個場景中：
- URL變更：當網站的頁面位址改變時，重新導向可以確保舊URL仍然能夠訪問，並將使用者引導至新的URL，以避免斷鍊和不良使用者體驗。
- 域名轉移：如果網站更換了域名，透過重定向可以將舊域名的流量無縫轉移到新域名，保持網站訪問的連續性。
- 行動端優化：根據使用者裝置類型（如行動裝置和桌面裝置）進行重新導向，提供最佳化的頁面版本。
- SEO優化：當頁面內容合併或刪除時，使用重定向可以集中權重，避免產生重複內容，優化搜尋引擎的排名。
常見的重定向類型：
• 301重定向（永久重定向）：表示頁面永久搬遷到新地址。搜尋引擎會將舊地址的權重傳遞到新地址。
• 302重定向（暫時重定向）：表示頁面暫時搬遷，未來可能會返回舊地址，搜尋引擎不傳遞權重。
註：除了常用的301、302之外，還有303、307、308以及特殊重定向，不過這些對於一般的朋友較少遇到，所以本文中不多講。
CF的重定向實作方式
CF的重定向功能有幾種不同的實作方式，其中最重要的是：頁面規則實作的重定向以及重定向規則。
頁面規則實作的重定向
在我講Cache Rules(快取規則)時(參見：家庭資料中心系列cloudflare教程(六) CF Cache Rules(快取規則)功能介紹及詳細設定教程)，也提到了頁面規則，因為頁面規則也可以實現快取(只能基於URL方式來匹配)。同樣的道理，頁面規則也能實現重定向，只不過同樣只能基於URL來匹配，且只能實現301或者302重定向(當然，一般也只需用到301或者302)。
頁面規則的配置很簡單，以將tangwudi.com的訪問重定向到www.tangwudi.com為例：
雖然只能基於URL來匹配，但是透過頁面規則實現的重定向有特有的優勢：匹配傳入URL時支持*通配符及可以透過"$數字"的捕獲組直接把內容傳遞到重定向URL，如下圖：
也支援透過多個通配符+捕獲組來傳遞參數，如下圖：
不過，使用珍貴的只有3個免費名額的頁面規則來做重定向，是個比較奢侈的行為～，即便要用也要最高效的使用。
使用頁規則來做重定向有個最大的優勢，其在流量序列(流量序列的詳細概念請參考文章:家庭資料中心系列cloudflare教程(二) CF整體方案流量序列中各技術節點功能簡介)中的優先權非常高，高於後面要講的"重定向規則"(以及"Cache Rules")：
這點非常重要，也是後面要講的某個場景中，複雜的重定向需求能夠實現的關鍵。
重定向規則
重定向規則介紹
由於頁面規則只有3條免費的額度，並且只能透過URL這種粗曠的方式來匹配入向的URL請求，所以並不適合作為日常重定向需求的常規手段。
作為替代，CF提供了重定向規則作為日常重定向的常規手段(類似於頁面規則實現的快取功能與快取規則之間的關係)。
注意：重定向規則可以建立簡單的301(永久重定向)或302(暫時重定向)規則(其實還有303、307、308重定向，比頁面規則支援的類型多)：
重定向規則的類型
重定向規則依照類型分為"靜態"和"動態"兩種，靜態重定向和動態重定向各有不同的用處，適用於不同的場景。
1. 靜態重定向：
• 用途：靜態重定向適用於將固定的URL 重新導向到另一個固定的URL(例如前面範例中將對https://tangwudi.com的所有訪問重定向到https://www.tangwudi.com)，這種重定向規則是靜態的，因為它不會根據請求的內容、參數等動態變化，而如果要求包含參數，例如要求https://tangwudi.com/*的所有訪問重定向到https://www.tangwudi.com/*就不能用靜態重定向了。
• 典型場景：舊頁面遷移到新頁面、將非首選網域重新導向到首選網域(上面的案例)、解決死鏈，避免404 錯誤。
2. 動態重定向：
• 用途：動態重定向會根據請求的內容、查詢參數、使用者地理位置等進行動態變更。例如，可以根據使用者所在的國家重定向到不同的域名，或根據URL 中的某些參數進行重定向。
• 典型場景：基於使用者的地理位置和裝置類型或瀏覽器類型進行個人化重新導向、基於請求的特定條件(如使用者裝置、來源國家等)定義重定向規則、基於原有網域的某種"規律"進行重定向。
重定向規則配置場景
靜態重定向
常規使用場景
還是以前面的例子來舉例：將tangwudi.com的訪問重定向到www.tangwudi.com，請按照如下方式配置該需求。
在"規則"-"重定向規則"-"建立規則"：
當然，"當傳入請求匹配時"的條件設定可以非常靈活，除了主機名稱還有其他很多選項：
所以，"重定向規則"和僅靠URL為匹配條件的"頁規則"比起來，能夠實現靈活得多的匹配條件。
當然，魚和熊掌不能兼得，重定向規則的匹配條件也有缺點：不支援頁面規則傳入符合條件支援的*通配符，所以導致靜態重定向不能像頁面規則的重定向那樣透過通配符傳遞參數：靜態重定向不管傳入URLtangwudi.com/後面帶有多少參數，都只能固定跳到www.tangwudi.com/，既首頁。
進階使用場景：批次重定向
因為靜態重定向一次只能跳一個目標URL，如果有大量的URL要跳轉(比如站點整體遷移到另一個域名)，默認10條額度可不使，所以，靜態重定向還有個單獨的加強功能"批量重定向"：
先依照下列步驟建立批次重定向清單：
然後將建立的"批量重定向清單"關聯到"批量重定向規則"：
常見完成：
註1：批量重定向列表只有5條額度。
註2：csv官方格式如下：
example.com/contacts,https://example.net/contact-us,301,,,, example.com/about,https://example.net/about-us,,FALSE,TRUE,, example.com /docs,https://example.com/draft-docs,302,,TRUE註3：批量重定向並不是本文的重點，因為自從有了動態重定向，"規律性"的重定向不管數量有多少，一條動態重定向的目標URL表達式就夠了～。
動態重定向
常規使用情境：帶有URI內容的跳轉
動態重定向相對來說就靈活多了，雖然仍舊不支援通配符，但是卻可以透過規定的"字段"實現URI部分參數的傳遞，例如"http.request.uri.path"字段可以實現URI部分"/*"通配符的傳遞效果。
例如還是上面的例子，這次我想要把tangwudi.com/*的存取請求原封不動的重定向到www.tangwudi.com/*上，這時就應該使用動態重定向：
重定向的目的URL表達式如下：
concat("https://www.tangwudi.com",http.request.uri.path)附加知識：使用規定欄位和函數建構表達式
規定字段
動態重定向的表達式中可以使用規定欄位來自動比對傳入URL中的對應內容，舉例說明：假設傳入的完整URL為：https://blog.tangwudi.com/123，此時如果表達式中有"http.host"字段，那麼字段內容就是"blog.tangwudi.com"；如果表達式中有"http.request.uri.path"字段，那麼字段內容就是"/123 "。
註：更多欄位請參閱：動態重定向字段。
使用函數構造表達式
建構表達式的時候要注意表達式的完整性和正確性，特別要注意一些欄位本身表達的內容，還是以上面的傳入URLhttps://blog.tangwudi.com/123為例，假設以"concat"函數構造的跳轉目標URL的表達式如下：
concat("https://www.tangwudi.com/",http.request.uri.path)那麼，表達式的真實效果為：https://www.tangwudi.com//123，因為"http.request.uri.path"字段代表的內容本身就是帶了"/"的，加上前面雙引號中字段https://www.tangwudi.com/結尾的"/"，自然就是這個樣子，這肯定是不正確的，所以正確的表達式寫法需要將前面雙引號中的"/"去掉，如下：
concat("https://www.tangwudi.com",http.request.uri.path)除了concat，其他較常用的函數還有substring，lower，upper。
以substring函數為例，其意義是"從左到右提取從指定位置開始的字串"，此處的指定位置是從0開始計數，舉例說明：substring(http.request.uri.path,3)的意思是從位置3開始索引字串，假設"http.request.uri.path"的內容為："/tangwudi/abc"，那麼，此處函數表達式的輸出內容為"ngwudi/abc"。
註：0-/，1-t，2-a，3-n。
進階使用場景：圖床網域遷移
以我圖床的圖片為例，假設我想要把https://image.tangwudi.com/2023/*.png重定向到https://abc.tangwudi.com/image/*.png(*的內容必須一樣)，新動態重定向規則如下：
重定向目標URL表達式為：
concat("https://abc.tangwudi.com/image/",substring(http.request.uri.path,6))注意：本例中這種情況使用頁面規則的重定向也簡單。
進階使用場景：群組網域基於地理位置進行跳轉
這是以我之前的部署方式為例子，當時我剛好處於從備案域名往"tangwudi.com"上遷移的時期，所以那段時期我2個域名同時生效，所有的應用都有2個域名入口：一個是CF的，網域名稱"*.tangwudi.com"；一個是備案域名，域名假定是"*.tangwudi.xyz"。
我當時的需求是所有應用程式對外使用統一入口"*.tangwudi.com",但是根據訪問請求的來源做判斷：如果訪問者是國內IP，就重定向到"*.tangwudi.xyz/*"；如果訪客不是國內IP，則正常存取。
這個需求裡面有2個*變數：三級網域的主機名稱和URI內容：國內用戶訪問blog.tangwudi.com/123，就重定向到blog.tangwudi.xyz/123；訪問wlk.tangwudi.com/12345，就重定向到wlk.tangwudi.xyz/12345。
不過，這種需求就有點麻煩了，我前面提到過，就算是動態重定向，也只能透過字段"http.request.uri.path"來實現URI部分對應的"/*"通配符傳遞效果。而主機名稱部分"http.host"只能傳遞完整網域(本例中是blog.tangwudi.com和wlk.tangwudi.com)，無法只傳遞三級網域的主機名稱部分(本例中是blog和wlk)。
本來，如果只是無條件從"*.tangwudi.com/*"重定向"*.tangwudi.xyz/*"，類似的需求一條頁面規則的重定向就完事：
只是，要實現基於國家等地理位置為條件進行跳轉，就必須結合重定向規則的動態重定向來完成。
咋辦呢？經過一番思考：既然頁面規則實現的跳轉只是不支援基於地址位置判斷，跳轉部分可以實現；而動態重定向可以實現基於地址位置的判斷，只是不能實現跳轉部分的要求，那我可不可以將兩部分結合在一起來實現該需求呢？
有了這個思路就好辦了：
- 步驟1、創建一條動態重定向規則將國內用戶重定向到一個虛構的URL
透過目標表達式建構一個以虛構的網域名稱"abc.tangwudi.com"為host的全新URL讓國內用戶進行重定向(虛構的網域名稱也需要在CF的DNS裡加入任意位址的解析並開啟小橙雲朵) ，同時將完整的三級網域和URI部分組合在一起作為全新URL的URI部分，以便頁面規則使用通配符進行提取：
URL重定向表達式為：
concat("https://abc.tangwudi.com/",http.host,http.request.uri.path)在上面的表達式中，使用"http.host"來傳遞原始的三級域名，使用"http.request.uri.path"來表示原始的URI部分，所以如果原本的訪問連接是"https://blog.tangwudi.com/123"，那麼該表達式構成的全新URL就是"https://abc.tangwudi.com/blog.tangwudi.com/123"。
-
步驟2、建立頁面規則來接收國內用戶對虛構URL的訪問，從虛構URL中捕獲相關資訊以建構正確的訪問URL，然後再次以重定向方式發給國內用戶
利用頁面規則在流量序列中優先權高於Cache Rules的優勢(該重定向不能被快取)，接收國內客戶端使用全新URL發起的訪問，然後使用前面講過的通配符捕獲組來分離URL中URI部分包含的主機名稱和原來的URI內容，組成了第2次重定向URL："
https://blog.tangwudi.xyz/123"，並發給了國內用戶。
-
步驟3、國內用戶使用第2次收到的真正的URL"
https://blog.tangwudi.xyz/123"進行存取。
這樣，經過了2次重定向，實現了我基於地理位置和2個變數進行重定向的要求。不過，我其實不建議正常情況下使用方式，因為這種方式有個很大的缺點：跳來跳去，給人觀感不好，會顯得網站很不專業(個人觀感)。
註：我這裡只是簡單的示範了2個不太複雜的例子，實際情況下更複雜的需求很多，就看大家對動態重定向的表達式以及頁面規則通配符的理解和想像力了。
其他重定向方式
其實，除了使用頁面規則、重定向規則實現來重定向功能以外，使用worker也可以實現，只不過，鑑於worker這個萬金油地位(好多功能都可以用worker實現)，我就不把它算作正兒八經的重定向方式了。而且，使用worker來實現重定向有個最大的麻煩：worker優先權在流量序列中最低，所以為了確保訪問請求能夠到達worker以實現重定向，可能需要配置其他流量序列的功能模組來配合(比如Cache Rules)，這樣就遠不如使用重定向規則和頁面規則來配合完成重定向功能來得省心。
另：在"轉換規則"中，還有一個"重寫URL"的功能：
如果說"重定向"是"正大光明"的告訴用戶改變訪問地址，那麼"重寫URL"就是"偷偷摸摸"的在不告訴用戶的情況下(瀏覽器訪問地址不會變化)把訪問URL的URI部分修改了(域名改不了)，不過這和本文"重定向"的主題不符，我就不多說了。
註：國內CDN只提供"重寫URL"功能(可能是怕大家幹壞事)，所以當需要域名重定向功能時，很多朋友不得不使用自己的VPS來實現跳轉(我之前備案域名實現跳轉www就是使用騰訊雲端輕量伺服器上的nginx來完成)，從這個角度來說，CF免費提供的各種強大的基於邊緣網絡的重定向功能可真是太良心了，讓我們不再需要動不動就在VPS上配置(關鍵很多將自己靜態網站進行託管的人都沒有自己的VPS～)，再次盛讚一下大善人。
結束感悟
CF系列教學終於寫完了(從7月10號發布第一部，到9月2號的第十部，期間將近2個月的時間)，每一部我都寫得很累(包括這最後一部我原本認為寫起來會很輕鬆的"重定向")，關鍵就在於CF相關知識的延伸性：寫著寫著隨時可能蹦一個我都沒太關註的概念出來(如果只是配置功能，不寫成文章，也不會去關注這些概念)，導致我不得不頻繁使用"注"或者"附加知識"的方式進行臨時性的解釋，否則文章的可讀性就要被破壞，再加上本來CF很多功能彼此都有關聯性，所以導致我寫每一部教學都非常累。
不過，雖說是如此，我覺得還是很值得的，現在回頭來看沒寫系列教程之前的我，對每一部教程講述的功能，理解得都較膚淺，只是停留在能夠應付基本使用的層次上，所以導致印像也不深刻。例如這篇教學的重定向功能，我甚至都忘記了當時從備案域名遷移到"tangwudi.com"時具體是怎麼配置的了(畢竟大半年前遷移完之後我就沒怎麼使用過複雜的重定向功能了)，研究了半天才找到關鍵點(這就是不形成文字記錄的下場)。而現在，當這篇教程寫下來之後，即使我以後又忘記了，只要看看這篇教程，就什麼都想起來了，這就是俗話所說的：好記性不如爛筆頭。
不過，CF系列教程所講述的內容，只是基於我日常使用習慣，將我認為常用的功能進行了歸納和總結，而在我的"日常使用習慣"形成的盲區之外，還有太多的功能沒談到，例如"點"類型的"Hotlink保護"功能，打開預設就可以防止圖片盜鏈(基於referer判斷)：
或是"面"類型的"D1資料庫"，也有免費方案可以蹭的：
只不過因為目前我的知識面有限，有些功能想蹭都不知道怎麼去蹭，只能留下遺憾在心間了，如果以後知道方法了，再用文章寫出來吧，不過就不是以系列教程的名義了，畢竟，不能破壞"十"全"十"美。
另：所謂"言必信，行必果"，終於把系列教程寫完了，強迫症患者總算可以睡個安穩覺了：
