他花3天做了个反向代理，让40%的"消失用户"重新显形

你上线了一个产品。接入Google Analytics，再配个Amplitude，可能还试了PostHog。一周后打开仪表盘，数字怎么看怎么别扭。

不是小偏差，是系统性崩盘。30%到40%的用户装了广告拦截器，而拦截器从不区分你是千亿广告巨头还是12个用户的 side project。它们一视同仁地掐断所有已知分析域名的请求。你的SDK加载正常，事件触发正常，但数据永远到不了服务器——请求还没离开浏览器，就在www.google-analytics.com被击毙了。

你在用60%的数据做100%的决策。这不是分析，是掷骰子。

Raj Nandan 就是这个掷骰子的人之一。他在2025年初开源了Saki，一个专门解决这个问题的Nginx反向代理。没有配置文件，没有环境变量，一条docker命令就能跑。

docker run -d -p 8765:80 rajnandan1/saki

原理简单到近乎粗暴：让分析请求走你自己的域名。www.googletagmanager.com会被拦截，但your-domain.com/tg/script.js不会——广告拦截器认不出这是分析流量，它看起来只是你站点的普通资源。

两条路线的分野：为什么现有方案"不对劲"

Raj 审视了一圈市面上的解法，发现它们落在两个极端。

一端是付费代理服务。它们确实能工作，但本质是你花钱请人跑Nginx。"这感觉不对"，Raj 在自述里写道。另一端是自建服务端方案：手写代理、处理请求头、折腾CORS、管理路径重写。可行，但烦人。他不愿为维护一个Node.js服务器而分心，只想转发个请求而已。

Saki的定位是"dumber"——更笨，更省事。作为自托管的Nginx容器，它把分析请求从你的基础设施转发出去，而非直连分析服务商。

预置路由覆盖了大多数团队实际在用的服务：Google Tag Manager走/tg/，Google Analytics走/ga/，Amplitude走/amp/，PostHog走/ph/，Plausible走/pl/，Umami走/um/。路径设计刻意模糊，/tg/不会尖叫"我是GTM"，这是故意的。

如果列表里没有你要的服务，加一段Nginx location块就行。只要有域名，Saki就能代理。

一行代码的迁移：从"被拦截"到"第一方"

网站端的改动只有一行。之前：

之后：

SDK不用换，配置不用重写。同一个脚本，换了个主机名。

Saki会转发所有原始信息：User-Agent、Cookie、IP地址、语言、来源页。分析服务商看到的仍是正常请求，完全不知道中间过了道代理。

生产环境建议配个子域名+HTTPS，比如s.yourdomain.com。Railway、Render、Fly.io、VPS都能跑。项目仓库里列了Railway和Render的一键部署按钮，以及Docker Compose示例。

技术细节的取舍：Raj 的"不折腾"哲学

Saki的默认配置暴露了一些设计选择。8765端口映射到容器内的80端口，意味着你可以快速本地测试，但生产环境需要反向代理或负载均衡来终止TLS。Nginx配置里没提缓存策略，每次请求都是实时转发，这对分析场景是合理的——你不需要也没想要缓存遥测数据。

路径前缀的命名很有意思。/tg/、/ga/、/amp/都是两字母缩写，既节省字节，又避免语义暴露。这比一些竞品用/analytics/或/tracking/聪明得多，后者等于主动向拦截器招手。

Raj 没做请求体修改或事件转换。Saki是纯粹的管道，不碰payload。这意味着你没法用它做服务端去重或采样，但也意味着它不会在你和分析服务商之间制造奇怪的bug。

开源协议是MIT，仓库里有完整的Dockerfile，可以自己打镜像。 issue区目前很安静，但项目刚发布不久，生态还在早期。

拦截器战争的下一个回合

Saki的解法并非无懈可击。广告拦截器可以更新规则，识别常见的代理路径模式。/tg/、/ga/这类前缀用多了，就会变成新的黑名单目标。更激进的方案是动态路径——每次部署随机生成前缀，但这也增加了运维复杂度。

另一个角度是法律风险。欧盟部分司法管辖区对"绕过用户明确表达的技术偏好"有严格解释，即便你的分析完全不用于广告。Raj 的文档没提GDPR合规，使用者需要自己评估。

但回到最初的问题：40%的数据黑洞，你填还是不填？

Raj 的选择是填，用最省力的方式。Saki的README结尾没有愿景陈述，只有一行安装命令和预置路由列表。这种克制本身也是一种产品态度——工具就该沉默地完成工作，不抢戏，不制造新问题。