Caddy 默认的 php_fastcgi 配置会将所有未匹配路径重写到 index.php，导致 404 请求返回 200 状态码和首页内容；本文详解如何通过自定义 try_files 行为修复该问题，确保真实 404 响应正确返回。
caddy 默认的 `php_fastcgi` 配置会将所有未匹配路径重写到 `index.php`，导致 404 请求返回 200 状态码和首页内容；本文详解如何通过自定义 `try_files` 行为修复该问题，确保真实 404 响应正确返回。
在使用 Caddy + PHP-FPM 构建 Web 服务时，一个常见但易被忽视的问题是：访问不存在的路径（如 example.com/invalid/route.php）并未返回标准的 404 响应，而是意外加载了根目录下的 index.php，且 HTTP 状态码为 200 OK。这不仅破坏 RESTful 语义、影响 SEO 和 API 可靠性，还可能暴露不期望的路由逻辑。
根本原因在于 Caddy 的 php_fastcgi 指令默认启用了隐式路由器行为：它假设站点根目录存在 index.php 并将其作为“前端控制器”（如 Laravel、Symfony 的典型模式），因此自动将所有未命中静态文件的请求 fallback 到 index.php。这一行为由内置的 try_files 逻辑驱动，而非用户显式配置。
要解决该问题，必须显式覆盖默认的 try_files 行为，让 Caddy 在转发前严格校验 PHP 文件是否存在。推荐采用 Caddy 官方文档中提供的“展开式”（expanded form）配置，替代简写的 php_fastcgi 单行指令：
:80 {
root * /var/www/example.com
file_server
# 替换原 php_fastcgi 行：显式控制文件查找顺序
@phpFiles {
path *.php
file {path}
}
reverse_proxy @phpFiles localhost:9000 {
transport http {
read_timeout 30s
write_timeout 30s
}
}
# 关键：仅当 .php 文件真实存在时才代理；否则继续匹配后续处理器（触发 404）
@notFound {
not file {path}.php
not file {path}
}
handle @notFound {
respond "Not Found" 404
}
encode gzip
}✅ 关键改进说明：
立即学习“PHP免费学习笔记（深入）”；
- 使用
@phpFiles匹配器精确限定仅对真实存在的.php文件路径发起 FastCGI 代理； - 移除全局
try_files {path}.php {path}，避免无条件 fallback； - 通过
@notFound显式捕获既非 PHP 文件也非静态资源的请求，并统一返回404； - 保留
file_server的默认 404 处理能力（当请求静态资源不存在时自动生效）。
⚠️ 注意事项：
- 若你确需前端控制器模式（如使用 WordPress 或 Laravel），则不应禁用
index.phpfallback，而应确保应用层正确处理 404（例如 Laravel 的abort(404)）；此时问题根源在 PHP 应用本身，而非 Caddy 配置。 - 修改后务必重启 Caddy：
sudo systemctl reload caddy或caddy reload； - 建议配合
curl -I http://localhost/invalid/path.php验证响应头中的HTTP/1.1 404 Not Found状态码。
通过此配置，Caddy 将严格遵循“存在即服务，不存在即报错”的原则，兼顾 PHP 动态能力与 HTTP 语义规范，为生产环境提供健壮、可预测的路由行为。
