仅欧洲替代方案 Cloudflare.

Cloudflare is the most US-exposed vendor in most "EU" stacks because it sits in front of the user - every visitor connects to a Cloudflare edge server before reaching your origin. The EU regions of Cloudflare are EU-located edges, but the parent company is a Delaware corporation with US-controlled key material and US-controlled traffic logs. For Schrems II purposes, Cloudflare in front of personal-data traffic is one of the most defensible problems to remove first, because the alternatives - Bunny.net (SI) and KeyCDN (CH) - have comparable feature sets and dramatically simpler legal stories.

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

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

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

驻留

数据物理存储在哪里?

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

次级处理者

您的数据路径中还有谁?

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

司法管辖区

哪些法律可以强制披露?

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

密钥托管

谁实际持有加密密钥?

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

失败 AWS · Azure · GCP · EU 区域

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

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

通过 Binadit 托管技术栈

四项全部通过。

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

为什么团队正在退出 Cloudflare

The pattern we see: a privacy or DPO review identifies Cloudflare as a US subprocessor that processes every visitor request including IP addresses, browser fingerprints (via Bot Management) and cookies. Under Schrems II that is a transfer that needs supplementary measures - typically encryption that Cloudflare cannot read, which defeats the WAF and Bot Management features that were the reason for using Cloudflare. The simpler answer is to swap to an EU-jurisdictional provider where the legal analysis collapses to "no transfer." Bunny.net is the standard target and the migration is genuinely a few hours of DNS and configuration work.

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. Days 1-3

    Inventory & risk-rank

    List every Cloudflare product in use: CDN, DNS, WAF rules, Workers, Pages, R2, Tunnel, Access. Map each to a personal-data exposure (does it touch PII?) and migration complexity. Output: priority list, usually CDN/DNS first.

  2. Days 4-10

    Soft swap (CDN, DNS, R2)

    Provision Bunny pull zones for the same hostnames. Test with a staging hostname. Cut DNS over with low TTL pre-stage. R2 → Bunny Storage migration via parallel-write. WAF rules ported manually to Bunny WAF.

  3. Weeks 2-6

    Hard pieces (Workers, Tunnel, Access)

    Worker code reviewed and either ported to Bunny Edge Scripting, rewritten as origin-side middleware, or self-hosted on Knative. Tunnel replaced with Netbird or self-managed Wireguard. Access replaced with Pomerium or Authelia. Pages workloads moved to GitLab Pages or self-hosted.

Cloudflare-to-Bunny migrations almost always reduce monthly spend by 40-70% at typical mid-market volumes. The exceptions are Workers-heavy stacks (where the equivalent self-hosted infrastructure has higher fixed cost) and high-traffic Pages stacks (where Cloudflare's aggressive free tier is hard to match).

常见问题

查看所有常见问题

Cloudflare has EU-only data plans now - does that solve it?
Cloudflare's "Data Localization Suite" can keep EU traffic on EU edges and EU keys, which addresses residency. It does not address jurisdiction: Cloudflare Inc. remains a US corporation subject to the CLOUD Act. For most Schrems II analyses, the data-localization product is an improvement but not full sovereignty.
Will switching CDN affect performance for European visitors?
For European users specifically, Bunny.net often performs equal or better than Cloudflare because their EU POP density is higher per-traffic. Real-world tests on e-commerce migrations have shown TTFB improvements of 10-30ms for EU-specific traffic. For global users (US, APAC), Cloudflare's POP count is larger.
How do we handle Cloudflare Workers replacement?
Three patterns depending on the Worker: (1) trivial request rewrites move to Bunny Edge Scripting unchanged, (2) Workers that talk to KV / Durable Objects need a re-architect - typically the logic moves to the origin and uses Redis or Postgres, (3) Workers acting as API endpoints become small Knative services on EU infrastructure.
Is Bunny.net a real Schrems II-safe alternative?
Bunny.net is BunnyWay d.o.o., headquartered in Ljubljana, Slovenia (EU member). The legal entity is fully under EU jurisdiction. Their published subprocessor list is short and EU-focused. For Schrems II, the analysis collapses to "no third-country transfer" which is materially easier than Cloudflare's data-localization story.
What about Fastly or Akamai?
Both US-headquartered. Fastly is San Francisco; Akamai is Cambridge, MA. Same CLOUD Act analysis as Cloudflare. They are not Schrems II-easier than Cloudflare; they are different US providers with different feature sets.
How long does a Cloudflare migration take?
For a typical workload (CDN, DNS, basic WAF, no Workers): 1-2 weeks elapsed. For a Workers-heavy or Tunnel-dependent setup: 4-8 weeks. We can run the whole thing as a managed migration if you want it done without burning your team's capacity.

规划您的退出 Cloudflare.

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

预约通话 对比其他服务商