内容分发网络位于网站前端，请求先抵达其边缘服务器，由它提供缓存、终止TLS、过滤流量并回源，这意味着它是共享依赖。笔者查阅了密码线索（CipherCue）追踪的欧洲公司，在检测到CDN的44143家企业中，39547家部署在云耀（Cloudflare）之后，占比89.6%。作为参照，W3技术（W3Techs）截至2026年7月28日的数据称云耀在可识别反向代理中占84.1%。此次仅统计实际运行CDN的公司。

内容分发网络（CDN）位于网站前端。请求先到达 CDN 的边缘服务器，由后者提供缓存内容、终结 TLS、过滤流量，再把其余请求转发回源站。这意味着 CDN 是一个共享依赖：一旦它宕机，后面的每个网站都会同时宕机，无论这些网站之间还有什么其他不同。

我检查了 CipherCue 追踪的欧洲公司，看它们的网站由哪家 CDN 提供服务。在检测到使用 CDN 的 44,143 家公司中，39,547 家使用 Cloudflare，占比 89.6%。

作为参照，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

Amazon 以 3,112 家位居第二，但这个数字需要说明。我们通过 CloudFront 检测 Amazon，而 Amazon 同时也是综合云主机商，所以其中有些公司的源站恰好放在 AWS 上，并非有意选择 CloudFront 作为入口。Fastly 没有这种歧义，它是纯粹的 CDN，以 1,299 家位居第三，大约是每三十家 Cloudflare 客户对应一家 Fastly 客户。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 日，约 11:20 至 17:06 UTC。一次数据库权限变更导致 Bot Management 功能文件被重复条目填满、体积翻倍，超过代理执行的上限，导致核心 CDN 和安全服务崩溃。Cloudflare 的报告称这次宕机“不是由任何形式的网络攻击或恶意活动直接或间接造成的”（blog.cloudflare.com）。
• 2025 年 12 月 5 日。在缓解一个影响全行业的 React Server Components 漏洞时所应用的配置变更导致全球中断（Cloudflare outage postmortems）。
• 2026 年 2 月 20 日，自 17:48 UTC 起持续 6 小时 7 分钟。一个清理自动化任务将错误的 API 响应解读为撤回 BYOIP 前缀的指令，25% 的前缀通过 BGP 被从互联网上撤回。Cloudflare 再次声明“不是由任何形式的网络攻击或恶意活动直接或间接造成的”（blog.cloudflare.com）。

三起事件没有一起是攻击。一个翻倍的配置文件、修补别人漏洞时做的一次变更、一次删了太多东西的清理任务：这些都是日常内部工作，却触及边缘节点并带垮了大量网站。上表中的公司在 11 月 18 日不需要有任何共同点就一起离线了——共享同一道前门就够了。

这不是说 Cloudflare 做事马虎。Fastly 和 Akamai 也会出类似的问题；只是它们的问题影响的网站少得多，因为它们背后的网站少。这正是关键所在。当一家供应商占据市场大部分份额时，它的错误就不再只是它自己的问题，而是同时变成所有人的问题。

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。带 Fastly 缓存节点的 x-served-by 表示 Fastly。x-amz-cf-id 表示 Amazon CloudFront。没有此类头，且 server 值指向你自己的 Web 服务器或源站主机，通常意味着前面没有 CDN。

方法说明

来源与队列： CipherCue 自己对欧洲公司网站的观测数据（HTTP 响应指纹识别和 DNS），不是第三方数据集。队列是我们追踪的实体集合中，国家归属为德国、英国、荷兰、波兰、法国、意大利、西班牙或爱尔兰之一、且至少检测到一个 CDN 组件的公司。截至 2026 年 9 月 7 日每家公司的最新观测，得到 44,143 家公司。这是我们数据集内的公司计数，不是对这些国家所有公司的代表性抽样，也不涉及完全不用 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 自己发布的事后报告，已在文中注明出处。时间和持续时长以 Cloudflare 表述为准。我们直接链接原始来源，而非转述二手报道中的数字。

国家分组 是我们自己的选择，并明确说明，以便分国表格可以独立阅读；总数字是这八个市场的并集，而非单一国家。

在你自己的市场中查找

CipherCue 按公司追踪 CDN、主机、邮件和 DNS 基础设施，可按厂商、国家和行业筛选。如果你在上述类别中销售欧洲替代品，目录会显示你所在市场中哪些公司目前在使用哪家现有厂商：我们检测到使用 Cloudflare 的公司列表在此，欧盟厂商目录涵盖各类别的替代选项。

社区对欧洲九成网站依赖 Cloudflare 反应分化，多数人从性价比和避责角度认可其主导地位，少数人则警惕美国监控背景并批评欧洲缺乏真正自主能力。

认可 Cloudflare 的免费与低价策略带来极高性价比和易用性

• 许多开发者和企业指出，Cloudflare 免费计划即含 DDoS 防护、域名管理等丰富功能，相比传统 Akamai 或谷歌亚马逊的复杂和高成本，小网站几分钟即可上线，即便宕机也因同行同样依赖而风险共担（认可度：较多人） > 在 Cloudflare 上用新域名建站只需几分钟，而谷歌和亚马逊的复杂流程令人尴尬（@jillesvangurp）

认为欧洲对美国技术依赖是数十年积累且难以扭转

• 多位评论者指出，四十年的技术采纳使美系架构根深蒂固，企业采购常出于避责心理“没人因买 IBM/Cloudflare 被炒”，即便有政治意愿，重建异构基础设施也需数十年且怕美方报复（认可度：较多人） > 美国对科技的统治近乎全面，即使有意愿解套也是耗资巨大的数十年工程（@noir_lord）

质疑 Cloudflare 免费模式的背后动机并警惕监控

• 部分用户提醒，免费层可能源自美国情报机构私有化监控的需求，并非善意，其拦截页面也损害体验，应追问“慷慨”原因（认可度：少数人） > 别以为 Cloudflare 的免费层出自善意，它本质上是美国政府的巨型中间人监控项目（@dakolli）

指出内容分发网络并非刚需且存在可行替代方案

• 有评论疑问为何不能自建或轻松换用其他厂商，实际有 Bunny.net、CDN77 等替代品，且欧洲内部各国采用率差异巨大，暗示许多部署可能盲目跟风而非必要（认可度：少数人） > 内容分发网络难道不是一种可以近乎无成本切换的普通商品吗（@amelius）

认为欧洲不自强而抱怨纯属自身能力问题

• 个别声音直言欧洲并非没有本土选择，却只发牢骚不投资研发，本质是技术实力与执行力的欠缺（认可度：少数人） > 欧洲自己有本土方案却不用，光抱怨美国主导不过是自身技术实力不行（@tonyhart7）

有价值的补充

• 英国在统计中约有 1.7 万站点使用内容分发网络，而人口更多的法国、德国仅 4 千和 6 千，可能反映各国技术栈保守程度或跟风文化不同。
• 过去抵御分布式拒绝服务需向 Akamai 等支付高昂费用，如今小商月付两百美元即可获得类似保护，行业价格被彻底重划。
• 有考证称美国国土安全部早年对反垃圾邮件公司的问询直接催生了 Cloudflare，说明其起源与公共安全议程相连。
• 企业采购 Cloudflare 等巨头产品常源于避责文化，类似“没人因买 IBM 被解雇”的旧谚，多数公司决策意在覆盖风险。
• 有评论者认为高效政府通常只出现在真正严重的危机中，平时低效反而令人不安，这解释了欧洲主权计算倡议难以落地。