我會(huì)按行業(yè)老兵的視角來寫這篇博文說的都是自己實(shí)操中遇到的問題和沉淀下來的經(jīng)驗(yàn)。注意一點(diǎn)全文不會(huì)出現(xiàn)任何與跨境訪問相關(guān)的表述只談 Cloudflare 作為邊緣網(wǎng)絡(luò)服務(wù)和服務(wù)器源站本身的技術(shù)協(xié)作。1. 整體設(shè)計(jì)思路拆解先搞清楚這個(gè)環(huán)境到底要跑什么先說結(jié)論我理解的這套系統(tǒng)核心思路不是在本地或某臺(tái)物理機(jī)上裝一個(gè)叫“cloudflare-os”的發(fā)行版而是以操作系統(tǒng) 云廠商邊緣網(wǎng)絡(luò)這套組合體為骨架把服務(wù)器、域名、訪問鏈路、安全策略統(tǒng)一納管的一套部署方案。簡單說**它真正研究的是如何在服務(wù)器端把自己的源站“打磨”得適合在Cloudflare背后運(yùn)行。**換種說法——你的服務(wù)器是什么系統(tǒng)不關(guān)鍵關(guān)鍵是你怎么讓這臺(tái)機(jī)器的服務(wù)在Cloudflare這套全球邊緣架構(gòu)下穩(wěn)定、安全、快速地把內(nèi)容交給訪客?，F(xiàn)在不少同學(xué)上來就在VPS上搭好Nginx、MySQL、Redis一頓配置然后把域名接入Cloudflare結(jié)果發(fā)現(xiàn)網(wǎng)頁一會(huì)兒502一會(huì)兒顯示真實(shí)IP更別提證書配置、源站被封這些連環(huán)坑。這個(gè)現(xiàn)象的根源在于**絕大多數(shù)人對(duì)“邊緣網(wǎng)絡(luò)”的理解是錯(cuò)的。**他們以為邊緣網(wǎng)絡(luò)就是“套了一層CDN加速”實(shí)際上Cloudflare做的事情是DNS解析、全球負(fù)載均衡、七層代理、防護(hù)過濾、緩存加速、出口安全六大層全部疊在一起。你的源站根本不是在“外面”直接暴露給訪客而是躲在這一整套服務(wù)背后。既然這樣你的服務(wù)器管理思路就必須圍繞“源站隱身 邊緣信任 CDN適配”來設(shè)計(jì)。說回項(xiàng)目適用的場(chǎng)景。我一直覺得cloudflare-os這種思路最典型的適用對(duì)象包括這幾類人一類是個(gè)人開發(fā)者手里幾臺(tái)小服務(wù)器想把服務(wù)做得正規(guī)點(diǎn)但又不愿意花太多精力在運(yùn)維上一類是代理型業(yè)務(wù)運(yùn)維人員需要把客戶的內(nèi)容發(fā)布能力做得體面對(duì)穩(wěn)定性和安全性都有要求還有一類是自己搭過環(huán)境、但一直被“IP暴露”“源站被攻擊”“每次改完配置不生效”困擾的老手。這套東西解決的核心痛點(diǎn)就是讓你能用一個(gè)相對(duì)標(biāo)準(zhǔn)的方法把服務(wù)器和Cloudflare的各項(xiàng)能力校準(zhǔn)對(duì)齊然后一步步把部署從“能跑”推向“跑得穩(wěn)、扛得住、防得住”。這篇文章我就完整復(fù)盤一次從頭配置的全過程。從服務(wù)器選型、DNS接入到SSL模式選擇、防火墻規(guī)則、緩存策略、訪問控制再到幾種最典型的故障排查方式全部按我的實(shí)際經(jīng)驗(yàn)來講。文末會(huì)附上一些踩坑記錄希望能幫你省點(diǎn)時(shí)間。2. 前置準(zhǔn)備服務(wù)器、域名和賬戶的三項(xiàng)校準(zhǔn)2.1 服務(wù)器選型與系統(tǒng)定位因?yàn)楹诵氖窃凑九c邊緣網(wǎng)絡(luò)配合服務(wù)器的地理位置其實(shí)沒有你想象的那么重要。有些人總覺得“服務(wù)器離訪客近就夠用”但如果你的流量絕大多數(shù)是動(dòng)態(tài)API、登錄回話、數(shù)據(jù)庫讀寫那CDN的緩存根本幫不上忙真正決定響應(yīng)速度的是服務(wù)器本身的進(jìn)程能力和鏈路質(zhì)量。反過來如果流量大多是靜態(tài)資源、圖片、文本內(nèi)容那服務(wù)器放哪兒都無所謂反正邊緣節(jié)點(diǎn)會(huì)替你扛大頭?；谶@個(gè)判斷我建議選服務(wù)器時(shí)重點(diǎn)關(guān)注三件事處理器主頻盡量高、內(nèi)存起步4GB、順帶確認(rèn)一下入站帶寬的峰值。這樣做的原因很簡單Cloudflare回源連接是長連接高峰時(shí)會(huì)有很多并發(fā)請(qǐng)求直接穿透到源站如果機(jī)器性能太弱單機(jī)負(fù)載一高Nginx進(jìn)程就會(huì)頻繁僵死表現(xiàn)為“偶爾502、CPU跑滿”。這一點(diǎn)在配置階段沒那么顯眼一旦流量上來自行暴露。系統(tǒng)我推薦Debian 12或Ubuntu 22.04 LTS。無關(guān)信仰純粹是因?yàn)檫@兩個(gè)系統(tǒng)的內(nèi)核版本對(duì)iptables、nftables和常用運(yùn)維工具支持最省心軟件源里Nginx版本也夠新不用為了裝一個(gè)模塊去編譯半天。2.2 域名接入與NS托管先想清楚要不要全托管域名托管有兩種做法第一種是把域名的NS記錄整體交給Cloudflare托管這意味著域名的所有DNS解析都由Cloudflare統(tǒng)一管理換服務(wù)器、加子域、做負(fù)載均衡全部在同一個(gè)面板里搞定。第二種是只在原有DNS服務(wù)商處添加一個(gè)指向Cloudflare的“CNAME 別名”這種方式叫做部分接入優(yōu)點(diǎn)是保留原來DNS服務(wù)商的一些特殊功能但缺點(diǎn)是你無法享受Cloudflare的很多高級(jí)功能比如代理橙云狀態(tài)、防火墻規(guī)則里的域名級(jí)匹配等。我個(gè)人強(qiáng)烈建議直接走NS托管。理由不是“官方推薦”而是實(shí)際運(yùn)維時(shí)你會(huì)發(fā)現(xiàn)**橙云狀態(tài)的開關(guān)、記錄級(jí)別的代理控制、內(nèi)部跳轉(zhuǎn)規(guī)則這些操作在NS托管下最不容易出錯(cuò)。**如果走部分接入你會(huì)在兩個(gè)面板之間來回切出了DNS問題排查成本立刻翻倍。需要注意一點(diǎn)NS托管后你原先在舊服務(wù)商處的解析記錄全部都要手動(dòng)遷移到Cloudflare面板重新錄一遍。這個(gè)動(dòng)作不要拖到最后一刻提前兩天做留出DNS緩存的更新時(shí)間。2.3 賬戶層面的基本安全設(shè)置Cloudflare賬戶開啟兩因素認(rèn)證2FA永遠(yuǎn)是第一優(yōu)先級(jí)這件事別偷懶。然后是創(chuàng)建API令牌而不是用全局API Key寫腳本令牌權(quán)限要落到具體業(yè)務(wù)需要的范圍比如只給DNS編輯權(quán)限不給賬戶管理權(quán)限。這兩個(gè)動(dòng)作能在你誤操作或者令牌泄露時(shí)把損失控制在一個(gè)小范圍內(nèi)而不是整個(gè)資源都暴露在攻擊者面前。3. 邊緣與源站的連接SSL/TLS模式和Web Server配置校準(zhǔn)3.1 SSL/TLS加密模式的選擇這步直接影響回源鏈路能否跑通Cloudflare面板里有個(gè)選項(xiàng)叫“SSL/TLS加密模式”很多第一次配置的人容易被這里的選項(xiàng)繞暈Off關(guān)閉、Flexible靈活、Full完全、Full (Strict)完全嚴(yán)格。它們的本質(zhì)區(qū)別在源站是否安裝了有效證書、回源連接是否加密以及是否校驗(yàn)證書。我的推薦是**只要你的源站能裝證書一律選擇 Full (Strict)。**這個(gè)模式會(huì)強(qiáng)制Cloudflare邊緣節(jié)點(diǎn)與源站之間使用加密連接并且會(huì)校驗(yàn)源站證書是否有效。這樣一來訪客到邊緣節(jié)點(diǎn)是加密的邊緣節(jié)點(diǎn)到源站也是加密的整個(gè)鏈路沒有一段是明文傳輸。舉個(gè)反面例子有位同學(xué)用的是Flexible模式在邊緣與源站之間使用HTTP明文回源。結(jié)果他的登錄接口每次提交賬號(hào)密碼其實(shí)都被“裸奔”在公網(wǎng)的中間鏈路上。就算邊緣有HTTPS回源這一段的信任被完全放棄毫無安全可言。Flexible只適用于一種場(chǎng)景確認(rèn)源站完全不支持HTTPS配置的老舊服務(wù)而且無法快速改造。除此之外這個(gè)選項(xiàng)基本是壞味道。3.2 為源站準(zhǔn)備正常的證書選擇Full (Strict)的前提是源站得有一張合法證書。別慌不用花錢買。兩套方案使用Cloudflare的Origin CA證書這是一種只能用于源站回源驗(yàn)證的免費(fèi)證書和公共受信任的證書不一樣它會(huì)明確表明“我是Cloudflare簽發(fā)的用于邊緣和源站之間的通信”。這個(gè)方案的好處是簽發(fā)快、配置方便源站上只要裝好證書本體和私鑰然后信任Cloudflare的CA根證書即可。使用通用受信任證書比如Lets Encrypt這套方案能兼顧C(jī)loudflare回源驗(yàn)證和其他場(chǎng)景。壞處是你要定期續(xù)期通常在服務(wù)器上掛一個(gè)certbot定時(shí)任務(wù)來做。我建議普通場(chǎng)景直接上Origin CA證書。理由很現(xiàn)實(shí)那些通過公開證書簽發(fā)的機(jī)器一旦你忘了續(xù)期到期那天網(wǎng)站就會(huì)瞬間502而且排查半天還不一定能想到是證書過期。Origin CA證書的維護(hù)頻率低回源鏈路里它是封閉信任的外網(wǎng)不直接依賴省心不少。生成Origin CA證書的方式也很簡單進(jìn)入Cloudflare面板的SSL/TLS設(shè)置找到“源站服務(wù)器”選項(xiàng)頁創(chuàng)建一個(gè)證書選擇證書有效期然后填上你的源站域名比如origin.example.com點(diǎn)擊生成。把證書PEM內(nèi)容和私鑰存到/etc/ssl/cloudflare/下后續(xù)Nginx配置用。3.3 Web服務(wù)器回源監(jiān)聽配置讓Nginx接住回源流量如果你用的是Nginx關(guān)鍵配置大概長這樣server { listen 443 ssl http2; server_name origin.example.com; ssl_certificate /etc/ssl/cloudflare/origin-cert.pem; ssl_certificate_key /etc/ssl/cloudflare/origin-key.pem; ssl_client_certificate /etc/ssl/cloudflare/origin-pull-ca.pem; ssl_verify_client on; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }注意最后的ssl_verify_client on配合ssl_client_certificate。這行的作用是讓源站只允許持有Cloudflare回源證書的客戶端連接。換句話說就算有人拿到了你的源站IP并且嘗試用443端口訪問他的請(qǐng)求也不會(huì)被Nginx正常響應(yīng)因?yàn)樗怀钟蠧loudflare的上游證書。這個(gè)機(jī)制和Cloudflare的面板開關(guān)“Authenticated Origin Pulls”是連動(dòng)的開了之后源站層面的身份認(rèn)證一下子就扎實(shí)了。這個(gè)配置里還有一點(diǎn)容易漏掉proxy_set_header Host $host。由于源站可能同時(shí)存在多個(gè)服務(wù)每個(gè)服務(wù)有不同的server_name你必須保證回源請(qǐng)求里帶的Host頭是訪客最初訪問的那個(gè)域名而不是源站自身的名字。否則一多域名部署環(huán)境下所有請(qǐng)求都會(huì)落到默認(rèn)站點(diǎn)里癥狀就是“所有域名的頁面都能打開但打開的內(nèi)容全是同一個(gè)網(wǎng)站”。3.4 防火墻與源站IP保護(hù)隱藏源站是第一要?jiǎng)?wù)源站IP暴露是最常見的高危問題。只要IP被掃出來邊緣網(wǎng)絡(luò)做得再漂亮攻擊者也能繞過防護(hù)直接打你的源站。怎么判斷IP有沒有暴露很簡單你在源站服務(wù)器上隨便起一個(gè)非標(biāo)準(zhǔn)端口的HTTP服務(wù)比如8080端口然后直接訪問http://你的服務(wù)器IP:8080如果能正常打開Nginx歡迎頁說明你的IP是裸露的。接下來要做兩件事第一把源站的防火墻配置成只接受來自Cloudflare回源IP段的請(qǐng)求。Cloudflare官方發(fā)布的IP列表是公開的配置流程就是定期拉取這個(gè)列表并把這些IP段加入白名單。其他來源的訪問全部拒絕。第二修改SSH登錄端口、關(guān)閉密碼登錄、改用密鑰登錄。這個(gè)步驟早做早省心。攻擊者掃到你的源站IP之后第一件事就是試探SSH的22端口如果看到能連大概率會(huì)開始暴力破解。雖然系統(tǒng)還可以靠Fail2ban兜底但直接把入口收窄勝于事后補(bǔ)救。我用iptables做過一個(gè)最小規(guī)則集配置邏輯是這樣的SSH端口只允許我自己的常用IP訪問80和443端口只允許回源IP段訪問。其他出方向做狀態(tài)追蹤攔截。實(shí)際配置這么說iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p tcp --dport 22 -s 你的常用IP/32 -j ACCEPT iptables -A INPUT -p tcp --dport 80 -s 173.245.48.0/20 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -s 173.245.48.0/20 -j ACCEPT iptables -A INPUT -j DROP注意上述IP段只是截取了示例真實(shí)使用時(shí)需要拉取Cloudflare官方完整IP段并逐個(gè)添加。這段規(guī)則一共就四個(gè)動(dòng)作但它能把“非Cloudflare回源IP訪問WEB端口”的需求徹底斷掉。很多人在配置完這個(gè)規(guī)則后發(fā)現(xiàn)網(wǎng)站502第一反應(yīng)是防火墻寫錯(cuò)了。其實(shí)排查方向應(yīng)該是回源IP列表是否寫全了是不是忘了加IPv6段很多服務(wù)器默認(rèn)啟用了IPv6而你在原列表里只寫了IPv4導(dǎo)致回源請(qǐng)求走IPv6時(shí)被防火墻攔下。這個(gè)問題我踩過一次在下面排查章節(jié)會(huì)具體展開。4. 實(shí)操全流程完成一次標(biāo)準(zhǔn)部署4.1 流程總覽我自己整理的完整部署鏈路大致分五個(gè)步驟DNS接入全量托管解析記錄并開啟“橙云代理”狀態(tài)。源站軟件環(huán)境配置安裝Nginx、配置防火墻、生成Origin CA證書并應(yīng)用到Nginx。Cloudflare面板配置SSL/TLS模式打開Authenticated Origin Pulls開關(guān)。配置緩存規(guī)則、頁面規(guī)則和訪問控制讓靜態(tài)資源盡量命中邊緣緩存。做一次全鏈路驗(yàn)證檢查證書狀態(tài)、回源鏈路、緩存命中率和安全防護(hù)是否生效。下面把這五步拆開講。4.2 DNS接入和“橙云狀態(tài)”的正確理解在Cloudflare的域名解析頁面添加完全相同的A記錄主機(jī)名為IPv4地址填入你的源站服務(wù)器IP然后最重要的是確認(rèn)記錄行的“代理狀態(tài)”是橙云開啟。這是邊緣網(wǎng)絡(luò)的啟動(dòng)開關(guān)。橙云狀態(tài)開啟后這個(gè)域名才會(huì)真正納入Cloudflare的反代網(wǎng)絡(luò)灰色的“僅DNS”狀態(tài)則只是單純解析沒有防護(hù)和加速。設(shè)置好以后我建議先等半小時(shí)再繼續(xù)下一步。因?yàn)镈NS變更在全球傳播有延遲你要確保自己電腦用的本地DNS已經(jīng)解析到Cloudflare的節(jié)點(diǎn)IP再進(jìn)入SSL配置階段不然可能出現(xiàn)“面板已經(jīng)顯示生效但瀏覽器訪問還是打到源站”的錯(cuò)覺。4.3 源站證書生成與Nginx配置協(xié)同在Nginx端配置時(shí)我要再次強(qiáng)調(diào)ssl_verify_client on這個(gè)身份校驗(yàn)的重要性。如果你只在這個(gè)服務(wù)器上跑正常的HTTPS網(wǎng)站而沒有開啟客戶端證書驗(yàn)證好處是瀏覽器訪問源站IP時(shí)不會(huì)報(bào)錯(cuò)但同時(shí)也給了攻擊者訪問源站內(nèi)容的余地。開啟這個(gè)驗(yàn)證之后直接訪問源站IP會(huì)返回400錯(cuò)誤因?yàn)槟銢]有Cloudflare的客戶端證書。這個(gè)錯(cuò)誤本身就是最好的“信號(hào)燈”——它說明源站已經(jīng)被“鎖”住了。server { listen 80; server_name origin.example.com; return 301 https://$host$request_uri; }上述配置段的作用是把HTTP請(qǐng)求強(qiáng)制跳到HTTPS。因?yàn)槲覀冊(cè)诿姘鍖用嬉呀?jīng)開啟Full (Strict)模式如果源站還在監(jiān)聽80端口并接受明文請(qǐng)求等于給邊緣回源留下了明文通道。嚴(yán)格來說能關(guān)就關(guān)能跳就跳這才是一條閉環(huán)的安全鏈路。4.4 配置頁面規(guī)則和緩存策略緩存策略是邊緣網(wǎng)絡(luò)配置里提升性能最直接的地方。默認(rèn)情況下Cloudflare不會(huì)緩存帶動(dòng)態(tài)特征的請(qǐng)求比如帶cookie、POST類型、或設(shè)置了no-cache響應(yīng)頭的請(qǐng)求。我個(gè)人的習(xí)慣是這樣設(shè)置的對(duì)于靜態(tài)資源目錄比如/static、/assets、/uploads專門建一條頁面規(guī)則或緩存規(guī)則設(shè)置緩存級(jí)別為“緩存所有內(nèi)容”并設(shè)定邊緣緩存TTL為一個(gè)月。這樣做的好處是訪客第二次訪問時(shí)會(huì)直接命中邊緣節(jié)點(diǎn)源站連請(qǐng)求都不會(huì)收到壓力直接下降一個(gè)量級(jí)。對(duì)于動(dòng)態(tài)接口緩存規(guī)則設(shè)置為“繞過緩存”并且開啟Cache-Control: no-store響應(yīng)頭。很多初學(xué)者喜歡把緩存規(guī)則一刀切全設(shè)成緩存結(jié)果是用戶的登錄信息、庫存數(shù)量、評(píng)論內(nèi)容全被緩存到邊緣節(jié)點(diǎn)最后出現(xiàn)“頁面內(nèi)容與其他用戶串臺(tái)”的事故。這個(gè)坑看著低級(jí)但網(wǎng)上搜索相關(guān)問題時(shí)你會(huì)發(fā)現(xiàn)問的人真不少。還有一點(diǎn)值得注意就是Cloudflare的“開發(fā)模式”開關(guān)。這個(gè)開關(guān)開啟后會(huì)在三小時(shí)內(nèi)繞過邊緣緩存每次修改站點(diǎn)樣式、更換圖片后可以臨時(shí)開一下確認(rèn)效果。但千萬記得關(guān)閉否則時(shí)間一長你會(huì)誤以為緩存規(guī)則失效排查到半夜才發(fā)現(xiàn)只是忘了關(guān)開關(guān)。4.5 訪問控制和防火墻規(guī)則聯(lián)動(dòng)Cloudflare的一項(xiàng)重要能力是按地區(qū)、ASN、IP段做訪問控制。比如你的業(yè)務(wù)只服務(wù)特定地區(qū)用戶那就可以在防火墻規(guī)則里設(shè)置“國家/地區(qū)等于XX則允許”其余地理位置一律阻止。這條策略必須在邊緣就“掐住”而不是等到請(qǐng)求回源到服務(wù)器上再做判斷。同時(shí)我建議開啟TLS版本控制和“最低TLS版本為1.2”的設(shè)置。放心這是安全的。原因很簡單TLS 1.0和1.1早就是老古董了仍然開放等于給抓包和降級(jí)攻擊留了口子。這塊配置放在SSL/TLS設(shè)置的“邊緣證書”區(qū)域下拉菜單里選擇TLS1.2即可。5. 常見問題與排查技巧實(shí)錄5.1 常見問題速查表以下問題全部來自真實(shí)場(chǎng)景我按出現(xiàn)頻率排了一下問題現(xiàn)象可能原因排查路徑網(wǎng)頁顯示502或523源站Nginx未正常啟動(dòng)或防火墻攔截回源IP登入源站檢查Nginx進(jìn)程暫時(shí)關(guān)閉防火墻做對(duì)比測(cè)試再重新恢復(fù)規(guī)則源站IP被掃到網(wǎng)站能繞過防護(hù)直接訪問NS托管后仍然開啟灰色DNS狀態(tài)或部分域名沒開橙云逐個(gè)檢查A記錄的代理狀態(tài)確保為橙色云朵全站內(nèi)容都被緩存用戶數(shù)據(jù)互相串臺(tái)緩存規(guī)則把動(dòng)態(tài)請(qǐng)求也緩存了查頁面規(guī)則把動(dòng)態(tài)路徑設(shè)置為“繞過緩存”修改Nginx配置后不生效沒有reload或者瀏覽器本地緩存了舊頁面執(zhí)行nginx -t systemctl reload nginx再使用無痕窗口測(cè)試HTTPS訪問出現(xiàn)證書報(bào)錯(cuò)面板SSL模式與源站證書不匹配檢查面板SSL模式是否為Full (Strict)并確保證書有效國外訪問正常國內(nèi)訪問很慢未開啟緩存回源鏈路質(zhì)量差優(yōu)化動(dòng)態(tài)接口響應(yīng)體大小提升靜態(tài)資源緩存命中率5.2 我犯過最痛的一個(gè)錯(cuò)忘了IPv6防火墻規(guī)則有一次我給一臺(tái)服務(wù)器配置防火墻只加了IPv4的Cloudflare回源IP白名單。配置期間一切正常第二天下午有訪客報(bào)告網(wǎng)站偶爾打不開。我登上服務(wù)器看到Nginx日志里一大片連接被拒絕的情況當(dāng)時(shí)第一反應(yīng)是防火墻規(guī)則順序不對(duì)但檢查了一圈毫無收獲。后來我隨手執(zhí)行ip -6 addr show才發(fā)現(xiàn)這臺(tái)機(jī)器不僅啟用了IPv6而且Cloudflare的回源連接確實(shí)走到了IPv6通道。因?yàn)槲业陌酌麊卫飰焊鶝]有IPv6段防火墻直接把所有IPv6回源流量給DROP了。修復(fù)方案就是在防火墻里補(bǔ)充IPv6規(guī)則同時(shí)添加Cloudflare官網(wǎng)列出的IPv6回源IP段。這件事給我印象極深后來每次配置防火墻我都會(huì)在默認(rèn)的checklist里加一項(xiàng)“確認(rèn)IPv6白名單”。5.3 緩存命中率上不去或者APO一直不生效我經(jīng)常被問的一個(gè)問題是“為什么我設(shè)置了緩存規(guī)則但緩存命中率依然只有10%”這時(shí)我第一句話永遠(yuǎn)反問你的頁面上有沒有設(shè)置Cache-Control響應(yīng)頭如果沒有Cloudflare默認(rèn)會(huì)按照自己的算法來決策是否緩存結(jié)果就是大部分HTML頁面不會(huì)被緩存只有帶明確緩存標(biāo)記的靜態(tài)資源才會(huì)命中。解決方式是在源站Nginx里給靜態(tài)資源明確加上Cache-Control: public, max-age31536000同時(shí)在動(dòng)態(tài)頁面設(shè)置Cache-Control: no-cache。這個(gè)操作我一般放到Nginx的server或location層級(jí)來配置僅改動(dòng)幾個(gè)響應(yīng)頭就能帶來可觀的命中率提升。具體配置示例location ~* \.(js|css|png|jpg|jpeg|gif|webp|svg|woff2|ttf)$ { expires 365d; add_header Cache-Control public, no-transform; }5.4 使用無痕窗口和curl命令做標(biāo)準(zhǔn)驗(yàn)證最后一步驗(yàn)證整體部署時(shí)我通常不會(huì)直接用普通瀏覽器。原因很簡單本地緩存可能把舊頁面帶出來干擾你的判斷。我的標(biāo)準(zhǔn)流程是curl -I https://你的域名重點(diǎn)看響應(yīng)頭里的這些字段cf-cache-status如果顯示HIT說明命中緩存顯示DYNAMIC說明被判定為動(dòng)態(tài)請(qǐng)求。server顯示cloudflare說明已經(jīng)走在邊緣網(wǎng)絡(luò)上。cf-ray有值說明請(qǐng)求確實(shí)穿過了Cloudflare的節(jié)點(diǎn)。SSL_VERIFY狀態(tài)如果沒有報(bào)錯(cuò)說明回源鏈路證書校驗(yàn)成功。如果cf-cache-status一直是MISS請(qǐng)先檢查你的頁面規(guī)則是否將路徑排除在了緩存之外再檢查源站響應(yīng)頭是否設(shè)置了no-cache。多數(shù)情況都出在這兩個(gè)點(diǎn)上。6. 我的實(shí)操體會(huì)與后續(xù)擴(kuò)展建議整套環(huán)境從零到跑通我個(gè)人的體感是這樣的真正花時(shí)間的地方不是“點(diǎn)面板按鈕”而是理解每一條配置背后到底在“信任誰”“防住誰”。Cloudflare不是代理你的域名而是在你源站前面起了一層“保護(hù)殼”。你必須先讓源站默認(rèn)不信任所有請(qǐng)求然后從邊緣到源之間建立一條僅屬于你自己的可信通道這套體系才算真正搭起來。在后續(xù)擴(kuò)展上如果你跑的業(yè)務(wù)規(guī)模上來了我建議再補(bǔ)兩塊內(nèi)容。一個(gè)是在多臺(tái)源站機(jī)器前掛負(fù)載均衡器Cloudflare有Weighted Load Balancing功能可以按權(quán)重把流量分發(fā)到不同區(qū)域?qū)崿F(xiàn)高可用。另一個(gè)是啟用Logpush或Workers來定期分析訪問日志把緩存命中率、5xx錯(cuò)誤率、回源失敗次數(shù)收集成趨勢(shì)圖提前發(fā)現(xiàn)潛在問題。最后分享一個(gè)很實(shí)用的小技巧每次修改完Cloudflare面板規(guī)則之后盡量用“無痕窗口 時(shí)間戳參數(shù)”訪問頁面。比如在URL后面加上?v20250101做測(cè)試時(shí)可以強(qiáng)制繞過邊緣緩存。這個(gè)小習(xí)慣能讓你少掉很多頭發(fā)——尤其是調(diào)試靜態(tài)資源更新問題時(shí)。