curl -i -X POST https://api.example.com/callback -d '{}'
curl -i -X POST https://api.example.com/callback -b 'sid=expired' -d '{}'
回调接口未登录时跳登录页返回 302，渠道把这当失败，从凌晨重试到第二天上午，日志刷了 9000 行。这类现象通常不是突然出现的，往前翻半天日志能看到苗头。
追下去是这么回事：回调路径被全局登录拦截器覆盖，没有会话上下文就跳转。渠道只认 2xx，3xx 一律按失败处理并进入重试队列。
「回调返回码非2xx」排查到最后往往是很小的一处差异，前面那些复杂猜测可以先放一放。权限不要一口气开到最大，先加到够用再往上试，范围小才好收。
把复现步骤压到三条以内，交给同事也能跑出来，才算真的定位清楚。改动写完就同步给同事，下一个人踩同一个坑，成本还是你的。
处理上按这个顺序：把回调路径加进拦截器白名单 不做登录跳转；回调统一返回 JSON 和明确的 2xx；网关层确认没有额外跳转规则；用不带 Cookie 的 curl 验证返回码。
确认没问题再收工，不带 Cookie 请求返回 200 和 JSON 响应 渠道重试记录停止增长。