Cloudflare CDN测评：免费方案的吸引力与中国大陆访问的现实

把域名接入Cloudflare，打开代理，图片开始出现HIT，源站流量也降下来了；海外同事觉得快，大陆用户却反馈晚上偶尔打不开。这个场景容易把讨论推向两个极端：有人认为免费方案已经足够，有人认为Cloudflare在国内完全不能用。两种判断都跳过了最重要的条件：什么用户，在访问什么内容，慢在请求的哪一段？

Cloudflare免费方案的吸引力是真实的，但基础功能免费、内容正确交付和中国大陆访问达标，需要分别证明。对公共静态内容多、海外用户占比较高、团队能够自行维护配置的网站，它有很强的试用价值。对大陆交易、预约或登录业务，不能拿海外成绩或一张命中缓存的图片作为上线依据。Cloudflare全球网络的汇总成绩，也不能直接当成免费方案在大陆的交付结论；选型最终要落到自己的域名和关键业务上。

免费方案真正省下的，是接入基础能力的门槛

Cloudflare提供的价值并不只是一份缓存。Cloudflare免费方案把网站接入基础安全与性能服务的门槛降得很低。对小团队来说，不必先分别搭建边缘代理、管理边缘证书、配置缓存再整合安全入口，可以把精力放在网站本身。这种管理上的简化，有时比一次测速领先几十毫秒更有意义。

不过，DNS托管与网站代理必须分清。按Cloudflare代理状态说明，橙云表示受支持的HTTP流量经过Cloudflare，灰云的DNS-only只是解析，不会自动获得同一条代理路径上的缓存与防护。域名使用Cloudflare的NS，并不意味着所有子域名都在使用Cloudflare CDN；网站首页、图片、API和邮件主机应逐项核对。

它也不是传统意义上的静态文件存储。接入代理后，源站仍需提供内容；缓存未命中、不可缓存业务以及需要更新的响应，都可能继续消耗源站资源。免费CDN可以降低交付负担，不能代替数据库、应用服务器和可靠的部署流程。把域名接入成功写成“整个网站已经全球加速”，会漏掉大量实际请求。

计费也要按产品拆开。Cloudflare请求链路与计费说明区分了基础带宽与Workers、存储、缓存持久化、路由等产品的计费维度。常规CDN带宽包含在方案中，不等于同一请求调用的附加服务都免费，更不等于源站云厂商不收公网出流费用。评估时应该记录实际启用了什么，而不是只看账号首页写着Free。

“免费流量”不能理解成任意内容无限分发

Cloudflare的CDN定位于网页与网站交付。其CDN媒体与大文件使用条款对Free、Pro和Business列出了视频、大文件及高占比图片、音频等内容的使用边界，涉及相应付费服务；不符合要求时，服务可能被限制。普通网页插图与把CDN当成大型图床、视频站或下载平台，不应混为一谈。

这里至少有三个不同问题：内容是否符合使用条款，单次请求是否超过技术限制，以及传输能力是否满足业务。文件能下载，并不能证明用途符合条款；小文件命中，也不能证明大文件会被缓存。上传请求大小、可缓存文件大小、回源超时和持续下载速度各自约束不同环节，不应看见一个“上限”就给上传和下载同时下结论。

因此，视频、软件镜像、用户文件和高比例媒体外链业务，应先拿内容结构与预计用量确认产品适配，再做性能试用。简单升级一个普通网站套餐，不能被当成自动消除全部媒体限制的方法。如果网站只是正常文章配图，也不需要反过来把条款理解为“一张图片都不允许”，关键在实际用途和适用服务范围。

中国大陆访问的现实：先确认使用的是哪张网络

普通全球网络与Cloudflare China Network是两个不同的接入条件。官方Cloudflare中国网络接入要求说明，中国网络由合作伙伴京东云在大陆运行部分性能和安全产品，面向Enterprise客户单独订阅；拟接入的每个顶级域名还需要有效的ICP备案或许可证。它不是免费账号打开代理后自动拥有的节点，也不是升级Pro或Business就会开启的能力。

这件事影响的是请求入口。大陆用户如果进入境外边缘，用户到边缘这段仍要经过相应跨境路径。即使响应已经HIT，缓存消除了本次取内容的回源等待，用户也仍需完成到边缘的连接与传输。缓存可以省掉后半段工作，不能凭空缩短一条已经存在的慢入口路径。这正是“命中率很好，国内体验仍然波动”能够同时成立的原因。

入口也不能只凭地理距离理解。Cloudflare关于请求未进入地理最近机房的说明涉及网络路由、互联和流量工程。不同运营商、地址族和时段可能获得不同路径；地图上离用户最近的城市，不保证是这一条连接实际进入的位置，更不保证是最稳定的路径。需要观察实际域名，而不是用节点数量推导体验。

大陆源站的位置还可能改变动态请求的账。当大陆用户进入境外边缘，而不可缓存内容又要从大陆源站取得，链路可能包含用户到境外边缘和境外边缘回大陆源站两段跨境通信。缓存静态内容仍可能有效，动态页面却未必受益。判断迁移源站能否改善体验，必须同时考虑用户入口、边缘回源、应用处理和数据依赖，不能只说“服务器离国内近”。

我们对大陆为主的商业网站更谨慎：先证明关键地区能稳定打开，再讨论免费方案节约了多少。对海外为主的网站，则可以分别接受不同地区的测试结论。大陆、港澳台和海外不能混成“亚洲”一组，电信、联通、移动也不应合并成一个全国平均值。已有的Cloudflare国内分地区与运营商测速可以承接具体采样方法，本篇进一步把这些结果对应到采购和架构决策。

缓存收益有多大，取决于网站真正可以共享什么

Cloudflare的默认缓存行为主要依据文件扩展名判断资源资格，HTML和JSON默认不缓存。于是一个WordPress站可能图片、CSS和JS已经命中，首页HTML仍访问源站；一个SaaS前端资源很快，账户查询却继续等待数据库。免费CDN接入后源站压力没有明显下降，不一定是网络没有作用，也可能是主要请求没有进入共享缓存。

测评前可以把请求分成三组：版本化公共资源、允许短时共享的公共HTML或接口、用户专属业务。第一组适合充分利用缓存；第二组需要明确内容新鲜度与更新方式；第三组首先保证权限和隔离。页面由程序生成，并不必然不能缓存；文件看起来静态，也不代表可以忽略它是否返回用户身份信息。

缓存键决定哪些请求会被视作同一个对象。商品筛选参数、语言、货币、登录状态如果影响响应，就不能随意忽略。忽略所有查询参数可能把不同商品结果混在一起；保留无关的营销追踪参数又可能形成大量缓存副本。正确做法是先列出影响内容的变量，再检查当前套餐可用的规则和实际响应，不能从别人的配置截图推断自己具备同样的能力。

尤其不要用一条覆盖全站的强制缓存规则去换漂亮的HIT比例。用户中心、购物车、后台和带授权信息的下载，都需要独立验证。依据共享缓存与私有响应配置区分可存储范围，再用两个授权账号、匿名状态及退出登录后的请求检查内容隔离。发现跨用户内容串用时，性能试用应停止，先修正规则并处理既有对象。

命中率还要分请求与字节。大量小图标命中可以提高请求命中率，却未必省下大图片占用的出流。发布流程同样重要：长缓存适合内容变化就更换URL的资源，不适合不断覆盖的入口文件。边缘刷新也不等于用户浏览器中的旧副本立即消失；如果更新依赖频繁全站清缓存，要把重填期间的源站峰值纳入成本。

怎样判断慢在入口、回源，还是页面自身？

CF-Cache-Status缓存状态可以帮助拆开请求：HIT表示缓存提供了对象，DYNAMIC通常表示请求没有获得缓存资格，BYPASS对应响应阶段未缓存，REVALIDATED涉及向源站验证。DYNAMIC并不等于配置错误，账户接口保持动态可能正是正确行为。Age只能辅助解释对象年龄，也不能用来推算它还会在缓存中保留多久。

Cloudflare的官方缓存文档会区分不同配置下的行为，因此不要把no-cache简单当成绝不存储，也不要只凭Set-Cookie判断所有强制缓存规则都安全。边缘未命中与企业源站实际收到请求，也需要在分层缓存、Workers等架构下核对。客户端状态、源站日志和当前配置是三个证据面，缺少后两者时最多给出定位方向。

这张表用于缩小范围，不用于直接定责。即使HIT请求慢，仍可能存在边缘代码、额外处理或传输问题；即使源站直连快，也不能自动证明Cloudflare回源慢，因为两次测试未必走同一路径。要把请求时间、缓存状态、配置版本和业务处理记录关联起来，才能对调整方案作出有根据的选择。

升级付费之前，先问购买能力能改变哪段请求

Pro、Business和Enterprise增加的能力，需要对照实际产品与合同；升级本身不是“中国大陆变快”的技术机制。更细的安全控制、更多规则和更好的支持渠道可能很有价值，但这些价值与大陆用户是否进入境内网络是不同问题。如果销售建议升级，应要求明确交付路径变化、功能范围与验收对象，而不是只承诺“优先线路”。

例如Argo Smart Routing回源优化已纳入Smart Shield相应产品组合，重点在Cloudflare到源站的网络传输。它值得用于验证MISS和不可缓存请求的网络等待，却不应被理解为免费套餐转付费后自动获得大陆节点，也不能承诺消除用户到境外边缘的所有问题。数据库处理占主要时间时，它改善的空间还会受到应用瓶颈约束。

付费试用应该设置一组可解释的对照：保留免费基线，在相同地区、URL、缓存条件、源站和业务版本下，仅改变拟购买的能力。若同时换源站、延长TTL、压缩图片再打开路由优化，就无法知道哪项投入起了作用。对已经HIT的资源，不要用几乎不回源的样本证明回源优化收益；对安全产品，则看合法请求是否被正确处理及规则是否够用。

因此，升级门槛可以很具体：源站网络等待占比高且对照测试有改善，才继续评估路由功能；免费规则无法表达业务例外，才研究更合适的安全控制；排障资料或支持渠道不足，才把相关服务纳入合同。若目标地区连接仍不达标，应该比较交付架构，而不是在普通套餐之间反复试错。

免费安全能力值得利用，也要检查它如何对待正常用户

“免费不安全”和“开了Cloudflare就不用管安全”同样不准确。按Cloudflare托管WAF规则范围，Free Managed Ruleset保护部分高影响、广泛被利用的漏洞；完整Cloudflare Managed Ruleset与OWASP规则集的可用性则取决于套餐。产品名称包含WAF，不代表所有规则、检测范围、例外控制和日志能力都一样。

评估安全时，要同时看恶意流量处理和合法业务完成。共享出口上的正常用户、移动应用、支付回调、第三方Webhook和监控程序，各有不同访问特征。挑战页面可能适合交互式浏览器，却可能打断无法完成验证的API客户端。排查需要确认是哪项安全功能、哪条规则、哪个条件触发，不应一看到访问失败就归结为大陆线路。

一个具体例子是Bot Fight Mode的例外限制：它可能挑战API或移动应用流量，且不能通过普通WAF自定义规则或Page Rules的Skip来跳过。遇到这类问题，继续堆一条“允许规则”可能并不起作用。应识别产品执行机制，选择能够满足例外需求的策略或产品，而不是长期关闭整站防护。

源站自身仍须保证认证、补丁、访问控制与回源安全。生产HTTPS可以按Full (strict)回源证书验证的条件准备有效证书、匹配的域名和端口；浏览器连接有HTTPS，不应被当作已经验证了另一段回源。源站允许哪些流量、如何防止绕过代理，也要单独设计。这里不需要对他人网站发起攻击，只需用授权测试验证自己的配置与正常业务。

Cloudflare CDN测评：先过两道门槛，再算三本账

CDNChart建议先设两道门槛：第一道是交付正确，第二道是关键用户可用。账户内容不能串用，发布不能长时间返回错误版本，核心操作不能被挑战拦断；这些没通过，命中率和免费带宽都不能补偿。正确性通过后，再检查目标地区的页面、登录、搜索或下单能否在业务约定的等待范围内稳定完成。阈值应由业务在测试前确定，不能测完再挑好看的指标。

过了门槛，再看三本账：体验账记录各地区的等待、长尾和失败；源站账记录实际请求、出流与峰值；运维账记录配置复杂度、排障耗时、附加服务与回滚能力。一个免费方案可能明显省源站流量，却没改善大陆首访；也可能缓存收益一般，但整合管理很有价值。把这些收益分开，才能看清保留、升级或替换的理由。

试用基线应是现有生产交付方案，而不只是一个人为暴露的源站。先冻结内容版本、缓存策略和安全规则，准备公共HTML、版本化静态资源、代表性图片及关键动态接口。公开测速不能完成登录身份与业务校验，动态流程需要测试账号；订单或支付则在安全测试环境验证，不用真实交易来试配置。

采样先按真实用户分布安排重点地区，再拆电信、联通、移动，以及家庭宽带、手机网络和地址族。云服务器探针只能代表那个出口，不能替代居民宽带。海外地区按用户国家单独取样，大陆高峰与用户投诉时段增加观察。已有浏览器缓存和首次访问也要区分，否则老用户的快速结果会掩盖新用户连接失败。

每条记录保留测试时间与时区、URL、网络环境、响应IP、状态码、协议、缓存状态、响应大小和各阶段耗时；能取得时再补入口线索、Ray ID与源站处理耗时。缓存状态与入口不同的样本分别统计，不拿预热后的HIT与对照方案的MISS直接比较。一个规则变更后出现的进步，应明确是配置优化还是产品能力改变。

可以用多地区网站测速初步观察公开URL的响应IP、状态码和访问耗时，再以受控客户端、浏览器观测与服务端记录补充诊断。工具没有输出的缓存、入口或业务字段不能自行推断；它也不能代替登录流程、完整页面渲染、合同验收或负载测试。分工清楚，结果才不会被扩大解读。

正式报告同时呈现尝试次数、业务成功次数、超时、证书错误、安全拦截和业务错误，再报告成功请求的P50、P95。P50用于观察典型等待，P95用于观察靠近较慢一端的请求，但二者都不能代替失败比例。只跑少量请求不足以解释稳定的尾部表现，应该扩大到覆盖相关时段的样本，并标明样本数。不同地区的分位数不能直接平均；全球汇总也不能让海外成功样本掩盖大陆某个关键网络持续失败。

若需要汇总业务影响，可以用真实用户占比对分组失败率加权，但每组结果必须保留，关键地区还应有独立门槛。真实用户监控也有缺口：页面或采集脚本没加载出来的访问，可能根本没有留下记录。因此不能只看到已采集页面的体验很好，就认定所有用户都能打开；主动探测、投诉记录与业务日志应共同补足失败证据。

三个检查，帮助把“国内慢”缩小为具体问题

下面命令只适用于有权限测试的域名，示例需替换。按Linux/macOS写；Windows PowerShell使用curl.exe，并将/dev/null换成NUL。它们用于低频诊断，不是压测。第一条采用固定IPv4与HTTP/1.1便于分段比较；实际浏览器使用的协议与连接复用，需要另设测试组。

curl -4 --http1.1 --compressed -sS --connect-timeout 8 --max-time 30 -D - -o /dev/null -w "\nstatus=%{http_code} ip=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total} bytes=%{size_download}\n" "https://www.example.com/assets/app.v1.js"

固定URL重复执行，记录CF-Cache-Status、Age、CF-RAY、Cache-Control、Content-Encoding和响应大小。首次请求不必然是MISS，重复请求也不保证每次HIT；按实际状态分组，不添加随机参数制造无法复用的缓存键。命令丢弃正文，只能检查响应头与计时，另用安全的内容校验确认取到的是预期资源；同时保留curl退出码，不能把连接失败输出的状态000当成HTTP响应。

按curl累计计时字段的定义，在无代理、无跳转的新建HTTPS连接中，TCP阶段可近似用connect减dns，TLS用tls减connect，下载用total减first_byte。first_byte减tls仍包含请求发送、边缘处理和可能的回源等待，不是纯源站处理时间。超时上限只是本次测试的观察条件，不是Cloudflare的服务承诺；若URL跳转，应逐跳核对，不直接混算阶段。

curl -4 -sS --max-time 15 "https://www.example.com/cdn-cgi/trace"

Cloudflare入口诊断端点可以提供当前请求的colo等线索。它用于看入口，不会访问你页面的全部依赖，也不证明账户接口已经变快。替换为-6可以单独检查具备IPv6条件的测试网络，但要保留不支持IPv6、解析失败与连接失败的区别；输出中的客户端IP等信息应脱敏后分享。

再结合CF-RAY与机房代码的含义检查记录。启用Argo或分层缓存时，部分Ray信息可能对应连接源站的机房，不能仅凭后缀把它当成全国用户入口；需要与诊断端点和可获得的日志相互核对。普通IP归属地标签也不能独立证明物理服务器位置。

curl -4 --http1.1 --compressed -sS --connect-timeout 8 --max-time 30 --resolve www.example.com:443:203.0.113.10 -D - -o /dev/null -w "\nstatus=%{http_code} first_byte=%{time_starttransfer} total=%{time_total}\n" "https://www.example.com/assets/app.v1.js"

最后一条用于获准环境下的源站对照，保留相同URL、Host和TLS SNI，不用HTTPS直接访问裸IP。若源站只允许CDN回源，不要临时开放全网；使用管理员已有的测试路径。源站证书若依赖专用CA，应按可信流程配置对应CA，不能加-k跳过验证。测试机直达源站也不等于Cloudflare回源路线，两者只辅助定位，结论仍要结合源站日志与配置。

把免费方案放进总成本，而不是只比较月费

第一项是源站实际节省。假设一组符合条款的公共静态内容，每月向用户交付600GB，字节命中率为80%，在简化模型下，未由缓存覆盖的传输约为120GB。这只是解释模型，不是Cloudflare或CDNChart实测，也未计入重新验证、缓存重填、压缩差异及其他动态内容。最终应核对源站出流与账单，不能把请求命中率直接代入流量公式。

第二项是附加能力与维护投入。同一个网站可能同时使用路由优化、图片处理、Workers或存储，而不同产品各有计量方式。不能因为公共资源HIT，就假设前置边缘代码不会执行或不会计费；应看具体调用路径。还有证书维护、规则回归、误拦截处理和迁移脚本，这些没有出现在免费套餐账单上，却可能占用团队很多时间。

第三项是故障处理条件。按Cloudflare技术支持范围，Free主要依靠社区处理技术问题，标准工单限于账单、账号及注册商等事项；普通技术工单、聊天和紧急电话的可用性随套餐不同。不能把“账号问题可以提交工单”写成“免费网站故障随时有人工接手”，也不要把支持首次响应与业务恢复时间混为一谈。

采购还应逐项确认日志字段、采样方式、保留时间、导出权限和告警渠道。控制台里的汇总图不等于能检索任意一条失败请求，暂时没有看到事件也不证明从未误拦截；需要留存怎样的证据，应由业务排障与审计要求决定。

对低风险内容站，团队自行排障可以接受，免费方案的成本优势往往容易体现。对广告落地、付费订阅、预约与交易业务，受影响的可能是用户完成操作的机会，而不仅是服务器费用。不要凭空给访问失败估算转化损失，但应使用自己的业务记录核对：免费省下的支出，是否被长尾故障、人工排查或关键地区流失抵消。

哪些网站值得采用，哪些应该保留其他交付方案？

海外文档、开源项目主页、作品集和以公共内容为主的网站，通常值得先用免费方案验证。带版本的静态资源容易管理，个性化请求少，团队也更容易保持缓存正确。海外企业展示站也可以从它开始，但表单、询盘和依赖服务必须实际验证；网站流量小，不代表一次故障的业务影响小。

海外SaaS、电商和会员业务并非不能使用Cloudflare，而是不能只验收静态文件。免费基础接入可以作为起点，后续是否保留取决于动态路径、安全例外、可观测性与支持要求。对中国大陆为主、需要稳定获客或关键操作成功的业务，CDNChart更建议同时比较合适的境内交付方案；如果要采用China Network，就按独立接入、产品范围和合同逐项验收。

国内外用户都重要时，可以评估分区域交付或多CDN，而不必坚持所有流量只走一家。但两条路径需要统一源站身份、证书、缓存新鲜度、刷新机制和安全规则；DNS切换也受缓存与客户端行为影响，不能被当成瞬间且完整的故障转移。用于切换的健康检查，还必须能反映真实入口和关键业务，而非只证明源站上的一个空接口返回200。

不要随意把其他CDN串在Cloudflare前后就称为“国内优化”。串联可能增加回源层级、重复缓存、真实IP还原与TLS配置问题，具体架构应取得相关产品支持并完整验证。网上流传的“优选IP”也可能随运营商和时段改变，不具备合同保障；一次更快不等于可维护的长期方案，更不应因此改变权威DNS或暴露源站而不做回归。

保留退出能力同样重要。迁移前备份DNS记录和规则清单，核对DNSSEC、邮件记录、证书与新路径的源站访问权限。尤其要理解Cloudflare Origin CA的信任范围：这类证书用于Cloudflare到源站，不是浏览器普遍信任的公开证书；直接改成DNS-only可能导致用户看到证书错误。所谓“随时关掉代理回滚”，必须先验证回退路径真正可用。

最终，Cloudflare厂商表现参考适合初筛与观察指标口径，不能单独证明你的免费域名在大陆三网达标；厂商汇总也不等于免费方案专项结果。一个有价值的测评结论应能说清楚：哪些用户和资源通过了验证，哪些问题可以配置解决，哪些要求必须通过产品升级或另一种交付架构满足。

选型时还需要回答的几个问题

域名有ICP备案，免费Cloudflare就会走大陆节点吗？

不会因有备案而自动改变接入产品。备案是China Network接入条件之一，不等于已经订阅并启用该网络。应确认账户、合同和实际端点，不能从域名资料推断节点使用范围。

Cloudflare的1.1.1.1很快，能说明我的网站快吗？

不能。递归DNS服务、权威DNS与网站HTTP代理承担不同工作；测试解析器没有覆盖自己域名的缓存、回源和应用。即使解析很快，也可能在后面的连接、业务处理或资源加载阶段等待。

网页能打开，就可以把挑战访问算作成功吗？

应该按预期业务定义。用户能完成验证并取得内容，可以与无挑战访问分别记录；监控或API只拿到挑战页面，却没有取得预期响应，应计为业务未完成。测评不能把“边缘返回了一段HTML”自动当成正常业务成功。

免费方案达到要求，还需要为了“企业级”而升级吗？

没有必要仅按标签升级。如果正确性、关键地区体验、安全控制与处理条件都符合业务要求，可以保留免费方案。真正值得付费的是已经验证的能力缺口；同样，关键用户持续无法完成业务时，也不应因为月费为零而继续忽略问题。