Cloudflare 把 RUM 監控腳本預設塞進網頁:換個 Name Server 就中招
Cloudflare Blog · 2025-09-17（2026-07-15 更新）
Cloudflare 在官方部落格文章《The RUM Diaries: Enabling Web Analytics by Default》中說明,自 2025-10-15 起,所有掛在 Cloudflare 的 Free 方案網域,只要維持「橘雲」代理模式,就會被自動注入一段 Web Analytics 監控用的 JavaScript。這篇文章今年 2026-07-15 又更新過一次,但真正把話題炒熱的是本週(2026-08-17)Hacker News 上一則 Tell HN 貼文——一名開發者把網域的 Name Server 切換到 Cloudflare 後,發現原本刻意做成零 JavaScript 的靜態網站被動加上了分析腳本。
原本的問題
Cloudflare 過去的 Web Analytics 只涵蓋瀏覽器端的效能指標,例如 LCP、INP、CLS、TTFB,這些數字來自使用者裝置端的 Performance API 與 Resource Timing API。這些前端指標跟 Cloudflare 自己在邊緣網路層(DNS 解析、Argo 路由、邊緣節點到源站的路徑)蒐集到的資料完全分開。官方文章把這個現象形容為「效能橫跨多層:從裝置與瀏覽器,到 DNS 查詢與路由,到邊緣設定與源站位置」,彼此的資料互不打通。對開發者而言更直接的痛點是,要打開這種前端監控得自己在 </body> 前手動貼一段 beacon,或在 Pro / Business / Enterprise 方案裡手動勾選「Automatic Setup」。
採用的方法
Cloudflare 的解法是把 Web Analytics 對 Free 方案網域預設開啟,時間點訂在 2025-10-15。只要網域維持代理模式(俗稱「橘雲」,DNS 記錄設成 proxied 而非 DNS only),Cloudflare 就會在 HTML 回應離開邊緣節點前直接改寫內容,插入一段非同步載入、不阻塞渲染的監控腳本。這段腳本 hook 瀏覽器的 Performance API 與 Resource Timing API,蒐集 Core Web Vitals(LCP、INP、CLS、TTFB),送到最近的 Cloudflare 資料中心做前處理——前處理階段會先去除 IP 位址等可識別個資,不使用 cookie 或 localStorage,改用「一次不重複的 referral 或 navigation 事件」定義成一次 visit。
| 方案 | 預設狀態 | 啟用方式 |
|---|---|---|
| Free | 2025-10-15 起預設開啟 | 自動注入,可於 Dashboard/API 關閉 |
| Pro | 預設關閉 | 手動 Automatic Setup 或貼 beacon |
| Business | 預設關閉 | 同上 |
| Enterprise | 預設關閉 | 同上 |
若要關閉,可以在 Dashboard 的 Web Analytics → Manage RUM Settings 裡停用,或直接打 API:
DELETE https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/rum/site_info
# 或
PUT https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/rum/site_info
{ "auto_install": false }Cloudflare 特別註明「一旦你停用過一次,我們就不會再重新啟用」,這個 opt-out 是永久性的,不會因為後續改動其他設定又被自動打開。
實際效果
從 Cloudflare 的角度,這個改動讓平台預設就同時擁有前端效能與邊緣網路的對照資料,開發者不必額外設定。但從使用者回報看,「代理模式即插入腳本」的邊緣改寫機制對於原本刻意做成完全無 JavaScript 的靜態網站是個意外行為。在 2026-08-17 的 Tell HN 貼文裡,原作者的網站 textlog.cc 本來沒有任何 JavaScript,換成 Cloudflare 的 Name Server 後才發現被動掛上監控腳本,而要停用還得先在 Dashboard 裡「啟用」Web Analytics 功能,才找得到關閉選項。
討論串裡的工程師指出,根本原因是網域被設成「橘雲」代理而非「灰雲」(DNS only)——代理模式本來就代表 TLS 在 Cloudflare 終止,回應內容可以在離開邊緣前被重寫,這是 CDN 反向代理架構的必然結果,也是多數人啟用 Cloudflare 的原始目的。部分留言建議透過 Content-Security-Policy 限制第三方腳本來源,作為在無法完全避免邊緣改寫行為時的緩解手段:
- 把網域切回「灰雲」(DNS only),放棄 Cloudflare 的代理與 CDN 功能
- 在 Dashboard 手動停用 Web Analytics 並確認
auto_install: false - 用 CSP 的
script-src白名單阻擋非預期的第三方腳本來源