仅欧洲替代方案 Cloudflare.

在大多数“EU”技术栈中，Cloudflare是暴露给美国司法管辖权风险最大的供应商，因为它位于用户之前 - - 每个访问者在到达你的源站之前都会先连接到Cloudflare的edge server。Cloudflare的EU区域指的是位于EU的edge节点，但其母公司是一家特拉华州公司，密钥材料和流量日志均由美方控制。就Schrems II而言，去除Cloudflare对个人数据流量的前置处理，是最容易站得住脚、应当优先解决的问题之一，因为替代方案 - - Bunny.net（斯洛文尼亚）和KeyCDN（瑞士）- - 功能集相当，但法律层面简单得多。

美国 仅限 EU 的替代技术栈 11 已梳理的服务
预约通话 先扫描您的域
供应商
Cloudflare
总部
San Francisco, CA
司法管辖区
美国
法律制度
CLOUD Act, FISA 702, EO 12333

"欧盟区域"不等于主权。四个问题决定一切。

数据驻留告诉你数据存放在哪里。主权则告诉你哪个法律体系可以强制访问。这四点的答案必须都成立 - 否则该技术栈就不具备主权性。

驻留

数据物理存储在哪里?

不只是笼统的“在云端” - 而是具体在哪个数据中心、哪个国家、受哪种司法管辖。

次级处理者

您的数据路径中还有谁?

每一个接触数据的供应商:CDN、邮件中继、错误追踪、分析管道。

司法管辖区

哪些法律可以强制披露?

总部位于美国的提供商受 FISA 702 和 CLOUD Act 管辖 - 即使数据存放在法兰克福也不例外。

密钥托管

谁实际持有加密密钥?

如果云服务商同时持有数据和密钥，无论签订何种 DPA，数据对其而言都是可读的。

失败 AWS · Azure · GCP · EU 区域

在司法管辖权和密钥托管上失败。

欧盟数据、美国母公司、默认路径中的美国次级处理者、供应商管理的密钥。

通过 Binadit 托管技术栈

四项全部通过。

托管在欧盟、由欧盟总部基础设施提供。默认路径中零美国次级处理者。客户持有或欧盟 KMS 密钥。在您的第 28 条 DPA 中按名称列出。

为什么团队正在退出 Cloudflare

我们常见的情况是：隐私或 DPO 审查发现 Cloudflare 是一个美国分包处理方，会处理每一次访客请求，包括 IP 地址、浏览器指纹（通过 Bot Management）和 cookies。根据 Schrems II 判决，这属于需要补充措施的数据传输，通常是采用 Cloudflare 无法读取的加密方式，但这样一来又会削弱使用 Cloudflare 的初衷所在的 WAF 和 Bot Management 功能。更简单的解决方案是切换到司法管辖属于欧盟的供应商，这样法律分析就简化为“无需传输”。Bunny.net 是标准的迁移目标，迁移工作实际上只需几个小时的 DNS 和配置调整。

Cloudflare 服务及其仅欧盟等效方案

迁移不是"换一个盒子"。下面的映射是我们为离开以下平台的客户运行的 Cloudflare 基于 Schrems II 的考量 - 完全适用欧盟司法管辖，数据链路中不涉及美国母公司。

Cloudflare CDN

我们改用什么
我们为您部署并运维欧盟 CDN：Bunny.net 或 KeyCDN，并在源站使用 Nginx 和 Varnish 进行缓存。
工程说明
CDN 是我们少数不自行运行的层级之一。我们会选定 EU 提供商，配置缓存头、清除策略和源站防护，并将其作为托管服务的一部分进行运维。

Cloudflare WAF

我们改用什么
Binadit 托管云平台。Coraza 或 ModSecurity 配合 OWASP Core Rule Set，并使用 CrowdSec 进行行为拦截。
工程说明
规则会根据你的实际流量进行调优，而非直接套用默认规则集，这正是防止 WAF 悄悄拦截真实客户的关键。

Cloudflare DDoS protection

我们改用什么
Binadit Private Infrastructure。上游流量过滤，在应用边缘配合限速与 CrowdSec。
工程说明
流量型攻击在到达您的服务器之前就会被上游吸收。应用层滥用行为则在能够真正被理解的地方处理，即紧邻您的流量之处。

Cloudflare DNS

我们改用什么
Binadit 托管云平台。PowerDNS 或 Knot，权威 DNS，经 DNSSEC 签名。
工程说明
Zone 以标准 zone 文件形式导出和导入，因此这通常是迁移中最平稳的部分。请提前一周降低 TTL。

Cloudflare R2 (storage)

我们改用什么
Binadit 托管云平台。MinIO 或 Ceph RGW，兼容 S3。
工程说明
R2 的零出口流量费用是其独有优势；不过在欧盟提供商处，出口流量通常也是免费或费用极低的，因此这一成本优势依然适用。

Cloudflare Workers

我们改用什么
Binadit 托管云平台。在您的 Kubernetes 集群上运行 Knative 或 OpenFaaS。
工程说明
我们迁移的大多数函数最终都只是小型 HTTP 处理程序，可以作为普通容器顺利运行，通常成本更低，也没有冷启动问题。

Cloudflare Pages

我们改用什么
Binadit 托管云平台。由 Nginx 提供构建资产服务，通过 GitLab CI 部署。
工程说明
Pages 的主要价值在于构建流水线；这部分将转移至您的 CI 提供商。

Cloudflare Tunnel (Argo)

我们改用什么
Binadit 托管云平台。WireGuard 隧道，或在您自己的 DMZ 中部署 Nginx 反向代理。
工程说明
Netbird 总部位于德国，提供具有欧盟司法管辖权的“无公共 IP”方案。Wireguard 自行托管是标准的主权解决方案。

Cloudflare Access (zero trust)

我们改用什么
Binadit 托管云平台。WireGuard 配合 Keycloak 或 Authentik，置于内部服务之前。
工程说明
对于仅供内部使用的应用，在欧盟基础设施上部署 OIDC 保护的反向代理在功能上是等效的。

Cloudflare Stream (video)

我们改用什么
在Binadit基础设施上使用FFmpeg进行转码，并通过欧盟CDN（如Bunny.net）进行分发。
工程说明
转码是一种批处理工作负载，运行在您已拥有的算力资源上。分发则通过我们为您配置的CDN以常规HTTP方式完成。

Cloudflare Bot Management

我们改用什么
Binadit 托管云平台。使用 CrowdSec 进行行为检测，在边缘节点实施限速和验证页面。
工程说明
CrowdSec 总部位于法国，能力持续增强。对于高流量电商场景，DataDome（同样总部位于法国）是企业级替代方案。

我们如何迁移离开 Cloudflare

典型的中端市场迁移分为三个阶段进行。以下数据假设工程团队规模为 6-10 人，应用程序技术栈复杂度中等。

  1. 第 1-3 天

    清点与风险分级

    列出所有正在使用的 Cloudflare 产品：CDN、DNS、WAF 规则、Workers、Pages、R2、Tunnel、Access。将每一项与个人数据暴露风险（是否涉及 PII）及迁移复杂度对应起来。输出结果：优先级列表，通常 CDN/DNS 排在最前。

  2. 第 4-10 天

    软切换（CDN、DNS、R2）

    为相同的hostname配置Bunny pull zones。使用staging hostname进行测试。以低TTL预先配置完成DNS切换。通过并行写入方式完成R2 → Bunny Storage迁移。WAF规则手动移植至Bunny WAF。

  3. 第 2-6 周

    难点部分（Workers、Tunnel、Access）

    Worker代码经过审查后，将被移植到Bunny Edge Scripting、重写为源站中间件，或自托管于Knative。Tunnel替换为Netbird或自管理的Wireguard。Access替换为Pomerium或Authelia。Pages工作负载迁移到GitLab Pages或自托管方案。

从Cloudflare迁移到Bunny，在典型的中端市场流量规模下，几乎总能将月度支出降低40%-70%。例外情况是重度使用Workers的技术栈（其等效的自托管基础设施固定成本更高），以及高流量的Pages技术栈（Cloudflare激进的免费套餐很难被超越）。

常见问题

查看所有常见问题

Cloudflare现在有仅限EU的数据方案 - - 这能解决问题吗？
Cloudflare的“Data Localization Suite”可以将EU流量保留在EU的edge节点和EU密钥上，这解决了数据驻留（residency）问题，但并未解决司法管辖权问题：Cloudflare Inc.仍是一家受CLOUD Act管辖的美国公司。就大多数Schrems II分析而言，该数据本地化产品是一种改善，但并非完全的主权可控。
更换CDN会影响欧洲访客的性能吗？
对于欧洲用户而言，Bunny.net 的表现通常与 Cloudflare 相当甚至更优，因为其在欧盟范围内的 POP 密度按流量计算更高。电商迁移的实际测试显示，针对欧盟流量，TTFB 提升了 10-30 毫秒。而对于全球用户（美国、亚太地区），Cloudflare 的 POP 数量更多。
我们如何处理 Cloudflare Workers 的替换?
根据 Worker 的类型，共有三种模式：（1）简单的请求改写可直接原样迁移至 Bunny Edge Scripting；（2）与 KV / Durable Objects 交互的 Worker 需要重新架构，通常将逻辑迁移到源站，并使用 Redis 或 Postgres；（3）作为 API 端点的 Worker 则转为部署在欧盟基础设施上的小型 Knative 服务。
Bunny.net是一个真正符合Schrems II安全标准的替代方案吗？
Bunny.net 即 BunnyWay d.o.o.，总部位于斯洛文尼亚卢布尔雅那（欧盟成员国）。该法律实体完全受欧盟司法管辖。其公开的次级处理商列表简短且以欧盟为中心。就 Schrems II 而言，分析可简化为“不涉及第三国传输”，这比 Cloudflare 的数据本地化情况要简单得多。
Fastly 或 Akamai 怎么样？
两者总部均位于美国。Fastly 位于旧金山；Akamai 位于马萨诸塞州剑桥市。与 Cloudflare 相同的 CLOUD Act 分析适用。它们并不比 Cloudflare 更容易通过 Schrems II 审查；它们只是功能集不同的其他美国供应商。
Cloudflare 迁移需要多长时间?
对于典型工作负载(CDN、DNS、基础 WAF,不含 Workers):耗时1-2周。对于重度依赖 Workers 或 Tunnel 的场景:4-8周。如果你希望在不占用团队精力的情况下完成迁移,我们可以以托管迁移的方式全程负责。

规划您的退出 Cloudflare.

30 分钟范围确定通话。我们将您的技术栈映射到仅欧盟替代方案,估算迁移工作量,并告诉您这是否是正确的选择。

预约通话 对比其他服务商