Cloudflare + DigitalOcean 集成指南 2026

在 DigitalOcean Droplet 前面放置 Cloudflare 是开发者中的常见做法，因为它隐藏了服务器的真实 IP，通过 CDN 分配负载，并提供 DDoS 保护，而无需在 DigitalOcean 一侧付出任何额外成本。本文将逐步指导您完成从 DNS 迁移、启用代理、设置 SSL 到将 Cloud Firewall 锁定为仅接受 Cloudflare 流量的各个步骤，以及常见陷阱和修复方法。

为什么在 Droplet 前使用 Cloudflare

DigitalOcean Droplets 从第一天起就直接向互联网公开一个公共 IP，这与一些自动隐藏源 IP 的 PaaS 提供商不同。这意味着任何知道您 Droplet IP 的人都可以直接发送流量，无需使用您的域名，无论是扫描漏洞、暴力破解 SSH，还是小规模 DDoS 攻击导致 CPU/带宽激增直至网站崩溃。在前面放置 Cloudflare 可以在多个层级上一次性解决这个问题。首先，它隐藏了您的源 IP——当您启用代理（Orange Cloud）时，访问者只看到 Cloudflare 的 IP 地址，而不是您 Droplet 的真实 IP，除非它通过邮件服务器或遗忘的代理子域等其他渠道泄露。其次，Cloudflare 在每个计划（包括免费层）上提供第 3/4/7 层 DDoS 保护，涵盖单个 Droplet 无法承受的容量攻击。第三，拥有全球边缘节点的 Anycast CDN 意味着泰国或东南亚用户可以更快地加载页面，即使您的 Droplet 位于 nyc1 或 ams3 等遥远地区，因为静态资产缓存在用户附近。第四，Cloudflare 为用户提供免费的 SSL/TLS，减少对 Let's Encrypt 的依赖，用于面向客户端的流量（尽管如果您想要完全严格加密，仍需要在 Cloudflare 和 Droplet 之间的证书）。第五，在边缘缓存的静态内容（如图像、CSS 和 JavaScript）直接减少了 Droplet 上的负载，允许仅有 1 vCPU/1 GiB RAM 的小型实例（起价为每月 $6）处理更多流量而无需立即升级。对于在 Droplets 上运行公共网站的团队——无论是 WordPress、Node.js 应用还是静态网站——连接 Cloudflare 是一个值得采取的步骤，如果配置正确，几乎没有缺点。

• 通过启用代理将您的 Droplet 源 IP 隐藏在普通用户之外
• 即使在 Cloudflare 免费计划上也能获得免费的 L3/L4/L7 DDoS 保护
• Anycast CDN 为泰国/东南亚用户降低延迟，即使您的 Droplet 相隔很远
• 减少您 Droplet 的 CPU/带宽负载，因为静态资产在边缘缓存

将 DNS 迁移到 Cloudflare

用户经常问到的一点是：将 Cloudflare 连接到 Droplet 的第一步是将您域名的 DNS 管理迁移到 Cloudflare。首先登录 Cloudflare 仪表板并单击添加网站，然后输入您的域名。系统会自动扫描现有 DNS 记录，无论它们存储在您的注册商还是 DigitalOcean 的 DNS 中。如果您已经通过 doctl 将 DigitalOcean 用作 DNS 提供商，可以使用命令 doctl compute domain records list yourdomain.com 导出所有记录进行比较，以验证 Cloudflare 正确捕获了每条记录，特别是电子邮件的 MX 记录（如果在迁移后消失，您域名的电子邮件会立即停止工作）。审查后，添加或更新 A 记录以指向您 Droplet 的公共 IP，并检查任何 IPv6 的 AAAA 记录。接下来，Cloudflare 提供一对格式为 aida.ns.cloudflare.com 和 walt.ns.cloudflare.com 的名称服务器——您必须在注册商（GoDaddy、Namecheap 或本地泰国注册商）处设置这些。此步骤至关重要，因为它将完整的 DNS 控制从 DigitalOcean 或您的旧注册商转移到 Cloudflare。在更改名称服务器之前，应在实际切换前至少 24-48 小时将重要记录（如您域名的 A 记录）的 TTL 降低至 300 秒，以便切换快速进行并在您进行切换时全球更快地传播。名称服务器更改通常需要数分钟到 24-48 小时不等才能传播，具体取决于注册商和用户使用的解析器。在此期间，监控 Cloudflare 仪表板中的自动通知，一旦名称服务器已更改且您的域名已完全激活。

• 如果您使用了 DO DNS，使用 doctl compute domain records list 验证迁移前的所有记录
• 完全检查 MX 记录，以便迁移后域名电子邮件不会中断
• 在实际切换前至少 24-48 小时将 TTL 降低到 300 秒
• 在您的注册商处将名称服务器更改为 Cloudflare 提供的对

启用代理（Orange Cloud）+ SSL 完全严格

一旦您的域名在 Cloudflare 上激活，下一步是启用代理——或 Orange Cloud——在应该路由流量通过 Cloudflare 的 DNS 记录上，例如 www 和您根域名的 A 记录。单击记录旁的云图标以将其从灰色（仅 DNS）切换为橙色（代理）。将不应通过 Cloudflare 的记录保留为灰色，例如邮件服务器或专用 SSH 的子域，因为 Cloudflare 不代理所有协议。启用代理后，立即正确配置 SSL/TLS 模式。您有四个选择：关闭、灵活、完全和完全（严格）。对于具有现有 SSL 证书的 Droplet，建议使用完全（严格），因为它强制 Cloudflare 严格验证 Droplet 的证书，保护您免受 Cloudflare 和您源之间的中间人攻击。灵活模式仅加密用户到 Cloudflare 的流量，但将 Cloudflare 到 Droplet 的流量保留为纯 HTTP，通常在您的源应用已经强制 HTTPS 时导致重定向循环。对于 Droplet 上的证书，您有两个选择：像往常一样通过 Certbot 使用 Let's Encrypt，或使用 Cloudflare Origin CA 证书（免费，从 SSL/TLS > Origin Server > Create Certificate 创建）持续最多 15 年，无需像 Let's Encrypt 那样进行续订——但仅在 Cloudflare 和源之间有效，不适用于直接浏览器访问。在 Nginx 或 Apache 上安装证书后，从 SSL/TLS > Edge Certificates 启用始终使用 HTTPS，以便 Cloudflare 边缘自动将 HTTP 重定向到 HTTPS，减少 Droplet 上的重定向负担。

• 仅在您想要路由通过 Cloudflare 的记录（www、root）上启用代理，将其他记录保留为仅 DNS
• 如果您的 Droplet 已有有效证书，将 SSL/TLS 模式设置为完全（严格）
• 避免灵活模式，因为它通常会在强制 HTTPS 的应用中导致重定向循环
• 创建一个免费的 Cloudflare Origin CA 证书，持续最多 15 年
• 在边缘证书中启用始终使用 HTTPS，以便在边缘自动进行 HTTP 到 HTTPS 重定向

配置防火墙仅接受 Cloudflare IP

仅启用代理是不够的，因为您 Droplet 的公共 IP 仍可直接访问。如果有人发现您的真实 IP，他们可以直接发送请求绕过 Cloudflare，破坏您的 DDoS 和 IP 掩蔽策略。关键步骤是使用 DigitalOcean 的 Cloud Firewall——一个免费功能，无需额外成本——锁定您的 Droplet，使其仅从 Cloudflare 的 IP 范围接受端口 80 和 443 上的流量。Cloudflare 的官方 IPv4 和 IPv6 CIDR 块列在 cloudflare.com/ips，应始终获取最新版本，因为 Cloudflare 有时会更新范围。最简单的方法是使用 doctl 创建具有入站规则的防火墙，涵盖所有 Cloudflare CIDR 块，例如：doctl compute firewall create --name web-cf-only --droplet-ids DROPLET_ID --inbound-rules "protocol:tcp,ports:80,address:173.245.48.0/20 protocol:tcp,ports:443,address:173.245.48.0/20" 然后使用 doctl compute firewall add-rules FIREWALL_ID --rules "protocol:tcp,ports:443,address:173.245.48.0/20" 一次一个地添加剩余范围，重复直到涵盖所有 IPv4 和 IPv6 范围。对于 SSH（22）等其他端口，创建单独的规则，仅允许您团队的 IP 或 VPN，而不是向全球开放，因为 Cloud Firewall 作为每个端口允许列表工作，无论您添加多少规则，都无需额外成本。一个关键风险：如果您在 Cloudflare 更改范围时忘记更新 IP 范围，Cloudflare 的边缘节点可能暂时无法到达您的源，向用户返回错误 521/522。这就是为什么编写从 cloudflare.com/ips 获取最新 IP、将其与当前规则进行比较并按计划（例如每月 cron）更新防火墙的脚本是明智的，而不是设置一次就忘记。

1. 从 cloudflare.com/ips 获取最新的 Cloudflare IP 范围（IPv4 和 IPv6）
2. 使用 doctl compute firewall create/add-rules 仅从 Cloudflare 范围打开端口 80/443
3. 在单独的规则中保持 SSH（端口 22），仅允许您团队的 IP 或 VPN

基本缓存和页面规则

值得强调的是——在您的 Droplet 前放置 Cloudflare 的另一个主要好处是缓存，它显著减少了源的负载。默认缓存级别建议是标准，它按查询字符串缓存，您可以在缓存菜单中调整浏览器缓存 TTL 来控制浏览器缓存静态资产的时间，然后再次请求。为了进行更精细的控制，Cloudflare 提供缓存规则，这是替代旧页面规则的较新系统，允许您灵活地为每个路径设置条件和缓存行为。例如，创建一个规则以绕过 /wp-admin 和 /api 等路径上的缓存，因为它们频繁更改或与用户会话相关，然后创建另一个规则以使用长边缘 TTL（例如 1 个月）为 .css、.js、.jpg、.png 等静态文件设置缓存所有内容，以便边缘节点保持更长时间，并且更少从您的 Droplet 请求。部署新代码或更新静态资产时，立即清除缓存，以便用户不会看到旧版本——无论是通过仪表板中的清除所有内容还是通过 API 针对特定文件，以便在高流量网站上获得精确度。如果您正在调试并不确定缓存是否正在干扰，请暂时启用开发模式，它在 3 小时内自动绕过所有缓存，无需每个文件清除。对于 WordPress 要特别小心，因为您可能最终会得到双层缓存：您 WordPress 安装中的插件缓存加上 Cloudflare 的边缘缓存，它们之间的不一致可能导致陈旧内容意外持续。

1. 将缓存级别设置为标准并调整浏览器缓存 TTL 以满足您的需求
2. 创建缓存规则以绕过 /wp-admin 和 /api 上的缓存
3. 为 css/js/images 等静态文件设置缓存所有内容和长边缘 TTL
4. 部署后立即清除缓存以防止用户看到旧版本
5. 调试时暂时启用开发模式以在 3 小时内绕过所有缓存

何时使用此功能（真实用例）

当您的网站或应用面向公众且面临攻击或流量激增风险时，集成 Cloudflare 和 Droplet 是理想的。想象 WordPress 或 WooCommerce 商店在促销期间运行真实销售并担心 DDoS，新闻或博客网站的读者分散在多个国家需要一致的页面加载速度，或需要在到达源之前进行基本速率限制的公共 API 端点。另一个值得考虑的场景：运行小型 Droplets（1-2 vCPU）的团队希望在升级前尽可能延长该规格的寿命，因为边缘缓存的静态资产承担负载。另一方面，某些设置根本不需要 Cloudflare 代理：已由 VPN 或 WireGuard 保护的内部工具或管理仪表板在没有充分理由的情况下从添加代理层中受益。类似地，严重依赖长期 WebSocket 连接的应用在启用完全代理之前需要仔细检查超时和与您 Cloudflare 计划的兼容性——特别是对即使很小的边缘额外跳跃的延迟敏感的实时应用。非常低流量和没有特定安全威胁的网站可能不需要额外的复杂性，尽管设置它不花费任何成本并在您增长时稍后获得回报，所以建议从第一天开始就配置它。

1. 运行真实销售并担心高峰流量期间 DDoS 的 WordPress/WooCommerce 商店
2. 读者分散在多个国家需要一致加载速度的网站
3. 需要在到达源之前进行基本速率限制的公共 API

常见错误和解决方案

最常见的问题是重定向循环或 ERR_TOO_MANY_REDIRECTS，通常来自将 SSL/TLS 模式设置为灵活，而您 Droplet 的应用已经强制 HTTP→HTTPS（如 WordPress 的强制 HTTPS 插件），创建循环：Cloudflare 发送 HTTP 到源 → 源重定向到 HTTPS → 无限循环。修复：将 SSL 模式从灵活切换到完全或完全（严格）。第二个最常见的问题是错误 521（Web 服务器已关闭）或 522（连接超时），通常不是您的 Droplet 实际关闭而是您的 Cloud Firewall 误阻止 Cloudflare 的 IP，特别是在您设置允许列表防火墙后忘记在 Cloudflare 旋转范围时更新它。通过检查您的 Nginx/Apache 日志来验证 Cloudflare 的 IP 是否到达您的 Droplet——如果没有，您的防火墙正在阻止它们。第三个问题是真实访问者 IP 从您 Droplet 的日志中消失，完全被 Cloudflare 的 IP 替换，破坏在源处运行的流量分析和速率限制规则。修复：通过在 nginx.conf 中为所有 Cloudflare 范围添加 set_real_ip_from 173.245.48.0/20; real_ip_header CF-Connecting-IP; 配置 Nginx 以读取 CF-Connecting-IP 标头，然后重新加载。第四个：混合内容警告出现是因为某些资源链接被硬编码为 http://，即使启用了始终使用 HTTPS。修复：要么在源代码中重写链接，要么使用 Cloudflare 的自动 HTTPS 重写功能来修补其中的一些。第五个：部署新代码后，用户仍然看到旧版本，因为缓存是陈旧的，通过每次部署时运行缓存清除来修复——如果可能的话，通过您的 CI/CD 管道自动化它。

1. 重定向循环：将 SSL 模式从灵活更改为完全/完全严格
2. 错误 521/522 通常意味着 Cloud Firewall 阻止 Cloudflare 的 IP，而不是您的 Droplet 关闭
3. 日志中缺少真实访问者 IP：在 Nginx 中使用 real_ip_header CF-Connecting-IP

最佳实践

要使您的 Cloudflare-Droplet 设置长期保持坚实和真正安全，请遵循以下关键原则。首先，在生产中始终使用 SSL/TLS 模式完全（严格）——永远不要长期依赖灵活，因为 Cloudflare 和源之间的通道将不会加密，如果有人窃听了网络，会打开窃听的大门。其次，将 Cloud Firewall 锁定到仅 Cloudflare IP 范围，并添加第二层使用经过身份验证的源提取，这是 Cloudflare 功能，强制您的源在响应之前验证 Cloudflare 的客户端证书。这样，即使有人发现您的真实 IP 并假装是 Cloudflare，他们也无法在没有正确证书的情况下答复。第三，定期轮换您的 Origin CA 证书，即使它持续最多 15 年，因为定期轮换可以降低在不知道的情况下泄露时的风险。第四，将 DigitalOcean 监控与警报策略配对，在 CPU 或带宽异常激增时通知您，因为虽然 Cloudflare 过滤恶意流量很好，但您仍需要在源处进行监控作为最后的安全网。第五，在上线到生产之前在暂存子域或测试域上测试您的整个设置，确保 SSL、缓存规则和防火墙规则正确协同工作，不会为真实用户破坏您的网站。最后，以书面形式记录您的配置——您设置的防火墙规则、您创建的缓存规则、您使用的名称服务器——以便您的团队或未来的您在需要时快速排查或扩展系统。

• 在生产中始终使用 SSL/TLS 模式完全（严格），永远不要灵活
• 启用经过身份验证的源提取以及 Cloud Firewall 来阻止缺少证书的冒充者
• 定期轮换 Origin CA 证书，即使它们持续最多 15 年

领取 $200 免费额度 →