我把跳转链路追了一遍，我把这种“伪装成活动页面”的链路追完了：真正的钩子在第二次跳转
最近追查了一串看似普通的“活动页面”跳转链路，结果发现套路比想象中更精细：第一跳是幌子，第二跳才是收割真实流量和归因的钩子。把过程、识别办法和应对策略整理成一篇，方便同业和有防护需求的同学参考。
为什么这类链路危险但难以察觉
- 表面上是正常的活动页：促销、抽奖、下载等，用户体验毫无违和感；
- 第一跳通常是静态 200 页面或带有轻量 302 的跳转，能骗过简单的抓包和自动化检测；
- 真正的重定向由页面内脚本在加载后触发，可能是隐藏 iframe、XHR 返回后导航、或通过 window.location.replace 实现；
- 第二跳常常携带动态 token、referrer 串联和设备指纹，能把转化归到指定的合作方或广告网络。
我怎么追踪这条链路（实战步骤） 1) 基础手段：先用 curl 检查服务器端 3xx
- curl -I -L https://example.com 可以看到服务器端链路，但不会揭示 JS 驱动的后续跳转。
2) 浏览器层追踪：Chrome DevTools 是最直接的工具 - Network 面板勾选 Preserve log 并禁用缓存；
- 观察 document、xhr/fetch、iframe、ws 等请求；
- 在 Sources 面板用 Event Listener Breakpoints（DOM -> subtree modifications、XHR/fetch）来捕获脚本触发点。
3) 阻断跳转观察过程：在 Console 里临时替换导航函数 - 例如输入 window.location.assign = function(url){ debugger; }; 或 window.location.replace = function(url){ console.log('replace', url); };
- 这能拦截 JS 导航，让你看到真正发起跳转的时机与参数。
4) 查看隐藏请求：搜索 meta refresh、form auto-submit、document.createElement('iframe')、eval/atob 等可疑模式 - 有些页面把跳转 URL 放在一个 XHR 响应里，页面加载完再去请求后端获取“下一步”的真实目标。
5) 使用代理工具解密链路：mitmproxy / Burp 可以记录浏览器内的所有请求/响应，同时修改请求以测试条件分支（UA、cookie、geo）。 6) 自动化复现：用 Puppeteer/Playwright 抓取完整浏览器行为，记录页面事件与最终跳转目标；可在脚本里截获所有导航请求并保存链路。
常见的第二跳手法（我遇到的案例）
- XHR 通知 + window.location.replace：页面先载入“活动页”，然后发起一个后台请求，返回带 token 的跳转地址，响应被 JS 解析后直接替换当前页面。
- 隐藏表单自动提交：通过构造一个带有目标域的表单并 auto-submit，把用户浏览器当作“传递器”。
- iframe 嵌套再跳转：在主页面插入一个指向中间域名的 iframe，iframe 内再执行跳转或上报。
- 服务端链路切换：初次点击走 CDN 域或缓存页，随后在用户会话建立后，服务端根据规则下发第二跳的真实归因 URL。
- JS 混淆或加密：使用 base64、eval、映射数组等隐藏真实 URL，增加人工审查成本。
如何判断是否被“套链”
- 链路长度超过 2 次且第二次目标不透明；
- 跳转带有明显的归因参数（aff、sub、token、clickid 等）并非你方生成；
- 页面加载后出现额外的跨域请求到陌生追踪域名；
- 同一 URL 在不同环境（清除 cookie、不同 UA）表现不同。
应对建议（给流量方和检测方的实操清单）
- 抓取完整浏览行为而不是只看 HTTP 3xx：使用浏览器级采集或 headless 自动化技术；
- 在 QA/审计环节采用断点调试，拦截 window.location 家族函数并记录调用栈；
- 对流量引荐方做渠道与域名白名单，任何链路中出现未知第三方应触发复审；
- 在合约/业务端声明对多级重定向和第三方追踪的透明度要求；
- 建立自动化检测脚本：用 Puppeteer 加载链接、监听所有导航事件、比对初始和最终域名、导出链路日志；
- 对可疑脚本做静态解析：把混淆后的脚本 prettify、搜索 atob/eval、解码后再分析。
一个简单的 Puppeteer 验证脚本思路
- 启动浏览器，打开页面；
- 监听页面的 request 和 response，记录所有导航类型请求（document navigations）；
- 在控制台注入替换函数拦截 window.location，以便在跳转前记录目标；
- 输出完整的时间序列日志，包含每一跳的请求头、Referer、响应码和页面内触发点。
结论：别被第一屏迷惑 第一跳往往是为人眼设计的静态“活动页”，用以获取用户信任和通过人工审查；真正能改变流量归属、传递 token 并触发计费的是第二跳或更深层的脚本行为。对于任何依赖转化数据的团队，单看第一个页面是不够的，必须把链路“追完”——把所有脚本和中间域名都看清楚，才能判断这次活动是不是你想要的流量，或者是否存在被动导流和不当结算。
