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