Cloudflare 使用避坑指南｜适合企业用户

Cloudflare 是企业在做网站加速、安全防护、DNS 托管、零信任访问、边缘计算与全球流量治理时经常会接触到的平台。它的优势很明显：全球节点覆盖广、DNS 解析速度快、WAF 和 DDoS 防护能力成熟、配置入口集中、产品线丰富，能够帮助企业以相对较低的门槛获得较强的网络安全与访问性能能力。

但在真实企业环境中，Cloudflare 并不是“接入即万事大吉”。很多问题并不是 Cloudflare 本身不好，而是企业在接入前没有做好架构评估、配置策略过于粗放、对业务特性理解不足，最终导致访问异常、缓存错乱、源站暴露、SEO 波动、接口报错、证书问题、合规风险甚至业务中断。

本文将从企业用户角度出发，系统梳理 Cloudflare 使用过程中的常见坑点、风险场景与最佳实践，帮助企业在接入、配置、运维和扩展时少踩坑。

一、接入 Cloudflare 前，不要只把它当作“加速工具”

很多企业初次接触 Cloudflare，是因为想解决网站访问慢、遭遇攻击、DNS 不稳定或海外访问质量差等问题。于是直接把域名 NS 切到 Cloudflare，然后开启代理小云朵，认为这样就完成了加速与安全防护。

这是一个常见误区。

Cloudflare 更准确地说，是一个位于用户与源站之间的边缘网络平台。它不仅影响 DNS，还会影响 HTTPS、缓存、请求头、真实 IP 传递、安全校验、访问控制、API 调用、文件上传、WebSocket、邮件相关记录、SEO 抓取、源站日志等多个层面。

因此，企业在接入前至少要明确以下问题：

• 哪些域名需要经过 Cloudflare 代理？
• 哪些子域名只需要 DNS 解析，不需要代理？
• 源站是否能够正确识别访客真实 IP？
• 是否存在 API、支付回调、Webhook、登录接口等不能被缓存或拦截的路径？
• 是否使用了自签证书、泛域名证书或多源站证书？
• 是否有国内访问、海外访问、跨境业务、合规审计等要求？
• 是否已有 CDN、WAF、负载均衡、安全网关等产品，Cloudflare 与它们如何协同？

企业级使用 Cloudflare，首先要把它纳入整体网络架构，而不是把它视为单一工具。

二、DNS 托管迁移：不要忽略历史记录和灰度切换

Cloudflare 的 DNS 服务非常稳定，解析速度也很快。但企业迁移 DNS 时，最容易出现的问题就是遗漏记录。

很多公司的域名 DNS 记录经过多年演进，里面可能包含：

• 主站 A / AAAA / CNAME 记录；
• 邮件相关 MX、SPF、DKIM、DMARC 记录；
• 内部系统子域名；
• 第三方 SaaS 验证记录；
• 支付、客服、营销系统 CNAME；
• CDN、对象存储、API 网关记录；
• TXT 类型的所有权验证记录；
• 老系统遗留记录。

如果迁移时只关注 www 和根域名，很可能导致邮件收发异常、第三方系统验证失败、API 回调失败或内部服务无法访问。

建议做法

1. 迁移前导出现有 DNS 全量记录
   从原 DNS 服务商导出完整记录，并人工核对关键业务域名。

2. 区分“代理记录”和“仅 DNS 记录”
   Cloudflare 中橙色云朵表示开启代理，灰色云朵表示仅解析。不是所有记录都应该开启代理。

3. 邮件相关记录不要开启代理
   MX 记录本身不能被代理；邮件服务器相关的 mail.example.com 通常也应保持灰色云朵，否则可能影响 SMTP、IMAP、POP3 等协议。

4. 内部服务和非 HTTP 服务谨慎代理
   Cloudflare 常规代理主要面向 HTTP/HTTPS 流量。SSH、FTP、数据库、邮件等服务不能简单通过普通小云朵代理。

5. 降低 TTL 并做好切换窗口
   在迁移前降低原 DNS TTL，安排低峰期切换，准备回滚方案。

三、不要轻易开启所有子域名代理

Cloudflare 的代理能力主要适用于 Web 流量。对于企业来说，不同子域名用途不同，不能为了“统一保护”而全部开启代理。

例如：

如果企业将所有子域名统一开启代理，可能出现以下问题：

• 非 HTTP 服务无法连接；
• 第三方回调因安全规则被拦截；
• API 接口受到缓存或速率限制影响；
• 后台登录被误判为攻击；
• 真实源站地址仍可能通过未代理记录泄露；
• 某些端口不在 Cloudflare 支持范围内。

建议做法

按业务类型分层管理子域名：

• 静态资源域名：重点配置缓存；
• 官网域名：配置 HTTPS、WAF、Bot 防护；
• API 域名：关闭缓存，配置限速和白名单；
• 后台域名：接入 Zero Trust 或 IP 访问控制；
• 邮件和非 Web 服务：仅 DNS 解析，不走代理；
• 内部系统：尽量不要直接暴露公网。

四、SSL/TLS 模式选择错误，是企业最常见的坑

Cloudflare SSL/TLS 模式中，最容易被误用的是 Flexible 模式。

Cloudflare 常见的 SSL/TLS 模式包括：

• Off：不启用 HTTPS；
• Flexible：用户到 Cloudflare 是 HTTPS，Cloudflare 到源站是 HTTP；
• Full：用户到 Cloudflare 是 HTTPS，Cloudflare 到源站也是 HTTPS，但不严格校验证书；
• Full Strict：用户到 Cloudflare 是 HTTPS，Cloudflare 到源站也是 HTTPS，并严格校验证书。

对于企业来说，不建议使用 Flexible 模式。

原因是 Flexible 模式下，浏览器看到的是 HTTPS，但 Cloudflare 回源使用的是 HTTP。这会带来几个问题：

1. 源站链路不加密
   如果 Cloudflare 到源站之间经过公网链路，数据可能被监听或篡改。

2. 容易出现重定向循环
   源站如果强制 HTTP 跳 HTTPS，而 Cloudflare 又以 HTTP 回源，可能导致无限重定向。

3. 安全感假象
   用户以为全链路 HTTPS，实际上只有用户到 Cloudflare 这一段加密。

企业推荐配置

优先使用：

SSL/TLS Mode: Full (Strict)

并确保：

• 源站部署有效证书；
• 证书域名与访问域名匹配；
• 证书没有过期；
• 中间证书链完整；
• 源站支持现代 TLS 协议；
• HTTPS 重定向策略与 Cloudflare 配置一致。

如果企业不想购买源站证书，可以使用 Cloudflare Origin Certificate。该证书用于 Cloudflare 到源站之间的加密，但不适合用户直接访问源站。

五、源站真实 IP 暴露：Cloudflare 不是万能盾牌

很多企业以为开启 Cloudflare 代理后，源站就彻底隐藏了。事实上，如果配置不当，源站 IP 仍然可能暴露。

常见暴露方式包括：

• 历史 DNS 记录查询；
• 未代理子域名指向同一源站；
• 邮件服务器与 Web 服务共用 IP；
• 源站主动发起外部请求时暴露 IP；
• 证书透明日志泄露相关域名；
• Git、配置文件、错误页面泄露；
• 旧 CDN 或备份域名仍指向源站；
• 直接通过 IP 访问源站仍返回业务页面。

一旦攻击者获得源站 IP，就可能绕过 Cloudflare，直接攻击源站。

建议做法

1. 源站防火墙只允许 Cloudflare IP 段访问
   在服务器安全组、防火墙或负载均衡层限制入站访问，仅允许 Cloudflare 官方 IP 段访问 HTTP/HTTPS 端口。

2. 源站默认站点不要返回业务内容
   直接访问 IP 时，应返回空页面、403 或默认页，不应返回真实业务站点。

3. 分离邮件服务器与 Web 源站 IP
   邮件服务往往不能走 Cloudflare 代理，不应与核心 Web 源站共用公网 IP。

4. 定期扫描历史暴露面
   检查 DNS 历史、证书记录、代码仓库、第三方平台配置。

5. 使用 Authenticated Origin Pulls
   要求源站验证来自 Cloudflare 的客户端证书，提高回源安全性。

六、缓存策略不要“一刀切”

Cloudflare 的缓存能力很强，但缓存也是最容易造成业务事故的地方。尤其是企业网站中，静态资源、动态页面、登录态页面、API 接口、搜索结果页、购物车、订单页等混合存在，如果缓存规则设置不当，后果可能很严重。

常见问题包括：

• 用户 A 看到用户 B 的页面；
• 登录后页面被缓存，导致状态错乱；
• API 返回旧数据；
• 后台修改内容后前台不更新；
• 页面参数被忽略导致内容错误；
• 缓存了错误响应，如 500 或 404；
• 支付状态、库存状态延迟更新。

企业缓存建议

1. 静态资源适合强缓存

例如：

/static/*
/assets/*
/images/*
/css/*
/js/*

可以配置较长缓存时间，并通过文件名哈希控制版本更新，例如：

app.8f3a21.js
style.a72c9.css

2. 动态页面谨慎缓存

对于包含用户状态、个性化内容、实时数据的页面，应避免边缘缓存。

例如：

/account/*
/user/*
/cart/*
/checkout/*
/order/*
/admin/*

建议直接绕过缓存。

3. API 默认不要缓存

除非非常明确 API 是公开、只读、可缓存的，否则企业 API 应默认设置为：

Cache: Bypass

并通过响应头明确控制：

Cache-Control: no-store

或：

Cache-Control: private, no-cache

4. 注意 Query String

对于依赖查询参数的页面或接口，需要确认 Cloudflare 的缓存键是否包含 Query String。否则不同参数可能命中同一缓存，引发数据错误。

七、安全规则配置：别让 WAF 误伤正常业务

Cloudflare WAF、Bot Fight Mode、Rate Limiting、Managed Rules 等功能非常有用，但企业使用时不能简单地“全部开启”。

因为安全规则越严格，误伤概率越高。

典型误伤场景包括：

• 后台富文本编辑器提交 HTML 被判定为 XSS；
• API 请求体中包含 SQL 字符串被判定为 SQL 注入；
• 文件上传接口被拦截；
• 海外办公人员访问后台被质询；
• 爬虫抓取公开页面被阻断，影响 SEO；
• 第三方支付或物流回调被拦截；
• 移动 App API 请求被识别为异常 Bot；
• 企业代理出口 IP 请求频率过高触发限速。

建议做法

1. 先观察后拦截
   新规则上线时，优先使用 Log / Simulate / Challenge，而不是直接 Block。

2. 为关键路径建立例外规则
   对支付回调、Webhook、API、文件上传等路径单独配置规则。

3. 后台系统单独防护
   后台不应只依赖 WAF。建议叠加：

   • IP 白名单；
   • Cloudflare Access；
   • MFA 多因素认证；
   • VPN 或 Zero Trust；
   • 单独子域名隔离。

4. 定期查看安全事件日志
   Cloudflare Security Events 能帮助企业分析哪些规则触发、哪些 IP 被拦截、是否存在误伤。

5. 不要只按国家地区粗暴封禁
   国家/地区封禁有时有效，但也可能影响跨境用户、搜索引擎、云服务回调和合作伙伴访问。

八、真实访客 IP 处理：日志和风控系统必须改造

接入 Cloudflare 后，源站看到的连接 IP 通常是 Cloudflare 节点 IP，而不是真实访客 IP。如果企业没有正确处理请求头，就会出现很多问题：

• 日志中所有用户 IP 都变成 Cloudflare IP；
• 风控系统无法识别真实用户；
• IP 黑名单失效；
• 限流策略错误；
• 地域分析数据异常；
• 登录安全策略误判；
• 审计日志不准确。

Cloudflare 会通过请求头传递真实 IP，例如：

CF-Connecting-IP
X-Forwarded-For

企业源站需要在 Web 服务器、应用框架、日志系统中正确读取这些字段。

Nginx 示例

可以在 Nginx 中配置 Cloudflare IP 段，并恢复真实 IP：

set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;

real_ip_header CF-Connecting-IP;

注意：Cloudflare IP 段可能更新，企业应定期同步官方列表。

九、Page Rules、Cache Rules、Transform Rules 不要混乱叠加

Cloudflare 早期大量配置依赖 Page Rules，后来逐步引入 Cache Rules、Configuration Rules、Redirect Rules、Transform Rules、Origin Rules 等功能。企业在长期使用中，容易出现规则重叠、优先级混乱和历史配置遗留问题。

常见情况包括：

• Page Rules 中设置了缓存；
• Cache Rules 又设置了绕过缓存；
• Transform Rules 修改了请求头；
• Origin Rules 改写了回源地址；
• Redirect Rules 做了跳转；
• 源站本身也在做重定向；
• 最终请求行为难以判断。

建议做法

1. 建立规则台账
   记录每条规则的用途、负责人、上线时间、影响路径和回滚方式。

2. 按功能拆分规则
   缓存归缓存规则，跳转归跳转规则，头部修改归 Transform Rules，减少混用。

3. 控制规则数量
   不要为每个小需求都建规则，尽量通过路径规划和源站配置解决。

4. 变更前后做请求验证
   使用 curl -I 检查响应头、缓存状态、跳转链路和回源状态。

例如：

curl -I https://www.example.com/

重点关注：

CF-Cache-Status
Cache-Control
Location
HTTP Status

十、Always Use HTTPS 与源站跳转规则要统一

很多企业开启 Cloudflare 的 Always Use HTTPS，同时源站也配置了 HTTP 到 HTTPS 跳转。这本身没问题，但如果 SSL 模式、源站监听、代理头处理不一致，就可能导致重定向循环或访问异常。

常见表现：

• 浏览器提示“重定向次数过多”；
• HTTP 能访问，HTTPS 异常；
• 某些路径跳转到错误域名；
• API 被 301/302 重定向导致客户端报错；
• POST 请求被重定向后变成 GET。

建议做法

• 使用 Full Strict；
• 源站正确识别 X-Forwarded-Proto；
• 不要在多处写相互冲突的跳转规则；
• API 域名谨慎启用强制跳转；
• 对旧域名跳转、新域名跳转建立清晰规则。

十一、企业 API 接入 Cloudflare 要特别谨慎

Cloudflare 对网站非常友好，但 API 场景需要更细致的配置。尤其是企业有移动 App、小程序、开放平台、合作伙伴接口时，不能简单套用官网站点的安全策略。

API 常见风险包括：

• 请求被 Bot 规则拦截；
• JSON 请求体触发 WAF；
• 上传大文件失败；
• 请求超时；
• 客户端不支持某些 TLS 配置；
• 频率限制误伤正常业务；
• 缓存导致返回旧数据；
• 第三方回调无法通过 Challenge；
• OPTIONS 预检请求被拦截，影响 CORS。

建议做法

1. API 子域名单独管理
   例如使用 api.example.com，不要与官网共用完全相同规则。

2. 默认关闭缓存
   API 除非明确可缓存，否则绕过缓存。

3. 针对接口做限速而非全站限速
   登录、短信验证码、搜索接口、下单接口可以分别设计不同阈值。

4. 第三方回调配置白名单
   支付、物流、CRM、营销平台等回调来源尽量基于 IP、签名和路径做放行。

5. 避免对 API 使用交互式 Challenge
   浏览器用户可以完成验证，但 API 客户端通常无法处理 Cloudflare Challenge 页面。

十二、不要忽略上传大小和超时限制

企业网站中常见文件上传、视频上传、报表导出、大请求体提交等功能。Cloudflare 对请求大小、连接时长、响应时间等存在不同套餐层级的限制。

如果没有提前评估，可能出现：

• 大文件上传失败；
• 后台导出报表中断；
• 长轮询接口异常；
• 慢查询接口返回 524；
• WebSocket 不稳定；
• 用户提交大型表单失败。

其中，524 通常表示 Cloudflare 已连接到源站，但源站在规定时间内没有响应完成。

建议做法

• 大文件上传尽量直传对象存储；
• 后台导出改为异步任务；
• 长耗时接口拆分为任务查询模式；
• 优化源站响应时间；
• 对特殊接口考虑绕过 Cloudflare；
• 根据业务需求评估更高套餐或企业方案。

十三、Cloudflare 与中国大陆访问：不要默认一定加速

很多企业关心中国大陆用户访问体验。需要注意的是，Cloudflare 免费版、Pro、Business 的全球网络虽然强大，但对于中国大陆访问，并不总是稳定加速。不同地区、不同运营商、不同时间段体验可能差异较大。

如果企业主要用户在中国大陆，需要谨慎评估：

• 是否有 ICP 备案；
• 是否需要使用国内 CDN；
• 是否存在跨境访问链路问题；
• 是否要区分国内外解析；
• 是否有数据合规要求；
• 是否需要中国网络合作方案。

建议做法

1. 做真实用户监测
   不要只看单点测速，应从不同省份、运营商、时间段进行测试。

2. 国内外流量分流
   中国大陆用户可走国内 CDN，海外用户走 Cloudflare，通过智能 DNS 或全局流量调度实现。

3. 核心业务不要只依赖单一链路
   对高可用要求高的企业，应建立多 CDN、多源站或灾备方案。

4. 关注合规与备案
   涉及中国大陆业务时，域名备案、数据处理、内容合规都需要提前规划。

十四、套餐选择：不要只看价格，要看风险成本

Cloudflare 免费版功能已经很强，但企业用户不能只按价格选择套餐。不同套餐在 WAF、自定义规则、缓存能力、日志、SLA、支持响应、DDoS 防护细节、访问策略、性能功能等方面存在差异。

企业需要考虑：

• 业务是否承载收入；
• 停机损失有多大；
• 是否需要正式 SLA；
• 是否需要高级 WAF；
• 是否需要日志导出；
• 是否需要更高上传限制；
• 是否需要负载均衡；
• 是否需要企业级支持；
• 是否有合规审计要求；
• 是否需要多个团队协作和权限管理。

对于业务关键系统，建议至少评估 Business 或 Enterprise 方案，而不是长期依赖免费版承载核心业务。

十五、团队权限管理：不要共用一个管理员账号

企业使用 Cloudflare 时，经常出现一个账号管理多个域名、多人共用账号、离职员工仍有权限等问题。这是非常严重的安全隐患。

可能导致：

• 域名 DNS 被恶意修改；
• 安全规则被关闭；
• 证书配置被篡改；
• 流量被导向恶意源站；
• 业务被中断；
• 无法追踪操作责任。

建议做法

• 启用多因素认证；
• 使用团队成员独立账号；
• 按角色分配权限；
• 最小权限原则；
• 定期审计成员列表；
• 离职及时移除权限；
• 关键变更建立审批流程；
• 使用 API Token 而不是全局 API Key；
• API Token 限制权限范围和可访问资源。

十六、日志与监控：不要等故障发生才看

Cloudflare 提供了丰富的分析与日志能力，但很多企业只在出问题时才去看 Dashboard。实际运维中，应该把 Cloudflare 纳入监控体系。

建议重点监控：

• 总请求量变化；
• 缓存命中率；
• 4xx / 5xx 错误比例；
• WAF 拦截数量；
• DDoS 攻击事件；
• 源站响应时间；
• 带宽变化；
• 国家和地区流量分布；
• Top URL；
• Top IP；
• 规则触发情况；
• DNS 变更记录。

对于关键业务，可以将 Cloudflare 日志导入企业自己的日志平台或 SIEM 系统，与源站日志、应用日志、安全日志关联分析。

十七、变更管理：任何配置都应可回滚

Cloudflare 的配置生效很快，这是优点，也是风险。一个错误的规则可能在短时间内影响全球用户。

高风险变更包括：

• DNS 记录修改；
• SSL/TLS 模式切换；
• WAF 规则启停；
• 缓存规则调整；
• 页面跳转规则；
• Worker 脚本上线；
• 负载均衡源站修改；
• 防火墙规则变更；
• Zero Trust 策略调整。

企业变更建议

1. 建立测试域名
   在测试环境先验证规则。

2. 低峰期变更
   避免在业务高峰做大规模调整。

3. 保留回滚方案
   每次变更前记录原配置。

4. 分阶段灰度
   可以先针对某个子域名、路径、地区或少量流量测试。

5. 变更后立即观察指标
   重点看错误率、源站负载、缓存命中率、安全事件。

十八、Workers 与边缘逻辑：强大但不要滥用

Cloudflare Workers 可以在边缘节点运行 JavaScript/TypeScript 逻辑，用于请求改写、鉴权、A/B 测试、轻量 API、边缘渲染等场景。它非常灵活，但企业使用时要避免把复杂业务逻辑过度迁移到边缘。

潜在风险包括：

• 逻辑分散，难以维护；
• 调试成本上升；
• 与源站行为不一致；
• 计费不可控；
• Worker 错误导致全站异常；
• 安全校验逻辑重复；
• 团队缺乏边缘计算经验。

建议做法

• 只把适合边缘处理的轻量逻辑放到 Workers；
• 核心交易逻辑仍放在后端系统；
• 建立 Worker 版本管理和回滚机制；
• 配置异常监控；
• 不在 Worker 中硬编码敏感密钥；
• 对计费和调用量设置监控。

十九、Cloudflare Zero Trust：后台保护的好选择，但要规划身份体系

对于企业后台、内部工具、运维平台，Cloudflare Zero Trust 是非常值得考虑的方案。它可以替代传统 VPN 的一部分功能，通过身份认证、设备策略、访问规则保护内部应用。

适合场景包括：

• 管理后台访问控制；
• 内部 Wiki；
• Git、CI/CD、监控平台；
• 运维跳板入口；
• 第三方外包访问隔离；
• 多地区员工远程办公。

但接入前要规划好：

• 使用哪种身份提供商，如 Google Workspace、Azure AD、Okta；
• 是否要求 MFA；
• 是否按部门、角色、设备状态授权；
• 是否记录访问日志；
• 是否允许外包人员访问；
• 是否有紧急备用访问机制。

不要只用一个共享邮箱做后台访问授权，这会削弱 Zero Trust 的价值。

二十、企业落地 Cloudflare 的推荐实施流程

为了减少风险，建议企业按以下步骤实施：

第一步：资产盘点

梳理所有域名、子域名、源站 IP、业务系统、第三方依赖、DNS 记录、证书、邮件服务和历史 CDN 配置。

第二步：业务分级

区分官网、静态资源、API、后台、支付回调、内部系统、非 Web 服务，对不同类型制定不同 Cloudflare 策略。

第三步：测试接入

先选择低风险子域名接入 Cloudflare，验证 DNS、HTTPS、缓存、日志、真实 IP、安全规则。

第四步：源站加固

限制源站仅允许 Cloudflare IP 访问，配置真实 IP 识别，关闭直接 IP 访问业务站点。

第五步：正式迁移

在低峰期迁移核心域名，保持监控和回滚准备。

第六步：安全增强

逐步启用 WAF、Rate Limiting、Bot 防护、Zero Trust、Authenticated Origin Pulls 等能力。

第七步：持续优化

根据日志、性能指标和安全事件不断调整缓存规则、安全规则和流量策略。

二十一、企业使用 Cloudflare 的避坑清单

最后给出一份简明清单，便于企业上线前检查。

DNS 与域名

• [ ] 已导入完整 DNS 记录；
• [ ] 邮件相关记录未错误代理；
• [ ] 非 HTTP 服务未开启普通代理；
• [ ] 子域名用途已分类；
• [ ] 已规划回滚方案。

SSL/TLS

• [ ] 未使用 Flexible 模式承载核心业务；
• [ ] 已启用 Full Strict；
• [ ] 源站证书有效；
• [ ] HTTPS 跳转规则无冲突；
• [ ] 已测试 HTTP/HTTPS 访问链路。

源站安全

• [ ] 源站只允许 Cloudflare IP 访问；
• [ ] 真实 IP 已正确传递；
• [ ] 直接访问源站 IP 不返回业务页面；
• [ ] 邮件服务器与 Web 源站尽量分离；
• [ ] 已启用必要的回源认证。

缓存

• [ ] 静态资源已配置合理缓存；
• [ ] 登录、购物车、订单、后台不缓存；
• [ ] API 默认绕过缓存；
• [ ] Query String 缓存策略正确；
• [ ] 已验证 CF-Cache-Status。

安全规则

• [ ] WAF 新规则先观察后拦截；
• [ ] 支付回调和 Webhook 已放行；
• [ ] API 不使用交互式 Challenge；
• [ ] 后台使用独立访问控制；
• [ ] 定期查看安全事件日志。

运维管理

• [ ] 启用 MFA；
• [ ] 不共用管理员账号；
• [ ] API Token 使用最小权限；
• [ ] 配置变更有记录；
• [ ] 已建立监控和告警。

结语

Cloudflare 对企业来说是一套非常强大的网络与安全基础设施，但它不是简单的“DNS 加速开关”。企业真正要关注的，不只是能不能接入，而是接入后是否安全、稳定、可控、可观测、可回滚。

如果你的业务只是一个静态官网，Cloudflare 可以很快带来性能和安全收益；但如果你运营的是电商、SaaS、金融科技、跨境平台、企业后台或开放 API，那么每一项配置都可能影响真实业务链路。

企业使用 Cloudflare 的核心原则可以概括为：

先盘点，再分级；先测试，再上线；先观察，再拦截；先保护源站，再优化性能。

只有把 Cloudflare 纳入整体架构治理，结合源站安全、应用逻辑、访问控制、日志监控和变更流程，才能真正发挥它的价值，同时避免因为配置不当带来的隐性风险。