他花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結尾沒有愿景陳述，只有一行安裝命令和預置路由列表。這種克制本身也是一種產品態度——工具就該沉默地完成工作，不搶戲，不制造新問題。