落地页投放数据里出现“有点击、无转化”，服务器日志却显示请求先返回 302 再返回 200；或者浏览器地址栏始终停在中间页、最终页面未进入转化统计。这些现象通常不是广告素材问题，而是跳转链路的响应状态码、Location 头或缓存控制出现偏差。处理它的价值在于：一次跳转链路状态码核验清单可以同时定位归因丢失、版本错发和客户端空白页三类问题。本文按照上线前、运行中、异常后三个阶段展开，覆盖状态码语义、响应头核验与链路位置验证。
上线前：核验跳转链路的静态配置与状态码预期
上线前检查重点不是确认“能跳”，而是确认“跳得对”。如果状态码语义被写错，发布后很难通过页面展示直接发现。建议逐项核对以下内容。
- 明确 302 与 307/308 的边界：302 表示临时重定向，部分客户端会把 POST 改写为 GET；307 和 308 会保留请求方法与请求体。需要根据跳转后是否继续处理 POST 数据来决定，不要在同一链路中混用。
- Location 头使用绝对地址：Nginx 的 return、rewrite 与 PHP 的 header 都可以生成跳转，但相对地址在反向代理、CDN 或本地调试环境下可能解析到错误主机。通用示例如下：
BLOCK0
- 检查 Set-Cookie 与跳转的先后关系：如果跳转响应中同时返回 Set-Cookie，要确认 Cookie 是否先于跳转写入。否则后续页面版本判断会因缺少会话标识而失效。
- 控制跳转层数并记录来源：多层跳转会让状态码组合变复杂，建议在满足内容适配需求的前提下尽量压缩层数，并在每层写入统一的 X-Redirect-By 标记。
- 与页面版本规则做一次对照：上线前把跳转落点与为不同访客群体返回的页面版本逐条对照，确认 302 后的最终渲染版本与预期一致。可以先梳理请求全链路时序，再校验跳转节点与页面响应的先后关系。
这些检查项背后的共同原因是：上线后一旦出现状态码语义错误，往往表现为部分设备正常、部分设备异常，排查成本远高于上线前一次静态核验。
运行中：监控状态码比例与响应头变化
运行中不能只看页面是否打开，还要关注状态码比例和响应头是否随时间变化。可以从 Nginx access_log 中按状态码聚合，或把 3xx 响应单独输出到监控面板。
- 3xx 比例突然升高：如果 302 占比明显增加而 301 几乎消失，可能是规则改动把永久跳转改成了临时跳转。301 和 302 对部分广告平台的页面抓取和归因处理不同，应保持稳定。
- 200 与 302 交替出现：同一 URL 有时返回 200，有时返回 302，通常与缓存或 UA 判断有关。需要检查是否缺少 Vary: User-Agent，以及 CDN 缓存键是否包含 UA、Cookie 或设备类型。
- 响应头膨胀：一个跳转响应中出现多个 Set-Cookie 或多个 X-Redirect-By，说明多个中间层都在处理跳转。建议每层只写自己的标记，避免后续故障时无法定位是哪一层多加的状态码。
- 跳转耗时异常：跳转响应本身应当轻量，通常在几十毫秒到几百毫秒之间。若耗时明显偏长，优先检查 PHP 执行、文件读取或外部回源，而不是先增加服务器资源。可以参考流量识别链路时延优化中的时序排查方法。
运行中的状态码监控比单纯看流量涨跌更能提前暴露配置变更问题，因为状态码变化往往先于转化数据出现明显下滑。
异常后：按状态码与链路位置定位故障
当跳转链路已经影响投放时，建议按照“状态码—响应头—链路位置”的顺序定位，而不是直接重启服务或回滚最近一次改动。
- 最终页返回 404：先看 Location 头是否受请求 Host、X-Forwarded-Proto 或 CDN 回源参数影响，再检查规则中是否误过滤了关键 URL 参数。可以用 curl -I 逐跳查看状态码和 Location。
- 同一 URL 反复重定向：日志中常见“302 后继续 302”，且 Location 指向前一层或自身。通常与主机名、协议头或 URI 正则反向引用写错有关。需要对比 Nginx rewrite 的 last 与 redirect 标志差异。
- 最终页返回 200 但空白：这种症状常伴随“headers already sent”类错误。原因是 PHP 在发送 header 前已经输出 BOM、空白字符或警告信息，导致跳转未生效。需要检查文件是否为无 BOM 编码，并确认 output_buffering 配置。
- 502 或 504：跳转请求转发到上游超时，说明 PHP-FPM 工作进程可能耗尽或慢日志堆积。应优先查看进程池状态和慢日志，再决定是否调整进程数或超时参数。
- 移动端与桌面端版本错发：先确认 UA 判断发生在跳转前还是跳转后，再看 CDN 是否缓存了其中一个版本并回源到同一 URL。处理顺序通常为清缓存、验 UA、回放请求。
异常后的检查项都是为了回答同一个问题：状态码在哪个节点开始偏离预期。找到该节点后，修复范围会缩小到一个配置片段或一个响应头字段。
小结：上线前固定语义、运行中监控变化、异常后按节点定位，这三段共同构成跳转链路状态码核验清单。将其固化为发布前检查单和日志巡检规则，可以减少投放数据异常时从头排查的时间。
常见问题
跳转链路状态码 302 和 307 有什么区别？
302 是临时重定向，部分客户端会把 POST 改写为 GET；307 也是临时重定向，但保留原始请求方法和请求体。如果跳转后仍需要处理 POST 数据，应使用 307 或 308。
跳转响应返回 200 但最终页面空白是什么原因？
通常是 PHP 文件在发送 header 前已输出 BOM、空格或错误信息，导致跳转头没有生效，最终由当前脚本返回 200。需要检查文件编码和输出缓冲设置，并查看错误日志中的 headers already sent 提示。
如何判断跳转是否出现死循环？
可以通过命令行连续请求同一 URL，观察每次返回的状态码和 Location 头。如果 Location 指向自身或在前几跳中重复出现，说明规则存在循环重定向，需要检查主机名、协议和正则反向引用。
上线前需要核验哪些响应头？
至少要核验 Location、Set-Cookie、Cache-Control、Vary 和 X-Redirect-By。Location 应为绝对地址；Set-Cookie 要确认是否在跳转前写入；Vary 对移动端版本切换影响较大。
状态码 301 和 302 对广告归因有影响吗？
有影响。301 表示永久移动，浏览器和部分爬虫会更新缓存并减少重复抓取；302 表示临时移动，适合保持原地址继续参与投放统计。混用两类状态码可能导致部分平台对落地页版本和归因参数处理不一致。
延伸阅读
如果还想补齐状态码之外的重定向方式与使用场景，可以继续阅读页面跳转技术指南，补充 302、JS 与 Meta 刷新在实际链路中的选择依据。
