特殊字符目录名本身不导致php-fpm出错，根本问题在nginx层：uri解码与路径拼接不一致、rewrite未转义引发截断、php_value[doc_root]与nginx root不匹配、locale非utf-8致stat失败。
特殊字符目录名（如含空格、中文、括号、&、#、% 等）本身不会直接导致 PHP-FPM 出错，但会引发 Nginx 重定向失败或脚本无法执行——根本原因在于 URI 解码、路径拼接和 fastcgi 参数传递过程中的不一致。PHP-FPM 本身只接收并执行 Nginx 传来的 SCRIPT_FILENAME 路径，它不解析 URL 或参与重定向逻辑；真正“卡住”的环节在 Nginx 配置层。
URI 编码与 Nginx 的路径匹配脱节
Nginx 的 location 匹配发生在解码前（raw URI），而 $document_root 和 $fastcgi_script_name 拼接时若未同步处理编码状态，会导致物理路径错误。例如：
- 请求 URL 是
/api/v2/用户列表/get.php（含中文），浏览器自动编码为/api/v2/%E7%94%A8%E6%88%B7%E5%88%97%E8%A1%A8/get.php - Nginx 的
location ~ \.php$仍能匹配，但$fastcgi_script_name默认是解码后的路径（/用户列表/get.php） - 若
root目录下实际文件路径是/var/www/html/用户列表/get.php，则$document_root$fastcgi_script_name可能拼出正确路径；但若 Nginx 内部对$fastcgi_script_name处理异常（如某些旧版本或自定义 rewrite 后未重置），就可能变成/var/www/html/%E7%94%A8%E6%88%B7%E5%88%97%E8%A1%A8/get.php，文件自然找不到
rewrite 规则中未转义特殊字符引发循环或截断
当使用 rewrite 将带特殊字符的路径重写为标准路由时，若正则表达式未正确转义或捕获组内容含未处理的编码字符，容易导致：
- 重写后路径被截断（如
&被当作查询参数分隔符） - 重定向跳转 URL 缺失部分路径（如中文目录名在
return 301中未用$uri而误用$request_uri，后者含原始编码，而浏览器跳转时可能二次编码） - 出现 301/302 循环（如 rewrite 条件反复触发）
✅ 正确做法：对重定向目标使用 encode 函数（Nginx 1.11.8+ 支持 escape）或确保使用 $uri（已解码）而非 $request_uri（原始编码）；对 rewrite 中的变量做显式转义，例如：rewrite ^/([^/]+)\s+([^/]+)\.php$ /_.php last; → 改为更安全的匹配方式，避免依赖空格等易出错字符。
PHP-FPM 接收路径时的 doc_root 干扰
若 PHP-FPM 配置中启用了 php_value[doc_root]（尤其在多租户或 Magento 类应用中常见），该值会强制限制脚本必须位于指定根目录下。当 Nginx 的 root 指向一个含特殊字符的路径（如 /home/站点-测试/pub），而 doc_root 却写成硬编码的 ASCII 路径（如 /home/site-test/pub），PHP-FPM 会拒绝执行，报错 “No input file specified”。
✅ 解决方法：要么将 php_value[doc_root] 完全删除（推荐），让 PHP-FPM 完全信任 Nginx 传入的 SCRIPT_FILENAME；要么确保其值与 Nginx 的 root 完全一致（包括字符编码、大小写、符号），且路径存在可读。
权限与文件系统层面的隐性阻断
Linux 文件系统对 UTF-8 中文目录名支持良好，但若服务器 locale 设置异常（如 LANG=C）、Nginx 进程启动环境未继承 UTF-8 编码，或 PHP-FPM worker 以不同用户/环境运行，可能导致：
- Nginx 能列出目录，但
stat()系统调用对含中文路径返回 ENOENT - PHP-FPM 日志中显示路径乱码，实际是环境变量缺失导致路径解析失败
✅ 检查并统一设置：sudo localectl set-locale LANG=en_US.UTF-8
并在 PHP-FPM pool 配置中显式声明：
env[LANG] = en_US.UTF-8<br>env[LC_ALL] = en_US.UTF-8
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
