Cloudflare Tunnel 讓來源伺服器上的 `cloudflared` 主動建立向外連線，再由 Cloudflare 把網站流量送入 Tunnel。來源不必公開 IP 或開放入站 Web 連接埠，可減少攻擊者繞過代理直接存取主機。它仍需正確管理伺服器、DNS、TLS 和 WordPress。
先確認主機允許安裝連接器
Tunnel 適合可長期運行背景服務的 VPS、專用主機、容器或內部伺服器。共享主機未必允許執行 `cloudflared`。先確認管理權限和主機商政策。
理解向外連線模型
`cloudflared` 從來源主機建立 outbound-only 連線到 Cloudflare，之後請求可在同一 Tunnel 雙向傳輸。防火牆毋須讓任何訪客直接連入 Web 連接埠，但仍要允許連接器所需的向外網絡通訊。
為 Tunnel 使用清楚名稱
名稱應反映環境與服務，例如正式網站或測試站，不要只寫預設名稱。Tunnel 是持久物件，可包含一個或多個 connector。清楚命名有助日後辨認哪台主機離線、哪條公開路由仍在使用。
在來源主機安裝 cloudflared
從控制台建立 Tunnel，按作業系統取得安裝與連接命令。憑證或 token 等同連接器權限，不應貼在聊天、公開版本庫或網站文章。安裝後以系統服務運行，並確認重新啟動主機後會自動連線。
先以本機服務地址測試
確認 WordPress Web 伺服器能在來源主機本機地址正常回應，例如內部 HTTP 或 HTTPS 服務。Tunnel 不能修正 PHP 錯誤、資料庫連線或 Web 伺服器虛擬主機設定。先從來源本機測通，再處理公開主機名稱。
建立 Published Application 路由
將網站子網域或正式主機名稱對應到本機服務 URL。控制台可建立指向 Tunnel 的 DNS 記錄。服務 URL、Host header 和來源虛擬主機必須一致，否則可能出現錯誤網站、重導迴圈或無效憑證。
HTTPS 來源要驗證憑證
若 `cloudflared` 連接本機 HTTPS，應使用可信或內部 CA 簽發的來源憑證，並設定正確 Server Name。不要長期以停用 TLS 驗證掩蓋憑證錯誤。Tunnel 保護傳輸路徑，但來源端身份仍應可驗證。
關閉不需要的公開入站連接
確認 Tunnel 正常後，才逐步限制來源防火牆的公網 HTTP/HTTPS 入站流量。保留安全管理通道與回復方法。資料庫、SSH 和控制面板亦不應意外公開。
檢查真正訪客 IP
來源 Web 伺服器直接看到的連線可能來自 `cloudflared`，HTTP 應使用 Cloudflare 提供的可信標頭取得訪客 IP。只接受由受信任代理加入的標頭，避免訪客自行偽造。同步檢查 WordPress 安全外掛、限速和日誌是否讀取正確來源。
後台可再配合 Access
Tunnel 只是連接路徑，公開主機名稱預設仍可由網際網路存取。內部工具、測試站或敏感管理入口可配合 Access 身份政策。若為 WordPress 後台加上額外登入層，要測試 AJAX、REST API、排程和外部整合。
建立多個 Connector 提高可用性
同一 Tunnel 可運行多個 connector，降低單一程序故障。這不代表 WordPress 已有高可用；若所有連接器仍指向同一台故障主機，網站依然離線。
設定監察與自動重啟
監察 Tunnel、connector、來源回應時間及錯誤率。可設定自動重啟，但避免掩蓋憑證、DNS 或網絡問題。升級前先在測試環境驗證。
準備繞回原架構的方法
保存原 DNS、來源防火牆和 Web 服務設定，建立明確回復步驟。若 Tunnel 控制面、路由或連接器發生問題，可按既定程序恢復受限制的直接入口，而不是臨時把所有連接埠全面開放。
Tunnel 不取代 WordPress 保養
它不能阻止弱密碼、惡意外掛、未更新核心或已被入侵的來源主機。仍要使用雙重驗證、最低權限、備份、WAF、更新和惡意程式監察。隱藏 IP 是降低直接攻擊面，不是消除應用程式漏洞。
結語
Cloudflare Tunnel 的可靠部署順序是：確認主機能力、測通本機服務、建立 connector 和公開路由、驗證訪客 IP，再逐步關閉公網入站。配合來源 TLS、Access、監察與回復方案，才能安全隱藏 WordPress 來源而不犧牲可維護性。
