嵌了第三方客服窗口，对方后台能看到每个访客从哪一页点进来，地址里带着订单号和 uid，这些信息本来不该出站，截图里清清楚楚。日志里能对上时间点，这种反而好排。
页面和 iframe 都没有设 Referrer-Policy，浏览器按默认策略把完整地址发给第三方，跨域请求照样带上路径和参数。第三方拿到的是一份可读的访问轨迹。这一点先确认清楚，后面就不用反复试。
add_header Referrer-Policy 'strict-origin-when-cross-origin' always; <iframe src='https://chat.example.com' referrerpolicy='no-referrer'></iframe>
「referrer 泄露」改完先别急着全量，挑一台机器放半天，真有问题这段时间就能看出来。先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。
别只看报错的最后一行，往上看几行，真正的起因通常在上面。同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。
处理上按这个顺序：全站响应头加 Referrer-Policy，值用 strict-origin-when-cross-origin，跨域只留域名；iframe 标签上单独写 referrerpolicy，别只依赖响应头；订单页把敏感值从 query 挪进服务端会话。
结果对不对很好判断，打开对方提供的调试页，referer 只剩域名，路径和订单参数都没带过去。