内容分发网络（CDN）位于网站前端。请求首先到达CDN的边缘服务器，由其提供缓存内容、终止TLS、过滤流量，并把其余请求转回源站。这意味着CDN是一种共享依赖：一旦它宕机，其身后的每个网站都会一起宕机，无论这些网站之间是否还有其他共同点。
我翻查了CipherCue追踪的欧洲公司，看它们的网站由哪个CDN做前端。在我们检测到CDN的44,143家公司中，有39,547家位于Cloudflare身后。这一比例为89.6%。
在44,143家检测到CDN的欧洲公司中，89.6%位于Cloudflare身后
作为参照，W3Techs的数据显示，截至2026年7月28日，在可识别反向代理提供商的网站中，Cloudflare占84.1%（w3techs.com）。我们的89.6%采用同样的口径，即在已识别集合中的占比，而非全部网站的占比，因此两者接近；本文的欧洲口径略高一些。
我只统计了实际运行CDN的公司。如果一家公司的网站直接从自己的源站提供服务，那它根本不会出现在这些数字中。所以这不是“Cloudflare对阵整个互联网”，而是问：CDN用户选择了谁。
第一名与其他所有人
我们归类出四家CDN厂商，按各自被检测到的不同公司数量统计：
39,547
Cloudflare
3,112
Amazon
1,299
Fastly
396
Akamai
检测到各CDN厂商的不同欧洲公司数量（同一家公司可能出现在多家厂商之下）
Amazon以3,112家排名第二，但这个数字需要加个说明。我们通过CloudFront检测Amazon，而Amazon同时也是通用云主机，因此其中一些公司只是源站恰好放在AWS上，而非有意选择CloudFront作为前门。Fastly没有这种模糊性。它是纯CDN，以1,299家位居第三，大约每三十家Cloudflare用户才对应一家。Akamai是该领域最老牌的名字，以396家排名第四。
各厂商的原始计数相加会超过44,143，因为一家公司可能同时位于多家厂商身后，并在各家之下都被计入（比如Fastly做前门、AWS做源站）。这种重复计入会抬高较小厂商的总量，但不会抬高Cloudflare的份额——后者是相对于整个使用CDN的集合来度量的。
分国别来看
把八个国家合并成一张图会掩盖它们之间的差异，所以这里是按国家拆分的同一项测量。Cloudflare在其中所有国家都是多数派前门，但份额从西班牙和爱尔兰的约五分之四，到荷兰的约二十分之十九不等。
国家 | 使用CDN的公司数 | 位于Cloudflare身后 | Cloudflare份额
荷兰 7,939 7,587 95.6% 英国 17,007 15,846 93.2% 波兰 2,896 2,682 92.6% 法国 4,008 3,456 86.2% 意大利 3,661 3,126 85.4% 德国 5,715 4,650 81.4% 西班牙 2,001 1,576 78.8% 爱尔兰 792 624 78.8%
英国的绝对数量最大，一个市场内就有15,846家使用CDN的公司位于Cloudflare身后。德国在主要市场中最低，为81.4%，但仍然是五分之四。
集中的代价
公司购买CDN的部分原因就是韧性，而独立供应商的一个优势在于它们各自独立地发生故障。当一个市场的大多数都位于同一家供应商身后时，这个优势就消失了。那里发生事故，就不再是一家公司的宕机，而是大半个市场在同一当天下午一起宕机。
Cloudflare近来的事故包括：
- 2025年11月18日，约UTC 11:20至17:06。一次数据库权限变更导致一个Bot Management功能文件被重复条目填满、体积翻倍，超过了代理强制执行的限额，导致核心CDN与安全服务崩溃。Cloudflare的说明指出，此次宕机“并非由任何网络攻击或恶意行为直接或间接造成”（blog.cloudflare.com）。
- 2025年12月5日。在缓解一个影响全行业的React Server Components漏洞时应用的一次配置变更，造成了全球性中断（Cloudflare宕机复盘）。
- 2026年2月20日，自UTC 17:48起，持续6小时7分钟。一个清理自动化任务把一条有缺陷的API响应当作指令，撤销了BYOIP前缀，其中25%通过BGP从互联网上被撤下。Cloudflare再次表示，事故“并非由任何网络攻击或恶意行为直接或间接造成”（blog.cloudflare.com）。
三次事故没有一次是攻击所致。一个翻倍的配置文件、一次在给别人打补丁时做出的变更、一个删多了的清理任务：都是例行内部工作，却波及边缘节点，把大量网站一起带下线。表中的那些公司不需要任何共同点，就会在11月18日一起离线。共用同一扇前门就够了。
这不是说Cloudflare马虎。Fastly和Akamai同样会发布这样的bug；只是因为身后站点更少，事故带倒的网站也更少。这正是问题所在。当一家供应商站在大半个市场面前，它的错误就不再是它自己的问题，而是所有人同时的问题。
CDN并不是数据所在之处
这里丝毫没有涉及公司将数据存放在哪里。CDN只是前门；源服务器、数据库以及处理数据的人都在它身后，而对于GDPR或数据驻留问题，真正算数的是后端。如果改测那一端，欧洲的情况会好看一些：深入查看API子域名而非前门的人，通常会发现比我这里多得多的OVH和Hetzner。我之所以坚持只看前门，是因为它是会同时让所有人宕掉的那部分——正是上述宕机事故中发生的事情。
检查你自己的前门
你可以从响应头看出一个域名前面是哪个CDN（如果有的话）：
curl -sI https://example.com | grep -i 'server\|cf-ray\|x-served-by\|x-amz-cf-id'
出现cf-ray头或server: cloudflare表示Cloudflare。x-served-by带Fastly缓存节点表示Fastly。x-amz-cf-id表示Amazon CloudFront。没有这些头，且server值是你自己的web服务器或源站主机名，通常说明前面没有CDN。
方法说明
来源与样本： CipherCue对欧洲公司网站的自行观测（HTTP响应指纹与DNS），而非第三方数据集。样本是我们追踪实体集中，国家归属为德国、英国、荷兰、波兰、法国、意大利、西班牙或爱尔兰之一，且至少检测到一个CDN组件的公司。这给出44,143家公司，采用每家公司截至2026-09-07的最新观测。这是我们数据集内的公司数量，不是对这些国家所有公司的代表性抽样，也不是对完全不使用CDN的公司所做的断言。该样本还偏向中小企业而非大型企业，而Cloudflare的免费套餐恰恰在这一细分市场最有优势，因此请把这个数字理解为这一构成下CDN使用公司中的集中度，而非专门针对大型企业的结论。
“检测到CDN”的含义： 当响应头或服务指纹与已知CDN厂商的模式匹配时（例如Cloudflare的cf-ray头、Fastly缓存节点的x-served-by、CloudFront的x-amz-cf-id），我们将该组件归类为CDN。直接从源站提供服务且没有可识别CDN指纹的公司被排除在分母之外。隐藏了这些头的错误配置或非常规部署会被漏计。
重复计数： 一家公司可能被检测到位于多家CDN厂商身后，并在各家之下分别计入。Cloudflare份额（89.6%）是检测到Cloudflare的公司数除以所有检测到任一CDN的公司数，因此同时位于Cloudflare和Fastly身后的公司在分子和分母中各计一次。因此各厂商的原始计数之和会超过44,143。
Amazon的说明： Amazon是通过CloudFront检测到的，但Amazon同时也是通用云主机。一些Amazon检测结果是前门层面的CloudFront选择，另一些则是AWS源站服务；我们没有把两者分开，这正是我们把Fastly（毫无歧义的纯CDN）作为最接近的干净对照组单独列出的原因。
宕机细节来自Cloudflare官方的
国家分组是我们的选择，并已明确说明，以便分国家表格可以独立阅读；头条数字是这八个市场的并集，而非单一国家。
在你自己的市场中找到这类信息
CipherCue按公司追踪CDN、主机托管、邮件和DNS基础设施，可按厂商、国家和行业筛选。如果你在这些品类中销售欧洲替代方案，该目录会显示你所在市场中的哪些公司目前在使用哪家现有厂商：我们在Cloudflare身后检测到的公司列在那里，EU供应商目录则按品类列出替代方案。
免费账户
在研究本文提到的某家公司？
查看其观测到的技术栈、DNS状况、托管地理位置和变更历史。免费，无需信用卡。30秒即可完成设置。
通过邮件获取我们的基础设施研究
新的研究与分析直接送达你的收件箱。无垃圾邮件。随时可退订。