你有没有遇到过这种情况：后台显示用户活跃度正常，但前端监控仪表盘上的页面浏览量却低得离谱？一位AWS工程师最近就碰上了这茬——排查半天发现，uBlock Origin把CloudWatch RUM的数据请求全拦了。
这不是个例。随着广告拦截器渗透率飙升，越来越多的"合法"遥测数据正在被误杀。而解决方案出人意料地简单：把AWS的监控端点藏进你自己的域名。
一、问题：RUM的"隐身"盲区
CloudWatch RUM（真实用户监控）是AWS里被低估的宝藏服务。页面加载时间、JavaScript报错、HTTP失败、Web Vitals核心指标——这些直接影响用户体验的数据，它都能抓。
但有个致命盲区。
RUM默认把数据发往dataplane.rum.*.amazonaws.com。广告拦截器的规则库不区分"好遥测"和"坏追踪"：凡是第三方域名往外传数据，一律按可疑处理。工程师打开DevTools时看到的一幕很说明问题——uBlock Origin安安静静地屏蔽了每一条RUM请求，仪表盘对这部分用户完全失明。
原文作者的原话是：「Our real user monitoring was blind to a non-negligible portion of our actual traffic.」
翻译过来：非 negligible（不可忽略）的流量，正在从你的监控视野里消失。对于依赖数据做产品决策的团队，这是系统性偏差。
二、原理：为什么域名成了命门
广告拦截器的判断逻辑很粗暴：看域名。你的业务代码跑在myapp.example.com，RUM数据却飞向amazonaws.com——跨域、第三方、Telemetry，三重标签叠加，触发拦截几乎是必然的。
这背后的用户心理也合理：普通用户装广告拦截器，本就不打算区分"Google Analytics"和"CloudWatch RUM"。他们要的是清净，不是技术考古。
但代价转嫁给了开发者。你以为是用户流失，其实是监控失效；你优化了性能，却看不到真实用户的加载体验。数据缺口会扭曲所有下游决策。
三、解法：用CloudFront做一层代理
修复方案的核心思路是域名归一化：让RUM请求看起来像你网站的一部分。
具体架构：
1. 在CloudFront上加一个行为路径/rum/*
2. 这个路径代理到RUM的真实数据平面端点
3. 前端SDK不再直连AWS，而是指向https://yourdomain.com/rum/
广告拦截器扫域名时，看到的是同源请求，放行概率大幅提升。
实现上，作者用的是AWS CDK，但CloudFormation、Terraform、控制台手动配置都能跑通。关键是理解这个代理层的作用：它不是绕开用户选择，而是消除"误伤"——你的RUM数据对业务运维是必要的，不该和广告追踪混为一谈。
四、落地：身份池与权限的坑
RUM的授权机制依赖Amazon Cognito身份池。浏览器端是未认证用户，需要显式开启allowUnauthenticatedIdentities: true。
权限链条要串好：
- 身份池 → IAM角色（WebIdentityPrincipal）
- 角色策略 → rum:PutRumEvents动作
- 资源范围限定到具体App Monitor ARN
作者贴出的CDK代码里有个细节：Cognito角色的信任策略要匹配amr: unauthenticated，这是浏览器匿名访问的凭证来源。漏了这一环，前端SDK会报授权失败，但错误提示往往模糊成"网络问题"，排查起来很耗时间。
配置参数建议：
- sessionSampleRate: 1.0 全量采集（小流量场景）
- enableXRay: true 开启分布式追踪联动
- telemetries 数组按需选性能、错误、HTTP三类
五、延伸：这场猫鼠游戏的边界
代理方案不是银弹。极端情况下，广告拦截器可以进化到检查请求体内容、分析流量模式。但在当前生态里，域名白名单仍是主流策略，同源代理的通过率显著高于第三方直连。
更深的问题是谁来定义"合法遥测"。RUM收集的是性能数据，不含个人身份信息，但用户没有技术能力分辨。拦截器的粗粒度规则是效率与误伤的权衡，开发者的应对则是技术层面的精细化规避。
这对产品团队的启示是：监控基础设施的设计，必须前置考虑客户端环境的不确定性。等数据缺口暴露再补，损失已经发生了。
原文作者最后没说的潜台词：如果你还在用默认端点，你的RUM仪表盘可能正在系统性地低估真实流量。检查一遍DevTools的网络面板，看看有没有红色的拦截标记——这五分钟，值得花。
热门跟贴