跨域跳转之后来源标识丢了，我见过太多团队的第一反应就是打开跳转插件的后台，把参数透传那个开关来回拨弄几遍，要么干脆在URL屁股后面手动糊一段UTM上去。这种做法在同源、单域名那种简单跳转里确实能蒙混过关，可只要链路中间冒出来一次跨域，同样的毛病就会没完没了地复发。为什么会这样？因为来源标识的丢失压根儿就不是某一个开关能兜住的事——它沿着协议层、策略层、插件层、目标页这四层一层一层地衰减下去，你在最后一层做的任何缝缝补补，说白了都只是在接前三层漏下来的残渣而已。
上个月有个做家居流量站的客户找过来，说他们投放后台明明能看到点击数据，落地页也能正常打开，可分析工具里来源一栏清一色全是direct。他们前后换了两个跳转插件，手动补过UTM，甚至把跳转方式从JS改成302，问题照旧。后来我们坐下来按层次一层层拆，最后发现根因卡在响应头的Referrer-Policy上，插件层怎么调都绕不过去。这篇文章我就把这个排查顺序从头到尾讲一遍。
先分清来源标识在跨域链路上会经历哪几次衰减
来源标识这东西，很多人把它当成一个单一字段来看，这就已经偏了。它至少包含三类信号：一个是HTTP Referer请求头，一个是URL上挂着的查询参数（UTM、gclid、自定义渠道码都算），还有一部分场景下要依赖Cookie或者localStorage里存的渠道标记。这三类信号在跨域跳转的时候，存活条件完全不一样，你要是把它们搅在一起谈“丢失”，那基本就是在黑暗里找路。
HTTP Referer的衰减，浏览器和响应头策略说了算，跨域时默认行为受Referrer-Policy控制。URL查询参数呢，衰减取决于跳转插件和中间页的拼接逻辑，任何一次没显式透传的跳转都会把它截断。Cookie和存储类标记的存活，由域名边界决定，跨域之后目标页根本读不到源域的存储。这三条链路的衰减节点各不相同，排查顺序也应该顺着“先协议、再策略、后插件、末目标页”来走。
三类信号的存活条件对照
- HTTP Referer：受Referrer-Policy、HTTPS到HTTP降级、rel="noreferrer"影响，跨域时默认只发送origin，不带完整路径。
- URL查询参数： 只要跳转环节有一次没有显式拼接，就会在当前层丢失，跟跨域本身无关，但跨域场景下中间页更多，丢失概率更高。
- Cookie与存储标记： 同源可读，跨域后目标页无法直接读取源域写入的渠道标记，需要服务端或参数回传才能延续。
把这三类信号掰开来看之后，排查就有了明确的检查项。下面按层次逐一拆解。
协议层：HTTPS到HTTP的降级会直接截断Referer
这一层是最容易被跳过去的。跳转链路里一旦出现从HTTPS页面跳向HTTP目标页的情况，浏览器默认就不发Referer头了。这事儿跟插件没半点关系，是协议层面的安全策略在起作用。很多团队测试环境跑HTTP，生产环境跑HTTPS，测试的时候看着参数都在，一上线就丢，根子就埋在这儿。
验证方法其实很直接：在跳转前的页面打开开发者工具，看Network面板里跳转请求的Referer字段到底在不在。如果跳转目标是HTTP、源页是HTTPS，这个字段大概率是空的。处理方式不是去改插件，而是把整条链路的协议统一到HTTPS，或者在跳转前把需要传递的标识从Referer转移到URL参数上，由插件显式拼接。
- 源页与目标页的协议是否一致，是否存在HTTPS到HTTP的降级。
- 跳转请求的Referer字段在Network面板中是否为空。
- 是否存在rel="noreferrer"或meta referrer标签在页面级别关闭了Referer。
策略层：Referrer-Policy决定了跨域时能带多少信息
Referrer-Policy是响应头或者meta标签里设置的策略，它决定了跨域请求时Referer字段到底发送什么内容。常见取值里，no-referrer完全不发，same-origin只在同源时发，strict-origin-when-cross-origin跨域时只发origin（域名部分，不带路径和参数），unsafe-url则发完整URL。不少站点默认用的就是strict-origin-when-cross-origin，跨域时你只能拿到来源域名，路径和查询参数都拿不到，分析工具自然认不出具体来源。
这里有个容易搞混的地方：Referrer-Policy管的是Referer请求头，它管不着URL上的查询参数。如果你的来源标识是靠UTM参数传递的，Referrer-Policy收紧不会影响UTM，只要插件在跳转时把参数拼上了，目标页照样能读到。所以排查的时候要先确认来源标识靠的是Referer还是靠参数，这两条路的处理方式完全不同。
如果来源标识确实依赖Referer，跨域场景下就得把策略调整到能发送完整信息的取值，但这会带来隐私和合规上的权衡。更稳妥的做法是在跳转插件层把来源信息转成URL参数，让标识不依赖Referer存活。这个决策的边界在于：你的分析工具是否支持从URL参数读取来源，以及你是否能接受URL变长带来的其他影响。
- 源页响应头或meta标签里的Referrer-Policy取值是什么。
- 跨域时实际发送的Referer是完整URL、origin还是空。
- 来源标识依赖的是Referer还是URL参数，两条路径要分开验证。
插件层：跳转时的参数拼接是否完整透传
跳转插件的核心职责之一，就是在跳转时把当前URL上的查询参数带到目标URL上去。但不同插件的默认行为差得挺远，有的默认透传全部参数，有的只透传白名单里那几条，有的遇到重定向链会在中间某一跳直接断掉。排查这一层，得按跳转的每一跳去看参数还在不在。
具体怎么操作呢？在跳转的起点记录完整的查询字符串，然后在每一跳的中间页用开发者工具看当前URL，逐跳比对参数有没有减少。如果某一跳之后参数消失了，问题就出在那一跳的插件配置或者中间页逻辑上。我见过最多的情形是中间页用了服务端302，但302的Location头里没有把原始查询参数拼进去，参数在这一跳就没了。
还有个坑是参数编码。查询参数里如果有中文或者特殊字符，某一跳做了URL编码但下一跳没有解码，参数值就变成乱码，分析工具识别不出来，表现上跟丢失一模一样。排查的时候要把编码前后的值都打出来对比着看。
- 跳转起点、每一跳中间页、目标页的完整查询字符串逐跳比对。
- 302或301的Location头里是否显式拼接了原始查询参数。
- 参数是否存在编码不一致导致的乱码，表现为值可读但无法匹配。
目标页：接收端的读取逻辑是否匹配传递格式
参数传到了目标页，不代表分析工具就能读到。目标页接收来源标识的方式有三种：前端JS从URL读取、服务端从请求里解析、分析工具的SDK自动采集。这三种方式对参数的格式要求不一样，传递格式和读取逻辑一旦对不上，标识照样丢。
打个比方，插件传的是utm_source=baidu，但分析工具配置的是从referrer字段读来源，那参数传了也白传。再比如插件传参用了个自定义的渠道码字段，目标页的JS却只认UTM标准字段，自定义字段就被无视了。排查这一层，先把目标页实际读取的字段名和格式列出来，再回头比对插件传出去的字段名和格式，看是否一一对应。
验证方法是这样：目标页加载后，用开发者工具的控制台把URL上的所有查询参数和分析工具实际采集到的来源字段都打印出来，两者一对比就清楚了。如果URL上有参数但采集字段是空的，问题就出在读取逻辑或者字段名不匹配上。
- 目标页读取来源标识的字段名、格式、读取时机（DOMContentLoaded前还是后）。
- 插件传出的字段名与目标页读取的字段名是否完全一致，包括大小写。
- 分析工具的采集配置是否覆盖了这些字段，是否需要额外的映射规则。
实战复盘：一个家居流量站的来源标识恢复过程
回到开头那个客户。他们做家居品类的内容流量站，日均点击量在一千二三的量级，服务器是两台4核8G的云主机，跳转链路是：投放页（HTTPS）→ 跳转插件中间页（HTTPS）→ 目标落地页（HTTPS）。分析工具用的是常见的第三方统计，来源字段靠UTM和Referer双通道。
他们最早的排查方向全堆在插件层，换了两个插件，手动在跳转URL里补了UTM，问题没解决。后来按层次拆开看：协议层都是HTTPS，降级可以排除；策略层发现源页的Referrer-Policy是strict-origin-when-cross-origin，跨域时Referer只带域名，但UTM参数是拼在URL上的，理论上不受影响；插件层逐跳比对后发现，中间页的302响应里Location头没有拼接原始查询参数，参数在这一跳丢了；目标页的读取逻辑本身没问题。
调整过程分两步走：先把中间页的302逻辑改成显式拼接原始查询参数，确保每一跳都透传；再把Referrer-Policy调整为在跨域时能带完整路径的取值，作为Referer通道的补充。调整后来源标识在分析工具里的识别率从原来的不到三成恢复到八成以上，direct占比明显下降。整个过程没动目标页的任何代码。
这个案例里值得记一笔的是：他们一开始把问题归因到插件“不好用”，但插件本身没有配置错误，是中间页的302逻辑没有透传参数。如果只盯着插件后台的开关，这个问题会一直反复。
按信号衰减顺序走的排查决策边界
把上面四层串起来，排查顺序应该是：先确认来源标识的类型（Referer还是URL参数），再确认协议是否一致，然后看Referrer-Policy的实际发送内容，接着逐跳比对参数是否完整，最后核对目标页的读取逻辑。这个顺序的依据就是信号的衰减方向——越靠前的层，影响面越大，越靠后的层，影响面越小。
选择边界上，如果来源标识依赖Referer，跨域场景下要接受Referrer-Policy的收紧是默认行为，更稳妥的方案是把它转成URL参数传递；如果依赖URL参数，重点就在跳转链路的每一跳是否显式拼接，以及编码是否一致。两条路径的排查重点不同，不要混在一起查。
排查顺序速查
- 确认来源标识类型：Referer、URL参数、还是存储标记。
- 确认协议一致性： 是否存在HTTPS到HTTP的降级。
- 确认Referrer-Policy的实际发送内容： 完整URL、origin还是空。
- 逐跳比对查询参数： 起点、每一跳中间页、目标页。
- 核对目标页读取逻辑： 字段名、格式、读取时机。
这个顺序不是死的，如果第一层就发现了问题，后面的层可以快速跳过。但反过来，从最后一层往前查，很容易在目标页反复改代码却找不到根因。排查的效率差异，就来自是否按信号的衰减方向走。
这套方法不适用哪些场景
需要说明的是，这套排查路径针对的是跳转插件链路里来源标识丢失的问题，前提是链路本身合规、目标页能正常访问。如果目标页自己有访问策略限制，或者跳转链路里存在非标准的中间层（比如某些平台自带的跳转服务），排查路径得相应调整，不能直接套用。
另外，如果来源标识的丢失是间歇性的，比如某些时段正常、某些时段丢失，那还要考虑中间页的缓存策略和CDN节点的差异。这种情况下，逐跳比对的样本要覆盖不同时段和不同节点，不能只看一次请求的结果。这部分属于链路缓存策略的排查范畴，跟本文讲的信号衰减顺序是两条不同的线，需要分开处理。
最后说一句，来源标识丢失的排查本质上是个链路一致性问题。跳转插件只是链路里的一环，把它当成唯一的抓手，问题就会反复。按协议、策略、插件、目标页四层依次检查，每次只改一层并验证，才能把根因定位清楚。
