我会按行业老兵的视角来写这篇博文说的都是自己实操中遇到的问题和沉淀下来的经验。注意一点全文不会出现任何与跨境访问相关的表述只谈 Cloudflare 作为边缘网络服务和服务器源站本身的技术协作。1. 整体设计思路拆解先搞清楚这个环境到底要跑什么先说结论我理解的这套系统核心思路不是在本地或某台物理机上装一个叫“cloudflare-os”的发行版而是以操作系统 云厂商边缘网络这套组合体为骨架把服务器、域名、访问链路、安全策略统一纳管的一套部署方案。简单说**它真正研究的是如何在服务器端把自己的源站“打磨”得适合在Cloudflare背后运行。**换种说法——你的服务器是什么系统不关键关键是你怎么让这台机器的服务在Cloudflare这套全球边缘架构下稳定、安全、快速地把内容交给访客。现在不少同学上来就在VPS上搭好Nginx、MySQL、Redis一顿配置然后把域名接入Cloudflare结果发现网页一会儿502一会儿显示真实IP更别提证书配置、源站被封这些连环坑。这个现象的根源在于**绝大多数人对“边缘网络”的理解是错的。**他们以为边缘网络就是“套了一层CDN加速”实际上Cloudflare做的事情是DNS解析、全球负载均衡、七层代理、防护过滤、缓存加速、出口安全六大层全部叠在一起。你的源站根本不是在“外面”直接暴露给访客而是躲在这一整套服务背后。既然这样你的服务器管理思路就必须围绕“源站隐身 边缘信任 CDN适配”来设计。说回项目适用的场景。我一直觉得cloudflare-os这种思路最典型的适用对象包括这几类人一类是个人开发者手里几台小服务器想把服务做得正规点但又不愿意花太多精力在运维上一类是代理型业务运维人员需要把客户的内容发布能力做得体面对稳定性和安全性都有要求还有一类是自己搭过环境、但一直被“IP暴露”“源站被攻击”“每次改完配置不生效”困扰的老手。这套东西解决的核心痛点就是让你能用一个相对标准的方法把服务器和Cloudflare的各项能力校准对齐然后一步步把部署从“能跑”推向“跑得稳、扛得住、防得住”。这篇文章我就完整复盘一次从头配置的全过程。从服务器选型、DNS接入到SSL模式选择、防火墙规则、缓存策略、访问控制再到几种最典型的故障排查方式全部按我的实际经验来讲。文末会附上一些踩坑记录希望能帮你省点时间。2. 前置准备服务器、域名和账户的三项校准2.1 服务器选型与系统定位因为核心是源站与边缘网络配合服务器的地理位置其实没有你想象的那么重要。有些人总觉得“服务器离访客近就够用”但如果你的流量绝大多数是动态API、登录回话、数据库读写那CDN的缓存根本帮不上忙真正决定响应速度的是服务器本身的进程能力和链路质量。反过来如果流量大多是静态资源、图片、文本内容那服务器放哪儿都无所谓反正边缘节点会替你扛大头。基于这个判断我建议选服务器时重点关注三件事处理器主频尽量高、内存起步4GB、顺带确认一下入站带宽的峰值。这样做的原因很简单Cloudflare回源连接是长连接高峰时会有很多并发请求直接穿透到源站如果机器性能太弱单机负载一高Nginx进程就会频繁僵死表现为“偶尔502、CPU跑满”。这一点在配置阶段没那么显眼一旦流量上来自行暴露。系统我推荐Debian 12或Ubuntu 22.04 LTS。无关信仰纯粹是因为这两个系统的内核版本对iptables、nftables和常用运维工具支持最省心软件源里Nginx版本也够新不用为了装一个模块去编译半天。2.2 域名接入与NS托管先想清楚要不要全托管域名托管有两种做法第一种是把域名的NS记录整体交给Cloudflare托管这意味着域名的所有DNS解析都由Cloudflare统一管理换服务器、加子域、做负载均衡全部在同一个面板里搞定。第二种是只在原有DNS服务商处添加一个指向Cloudflare的“CNAME 别名”这种方式叫做部分接入优点是保留原来DNS服务商的一些特殊功能但缺点是你无法享受Cloudflare的很多高级功能比如代理橙云状态、防火墙规则里的域名级匹配等。我个人强烈建议直接走NS托管。理由不是“官方推荐”而是实际运维时你会发现**橙云状态的开关、记录级别的代理控制、内部跳转规则这些操作在NS托管下最不容易出错。**如果走部分接入你会在两个面板之间来回切出了DNS问题排查成本立刻翻倍。需要注意一点NS托管后你原先在旧服务商处的解析记录全部都要手动迁移到Cloudflare面板重新录一遍。这个动作不要拖到最后一刻提前两天做留出DNS缓存的更新时间。2.3 账户层面的基本安全设置Cloudflare账户开启两因素认证2FA永远是第一优先级这件事别偷懒。然后是创建API令牌而不是用全局API Key写脚本令牌权限要落到具体业务需要的范围比如只给DNS编辑权限不给账户管理权限。这两个动作能在你误操作或者令牌泄露时把损失控制在一个小范围内而不是整个资源都暴露在攻击者面前。3. 边缘与源站的连接SSL/TLS模式和Web Server配置校准3.1 SSL/TLS加密模式的选择这步直接影响回源链路能否跑通Cloudflare面板里有个选项叫“SSL/TLS加密模式”很多第一次配置的人容易被这里的选项绕晕Off关闭、Flexible灵活、Full完全、Full (Strict)完全严格。它们的本质区别在源站是否安装了有效证书、回源连接是否加密以及是否校验证书。我的推荐是**只要你的源站能装证书一律选择 Full (Strict)。**这个模式会强制Cloudflare边缘节点与源站之间使用加密连接并且会校验源站证书是否有效。这样一来访客到边缘节点是加密的边缘节点到源站也是加密的整个链路没有一段是明文传输。举个反面例子有位同学用的是Flexible模式在边缘与源站之间使用HTTP明文回源。结果他的登录接口每次提交账号密码其实都被“裸奔”在公网的中间链路上。就算边缘有HTTPS回源这一段的信任被完全放弃毫无安全可言。Flexible只适用于一种场景确认源站完全不支持HTTPS配置的老旧服务而且无法快速改造。除此之外这个选项基本是坏味道。3.2 为源站准备正常的证书选择Full (Strict)的前提是源站得有一张合法证书。别慌不用花钱买。两套方案使用Cloudflare的Origin CA证书这是一种只能用于源站回源验证的免费证书和公共受信任的证书不一样它会明确表明“我是Cloudflare签发的用于边缘和源站之间的通信”。这个方案的好处是签发快、配置方便源站上只要装好证书本体和私钥然后信任Cloudflare的CA根证书即可。使用通用受信任证书比如Lets Encrypt这套方案能兼顾Cloudflare回源验证和其他场景。坏处是你要定期续期通常在服务器上挂一个certbot定时任务来做。我建议普通场景直接上Origin CA证书。理由很现实那些通过公开证书签发的机器一旦你忘了续期到期那天网站就会瞬间502而且排查半天还不一定能想到是证书过期。Origin CA证书的维护频率低回源链路里它是封闭信任的外网不直接依赖省心不少。生成Origin CA证书的方式也很简单进入Cloudflare面板的SSL/TLS设置找到“源站服务器”选项页创建一个证书选择证书有效期然后填上你的源站域名比如origin.example.com点击生成。把证书PEM内容和私钥存到/etc/ssl/cloudflare/下后续Nginx配置用。3.3 Web服务器回源监听配置让Nginx接住回源流量如果你用的是Nginx关键配置大概长这样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的面板开关“Authenticated Origin Pulls”是连动的开了之后源站层面的身份认证一下子就扎实了。这个配置里还有一点容易漏掉proxy_set_header Host $host。由于源站可能同时存在多个服务每个服务有不同的server_name你必须保证回源请求里带的Host头是访客最初访问的那个域名而不是源站自身的名字。否则一多域名部署环境下所有请求都会落到默认站点里症状就是“所有域名的页面都能打开但打开的内容全是同一个网站”。3.4 防火墙与源站IP保护隐藏源站是第一要务源站IP暴露是最常见的高危问题。只要IP被扫出来边缘网络做得再漂亮攻击者也能绕过防护直接打你的源站。怎么判断IP有没有暴露很简单你在源站服务器上随便起一个非标准端口的HTTP服务比如8080端口然后直接访问http://你的服务器IP:8080如果能正常打开Nginx欢迎页说明你的IP是裸露的。接下来要做两件事第一把源站的防火墙配置成只接受来自Cloudflare回源IP段的请求。Cloudflare官方发布的IP列表是公开的配置流程就是定期拉取这个列表并把这些IP段加入白名单。其他来源的访问全部拒绝。第二修改SSH登录端口、关闭密码登录、改用密钥登录。这个步骤早做早省心。攻击者扫到你的源站IP之后第一件事就是试探SSH的22端口如果看到能连大概率会开始暴力破解。虽然系统还可以靠Fail2ban兜底但直接把入口收窄胜于事后补救。我用iptables做过一个最小规则集配置逻辑是这样的SSH端口只允许我自己的常用IP访问80和443端口只允许回源IP段访问。其他出方向做状态追踪拦截。实际配置这么说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段并逐个添加。这段规则一共就四个动作但它能把“非Cloudflare回源IP访问WEB端口”的需求彻底断掉。很多人在配置完这个规则后发现网站502第一反应是防火墙写错了。其实排查方向应该是回源IP列表是否写全了是不是忘了加IPv6段很多服务器默认启用了IPv6而你在原列表里只写了IPv4导致回源请求走IPv6时被防火墙拦下。这个问题我踩过一次在下面排查章节会具体展开。4. 实操全流程完成一次标准部署4.1 流程总览我自己整理的完整部署链路大致分五个步骤DNS接入全量托管解析记录并开启“橙云代理”状态。源站软件环境配置安装Nginx、配置防火墙、生成Origin CA证书并应用到Nginx。Cloudflare面板配置SSL/TLS模式打开Authenticated Origin Pulls开关。配置缓存规则、页面规则和访问控制让静态资源尽量命中边缘缓存。做一次全链路验证检查证书状态、回源链路、缓存命中率和安全防护是否生效。下面把这五步拆开讲。4.2 DNS接入和“橙云状态”的正确理解在Cloudflare的域名解析页面添加完全相同的A记录主机名为IPv4地址填入你的源站服务器IP然后最重要的是确认记录行的“代理状态”是橙云开启。这是边缘网络的启动开关。橙云状态开启后这个域名才会真正纳入Cloudflare的反代网络灰色的“仅DNS”状态则只是单纯解析没有防护和加速。设置好以后我建议先等半小时再继续下一步。因为DNS变更在全球传播有延迟你要确保自己电脑用的本地DNS已经解析到Cloudflare的节点IP再进入SSL配置阶段不然可能出现“面板已经显示生效但浏览器访问还是打到源站”的错觉。4.3 源站证书生成与Nginx配置协同在Nginx端配置时我要再次强调ssl_verify_client on这个身份校验的重要性。如果你只在这个服务器上跑正常的HTTPS网站而没有开启客户端证书验证好处是浏览器访问源站IP时不会报错但同时也给了攻击者访问源站内容的余地。开启这个验证之后直接访问源站IP会返回400错误因为你没有Cloudflare的客户端证书。这个错误本身就是最好的“信号灯”——它说明源站已经被“锁”住了。server { listen 80; server_name origin.example.com; return 301 https://$host$request_uri; }上述配置段的作用是把HTTP请求强制跳到HTTPS。因为我们在面板层面已经开启Full (Strict)模式如果源站还在监听80端口并接受明文请求等于给边缘回源留下了明文通道。严格来说能关就关能跳就跳这才是一条闭环的安全链路。4.4 配置页面规则和缓存策略缓存策略是边缘网络配置里提升性能最直接的地方。默认情况下Cloudflare不会缓存带动态特征的请求比如带cookie、POST类型、或设置了no-cache响应头的请求。我个人的习惯是这样设置的对于静态资源目录比如/static、/assets、/uploads专门建一条页面规则或缓存规则设置缓存级别为“缓存所有内容”并设定边缘缓存TTL为一个月。这样做的好处是访客第二次访问时会直接命中边缘节点源站连请求都不会收到压力直接下降一个量级。对于动态接口缓存规则设置为“绕过缓存”并且开启Cache-Control: no-store响应头。很多初学者喜欢把缓存规则一刀切全设成缓存结果是用户的登录信息、库存数量、评论内容全被缓存到边缘节点最后出现“页面内容与其他用户串台”的事故。这个坑看着低级但网上搜索相关问题时你会发现问的人真不少。还有一点值得注意就是Cloudflare的“开发模式”开关。这个开关开启后会在三小时内绕过边缘缓存每次修改站点样式、更换图片后可以临时开一下确认效果。但千万记得关闭否则时间一长你会误以为缓存规则失效排查到半夜才发现只是忘了关开关。4.5 访问控制和防火墙规则联动Cloudflare的一项重要能力是按地区、ASN、IP段做访问控制。比如你的业务只服务特定地区用户那就可以在防火墙规则里设置“国家/地区等于XX则允许”其余地理位置一律阻止。这条策略必须在边缘就“掐住”而不是等到请求回源到服务器上再做判断。同时我建议开启TLS版本控制和“最低TLS版本为1.2”的设置。放心这是安全的。原因很简单TLS 1.0和1.1早就是老古董了仍然开放等于给抓包和降级攻击留了口子。这块配置放在SSL/TLS设置的“边缘证书”区域下拉菜单里选择TLS1.2即可。5. 常见问题与排查技巧实录5.1 常见问题速查表以下问题全部来自真实场景我按出现频率排了一下问题现象可能原因排查路径网页显示502或523源站Nginx未正常启动或防火墙拦截回源IP登入源站检查Nginx进程暂时关闭防火墙做对比测试再重新恢复规则源站IP被扫到网站能绕过防护直接访问NS托管后仍然开启灰色DNS状态或部分域名没开橙云逐个检查A记录的代理状态确保为橙色云朵全站内容都被缓存用户数据互相串台缓存规则把动态请求也缓存了查页面规则把动态路径设置为“绕过缓存”修改Nginx配置后不生效没有reload或者浏览器本地缓存了旧页面执行nginx -t systemctl reload nginx再使用无痕窗口测试HTTPS访问出现证书报错面板SSL模式与源站证书不匹配检查面板SSL模式是否为Full (Strict)并确保证书有效国外访问正常国内访问很慢未开启缓存回源链路质量差优化动态接口响应体大小提升静态资源缓存命中率5.2 我犯过最痛的一个错忘了IPv6防火墙规则有一次我给一台服务器配置防火墙只加了IPv4的Cloudflare回源IP白名单。配置期间一切正常第二天下午有访客报告网站偶尔打不开。我登上服务器看到Nginx日志里一大片连接被拒绝的情况当时第一反应是防火墙规则顺序不对但检查了一圈毫无收获。后来我随手执行ip -6 addr show才发现这台机器不仅启用了IPv6而且Cloudflare的回源连接确实走到了IPv6通道。因为我的白名单里压根没有IPv6段防火墙直接把所有IPv6回源流量给DROP了。修复方案就是在防火墙里补充IPv6规则同时添加Cloudflare官网列出的IPv6回源IP段。这件事给我印象极深后来每次配置防火墙我都会在默认的checklist里加一项“确认IPv6白名单”。5.3 缓存命中率上不去或者APO一直不生效我经常被问的一个问题是“为什么我设置了缓存规则但缓存命中率依然只有10%”这时我第一句话永远反问你的页面上有没有设置Cache-Control响应头如果没有Cloudflare默认会按照自己的算法来决策是否缓存结果就是大部分HTML页面不会被缓存只有带明确缓存标记的静态资源才会命中。解决方式是在源站Nginx里给静态资源明确加上Cache-Control: public, max-age31536000同时在动态页面设置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说明被判定为动态请求。server显示cloudflare说明已经走在边缘网络上。cf-ray有值说明请求确实穿过了Cloudflare的节点。SSL_VERIFY状态如果没有报错说明回源链路证书校验成功。如果cf-cache-status一直是MISS请先检查你的页面规则是否将路径排除在了缓存之外再检查源站响应头是否设置了no-cache。多数情况都出在这两个点上。6. 我的实操体会与后续扩展建议整套环境从零到跑通我个人的体感是这样的真正花时间的地方不是“点面板按钮”而是理解每一条配置背后到底在“信任谁”“防住谁”。Cloudflare不是代理你的域名而是在你源站前面起了一层“保护壳”。你必须先让源站默认不信任所有请求然后从边缘到源之间建立一条仅属于你自己的可信通道这套体系才算真正搭起来。在后续扩展上如果你跑的业务规模上来了我建议再补两块内容。一个是在多台源站机器前挂负载均衡器Cloudflare有Weighted Load Balancing功能可以按权重把流量分发到不同区域实现高可用。另一个是启用Logpush或Workers来定期分析访问日志把缓存命中率、5xx错误率、回源失败次数收集成趋势图提前发现潜在问题。最后分享一个很实用的小技巧每次修改完Cloudflare面板规则之后尽量用“无痕窗口 时间戳参数”访问页面。比如在URL后面加上?v20250101做测试时可以强制绕过边缘缓存。这个小习惯能让你少掉很多头发——尤其是调试静态资源更新问题时。