对于很多人来说，配置Nginx PHP无非就是搜索一个教程，然后复制粘贴。看似没毛病，但实际上网上很多资料年久失修，漏洞百出。如果你不知道该怎么做，只是复制粘贴，你迟早会为此付出代价。

假设我们用PHP实现了一个前端控制器，或者说白了就是一个统一的入口：将所有PHP请求发送到同一个文件，然后通过解析这个文件中的“REQUEST_URI”来实现路由。

一般来说，很多教程都会教你这样配置Nginx PHP:

服务器{ listen 80服务器名foo.com；根/路径；位置/{索引index.html index.htm index.php；if(！-e $request_filename) {重写。/index . PHP last；} }位置~ /。php $ { include fastcgi _ paramsfastcgi _ param SCRIPT _ FILENAME/path $ fastcgi _ SCRIPT _ name；fastcgi _ pass 127 . 0 . 0 . 1:9000；index.php指数；}}错误很多，至少品味不好。看看就能发现几个。我们有必要了解一下Nginx配置文件中指令的继承关系：Nginx配置文件分为很多块，分别是“http”、“server”、“location”等。从外到内。默认的继承关系是从外到内，这意味着内部块会自动获取外部块的值作为默认值。

让我们从“索引”命令开始，该命令在问题配置的“位置”中定义：

位置/{索引index.html index.htm index.php；}未来一旦需要添加新的“位置”，必然会出现重复定义的“索引”命令。这是因为很多“位置”是横向关系，没有继承关系。这时，“索引”应该在“服务器”中定义。通过继承关系，“索引”命令可以在所有“位置”生效。

让我们看一下“if”命令，并说每个人最误解的是Nginx命令：

if(！-e $request_filename) {重写。/index . PHP last；}很多人喜欢用“if”命令做一系列检查，但这实际上是“try_files”命令的责任：try _ files $ uri $ uri//index . PHP；此外，初学者往往认为“if”指令是内核级指令，但实际上是重写模块的一部分，Nginx配置实际上是声明性的，而不是过程性的，因此当它与非重写模块的指令混合时，结果可能不是您想要的。

看看“fastcgi_params”配置文件包含fastcgi _ params；Nginx有两个fastcgi配置文件，即“fastcgi_params”和“fastcgi.conf”，两者差别不大。唯一不同的是，后者对“SCRIPT_FILENAME”的定义比前者多了一个：fastcgi _ param SCRIPT _ FILENAME $ document _ root $ fastcgi _ SCRIPT _ name；注意：$document_root和$fastcgi_script_name之间没有/的关系。最初，Nginx只有“fastcgi_params”。后来发现很多人在定义“SCRIPT_FILENAME”时使用硬编码，于是引入了“fastcgi.conf”来规范用法。然而，一个问题出现了：为什么必须引入新的配置文件，而不是修改旧的配置文件？这是因为“fastcgi_param”命令是数组类型，和普通命令一样：内层替换外层；与普通指令不同的是，当它在同一级别多次使用时，它是添加的，而不是替换的。换句话说，如果“SCRIPT_FILENAME”在同一级别定义了两次，它们都会被发送到后端，这可能会导致一些潜在的问题。为了避免这种情况，引入了新的配置文件。此外，我们还需要考虑一个安全问题：当PHP打开“cgi.fix_pathinfo”时，PHP可能会将错误的文件类型解析为PHP文件。如果Nginx和PHP安装在同一个服务器上，最简单的解决方法就是使用“try_files”命令过滤一次：try _ files $ uri=404改进版根据前面的分析，给出了一个改进版，是不是比最初的版本清爽很多：

服务器{听80服务器名foo.com；根/路径；index.htmlindex.htmindex.php指数；location/{ try _ files $ uri $ uri//index。PHP $ is _ args $ args}位置~ /。php $ { try _ files $ uri=404包括fastcgi.conffastcgi _ pass 127。0 .0 .1:9000;}}以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持我们。