FastCGI重定向失败主因是Nginx与后端协同中URL解码、路径传递或Location头生成异常，需检查REQUEST_URI传递、proxy_redirect规则、SCRIPT_NAME/PATH_INFO设置及日志分层验证。
FastCGI 本身不直接处理重定向，重定向失败的根源通常在 Nginx 配置与后端（如 PHP-FPM）协同环节中——当目录名含特殊字符（如空格、中文、`%`、`+`、`{}`、`[` 等）时，URL 解码、路径传递或 Location 头生成容易出错，最终表现为跳转地址错误、404 或循环重定向。
检查 URL 解码是否被提前破坏
Nginx 默认会对请求 URI 进行一次解码（如 /api/%E4%B8%AD%E6%96%87/ → /api/中文/），但 FastCGI 协议要求将原始未解码的 URI 通过 REQUEST_URI 传给 PHP。若中间有 rewrite、proxy_pass 或自定义变量拼接，可能造成双重解码或乱码：
- 避免在
fastcgi_param REQUEST_URI中手动拼接或使用$request_uri以外的变量（如$uri已解码，不适合传给后端做重定向依据） - 确认未启用
merge_slashes off或非标准location正则匹配，否则含特殊字符的路径可能无法命中预期块 - 用
curl -v "http://host/%E4%B8%AD%E6%96%87/"查看 Nginx access.log 中的$request_uri和$uri是否一致，不一致说明解码时机异常
确保后端生成的 Location 头可被 proxy_redirect 正确改写
PHP 等应用常基于 $_SERVER['REQUEST_URI'] 或 $_SERVER['SCRIPT_NAME'] 拼接跳转地址。若原始路径含空格或中文，而 Nginx 的 proxy_redirect 规则只匹配 ASCII 路径，就会失效：
- 后端返回的 Location 若为
Location: /admin/用户管理/，需配置proxy_redirect ~^(/[^"]*)$ /admin$1;类似的正则规则（注意引号和编码边界） - 更稳妥的做法是关闭自动改写：
proxy_redirect off;，改由后端自己输出符合代理上下文的绝对路径（如https://example.com/admin/用户管理/） - 若用
fastcgi_param REDIRECT_URL或自定义 header 透传原始路径，确保 PHP 代码中对特殊字符做了rawurlencode()处理再拼入 Location
验证 FastCGI 参数是否保留原始语义
关键参数必须准确传递，尤其涉及路径构造的字段：
-
fastcgi_param SCRIPT_NAME "";：若设为空或错误值，PHP 可能误判脚本根路径，导致header("Location: /xxx")相对跳转出错 -
fastcgi_param PATH_INFO $fastcgi_path_info;：当用 PATH_INFO 模式（如/index.php/user/中文）时，确保$fastcgi_path_info包含完整未解码路径段 - 禁用
fastcgi_split_path_info的默认正则，或自定义适配中文/空格的表达式，例如：fastcgi_split_path_info ^(.+?\.php)(/.*)$;改为^(.+?\.php)(/.*)$并配合if判断，防止空格截断
用日志和 curl 定位具体断裂点
不要依赖浏览器跳转结果，分层验证每一步：
- 开启 Nginx 自定义日志格式，记录
$request_uri、$uri、$fastcgi_script_name、$fastcgi_path_info - 在 PHP 中打印
$_SERVER['REQUEST_URI']、$_SERVER['PATH_INFO']、$_SERVER['SCRIPT_NAME']，确认是否已损坏 - 用
curl -v请求含特殊字符的路径，观察响应头中Location:的原始值，再比对 Nginx access.log 中$upstream_http_location是否一致
