有了可以在兩台代理節點之間移動的 Web VIP，內部用戶端可以透過固定名稱連到 Nginx。今天要把這個入口發布到網際網路：正式網域交由 Cloudflare 回答公開 DNS，訪客先連到 Cloudflare Edge，再由 Cloudflare 經過 OPNsense、Web VIP 與 Nginx 抵達 Web 後端。

公開網站需要同時處理名稱委派、代理狀態、兩段 TLS、網站應用程式防火牆（Web Application Firewall，WAF）、Origin 入口限制與真實來源位址，才能建立可驗證且可持續服務的 HTTPS 入口。

今天要解決的問題

1. 網域註冊移轉、名稱伺服器（Nameserver）委派與 DNS 記錄管理有什麼差別？
2. 遞迴解析器如何從根名稱伺服器、TLD 找到 Cloudflare 權威 DNS？
3. Cloudflare 橘雲如何透過 CDN Edge 改變 DNS 回覆與 HTTP／HTTPS 路徑？
4. 使用者到 Cloudflare、Cloudflare 到 Origin 為什麼是兩條 TLS 連線？
5. TLS 終止位置如何決定 WAF 能否檢查 HTTP 請求？
6. Full (strict) 如何驗證 Origin 憑證？
7. OPNsense 如何只讓 Cloudflare 連到公開 Origin？
8. Nginx 如何安全還原真實用戶端 IP？
9. 如何從外部量測 Web VIP 切換後的公開 HTTPS 恢復時間？

本文閱讀方式

• 完整理解公開入口：依序閱讀 DNS、TLS、WAF、Origin 保護與用戶端 IP，最後再看 Lab 的驗證結果。
• 掌握完成 Lab 的最低限度知識：閱讀標有 ⭐ 的段落。
• 快速了解當天的部署內容：閱讀文末的 Lab／實作章節。
• 跟著系列建立完整系統：依照 GitHub 詳細部署文件 的天數順序操作。

為什麼修改 hosts 還能連到網站？

各位還記得 2024 年的喜傑獅「一讚折一元」事件嗎？業者解除公開 DNS 與網站 IP 的對應後，部分使用者在自己電腦的 hosts 寫入網站名稱與 Origin IP，讓瀏覽器直接連到持續運作的 Origin，並完成下單。

hosts 可以直接替這台電腦指定網站名稱對應的 IP，瀏覽器連線時會照常把原本的網站名稱放進 TLS SNI 與 HTTP Host。只要 Origin 接受網際網路連線並繼續提供訂單功能，請求便能抵達正確網站。那麼，使用 Cloudflare 發布網站時，要如何避免外部使用者知道 Origin IP 後直接繞過 Edge、WAF 與入口政策？後面的 DNS、代理路徑與 Origin 保護會逐步回答這個問題。

從名稱解析走到公開 HTTPS

瀏覽器輸入網址後，會先透過 DNS 找到連線目的地，再建立 TCP 與 TLS 連線，最後才傳送 HTTP 請求。橘雲啟用後，公開 DNS 回覆的是 Cloudflare Anycast IP。Origin 公網 IPv4 只供 Cloudflare 建立第二段連線。Cloudflare Edge 在第一段 TLS 解密 HTTP 請求，完成安全規則與代理處理後，再使用第二段 TLS 傳給 Origin。

這條路徑需要一個可由網際網路連入的公網 IPv4。若 WAN 位於上游 NAT 後方，還要由實際持有公網 IPv4 的上游設備轉送 TCP 443。公網位址、雙重 NAT 與 WAN 路徑可回到 Day 12 複習。

⭐ 網域委派與橘雲決定使用者先連到哪裡

註冊移轉與名稱伺服器委派是兩項操作

網域名稱同時涉及註冊、委派與記錄管理。網域註冊商（Domain Registrar）管理持有人資料、續約、轉移鎖與 Auth／EPP Code。頂級網域註冊管理機構（Registry）維護 .com 等頂級網域資料，並將網域的名稱伺服器公布在父 DNS 區域。權威 DNS（Authoritative DNS）才保存 A、AAAA、CNAME、MX、TXT 等實際記錄。

本次採用的方式

本次使用 Cloudflare 的 Connect a domain 建立 DNS 區域（Zone），再到 GoDaddy 將名稱伺服器改成 Cloudflare 指派的兩個值。網域由 GoDaddy 註冊與續約，Cloudflare 負責權威 DNS、橘雲代理與後續安全功能。本次沒有執行 Registrar Transfer。

圖（一）網域持有人在 GoDaddy 指定名稱伺服器。GoDaddy 將委派資料提交給 .com Registry，父 DNS 區域據此公布 Cloudflare 名稱伺服器

Cloudflare 的 Primary DNS Full Setup 會為該 DNS 區域指派兩台權威名稱伺服器。變更前先核對自動匯入的記錄。原網域若已啟用 DNSSEC，先移除註冊層的舊 DS 記錄，等待原 DS TTL 到期，並確認公開查詢已無舊 DS，再更換名稱伺服器。Cloudflare 顯示 Zone Status: Active 後，才啟用 Cloudflare DNSSEC 並加入新的 DS 記錄，避免父 DNS 區域保留舊金鑰資料而造成驗證失敗。

遞迴解析器依委派逐層找到最終答案

瀏覽器會把查詢交給作業系統的用戶端解析器（Stub Resolver），再由 ISP、企業網路或 1.1.1.1 等遞迴解析器（Recursive Resolver）完成查詢。沒有快取時，遞迴解析器依序從根名稱伺服器取得 .com 頂級網域（Top-Level Domain，TLD）名稱伺服器、從 .com TLD 取得 Cloudflare 名稱伺服器，最後向 Cloudflare 權威 DNS 取得 A Record，再依 TTL 暫存並回覆用戶端。

圖（二）沒有快取時，公共遞迴解析器依委派逐層找到 Cloudflare 權威 DNS，再取得 app.example.com 的 Cloudflare Anycast IP

根名稱伺服器與 TLD 提供下一站的委派資訊，權威 DNS 才提供 DNS 區域內的最終記錄。DNS 傳播主要來自父 DNS 區域的委派更新與各層快取依 TTL 到期後重新查詢。dig +trace app.example.com 可以觀察完整查詢鏈，dig A app.example.com 則檢查用戶端實際取得的位址。取得 IP 後，瀏覽器才另外建立 TCP、TLS 與 HTTP 連線。

內部名稱與公開名稱服務不同的使用範圍，可以同時存在：

橘雲讓 Cloudflare 成為 CDN 與公開反向代理

內容傳遞網路（Content Delivery Network，CDN）透過分散在不同地區的 Edge 節點接收使用者請求，並以 Anycast 將流量送往合適的 Cloudflare Edge。橘雲同時提供 CDN 與公開反向代理能力，Edge 會依內容與快取政策決定直接回應或連回 Origin。

簡單來說，CDN 就像替網站建立一組分散各地的高速公路交流道：使用者先連到網路路徑較合適的 Edge。Edge 有可用快取時直接回覆，需要最新或動態內容時才向 Origin 取得資料。

快取命中時，Edge 可以直接回傳已保存的內容，縮短傳輸距離並降低 Origin 的頻寬與處理負載。動態內容、快取未命中或設定為略過快取的請求則會回到 Origin。CDN 不會自動快取所有內容，登入、交易與個人化回應需依應用需求設定 Cache Rule 與回應標頭。

A、AAAA 與 CNAME 可以選擇 DNS only 或 Proxied。兩者都由 Cloudflare 回答 DNS，差別在於 HTTP／HTTPS 是否先經過 Cloudflare：

Cloudflare 在 Edge 終止第一段 TLS，套用快取、安全與代理政策後，再為需要回源的請求建立前往 Origin 的第二段連線。

圖（三）使用者先連到 Cloudflare Edge。需要回源的請求經過安全與代理政策後，再以另一條 HTTPS 連線送往 Origin

Proxied Record 的 TTL 預設為 Auto，目前是 300 秒，由 Cloudflare 控制。這個 TTL 限制遞迴解析器暫存 Cloudflare Anycast IP 的時間。本機、瀏覽器或上游快取可能讓實際觀察時間稍長。DNS 區域內雖然保存 Origin 公網 IPv4，權威 DNS 對橘雲查詢回覆的是 Cloudflare Anycast IP，因此外部 dig 無法直接看見該筆 Origin 位址。

橘雲主要改變公開解析與連線路徑。Origin 公網 IPv4 可能出現在歷史 DNS、郵件記錄或其他服務中，因此入口安全性還需要 OPNsense 的來源限制共同完成。

⭐ 兩段 TLS 分別驗證 Edge 與 Origin

Cloudflare 位於 HTTPS 路徑中間，使用者與 Origin 會分別建立一條 TLS 連線：

圖（四）瀏覽器驗證 Cloudflare Edge Certificate，Cloudflare 再以另一條 TLS 連線驗證 Nginx Origin Certificate

Edge Certificate 供瀏覽器驗證。Origin Certificate 可由公開 CA 或 Cloudflare Origin CA 簽發，交由 Cloudflare 驗證。

TLS 終止位置決定 WAF 的檢查位置

前面介紹過 OPNsense 的 IDS／IPS 功能，但 WAF 必須先取得解密後的 HTTP，才能檢查方法（Method）、主機名稱（Hostname）、URI、標頭（Header）與請求主體（Request Body）。今天的第二段 TLS 只會穿過 OPNsense，直到 proxy01／proxy02 的 Nginx 才終止。因此 OPNsense 上的 Suricata 可以檢查網路流量與可見的 TLS 資訊，直接在目前路徑加入 WAF 則無法取得完整 HTTP。

Cloudflare 也提供 WAF 服務。本次由 Cloudflare Edge 終止使用者建立的第一段 TLS，先對解密後的 HTTP 套用安全規則，再以 Full (strict) 建立第二段 TLS。OPNsense 則繼續負責來源限制、DNAT、連接埠與連線狀態。

WAF 也可以改放在自己的環境。放在 OPNsense 時，要先由 Nginx Reverse Proxy 終止 TLS，再把 HTTP 交給 NAXSI Module。只安裝 Plugin 並維持原本的 DNAT 路徑，NAXSI 不會收到 HTTP。另一種做法是把 WAF 放在 proxy01／proxy02，直接接在既有的 Nginx TLS 終止點後方。

本系列選擇 Cloudflare WAF，讓 HTTP 威脅先在 Edge 接受檢查，再由 OPNsense 只允許 Cloudflare Source 進入 TCP 443，同時保留 proxy01／proxy02 的入口 HA。需要自行掌握 WAF 規則時，可改放在 Proxy VM。具備雙防火牆、憑證與規則同步能力後，再評估由 OPNsense 終止 TLS。

圖（五）Cloudflare Edge 取得 HTTP 內容後依序執行 DDoS、Custom、Rate Limiting 與 Managed Rules，未被終止的請求才送往 Origin

付費方案還能使用範圍更廣的 Cloudflare Managed Ruleset 與 OWASP Core Ruleset。Free Managed Ruleset 只提供其中針對高影響漏洞的子集。實際效果要從 Security Events 核對命中的 Rule、Action 與誤判情況。

Full (strict) 驗證 Origin 憑證

Cloudflare 的 Full (strict) 會加密第二段連線，並驗證 Origin Certificate：

• 憑證在有效期間內。
• 憑證由 Cloudflare Origin CA 或公開信任的 CA 簽發。
• 憑證的 Common Name（CN）或 Subject Alternative Name（SAN）符合目標主機名稱。

今天使用 Full (strict)。部署順序是先讓兩台 Nginx 都能用正確憑證提供 TCP 443，再啟用 Full (strict)。Origin 憑證未符合條件時，Cloudflare 會拒絕連線，使用者可能看到 526 錯誤。

Full (strict) 管理 Cloudflare 與 Origin 的加密和驗證，HTTP 轉向 HTTPS 則是另一項入口政策。網站需要統一使用 HTTPS 時，可在 Edge 啟用 Always Use HTTPS 並驗證轉向結果。HTTP Strict Transport Security（HSTS）會被瀏覽器記住，適合等所有公開主機名稱都能穩定提供 HTTPS 後再啟用。

Cloudflare Origin CA 憑證的信任範圍是 Cloudflare 到 Origin。一般瀏覽器直接連 Origin 時通常不信任這張憑證，這正好符合 Origin 只接受 Cloudflare 路徑的設計。兩台 Proxy 必須安裝涵蓋相同主機名稱的憑證與私鑰，私鑰權限僅開放給必要服務。憑證有效期限則納入自行維護的監控與換發流程。

⭐ Origin 入口同時限制來源與目的

Cloudflare 連向 Origin 時，OPNsense 看到的來源位址是 Cloudflare 公布的 Proxy IP 網段。本次公開入口如下：

圖（六）Cloudflare 來源符合 WAN Rule 後，由 DNAT 轉向 Web VIP。Full (strict) 驗證 Nginx Origin Certificate 後傳送 HTTPS 請求

本次 Origin 回源只使用 IPv4。固定公網 IPv4 可建立 A Record，本次因公網位址由 DDNS 維護，改用橘雲 CNAME 指向 DDNS Hostname。公開 A 查詢會回覆 Cloudflare Anycast IPv4，OPNsense Alias 與 WAN Rule 也以 IPv4 建立。Cloudflare 的 IPv6 Compatibility 預設會讓橘雲主機名稱同時提供 Edge IPv6。用戶端即使透過 IPv6 連到 Cloudflare，第二段連線也可獨立使用 IPv4 Origin。未來若讓 Origin 直接具備 IPv6 路徑，Cloudflare IPv6 網段、WAN Rule、Origin Listener 與外部測試必須一起完成。

Cloudflare 會維護公開 IP 網段清單。Alias 應保存可追查的來源 URL、更新方式與最後同步時間，並在更新失敗時告警。這項規則只套用公開 Web Origin。OpenVPN、Bastion SSH 等服務具有自己的入口與來源政策。

來源 IP 白名單可以阻擋一般用戶端直接連向 Origin。需要更強的 Origin 身分驗證時，可以再導入 Authenticated Origin Pulls，讓 Nginx 於 TLS 階段驗證 Cloudflare 提供的 Client Certificate。Cloudflare Tunnel 則能以 Origin 主動建立的出站連線取代公開入站位址。今天先完成 Full (strict) 與來源網段限制，保留這兩種方式作為後續強化選項。

這也回答了開頭的問題。移除 DNS Record 只會讓一般解析器失去地址，不會停止已知 IP 上的服務。歷史 DNS、郵件記錄或其他服務也可能留下 Origin IP。真正的保護要放在連線路徑與應用程式本身：

1. 防火牆只允許 Cloudflare 公布的來源網段進入 Origin TCP 443。
2. 使用 Full (strict) 讓 Cloudflare 驗證 Origin 身分。需要由 Origin 驗證連線端確實是 Cloudflare 時，再加入 Authenticated Origin Pulls。
3. Nginx 只接受預定的主機名稱，其他 Host 交由 Default Server 拒絕。直連者即使保留正確主機名稱，也會由前兩層阻擋。
4. 需要停止交易時，同步關閉訂單功能、將商品設為不可購買或停止應用程式。移除 DNS Record 只會改變名稱解析結果。
5. 從外部使用 curl --resolve 保留原主機名稱、SNI 與 Host，強制連向 Origin IP。連線應被防火牆阻擋。

其中第一項直接封住已知 Origin IP 的繞過路徑，第五項則把這項安全條件變成可以重複驗證的負向測試。隱藏 Origin IP 可以降低被發現的機會，防火牆與 Origin 身分驗證才是持續有效的存取控制。

⭐ 真實用戶端 IP 在可信代理邊界內還原

啟用橘雲後，Nginx 的 TCP Peer 是 Cloudflare，預設的 $remote_addr 因此會是 Cloudflare IP。Cloudflare 另外以 CF-Connecting-IP 傳遞原始訪客位址。Nginx 只有在直接 Peer 屬於可信 Cloudflare 網段時，才應採用這個 Header。

# 只有官方公布的 Cloudflare 網段可以提供替代來源位址
set_real_ip_from <Cloudflare IPv4 或 IPv6 網段>;

# 使用 Cloudflare 保存的原始訪客位址更新 $remote_addr
real_ip_header CF-Connecting-IP;
real_ip_recursive on;

Nginx 轉送到 Web 後端時，直接以還原後的 $remote_addr 建立 X-Forwarded-For。Access Log 同時保存兩個位址、Host、請求、狀態與 Request ID，後續即可把 Cloudflare、Nginx 與應用程式事件沿著同一次請求串起來。

這個信任邊界也解釋了 Origin 來源限制的重要性：公開 Origin 若接受任意來源，攻擊者便能自行建立 CF-Connecting-IP Header。只信任 Cloudflare Peer 並封閉繞過路徑，Header 才能作為來源位址依據。

公開 HTTPS 的恢復時間由外部請求量測

Web VIP 的接管機制已經建立。本節專注於加入 Cloudflare Edge、第二段 TLS 與 WAN Policy 後，從真正的外部網路量測使用者看到的結果。VRRP、GARP 與選舉原理沿用既有設計。

量測前先定義起點與終點：

每次探測加入唯一 Query String 並要求不使用快取，同時記錄 HTTP Status、CF-Cache-Status 與回應中的後端身分。只有 DYNAMIC、BYPASS 或首次 MISS 等確實回源的結果納入計算。出現 HIT 便停止測試並先修正探測路徑。這樣會排除 Cloudflare Edge 的快取回應，量到今天新增後的完整公開路徑。

這項測試使用新的 HTTPS 請求觀察恢復。已建立的 TCP／TLS Session 會因代理節點故障而中斷，應用程式本身需要具備重新解析、重新連線與重試能力。

依公開路徑逐段排查

公開 HTTPS 適合依實際經過順序縮小問題範圍：

1. 查詢 NS，確認父 DNS 區域已委派到 Cloudflare。
2. 查詢公開 A Record，確認回覆 Cloudflare IP。
3. 檢查 Proxy Status、Edge Certificate、HTTP Status 與 cf-ray，確認請求確實進入 Cloudflare Edge。
4. 若出現 Block 或 Challenge，從 Security Events 核對實際命中的 DDoS、Custom、Rate Limiting、Managed Rules 或 Bot 防護。
5. 檢查 Cloudflare 到 Origin 的 TLS 結果。525 常指向 TLS Handshake，526 常指向 Full (strict) 憑證驗證。
6. 檢查 OPNsense Alias、WAN Rule 與 DNAT 命中情況。
7. 檢查 Web VIP 的持有者與 TCP 443 Listener。
8. 檢查 Nginx 到 app01／app02 的後端狀態與 Access Log。

Cloudflare 521／522 類型錯誤通常把排查方向帶到 Origin 拒絕連線或連線逾時。525／526 則優先檢查第二段 TLS。沿路徑確認每一段，比切換成 DNS only 或降低 Encryption Mode 更容易保留問題現場。

本次 Lab：把 Web VIP 發布成 Cloudflare 公開 HTTPS

GitHub 實作文件：Day 27 Cloudflare 公開 HTTPS 完整步驟

本次實作摘要

1. 將自己持有的網域加入 Cloudflare，核對 DNS 記錄後更新註冊商的名稱伺服器。
2. 等待 Zone Status 成為 Active，建立指向 DDNS Hostname 的 Proxied CNAME Record。
3. 建立涵蓋公開主機名稱的 Origin CA Certificate，部署到 proxy01、proxy02。
4. 讓兩台 Nginx 以相同 server_name、憑證與私鑰提供 TCP 443，先驗證設定再重新載入。
5. 將 Keepalived 的 Nginx 健康檢查改為檢查各節點自己的 HTTPS Listener。
6. 在 OPNsense 建立 Cloudflare IPv4 URL Table Alias、WAN TCP 443 規則與 DNAT。
7. 將 Cloudflare Encryption Mode 設為 Full (strict)。
8. 以可信 Cloudflare 網段與 CF-Connecting-IP 還原真實用戶端 IP。
9. 從外部網路完成公開存取、Origin 繞過、用戶端 IP 與 Web VIP 接管測試。

名稱伺服器與 DNS 快取更新需要時間。驗證時分開觀察委派、橘雲解析與 HTTPS 請求，避免只用瀏覽器成功畫面代替整條證據鏈。

本次實作使用橘雲，使公開 HTTP／HTTPS 請求進入 Cloudflare 的 Application Security 處理流程。Free Managed Ruleset 由 Free Plan 預設部署。為了留下可重現的 WAF 證據，另外建立只匹配 /day27-waf-proof 的 Custom Rule，從外部送出受控請求，再以 HTTP 403、cf-ray 與 Security Events 中相同的 Rule、主機名稱、Path 和時間交叉核對。

驗證一：公開網域已委派給 Cloudflare

Cloudflare 已為這個 DNS 區域指派兩台權威名稱伺服器，註冊商保存相同設定。外部解析器查詢 NS 時也得到同一組結果。

圖（七）Cloudflare、GoDaddy 與外部 Resolver 顯示相同的兩台名稱伺服器，驗證委派設定已對外生效

驗證二：橘雲改變公開 DNS 回覆與連線目的

從外部網路查詢公開 A Record，結果應為 Cloudflare Anycast IP，不直接顯示 Origin 公網 IPv4。接著以 curl 保留回應標頭，確認請求經過 Cloudflare 並取得網站內容。

圖（八）公開 A Record 回覆 Cloudflare Anycast IP。HTTPS 請求取得 HTTP 200、server: cloudflare、cf-ray 與 app01 後端身分

驗證三：兩台 Nginx 提供合格的 Origin HTTPS

proxy01、proxy02 都要通過 Nginx 設定檢查並監聽 TCP 443。Origin Certificate 的 SAN 涵蓋公開主機名稱，期限與簽發者符合 Full (strict) 條件。

圖（九）proxy01 的 Origin Certificate 涵蓋 xianmantang.shop 與 *.xianmantang.shop，Nginx 設定、TCP 443 Listener 與健康檢查均正常。proxy02 的服務狀態與實際接管結果另由圖（十四）交叉驗證

驗證四：Full (strict) 完成兩段 TLS

Cloudflare Dashboard 顯示 Full (strict)，外部用戶端則能驗證 Edge Certificate 並取得公開 HTTPS 回應。這兩項結果分別對應 Cloudflare 到 Origin、用戶端到 Cloudflare 的 TLS 狀態。

圖（十）Cloudflare 使用 Full (strict) 驗證 Origin。外部用戶端驗證公開 Edge Certificate 後取得 HTTP 200

驗證五：OPNsense 只轉送 Cloudflare 來源

CLOUDFLARE_IPV4 使用官方 IPv4 清單建立 URL Table Alias。WAN Rule 只允許這個 Alias 前往 TCP 443，DNAT 再將目的轉成 10.77.20.10:443。

圖（十一）Cloudflare IPv4 清單已載入執行階段。WAN Rule 與 Destination NAT 共同限制來源並將 TCP 443 轉向 WEB_VIP:443

驗證六：Origin 只接受 Cloudflare 路徑

同一台外部用戶端先以公開主機名稱成功連線，再用 curl --resolve 保留相同主機名稱與 TLS SNI、強制連向 Origin 公網 IPv4。前者成功且後者逾時，可以驗證公開服務可用，而且一般外部來源無法直接進入 Origin TCP 443。

圖（十二）同一台外部主機經 Cloudflare 取得 HTTP 200。保留相同主機名稱與 TLS SNI 強制直連 Origin 時得到 HTTP 000 與 curl rc=28

驗證七：Nginx 同時保存真實用戶端與 Cloudflare Peer

從外部送出帶有唯一測試字串的請求，再於目前持有 Web VIP 的 Proxy 查詢 Access Log。Log 中的用戶端 IP 應對應外部出口，Peer IP 則屬於 Cloudflare 網段。

圖（十三）相同 proof_id 將外部請求與 Nginx Access Log 對應起來。Log 同時保存真實用戶端、Cloudflare Peer、Host 與 HTTP 200

驗證八：Web VIP 接管後公開 HTTPS 恢復

先確認 proxy01 持有 Web VIP，再從外部持續送出不使用快取且具有唯一 Query String 的 HTTPS 請求。停止 proxy01 Nginx 後，保留第一筆失敗、proxy02 接管 VIP、第一筆恢復與連續三次 HTTP 200 的時間。

圖（十四）19:36:24 停止 proxy01 Nginx。proxy02 於 19:36:29 進入 MASTER 並接管 Web VIP。外部探測量得故障注入到穩定恢復約 6.7 秒，第一筆失敗到穩定恢復約 6.5 秒

圖中的兩台狀態取自切換期間的不同時間點。最終由 proxy02 持有 Web VIP，並於外部探測中恢復 HTTP 200。

測試結束後重新啟動 proxy01 Nginx，設定檢查、健康檢查與服務狀態恢復正常。探測間隔為一秒，因此結果以約 6.7 秒與約 6.5 秒表達，不解讀為毫秒級精度。

驗證九：Cloudflare WAF 阻擋受控請求

建立只匹配 /day27-waf-proof 的 Custom Rule，從外部送出帶有唯一 Query String 的請求。Cloudflare 回覆 HTTP 403，Security Events 也以同一時間、用戶端 IP、主機名稱、Path、Query String 與 Ray ID 記錄 DAY27_WAF_PROOF 的 Block 動作。

圖（十五）HTTP 403 的 cf-ray、時間與請求條件可在 Security Events 找到對應事件，驗證 Custom Rule 實際命中並阻擋請求

Lab 證據對照

本次公開 HTTPS 恢復時間

故障注入到穩定恢復從停止 Nginx 前記錄的時間開始計算，包含健康檢查、Keepalived 狀態轉換、VIP 接管，以及 Cloudflare 再次成功連上 Origin 的時間。使用者可見中斷則從外部探測第一次收到失敗開始計算，因此比前者少了約 0.256 秒。

切換期間出現 HTTP 521，表示 Cloudflare 當下無法與 Origin Web Server 建立連線。proxy02 接管 Web VIP 後，公開路徑恢復 HTTP 200。三次連續成功用來排除單次偶然回覆，實際計時取這組連續成功中的第一筆。由於探測間隔為一秒，本次結果適合以約 6.7 秒與約 6.5 秒解讀。

今天完成了什麼

• 釐清網域註冊移轉、名稱伺服器委派與 DNS Record 管理的責任。
• 追蹤遞迴解析器經由根名稱伺服器、TLD 與權威 DNS 取得答案的流程。
• 讓公開主機名稱透過 Cloudflare 橘雲代理，並以 Anycast IP 回覆公開 A 查詢。
• 讓使用者到 Cloudflare、Cloudflare 到 Nginx 都使用 TLS。
• 說明 Cloudflare Edge 終止 TLS 後，DDoS、Custom、Rate Limiting 與 Managed Rules 如何依序處理 HTTP 請求。
• 以 Full (strict) 驗證 Origin Certificate 的信任鏈、期限與名稱。
• 以 OPNsense Alias、WAN Rule 與 DNAT 限制 Origin TCP 443。
• 讓 Nginx 在可信代理邊界內還原真實用戶端 IP。
• 以正向、負向與故障切換測試驗證完整公開 HTTPS 路徑。

下一篇預告

下一篇是 Day 28｜PostgreSQL 資料誤刪如何復原？使用 pgBackRest、WAL Archive 與 PITR 回到指定時間點。公開入口與服務切換已經完成，接下來要替資料建立獨立的備份鏈，並實際還原到指定時間點。

參考資料

• Cloudflare｜Change your nameservers（Full setup）
• Cloudflare｜IPv6 compatibility
• Cloudflare｜Full (strict) encryption mode
• Cloudflare｜Protect your origin server
• Cloudflare｜Restoring original visitor IPs
• Cloudflare｜Managed Rules
• OPNsense｜Nginx Web Application Firewall
• Alfred's CyberLoom｜喜傑獅事件：改 hosts 為什麼能繞過 Cloudflare？