FastCGI 没有跳转

CGI 脚本已经输出 Location，经 Caddy 的 FastCGI 代理后，响应却是 200 OK，浏览器停在原页面。若脚本没有输出 Status，Caddy 2.11.7 的状态解析分支会产生这种结果。

这里针对 fcgiwrap 等 FastCGI 响应器转交 CGI 输出的场景。PHP 通常会自己输出重定向状态，不一定经过这条缺失 Status 的分支；普通 HTTP 上游返回 200 和 Location，也不能直接套用 CGI 的状态约定。

Location 存在，不代表客户端收到了重定向

CGI 的客户端重定向可以只输出一个绝对目标地址，随后结束响应头。服务器应将这种输出转换成 302 Found。Caddy 2.11.7 的 FastCGI 客户端却在没有 Status 时直接采用 200，没有根据 Location 改为 302。

先保留一个不产生业务写入的受控请求，查看实际状态码和 Location，暂时不要自动跟随跳转。对照 CGI 产生的响应头，确认缺失的是 Status，而不是目标地址被改写或请求落到了其他入口。

同时记录运行中的 Caddy 版本和代理 transport。只有实际使用 FastCGI 的请求才经过这条解析路径；修改 HTTP 反向代理或静态文件配置不会影响它。

在 CGI 输出中明确给出状态

能够修改脚本时，让原有重定向分支显式输出状态。下面是 shell CGI 的响应输出示例，目标地址要替换为业务允许的地址，且这些内容必须在任何其他响应头或正文之前输出：

printf '%s\r\n' \
  'Status: 302 Found' \
  'Location: https://example.com/new' \
  'Content-Type: text/plain; charset=utf-8' \
  '' \
  'Redirecting.'

空字符串输出的是响应头与正文之间的空行。保留脚本原来的运行环境与 FastCGI 接入方式；这段只说明重定向分支如何输出，不是替换整份应用脚本。

已有明确状态时，Caddy 会按它解析响应。不要给所有带 Location 的 200 强制改成 302，也不要覆盖业务原有的 301、303 或其他经过设计的跳转行为。若目标来自请求参数，需要沿用应用的目标地址校验，不能把外部输入直接拼成任意跳转。

修复已进入源码，稳定版边界仍要核对

截至 2026 年 10 月 14 日，对缺失 Status 且存在 Location 的情况返回 302 的修复已经合入源码；已核对的最新稳定版仍是 2.11.7。不能仅因为问题已经关闭，就把这个稳定版写成已包含修复。

后续升级前检查实际发布版本是否包含这一改动，并保留自定义模块、配置与可恢复的二进制。当前可以通过脚本显式给出状态处理，不必先换成未经项目验证的开发构建。

修改后检查响应确实为预期的重定向状态，Location 正确，浏览器能够到达目标。再验证普通响应仍为 200、原有显式状态未改变，以及认证和会话行为没有回归。

需要恢复时撤回脚本的这次输出修改，按原发布流程恢复并重新检查响应。若脚本已经输出正确状态，而客户端仍收到 200，应继续查实际响应器、中间代理和请求入口，不能重复修改同一个 CGI 头。