前言

我在之前的文章中說過，如果基於cloudflare來建站，在回源方式的選擇上，我一直只推薦使用Cloudflare Tunnel回源的方式，因為使用Cloudflare Tunnel(也叫Cloudflare Argo Tunnel)與傳統的Cloudflare公網位址回源(直接代理)相比，具有許多獨特的優勢。

只不過，這幾天我卻發現Cloudflare Tunnel回源的一個」大」問題，這個」大」問題雖然並不涉及安全這種原則性的問題，但是卻勝在夠隱蔽(默認就生效)，而且會影響網站網址SEO的權重，關鍵會影響網站的形象(顯得較low)～。

Cloudflare Tunnel的優勢

雖然本文主要是講Cloudflare Tunnel的」大」問題，但是實話實說，這個問題和其優勢比起來完全微不足道(並且也有解決的方式)。為了避免喧賓奪主，本著先褒後貶的精神，還是先把Cloudflare Tunnel回源和傳統公網地址回源的方式從安全性、配置和部署、網絡性能和穩定性、可伸縮性和冗餘、以及安全性和防禦能力這5個面向進行全面比較，用來證明Cloudflare Tunnel回源的優越性：

1. 安全性

Cloudflare Tunnel：

• 隧道加密： Tunnel 會透過加密隧道（TLS）將流量從Cloudflare 的邊緣節點傳遞到你的來源站。這意味著即使來源站的伺服器沒有公開暴露在公網，也能安全地與Cloudflare 通訊。

• 無公網暴露： 使用Tunnel 時，來源站的IP 位址不會暴露在外部，所有存取都會透過Cloudflare 中繼。這有效降低了潛在的DDoS 攻擊、連接埠掃描和其他網路攻擊的風險。

• 阻止未授權存取： 因為源站沒有直接對外提供服務，所以駭客或攻擊者無法直接存取來源站。

傳統回源（Cloudflare 直接代理）：

• 源站公開IP 暴露： 在傳統的Cloudflare 代理模式下，來源站的IP 位址是公開的。雖然Cloudflare 會代理請求，但來源站本身的IP 位址仍暴露給外部，因此可能會受到DDoS 攻擊或其他網路攻擊。

• 不提供加密隧道： 除非使用額外的加密配置，Cloudflare 在這種模式下並不會為與來源站之間的連接提供額外的加密保護。

2. 配置和部署

Cloudflare Tunnel：

• 無需暴露連接埠： 使用Tunnel 時，來源站不需要將連接埠開放到公網，所有的流量都會透過Cloudflare 的邊緣節點傳輸。你只需要在來源站安裝Cloudflare 的cloudflared 用戶端，並且設定好Tunnel，就可以直接將流量轉送到Cloudflare。

• 簡化防火牆配置： 由於源站不暴露端口，因此無需在防火牆上進行複雜的端口配置。只要允許Cloudflare 的IP 位址段存取你的來源站，減少了設定和維護的複雜性。

傳統回源（Cloudflare 直接代理）：

• 需要暴露連接埠： 在傳統模式下，來源站需要暴露連接埠（如80 和443）來與Cloudflare 通訊。此時，需要確保防火牆規則正確配置以允許Cloudflare 存取。

• 更多的網路和連接埠管理： 需要更多的手動設定來確保來源站能夠正確回應Cloudflare 的請求，尤其是在使用多個連接埠或服務的情況下。

3. 網路效能和穩定性

Cloudflare Tunnel：

• 智慧路由： Cloudflare Tunnel 可以利用Cloudflare 的 Argo Smart Routing 功能來優化流量的傳輸路徑，選擇最佳的路徑來減少延遲，提高網站的回應速度和穩定性。

• 穿透防火牆： 如果源站位於內部網路或某些嚴格的防火牆後面，Cloudflare Tunnel 透過在來源站和Cloudflare 之間建立安全的隧道，可以繞過防火牆或NAT 網路設備，確保流量傳輸不會中斷。

傳統回源（Cloudflare 直接代理）：

• 網路負載與傳輸： 傳統回源依賴來源站和Cloudflare 之間的網路連接，若源站的網路頻寬或穩定性不夠，可能導致效能問題，尤其在流量較大時。

• 可能受限的智慧路由： 傳統的代理模式無法直接使用Argo Smart Routing 功能，因此來源站的網路連線品質可能會直接影響網站的效能。

4. 可伸縮性和冗餘

Cloudflare Tunnel：

• 自動負載平衡和容錯： Cloudflare Tunnel 可以與Cloudflare 的負載平衡功能集成，使得流量可以智慧地分配到多個來源站。如果源站發生故障，Cloudflare 可以自動切換到備用源站，確保網站的高可用性。

• 對多地域支援： 如果你有多個來源站分佈在不同的地理位置，Cloudflare Tunnel 可以自動管理這些來源站之間的流量路由，確保使用者要求最優地到達離他們最近的來源站。

傳統回源（Cloudflare 直接代理）：

• 負載平衡和冗餘配置較複雜： 在傳統代理模式下，負載平衡和冗餘配置通常需要在來源站或Cloudflare 控制面板中進行手動設定。如果你有多個來源站，可能需要設定DNS 或多個代理伺服器來處理流量。

• 無自動跨地域支援： 對於跨地域的資料中心或多節點部署，傳統回源模式下的流量分配可能不如Tunnel 有效率。

5. 安全性和防禦能力

Cloudflare Tunnel：

• 保護內網應用： Cloudflare Tunnel 讓你可以將內部網路應用程式（如僅限公司員工存取的應用程式）安全地暴露給互聯網，而無需直接暴露到公網中。例如，如果你有一個內部服務，只想讓特定的外部用戶訪問，它可以透過Cloudflare Tunnel 安全地提供。

• 減少暴露的攻擊面： 使用Tunnel 時，來源站的內部應用程式不會直接暴露在公網，攻擊者無法直接針對這些內部應用程式發動攻擊。

傳統回源（Cloudflare 直接代理）：

• 暴露攻擊面： 在傳統的回源模式下，雖然Cloudflare 代理層能為你提供DDoS 保護和基本的防火牆功能，但源站暴露在公網的攻擊面相對較大，特別是如果沒有合理配置額外的防火牆和防護措施。

總結：Cloudflare Tunnel vs. 傳統回源

特性	Cloudflare Tunnel	傳統回源（Cloudflare 直接代理）
安全性	無需暴露源站，使用加密隧道，減少暴露攻擊面	源站暴露IP，有被攻擊風險，需額外配置安全措施
配置簡便性	安裝 cloudflared，簡化源站配置和防火牆設置	需手動配置源站端口，配置較為複雜
效能與穩定性	使用Cloudflare 的Argo Smart Routing，優化網路路徑	網路效能受限於源站網路連接
可伸縮性與冗餘	自動負載平衡，支援多地域應用的流量分配	需手動配置負載平衡，冗餘配置複雜
內網支援	可以安全地暴露內網應用，適合內部系統外網訪問	主要用於公網暴露，無法方便處理內部網路應用

所以，從以上比較可以看出，相對於傳統的公網地址回源方式，Cloudflare Tunnel除了在某些比較苛刻的網絡環境下運行不夠穩定(比如一些有嚴格限制策略的企業出口設備後面或者使用一些限制策略比較變態的寬頻業者)之外，可以說全方面勝出，360度無死角，完全沒有弱點。

問題的發現、分析及解決

無意中的發現

起因源自於我的習慣性操作：在google上搜尋自己的部落格(大部分個人部落客應該都有這個有點悶騷的習慣吧～)，正常來講，如果從第一頁開始，一頁一頁往後走到最後應該最多只有16頁：

但是在第16頁的最下面會有如下顯示：

上圖中的155條結果極為相似的條目是什麼呢，直到我昨天無意中把滑鼠放到了一條搜索記錄上才發現類似下面的顯示(原本怎麼搜到那條記錄我已經不記得了，正常搜索中應該會被隱藏)：

怎麼會有個8443埠？然後我直接在谷歌裡面用」blog.tangwudi.com:8443″進行搜索，結果嚇了我一條：

雖然沒有16頁那麼多，也有10頁：

8443這個Cloudflare預設開放的連接埠讓我有不詳的預感，我在之前的Cloudflare系列教學第3章(詳見：家庭資料中心系列cloudflare教學(三) 如何進入CF的邊緣網路及如何選擇適合的回源方式)中曾經提到8443：

只不過，我之前一直認為這個8443(包括其他的2053,2083,2087,2096)只是Cloudflare默認支援的源站服務端口(既如果源站使用這些端口就不用在Cloudflare上使用Origin Rules規則自訂回源端口)，但是今天搜到這個記錄就讓我有點懵逼了，於是我使用其他幾個端口依次進行搜索，都有，只是不多(不像8443有10頁那麼多) ，並且用瀏覽器加端口都可以存取：

為什麼會這樣呢？

Cloudflare預設開放的連接埠

在網路上搜了一下，Cloudflare在其Anycast IP(泛播IP)預設為開放的連接埠(8443、2053、2083、2087、2096)，是為了支援多種服務和協議，這些連接埠並非專門為每個使用者的特定需求而開放，而是針對Cloudflare 本身的基礎架構和常見用途的配置：

1. Cloudflare 服務的預設端口

這些連接埠通常用於與Cloudflare 的特定服務交互，或與常見的第三方應用相容。具體來說：

• 8443：這是一個常見的備用HTTPS 端口，通常用於HTTPS 協定的非標準端口。在許多情況下，企業級應用程式和某些網站服務會使用此連接埠作為安全的HTTPS 連線。 Cloudflare 預設支援此端口，用於某些與Cloudflare 服務的通訊或代理流量。

• 2053：此連接埠通常用於Cloudflare 的HTTP 流量代理。 Cloudflare 會透過這個連接埠路由流量，通常用於支援各種協定的特殊服務。

• 2083：這個連接埠通常是為 cPanel 控制面板提供支援。 cPanel 是一種廣泛使用的網站管理控制面板，預設使用2083 連接埠來進行HTTPS 連線。 Cloudflare 支援此端口，通常是為了代理來自cPanel 的流量。

• 2087：與2083 類似，2087 是為 WHM（WebHost Manager） 提供的端口，通常用於提供託管服務和管理伺服器配置。 Cloudflare 支援此連接埠是為了方便Web 主機服務供應商的整合。

• 2096：這個連接埠用於 cPanel Webmail。 Webmail 連接埠通常用於存取cPanel 提供的Web 郵件介面，Cloudflare 同樣支援這個連接埠以便為使用者提供相容性。

2. 為什麼Cloudflare 會開放這些連接埠？

• 相容性：這些連接埠對應許多常見的Web 應用和服務，尤其是在 Web Hosting 和 企業託管 環境中。 Cloudflare 為了確保最大範圍的相容性，會開放這些端口，尤其是對於使用cPanel、WHM 等面板的託管服務提供者。

• 流量代理支援：Cloudflare 的核心功能之一是代理流量並提供效能最佳化和安全防護。為了支援多種服務和協議，Cloudflare 需要允許這些連接埠上的流量透過其網路進行路由，從而提供全面的DDoS 保護、內容分發和效能最佳化。

• HTTPS 代理：對於需要透過HTTP(S) 進行安全通訊的各種服務，Cloudflare 預設為開放8443 和其他端口，作為HTTPS 代理的備用端口。這使得用戶和服務提供者可以在標準連接埠之外使用其他連接埠進行加密流量的傳輸。

3. 安全性考慮

儘管這些連接埠是Cloudflare 預設為開放的，但是它們並不會自動暴露給所有的使用者。 Cloudflare 實際上會在其邊緣節點上代理這些連接埠上的流量，並提供 DDoS 防護、Web 應用防火牆（WAF） 和其他安全功能，從而保障流量的安全性。

以上的內容說人話說就是：所有Cloudflare的Anycast IP(訪問託管在Cloudflare上的網域時解析到的IP位址)上，這些連接埠在4層上都是通的(可以建立tpc3次握手，可以用telnet存取埠進行簡單的測試，也可以用其他工具測試4層埠的可用性)，並且提供和443埠一樣的防護，但是這些埠並不會直接暴漏給所有使用者(就是使用者預設不能用網域加埠的方式進行存取)，也就是7層上正常應該是不通的。

---

對”www.visa.com「的8443埠進行4層可達性測試，的確是通的：

對”www.visa.com「的8443埠進行7層可達性測試(命令列下可以使用curl)，使用瀏覽器的確不能存取：

以上測驗的確證明了Cloudflare官方的說法。

---

罪魁禍首：Cloudflare Tunnel？

說實話，這個還真是把我搞懵逼了，關鍵在Cloudflare的儀表板裡根本沒有類似的選項可以設置，最後，我唯一能夠想到的，就是回源方式的差別，會不會是因為公網位址回源和Cloudflare Tunnel回源這2種方式造成的差異？要確認這個問題，就必須找實際的例子來比較，為了穩健起見，傳統公網回源和Cloudflare Tunnel回源的例子都需要。

傳統公網位址回源

以我比較欣賞的一個部落客(苯苯)的部落格(https://blognas.hwb0307.com)作為傳統公網回源測試的例子。
8443埠4層可達性：

2053埠4層可達性：

2083埠的4層可達性：

8443埠的7層可達性(7層只測8443埠就行，都一樣)：

可以看到和前面www.visa.com的結果是一樣的，也間接證明了傳統公網位址回源預設使用8443埠進行存取都應該是逾時。

Cloudflare Tunnel回源

這個稍微麻煩點，因為不認識使用tunnel方式建站的人，只能在網上直接找了，我準備專門找那種介紹Cloudflare Tunnel方式建站的個人博客，如果其域名解析的IP是屬於Cloudflare的IP地址段，那大機率就是使用Tunnel方式建站的，這個想法真是太天才了有沒有？就使用」Cloudflare Tunnel建站」的關鍵字，立刻找出目標：

先驗明下正身，確認下方是否為使用的Cloudflare：

使用”ip138″查詢IP訊息，確認就是目標：

例行檢查8443埠的4層可達性(2053、2083、2087、2096埠的檢查就省略了，都是一樣的)，是通的：

然後測試7層可及性：分別存取預設的443，然後是8443、2053、2083、2087、2096(第一個測試對象完整測試所有連接埠)，並且為了便於觀測，使用curl命令進行存取；由於首頁內容較多，不適合觀察，所以選擇/about.html(就是關於頁面)進行測試。
預設的443埠：

8443埠：

2053埠：

2083埠：

2087埠：

2096埠：

以上已經基本上可以證明我的”哥德巴赫無敵猜想」：基於Cloudflard Tunnel方式回源的網站，預設情況下除了標準的443端口，還有8443、2053、2083、2087、2096，均可以透過https的方式存取。

為了進一步驗證，我還找了一些博客(域名解析都是Cloudflare的IP地址，並且只驗證8443端口即可，其他端口就懶得一一截圖了，都是一樣的效果，大家感興趣自行驗證其他端口即可)：
1、https://liuhouliang.com:8443

2、https://mszx.me:8443

3、https://dmesg.app:8443

4、https://www.nodeseek.com:8443

…….

按照我這種思路用”Cloudflare Tunnel建站”為關鍵字在google上進行搜索，基本上每一頁都會找到使用Tunnel建站的網站，接著會發現這些端口都是默認打開的。

原理分析(不喜歡技術細節的朋友可以跳過)

在”傳統公用網址回源”和”Cloudflare Tunnel 回源”2種不同的回源方式下，連接埠行為的差異是由於它們的”流量轉送方式”和”代理處理機制”的根本不同所導致的。

傳統公網回源時連接埠逾時的原因

1. Cloudflare 代理程式的連接埠限制

• 在傳統公網回源方式中，Cloudflare 作為反向代理伺服器，主要負責將使用者的請求轉送到你的來源站。 Cloudflare 對外暴露的標準連接埠是 80（HTTP） 和 443（HTTPS），即透過這兩個端口，流量才會被正常代理到源站的指定端口範圍(既HTTP協議的80、8080、8880、2052、2082、2086、2095端口，HTTPS協議的8443、205 3、2083、2087、2096埠)，這裡的指定埠範圍的意思是選擇其中任何一個埠都行，Cloudflare只要發現來源站這其中的一個或多個埠是可以存取的，就會把來自HTTP 80或HTTPS 443連接埠的存取轉送到來源站對應協定的一個或多個連接埠上。

• 對於其他非標準連接埠的存取要求（例如HTTP的2052或HTTPS的2053），Cloudflare也會轉發，但是卻只會往”來源站相同的連接埠轉發「。

2. 源站防火牆和連接埠配置

• 雖然Cloudflare轉送了非標準連接埠上的存取要求，但來源站的防火牆和連接埠設定決定了這些非標埠的存取結果。如果來源站沒有針對這些連接埠的正確防火牆規則，或沒有開啟對應連接埠來接收流量，Cloudflare轉送了流量，也會出現逾時或連線失敗的情況，這就是預設逾時的原因，因為正常情況下源站根本不會開放這些非標端口(使用傳統公網位址回源方式建站的朋友，可以自己進行驗證)。

Cloudflare Tunnel 回源時所有連接埠都可以正常存取的原因

1. 加密隧道的連接埠靈活性

• Cloudflare Tunnel（cloudflared）與傳統回源方式不同。它透過建立一個 加密隧道，將流量從Cloudflare 的邊緣節點轉送到你的來源站，而來源站的實際IP 位址和連接埠並不會直接暴露給外部世界。

• 在這種模式下，Cloudflare 不再受限於80 和443 連接埠(可能是因為Cloudflare認為隧道足夠安全所以放飛了自我？)，它將自己Anycast IP上所有預設開放連接埠上收到的存取請求都轉送到了來源站的指定連接埠上。

2. 隧道轉送機制不受連接埠限制

• Cloudflare Tunnel 的核心工作機制是透過加密隧道將請求轉送到來源站。這個隧道是由cloudflared 用戶端負責處理的，它透過HTTPS 與Cloudflare 的邊緣節點進行通訊。

• 隧道內的流量被封裝和加密後， Cloudflare 可以將它轉送到任何指定的連接埠。無論是8443、2053 或其他非標準端口，Cloudflare 都能透過隧道將這些請求轉發到本地的cloudflared 用戶端，再由客戶端將請求交給來源站處理。

• 這種方式讓來源站的連接埠暴露在 Cloudflare Tunnel 內部，而不再需要公開或配置防火牆規則來允許特定連接埠直接透過傳統公網回源。

3. 源站連接埠與Cloudflare 隧道內的分離

• 與傳統回源不同，Cloudflare Tunnel 在隧道內建立了一個“虛擬的代理層”，使得來源站的連接埠不會直接暴露在互聯網上。源站的流量被加密隧道處理後才到達來源站，因此它不受公網防火牆和連接埠屏蔽規則的限制。

• 隧道中的流量是完全由Cloudflare 和cloudflared 用戶端控制的，來源站本地的連接埠配置變得更加靈活，只需要保證cloudflared 用戶端能夠正確地轉送流量，Cloudflare 則負責透過隧道將流量送到正確的端口。

4. 無連接埠對映和連接埠轉送需求

• 在傳統回源模式下，如果來源站配置了非標準端口，Cloudflare 必須允許這些端口的流量通過並進行相應的端口轉送。但在 Cloudflare Tunnel 中，所有連接埠流量都透過隧道傳輸，外部用戶與Cloudflare 的互動並不依賴來源站的開放埠。因此，任何連接埠都可以透過隧道訪問，而不需要手動設定連接埠對映。

小總結

以上一通分析其實沒啥意義，本質上就是看Cloudflare的喜好，目前看來，它就是在公網回源方式中，443端口以外的非標流量只轉發到源站的相同端口，(http協議的那幾個連接埠會被強制重定向到https，所以不考慮)；而在Tunnel模式下，就把所有https協議端口(443、8443、2053、2083、2087、2096)的請求全都轉發到源站的特定端口上，就這麼變態。

另：說不定啥時候它一不開心就改了呢？

帶來的影響

其實吧，如果以上這些連接埠都一樣要透過Cloudflare所有的安全偵測，那麼這樣到不會有安全方面的問題，這可能也是Cloudflare覺得無所謂的原因。問題的關鍵在於：因為這些完全是預設的行為，所以導致你可能完全沒有意識到：除了https協議的443端口，還會有這麼多端口的訪問流量會被轉發到你的源站！

不管Cloudflare是因為什麼原因預設轉送這些除了443之外的額外連接埠所存取的流量到來源站，事實行卻可能會給網站帶來一些負面的影響。

1. SEO 問題

• 重複內容問題：雖然多個連接埠會指向相同應用，但如果這些連接埠能被公開存取（如8443、2053 等），且沒有進行URL 規範化，那麼搜尋引擎可能會將其視為不同的頁面，從而認為是出現了重複內容，進而可能會認為這些不同的URL 是獨立的頁面(儘管它們實際上內容相同)，這樣就有可能影響你網站的”SEO 排名「。

2. 連接埠管理複雜性

• 維護和管理壓力：雖然Cloudflare Tunnel 可以將流量路由到同一個後端應用，但如果你沒有明確設定管理規則，多個連接埠的轉送可能會增加來源站的流量管理和維護難度。例如，不同連接埠的存取日誌可能會變得冗餘，或者如果某些連接埠暴露了不必要的服務，這些連接埠可能會成為意外的流量入口。

• 流量不必要分配：雖然這些連接埠不會造成實際的安全隱患，但如果沒有合理的存取控制，來源站可能會承受更多的流量，這樣的流量通常不會帶來額外的業務價值。

3. 品牌/使用者體驗影響

• 信任與專業性：如果使用者或潛在客戶發現你的網站能夠透過多個連接埠訪問，尤其是一些看起來像是「技術細節」的連接埠（例如8443 或2053），可能會對網站的」技術水平」或」專業性”產生疑問(就是我前面提到的”較low”)。雖然大多數用戶並不會深入了解後台設置，但多端口的暴露可能會讓某些用戶認為網站缺乏」精細的配置”或”管理不當」。

• 使用者感覺：有些用戶可能並不關心這些端口，但對」品牌形象」有較高要求的用戶，可能會因此對網站的專業性產生懷疑。尤其是在競爭激烈的行業中，細節往往能影響用戶的印象。

解決的辦法

要解決除了80，443之外端口可以訪問的問題倒是很簡單，只需要在WAF的自定義規則最優先的位置加入如下一條規則規則即可(以我的域名舉例，大家需要修改為自己的域名)：

http.host contains "tangwudi.com" and cf.edge.server_port ne 80 and cf.edge.server_port ne 443

要注意的是，上述指令只能用編輯表達式的方式寫入，因為常規的GUI裡沒有這個可選項：

之後在訪問其他連接埠就會被阻止，以我現在博客域名的8443連接埠為例：

註：為什麼我要建議在最優先位置新增一條阻止規則呢？因為正常來說，如果我們要做網站的SEO，Cloudflare WAF的自訂規則中一般都有一條優先級很高的跳過規則來允許各種經過認證的自動化程序(包括搜尋引擎的蜘蛛)的訪問，如下：

如果阻止非80、443端口訪問的規則在這條跳過規則之後，那麼因為自定義規則的優先級問題，搜索引擎仍舊可以通過所有端口訪問網站，只是常規用戶的瀏覽器訪問被阻止，所以搜索記錄中，一條網址有多筆搜尋記錄(不同連接埠)的問題依然存在，SEO問題依舊無法解決。而如果這條阻止存取的規則在最優先的位置，那麼所有對非標埠的存取(包括搜尋引擎蜘蛛)都會被阻止，自然就解決了這個問題：

註：如果對Cloudflare WAF自訂規則不熟悉的朋友，可以參考我另一篇文章：家庭資料中心系列cloudflare教程(四) CF WAF功能介紹及詳細設定教程。

附加知識：部分其他”隱藏參數”

在Cloudflare 的使用過程中，有一些“隱藏參數”，這些並不是普通用戶能直接接觸到的，也不容易被察覺，但卻能在一定程度上影響網站的行為、流量管理或安全性。這些參數通常屬於Cloudflare 更進階的 Worker 或 Firewall Rules 配置，它們涉及一些底層的流量控制和安全規則。這些參數對開發者或網站管理員可能非常重要，但一般使用者一般不需要直接了解或使用它們(類似上一節中用到的”cf.edge.server_port”參數)。

以下是一些類似cf.edge.server_port 的參數，通常不為一般使用者所知，通常需要更深入的Cloudflare 設定權限：

1. cf.edge.server_port

• 功能：此參數是Cloudflare 邊緣節點接收到請求時使用的端口，而 Cloudflare Tunnel 會將這些請求根據設定的隧道設定轉送到來源伺服器上指定的連接埠。

• 使用場景：WAF自訂規則中用於控制通過特定連接埠的流量。

2. cf.client.ip

• 功能：傳回發起請求的客戶端的 IP 位址。雖然一般使用者可以透過日誌查看自己的IP，但在Cloudflare 中，這個值是非常常見的，用於設定防火牆規則、存取控制和速率限制。

• 使用場景：可以根據IP 設定存取白名單或黑名單，甚至進行 速率限制 或 地理限制。

3. cf.ray

• 功能：這是Cloudflare 請求追蹤識別碼。每個請求都會產生一個唯一的 Ray ID，它用於在Cloudflare 的後台查找和追蹤特定的請求。

• 使用場景：通常用於 偵錯 或查看請求的詳細信息，幫助支援團隊分析請求路徑和問題。

4. cf.visitor.ip

• 功能：這是訪客的真實IP 位址，當Cloudflare 作為反向代理程式時，原始用戶端的IP 位址會保留在請求頭中。

• 使用場景：同cf.client.ip，可以用來設定IP 限制、請求分析等。

5. cf.pragma

• 功能：此參數顯示Cloudflare 快取相關的標頭，具體來說，它顯示是否啟用了Cache-Control 或其他快取設定。通常用於調試快取行為。

• 使用場景：當想檢查或調整快取設定時使用，特別是在 Cache Rules 中進行調試時。

6. cf.cf_access

• 功能：返回Cloudflare Access 認證相關的信息，例如使用者的身份驗證狀態、是否需要進行身份驗證等。

• 使用場景：Cloudflare Access 是一種基於驗證的應用程式存取控制工具，使用此參數可設定套用的存取權限和認證機制。

7. cf.browser.bot

• 功能：這是Cloudflare 用來判斷存取請求是否來自 爬蟲（Bot）的參數。如果為true，表示請求來自機器、爬蟲等非人類用戶，可能會觸發一些與用戶行為無關的安全策略或規則。

• 使用場景：通常用於 WAF 防火牆規則中，過濾爬蟲流量或執行 Bot 管理 策略。

8. cf.warp

• 功能：指示請求是否透過Cloudflare 的 Warp 服務進行加速和加密。 Warp 是Cloudflare 提供的VPN 服務，主要用於加速使用者的網路連線。

• 使用場景：可以用來為透過Warp 加速的使用者設定不同的路由規則或策略。

9. cf.edge.timing

• 功能：提供有關請求處理過程的效能資訊，顯示了從Cloudflare 邊緣節點到來源站的延遲等資訊。此參數對於效能分析和調優非常重要。

• 使用場景：用於 效能監控 和優化。

10. cf.edge.request

• 功能：此參數可以提供Cloudflare 請求的更多詳細信息，例如請求的 處理時間，從Cloudflare 到來源伺服器的回應時間等。

• 使用場景：通常在 診斷工具 或請求優化中使用，幫助檢測響應瓶頸。

11. cf.worker

• 功能：與Cloudflare Worker 相關的參數，傳回 Worker 服務的執行資訊。 Worker 是Cloudflare 的無伺服器運算平台，可用來執行JavaScript、處理請求、修改回應等。

• 使用場景：用於 自訂請求處理，例如修改HTTP 請求/回應、增強快取控制、存取權限控制等。

12. cf.mirror

• 功能：表示Cloudflare 是否正在使用 鏡像 數據，即在某些場景下，Cloudflare 會根據內容類型或其他因素啟用快取鏡像。

• 使用場景：適用於進階快取和內容分發策略。

13. cf.origin.latency

• 功能：顯示從Cloudflare 到來源站的延遲時間。可以幫助你了解來源站效能，特別是在請求回應時間較長時。

• 使用場景：用於 效能監控，偵測網路瓶頸。

14. cf.ratelimit

• 功能：返回請求是否受到 速率限制 的訊息。這個參數通常與Cloudflare 的速率限制功能結合使用，以幫助偵測流量是否超過設定的閾值。

• 使用場景：防止DDoS 攻擊、暴力破解等惡意請求的控制。

註：在上面講的這些參數中除了”cf.edge.server_port”以外，其他參數的資訊只是收集而來，我還沒機會使用，不能保證功能說明一定正確，等以後有機會再來驗證吧。

總結

這些控制參數大多屬於高級功能，普通用戶通常不會涉及到，但是對於流量分析、安全防護、效能最佳化和自訂配置這些管理、監控方面的需求來說卻很重要，大多數情況下，只有具有管理員權限的用戶或開發者才會接觸到這些參數，一般的朋友當個附加知識了解下即可。

後話

其實，本文說起來對於一般的個人部落客而言並無太大的實際作用：因為使用傳統公網地址回源方式的朋友用不上，而使用Cloudflare Tunnel方式建站的朋友一般也未必在意這個事(除了一些比較關注網站SEO的部落客)，所以本文充其量只能算是一個關於Cloudflare Tunnel技術探討方面的文章。

不過，透過本文也引出了一個沒啥用的小技巧，可以快速分辨出一個套Cloudflare的網站(網域解析出來是Cloudflare的Anycast IP位址的網站)是基於」傳統的公有網路位址回源」還是基於」Cloudflare Tunnel回源」：只需要使用瀏覽器或curl之類的命令列工具訪問網站的8443(或2053、2083、2087、2096)端口，如果是超時就是基於」公網地址回源」；如果可以訪問或顯示被”blocked”，就是基於”Cloudflare Tunnel回源」。

註1：本文也算是在發現應用存取相關問題時，如何快速定位問題發生的層次(4層還是7層)以及如何進一步排查問題點及解決問題的一個比較有意思的案例(正常人肯定想不到Cloudflare會區別對待不同的回來源吧)，以前我還在上班時，被冤枉自家設備有問題(搞過應用交付設備的朋友應該都懂)的時候經常需要自證清白，那種情況就少不了乾這種定位排查的事，結果最後90%以上的問題都跟自家設備沒關～。

註2：既然本文談到了SEO，下一篇文章就寫SEO相關的內容吧～。