这个坑值得记一笔。网关日志把完整 URL 记了下来，脱敏规则只覆盖 Authorization 头和手机号，安全扫描报出日志里有 access_token 参数，抽查发现分享链接和回调地址都带着它，Referer 里也有。
刚开始盯着「Referer 头里带着上一跳的完整 URL」，折腾了半个多小时，排掉了。
把日志和配置对完，能解释这个现象的基本就这几处。脱敏规则只匹配请求头，没有处理 query 参数；各服务参数名不统一，有 token 也有 access_token；异常堆栈里把整条 URL 原样打印了出来。
扫一遍日志确认泄露的参数名
python -c "import re;s=open('access.log',encoding='utf-8').read();print(set(re.findall(r'[?&]([a-z_]*(?:token|key|secret))=',s)))"然后按参数名统一替换成掩码
python -c "import re;t='https://a.cn/p?access_token=abc123&x=1';print(re.sub(r'([?&](?:access_token|token|key)=)[^&]+',r'\1***',t))"接着在网关层统一脱敏后再落盘
python redact.py --in access.log --out access_clean.log --rules query,header,referer复扫清洗后的日志确认没有残留
python redact.py --scan access_clean.log --pattern 'token=[^&*]'怎么算真的好了，看的是同一批现象。清洗后的日志里所有 token 参数都是三个星号，Referer 中的同类参数也被处理，复扫零命中。
补一句。密钥泄露往往不在请求头而在 URL 和 Referer，脱敏规则要按字段语义写，不能只盯着 Authorization。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。