你有没有发现Dashboard上的用户数据总是比实际少一截？不是代码bug，不是采样问题——是用户的广告拦截器把监控请求吃了。

AWS CloudWatch RUM（真实用户监控）本是个被低估的好工具，能追踪页面加载、JS错误、HTTP失败这些核心指标。但作者最近排查时发现，uBlock Origin把dataplane.rum.eu-west-1.amazonaws.com的请求全拦了。第三方域名长得像追踪脚本，广告拦截器可不管你是AWS还是广告公司。

打开网易新闻 查看精彩图片

数据缺口到底多大？作者没说具体比例，只提"non-negligible"——不可忽视。对依赖RUM做性能基线的团队，这意味着决策建立在残缺的样本上。

打开网易新闻 查看精彩图片

为什么广告拦截器会误伤RUM

问题出在架构设计。RUM默认把遥测数据直发到AWS的dataplane端点，域名带rum.*.amazonaws.com。广告拦截器的过滤规则按模式匹配：rum+amazonaws=潜在追踪器。

这不算误判。从用户视角，浏览器向第三方域名发送行为数据，确实符合"追踪"的定义。RUM收集的页面性能、点击路径、错误日志，粒度足够做用户画像。拦截器一视同仁，没义务区分"好遥测"和"坏遥测"。

作者的困境很典型：团队花了精力部署RUM，配了Cognito身份池、IAM角色、采样率，结果一部分用户的数据永远进不来。更麻烦的是这个问题隐蔽——你不会收到报错，只是Dashboard数字偏低，容易被归因成"用户变少了"或"性能变好了"。

解决方案：把RUM藏进自己的域名

修复思路是流量伪装。既然拦截器针对第三方域名，就把RUM端点搬到自有域名下。CloudFront正好能干这个：加一条/rum/*的行为规则，代理到AWS的dataplane。

客户端SDK配置跟着改：把默认的dataplane.rum.*.amazonaws.com换成https://yourdomain.com/rum/。请求走的是你的域名，拦截器规则不匹配，数据自然畅通。

作者用AWS CDK实现，但强调CloudFormation、Terraform、控制台都能做。核心就两步：CloudFront加行为，SDK改端点。没引入新服务，没额外成本。

部署前的权限基建

端点伪装只是表面，RUM的授权链不能省。浏览器发遥测前需要临时凭证，这套机制依赖Cognito身份池。

具体要配什么？作者列了四段代码：

打开网易新闻 查看精彩图片

一是身份池本身，开unauthenticated访问。RUM不需要用户登录，但得让匿名浏览器能拿令牌。

二是IAM角色，绑给未认证身份。信任关系里限死cognito-identity.amazonaws.com，加条件过滤：aud匹配身份池ID，amr包含unauthenticated。

三是角色挂载，把身份池和角色关联起来。

四是RUM应用监控器，配域名、采样率、遥测类型。作者开了100%采样（sessionSampleRate: 1.0），追踪performance、errors、http三类数据，顺便启了X-Ray链路追踪。

最后一步给guest角色加权限：rum:PutRumEvents，资源指向刚创建的app monitor。到这里，浏览器才有权往你的/rum/端点塞数据。

这个方案的真正价值

表面看是解决拦截器问题，实际是拿回数据主权。第三方SDK、监控工具、分析服务，多少都埋了类似的域名依赖。今天RUM被拦，明天可能是你的错误追踪、A/B测试、灰度发布。

CloudFront代理模式提供了一种通用思路：敏感功能收归同源，减少对外部域名的暴露。不只是防拦截，也降低CSP（内容安全策略）的复杂度，减少第三方脚本带来的供应链风险。

对25-40岁的技术决策者，这件事的启示在于：监控系统的完整性是架构问题，不是配置问题。默认方案往往假设网络环境理想，真实世界的浏览器插件、企业防火墙、隐私法规都在切割你的数据流。上线前问自己一句：如果30%的用户开着拦截器，我的Dashboard还准吗？

作者没提具体修复后的数据对比，但逻辑清晰——代理后请求走自有域名，拦截器规则失效，样本偏差消除。如果你也在用RUM，现在就可以打开DevTools，看看有没有红色的blocked请求。