8 月 16 日，Hacker News 上的一场激烈讨论把 Cloudflare 的一个设置变成了基础设施治理案例。站点所有者原本期望页面保持无 JavaScript，域名接入 Cloudflare 后，却在浏览器收到的 HTML 里看到了来自 static.cloudflareinsights.com/beacon.min.js、带有 data-cf-beacon 的脚本。帖子标题把问题归因于 nameservers 切换，但技术边界必须说清楚：单纯 DNS 不会改写 HTML。真正相关的是 proxied hostname，也就是响应经过 Cloudflare edge 的路径。

示意图：源站 HTML 经过边缘代理，在到达浏览器前被加入一个小型 RUM beacon

发生了什么

公开信号来自 “Tell HN: Cloudflare silently injects its analytics when you switch nameservers” 这个帖子；核查时，它已有数百个投票和一百多条评论。不过论坛只能说明讨论热度，不能单独作为产品事实。更可靠的依据是 Cloudflare 文档。Web Analytics 和 Observatory RUM 文档说明，RUM beacon 可以在 proxied 站点上自动插入。Cloudflare 2025 年 9 月 17 日的博客也写明，2025 年 10 月 15 日起，免费域名默认启用 Web Analytics，并排除 EU 和 UK 流量。当前文档还提供禁用自动设置或改为手动安装 snippet 的选项。

这就是争议的来源。Cloudflare 看到的是强调隐私的真实用户性能观测；不少运维人员看到的则是第三方在没有 origin 部署的情况下改变了生产响应。两种说法并不矛盾：beacon 可以是公开文档中的性能工具，也可以同时成为未经本团队变更流程批准的页面变化。

DNS-only 与 proxied 的区别

这点很重要。DNS-only 记录只负责解析名称，不把 Cloudflare 放进传输 HTML 的 HTTPS 路径，因此不能向页面主体添加脚本。proxied 记录不同：请求进入 Cloudflare reverse proxy，edge 可能应用 WAF、缓存、压缩、观测、bot 检查和内容转换，然后再把响应交给浏览器。

在控制台里，这可能只是橙色云朵和灰色云朵的差别；在架构上，它决定谁控制用户真正收到的内容。无论是 R2 custom domain、Pages、普通 origin 还是子域名，都要问同一个问题：哪些 hostname 被代理，哪些产品会作用在响应路径上。如果供应商能够增加 headers、展示 challenge、插入 beacon 或改写 HTML，它就已经是应用运行时的一部分。

Web Analytics 与 RUM 是什么

Cloudflare Web Analytics 被定位为注重隐私的性能分析。RUM beacon 从浏览器 Performance APIs 收集导航时间、资源时间、绘制时间、LCP、CLS、TTFB、INP 等 Core Web Vitals 以及页面加载相关指标。Data origin 文档把 https://static.cloudflareinsights.com/beacon.min.js 列为脚本来源，并说明 proxied 站点会把数据发送到 /cdn-cgi/rum。

也要避免夸大。Cloudflare 文档称，beacon 不访问 cookies、localStorage、sessionStorage、IP address 或 IndexedDB；正常 HTTP 处理过程中收到的源 IP 会在最近的数据中心丢弃。因此，把这件事说成 cookie 跟踪或恶意软件并不准确。专业问题是：基础设施默认设置改变了浏览器收到的页面。

为什么运营者不满

争议不只是多了一个小脚本。有些站点明确承诺无 JavaScript。有些政府、医疗、金融、教育、媒体和公益项目维护第三方脚本清单。很多组织要求在生产环境出现任何浏览器端第三方代码之前，先更新隐私说明、数据处理记录、同意机制、CSP、SRI、安全测试和供应商评估。即使 beacon 不读取 cookies，它也会触发这些流程。

信任链也受到影响。origin 生成一组字节，浏览器收到另一组字节。对于依赖可复现部署、严格 CSP、资源完整性或供应链审计的团队来说，edge mutation 不是小细节。如果团队不是通过变更工单，而是从用户投诉或论坛得知，流程已经失效。

这不是恶意软件恐慌

讨论需要保持准确。Cloudflare 是大型基础设施供应商，Web Analytics 是官方产品，自动插入机制在文档中有说明。beacon 的目的是真实用户性能遥测，不是窃取密码或读取浏览器存储。把所有被添加的脚本都称为攻击，会削弱真正的问题。

更有用的框架是授权与变更控制。一个脚本可以是良性的，但仍未被某个站点批准。一个默认设置可以帮助免费用户，同时对受监管流量过宽。供应商可以尽量减少个人数据，同时仍然给客户带来合规审查工作。成熟团队应该能分层决策：营销页可接受，登录应用不可接受，文档站点需要工单后才可启用。

治理问题

现代 edge 平台不再是中立管道。CDN、WAF、bot management、serverless edge、analytics、图像优化、邮件混淆、安全 challenge 和性能产品都位于 origin 与用户之间。它们的默认设置可能改变字节、headers、JavaScript 执行、缓存、延迟、遥测和错误处理。这就是软件供应链的一部分。

因此，组织需要 edge change model。控制台操作要有 owner。免费计划默认值也要像依赖项一样审查。供应商公告要映射到具体 zone 和 hostname。任何会改变 response body 的自动转换，在敏感、受监管或承诺无 JavaScript 的站点上，都应进入 change management。

审计清单

先做 diff。分别从 origin 和公开 hostname 获取同一页面，比较 HTML、headers 和脚本清单。搜索 static.cloudflareinsights.com、data-cf-beacon、/cdn-cgi/rum、bot-management scripts、email decode、Rocket Loader、Zaraz、challenge scripts、被转换的图片 URL 和意外 reporting endpoints。不要只查首页，也要查子域名。

检查 Web Analytics、Observatory、Speed、Zaraz、Rules、Transform Rules、Page Rules、Workers routes、Snippets、Bot Management、WAF managed challenges 和 cache settings。目的不是把所有功能都关掉，而是知道哪些功能会改变浏览器可见响应，以及谁批准了它们。

谨慎使用 CSP。MDN 的 Content Security Policy 指南说明，CSP 可以限制页面加载哪些资源。严格的 script-src 能阻止意外 beacon，Content-Security-Policy-Report-Only 可以先观察影响再强制执行。但 CSP 不能代替配置治理；如果功能仍然开启，只靠阻止供应商插入的脚本可能带来报告噪声和缺失指标。

在合适页面测试 Cache-Control: public, no-transform。Cloudflare FAQ 说明，有这个 header 时 proxy 不能修改原始 payload，因此 beacon 不会被自动插入。但它不是通用开关，可能影响有用的优化，需要在代表性页面上验证。

迁移清单与结论

迁移域名前，逐个 hostname 决定 DNS-only 还是 proxied。需要 CDN 缓存或 WAF 时，proxy 可能合理；需要保持 origin 字节完全一致时，DNS-only 或其他架构可能更好。启用 proxy 后，用浏览器和 CLI 审计 delivered HTML、headers、CSP reports、performance beacons、source maps、service workers、第三方脚本和到供应商 endpoint 的请求。涉及隐私和法律义务时，把事实交给 compliance 或法律顾问评估。

这场争议会在其他供应商和其他默认设置上再次出现。edge 平台越有用，就越不是中立管道。Observability 很有价值，但应当明确、可审查、可回滚。实用规则很简单：如果一个设置能改变浏览器收到的内容，它就属于生产变更。