Linux 下 Nginx + PHP 环境的配置

2017-12-11

Web

技术

本来想简单地写一写，结果发现越写越长，折腾了将近一个月，整出这篇 10000 多字的超长笔记…

从我开始折腾 WordPress、Typecho 博客至今，我折腾过无数次 Nginx 的安装、配置与 PHP 环境的搭建，看过各种各样的教程，它们往往都有一个共同点，就是仅仅是给你一些现成的命令复制粘贴，它们大多只是从操作的角度出发，并没有太多原理上的阐述。就像之前我看到火丁笔记博客的一篇文章所说：“如果大家不求甚解，一味的拷贝粘贴，早晚有一天会为此付出代价。”所以我希望通过这篇文章，能够在一个不一样的角度去描述这个过程，希望能对看到这篇文章的你有所帮助。

本文假定读者对 Linux 命令、程序的IO、HTTP 协议、基本的PHP语法、正则表达式有大致的了解。

1. 服务器后端做的事情

首先我们应该对网站的结构有一个基本的认识，通常来说一个网站的分为前端与后端两部分。它们相互依存，前端在用户的浏览器中，负责内容的显示和交互。后端负责处理浏览器发来的请求，根据不同的请求生成与请求对应的不同的响应返回给前端展示给用户。

浏览器与服务器之间需要通信，需要有一个统一约定的标准才能互相交流，这里用到的最主要的标准就是 HTTP 协议啦。（可能有的网站会用WebSocket等协议，但这篇文章只讨论HTTP的内容）

从本质的角度来看，后端的主要工作就是处理浏览器发来的 HTTP 请求，并根据服务器程序的业务逻辑返回这些请求对应的 HTTP 响应给浏览器。后端返回的响应，可以是一段 HTML/CSS/JavaScript 代码、也可以是一张图片、一段音频、或者是一个个不同类型的文件。

我们可以这么说，无论这个后端是什么程序编写的，只要它能依照 HTTP 协议返回符合协议规定格式的响应，就可以满足要求。因此，与前端只能用 HTML/CSS/JavaScript 三件套不同，后端的语言，平台的选择可以有很多，例如 PHP, Python, Ruby, JavaScript(Node.js), Java, Go, C++, C 等等。由于基于 PHP 的网站开发效率高，部署简单，性能也不错，所以在Web领域也十分流行。所以说，PHP 并不是全部，只是众多能写后端程序的语言中的一个选择而已。

2. Web服务器

后端处理 HTTP 请求，主要还是通过 Web 服务器程序来实现，Web 服务器产生响应主要有两条途径：

返回请求的对应的磁盘文件
把请求分发给其他的程序处理，并把该程序处理的结果返回。

如图：

HTTP服务器做的事情

其中，这里的请求分发的过程，也叫作反向代理（Reverse Proxy）。

一般来说用的比较多的 Web 服务器软件有 Nginx、Apache 和 Lighttpd，它们都是 C 语言编写的，其中因为 Nginx 的配置较为简单，高性能且资源占用较少，在业界备受欢迎，这里我也选择了 Nginx 作为网站的 Web 服务器。

3. PHP的执行机制

3.1 PHP脚本的执行

PHP的全称是，PHP: Hypertext Preprocessor，中文名为“超文本预处理器”。可以这么理解，PHP主要还是为了处理文本而产生的，这从它的代码中也有体现，我们来尝试一个简单的例子：

新建一个文本文件，命名为 temp.php ，里面输入以下内容：

这是php标签外的内容
---------华丽丽的分割线---------
<?php
$a = 2333 + 6666;
echo "这是PHP标签内部的内容，将会返回一个运算结果\n";
echo "2333+6666=" . $a;
?>
---------又是一条华丽丽的分割线---------
这是php标签外部的内容
---------下一条华丽丽的分割线---------
<?php
$b = 12345;
echo "变量\$b的值为" . $b;
?>
---------最后一条华丽丽的分割线---------
php标签外部的内容

把 temp.php 交给 PHP 解释器执行，这里我以 Linux 命令行为例，下面是这段脚本运行后的结果：

temp.php 的运行

我们可以发现，PHP 解释器在处理文本的时候，把 <?php 到 ?> 之外的内容直接输出到了标准输出流中，当遇到 <?php 到 ?> 之间的代码时，它运行了代码，再把代码中 echo 语句的结果输出到标准输出流中。

我们可以通过重定向的操作，把 PHP 解释器的标准输出流重定向到别的地方，例如，我这里把它的输出结果重定向到与代码同目录的 result.txt 里面。

这时候我们试一下把 result.txt cat出来，发现里面的内容也和之前的输出一样。

重定向 temp.php 的输出到文件

ps: 如果你对流的概念不熟悉，可以参考《鸟哥的 Linux 私房菜》关于流的描述

3.2 通过Web服务器运行PHP脚本

我们知道，PHP 这门语言主要应用在 Web 的领域中，所以一般 PHP 文件都是通过 Web 服务器来触发运行的。

为了方便测试，我们可以用下面的命令可以直接在 temp.php 所在的文件夹下启动一个临时的 PHP cli 开发服务器，就不用重新配环境那么麻烦了：

php -S 0.0.0.0:8888

PHP 自带的 CLI Web 服务器

在浏览器访问 http://0.0.0.0:8888/temp.php 或者 http://127.0.0.1:8888/temp.php，查看源代码，我们可以看到如图所示的结果：

浏览器的输出结果

我们可以发现，浏览器中看到的内容，和我们之前用 PHP 运行这个脚本生成的输出结果是一样的。

忽略细节的话，在某种意义上我们也许也可以这么说，PHP 服务器程序在收到浏览器发过来的请求之后，运行脚本，把脚本的标准输出流重定向到了浏览器，就像之前把命令行运行的结果重定向到了 result.txt 一样。

相比通过文件存储的静态网页，类似PHP每次接到请求后通过解释器执行，执行的结果来返回数据的页面，因为数据会根据实际情况而变化，我们通常也被称之为“动态网页”。

3.3 CGI协议

随着动态网页的流行，这种服务器接收请求，执行程序，把执行程序的输出返回给浏览器的过程也逐渐成型。规范化这个过程也变得有必要起来，由此，CGI协议便诞生了。

CGI (Common Gateway Interface)，中文名是“通用网关接口”，它定义了 Web 服务器与处理请求的程序之间传输数据需要遵循的标准。

一般来说，程序运行时，它与外界交互的途径是标准输入(stdin)、标准输出(stdout)和环境变量（有的程序可能涉及到其它的文件IO的操作，这里不是重点），CGI协议定义了HTTP请求、HTTP响应与程序运行的环境变量、输入流、输出流的对应关系，从而实现了通过一个可执行程序来处理HTTP请求的功能，这个程序在CGI中被称为“网关”(Gateway)。关于CGI协议的具体规定，我们可以参阅 RFC3875 的文档描述。 RFC 3875 - The Common Gateway Interface (CGI) Version 1.1

CGI协议规定了，每一个HTTP请求都对应着一个网关程序的进程来处理。这个HTTP请求的请求头(Header)，QueryString，以及其它关于请求来源的IP，端口等信息，作为网关程序运行的环境变量，这个HTTP中的请求体(Body)，作为网关程序运行的标准输入(stdin)；网关程序执行过程中的标准输出(stdout)，则作为这个HTTP请求的响应数据返回给Web服务器。

参考 TIPI 2.2 节对 CGI 的介绍，引用一下：

CGI 的运行原理

客户端访问某个 URL 地址之后，通过 GET/POST/PUT 等方式提交数据，并通过 HTTP 协议向 Web 服务器发出请求。

服务器端的 HTTP Daemon（守护进程）启动一个子进程。然后在子进程中，将 HTTP 请求里描述的信息通过标准输入 stdin 和环境变量传递给 URL 指定的 CGI 程序，并启动此应用程序进行处理，处理结果通过标准输出 stdout 返回给 HTTP Daemon 子进程。

再由 HTTP Daemon 子进程通过 HTTP 协议返回给客户端。

上面的这段话理解可能还是比较抽象，下面我们就通过一次 GET 请求为例进行详细说明。

图2.7 CGI 运行原理示举例示意图

图2.7 CGI 运行原理示举例示意图

如图所示，本次请求的流程如下：

客户端访问 http://127.0.0.1:9003/cgi-bin/user?id=1

127.0.0.1 上监听 9003 端口的守护进程接受到该请求

通过解析 HTTP 头信息，得知是 GET 请求，并且请求的是 /cgi-bin/ 目录下的 user 文件。

将 uri 里的 id=1 通过存入 QUERY_STRING 环境变量。

Web 守护进程 fork 一个子进程，然后在子进程中执行 user 程序，通过环境变量获取到id。

执行完毕之后，将结果通过标准输出返回到子进程。

子进程将结果返回给客户端。

基于PHP语言的Web程序，它的工作机制也类似于CGI的模型，但根据实际的情况，PHP 的具体实现会有些不一样。在PHP中，CGI协议所用到的程序，是通过它自带的 php-cgi 来支持的，这个后文会继续介绍。

3.4 SAPI 抽象层

刚刚我们可以注意到，我们可以通过浏览器发送HTTP请求的方式执行服务器的PHP脚本，也可以在服务器利用命令行运行文件的方式执行PHP，每种运行方式看起来很不一样，但实际上它们最终在PHP核心都是以一个相同的方式运行，这得益于PHP运行时的SAPI中间层。

那么，什么是SAPI呢？

首先我们来看看PHP的架构图（图片来自鸟哥的博客 ps: PHP的鸟哥和写 Linux 私房菜的鸟哥不是同一个人）

PHP架构图

从图片中可以看出，PHP内部从下到上分为4层：

负责 PHP 的执行的 Zend 引擎
Extensions 扩展层，各种基础的库和扩展都在这一层实现
SAPI：Server Application Programming Interface，服务端应用编程接口，它通过一些钩子函数，定义 PHP 与外部应用的交互，通过它可以实现 PHP 与上层应用的隔离，我们可以基于SAPI编写不同的应用适应不同的环境。
Application 层，这里代表了PHP应用的部分，如命令行下的脚本的执行，web服务器的脚本的执行等等

在这篇文章中，我们的关注点主要是在 Application 层与 SAPI 层的部分，理解了这些的话具体的部署自然就是水到渠成了。

当我们对PHP的架构有了一些印象之后，我们可以知道，SAPI是一种不同的应用与PHP内核的交互方式，上层的应用通过SAPI定义的接口把代码和执行需要的环境变量，输入输出等数据交给PHP内核解析。

下面是一些常见的 SAPI 的应用实现：

Shell CLI: 通过命令行执行 PHP 程序用到的 SAPI。
Apache 2.0 Handler: 通过 Apache 服务器的 mod_php 模块部署 PHP 服务的运行方式
PHP 自带的 CGI/FastCGI 接口: PHP 本身实现了一个名为 php-cgi 的程序，它有 CGI、FastCGI 两种工作模式，专门处理 CGI/FastCGI 的请求
PHP-FPM: 这是一个 PHP 专用的 fastcgi 管理器，克服了 php-cgi 本身的一些问题，并且附加了许多适合大流量高并发网站的功能

早期的 PHP 为了适配多种多样的Web服务器环境，内置了许许多多的 SAPI ，到PHP 7以后，只保留了一部分重要的 SAPI，其它的都已经移除，下面是 PHP 7 以后移除的SAPI列表：（来自菜鸟教程）

aolserver, apache, apache_hooks, apache2filter, caudium, continuity, isapi, milter, nsapi, phttpd, pi3web, roxen, thttpd, tux, webjames

通过PHP的 php_sapi_name() 函数我们可以获得当前PHP运行所使用的sapi的名字，实际的 PHP 代码编写中，我们可以根据这个函数的值判断程序所处的运行环境。

由于 SAPI 的多样，所以就有了许多不同的 PHP 部署方式，下面我会介绍一些常见的部署方式。

3.5 通过加载 Module 方式部署 PHP

Web 服务器除了可以通过 CGI 执行动态脚本外，还可以通过加载模块的方式来运行动态脚本，例如 Apache 的环境中是通过 mod_php 模块来实现运行PHP的，它利用了 Apache 2.0 Handler 这个 SAPI 与 PHP 解释器内核通信。

通过 Apache + mod_php 来部署 PHP 具有开箱即用，稳定成熟的特点，同时也有一些缺点：

Web 服务器与 PHP 解释器之间是耦合的，程序出问题的时候不好定位是 Apache 的问题还是 PHP 这一层的问题
由于PHP的执行用户是与 Apache 相同的，这某些情况下可能有安全隐患
这种方式对于高并发大流量的场景下的性能消耗较大

所以我个人不太推荐通过这种方式在实际生产环境中部署PHP，当然，本地的开发环境还是挺适合的，尤其是Windows环境下，一键安装，美滋滋。

3.6 FastCGI

上文提到了 FastCGI，它究竟是何方神圣呢？

首先我们回顾一下刚刚提到的CGI，它每次接到请求的时候，都需要根据请求的信息设置好参数，创建一个新的进程处理这个请求，处理完毕后退出程序，这样的模式又叫 fork-and-execute 模式。进程的创建和销毁是一个耗费较多系统资源的过程，当网站的并发量一大，系统把大量计算资源都花在了进程的创建和销毁上，造成了大量资源的浪费，性能也不高。

顾名思义，FastCGI = Fast + CGI，它是一种为了提高 CGI 通信性能的协议，是早期的 CGI 协议的改进版本。

参考 TIPI 2.2 节对 FastCGI 的介绍，引用如下：

FastCGI是Web服务器和处理程序之间通信的一种协议，是CGI的一种改进方案，FastCGI像是一个常驻(long-lived)型的CGI，它可以一直执行，在请求到达时不会花费时间去fork一个进程来处理(这是CGI最为人诟病的fork-and-execute模式)。正是因为他只是一个通信协议，它还支持分布式的运算，所以 FastCGI 程序可以在网站服务器以外的主机上执行，并且可以接受来自其它网站服务器的请求。

FastCGI 是与语言无关的、可伸缩架构的 CGI 开放扩展，将 CGI 解释器进程保持在内存中，以此获得较高的性能。 CGI 程序反复加载是 CGI 性能低下的主要原因，如果 CGI 程序保持在内存中并接受 FastCGI 进程管理器调度，则可以提供良好的性能、伸缩性、Fail-Over 特性等。

FastCGI 工作流程如下：

FastCGI 进程管理器自身初始化，启动多个 CGI 解释器进程，并等待来自 Web Server 的连接。

Web 服务器与 FastCGI 进程管理器进行 Socket 通信，通过 FastCGI 协议发送 CGI 环境变量和标准输入数据给 CGI 解释器进程。

CGI 解释器进程完成处理后将标准输出和错误信息从同一连接返回 Web Server。

CGI 解释器进程接着等待并处理来自 Web Server 的下一个连接。

FastCGI 运行原理示举例示意图

FastCGI 运行原理示举例示意图

FastCGI 与传统 CGI 模式的区别之一则是 Web 服务器不是直接执行 CGI 程序了，而是通过 Socket 与 FastCGI 响应器（FastCGI 进程管理器）进行交互，也正是由于 FastCGI 进程管理器是基于 Socket 通信的，所以也是分布式的，Web 服务器可以和 CGI 响应器服务器分开部署。Web 服务器需要将数据 CGI/1.1 的规范封装在遵循 FastCGI 协议包中发送给 FastCGI 响应器程序。

相比 CGI，这里又多了个需要我们考虑的程序 —— FastCGI 进程管理器。还有一个通信协议——FastCGI 协议。同时，HTTP 请求也不是 Web 服务器自己处理了，而是封装成 FastCGI 协议格式的数据包发送到 FastCGI 服务器程序。

PHP 本身内置了一个名为 php-cgi 的程序，它有 CGI、FastCGI 两种工作模式，专门处理 CGI/FastCGI 的请求。

3.7 PHP-FPM

刚刚我们有提到，PHP 可以通过内置的 php-cgi 程序的 FastCGI 模式实现 FastCGI 进程管理器的功能，解决了 CGI 的资源占用和并发的性能问题，同时也支持了分布式计算。然而，在需求日益增长的时候，php-cgi 也暴露出了一些问题。最大的问题是，php-cgi 的配置不够人性化，主要体现在其修改 php.ini 后，不支持平滑重启，每次都要先停止服务再启动才能更新配置，这在某些场景下是很致命的。

为了解决上面的问题，一位名叫 Andrei Nigmatulin 的开发者开发了 PHP-FPM，打破了这个尴尬的局面。

PHP-FPM 是一个为 PHP 量身打造的专用 FastCGI 进程管理器，它解决了上面的问题，并且在许多方面表现十分出色，因此在 PHP 5.3 版本以后，PHP-FPM 已经正式内置在 PHP 中了。官网关于 PHP-FPM 的介绍

综上，需要部署 PHP 环境的话，Apache/Nginx + PHP-FPM 是优于CGI 和 Module 加载的一个很好的选择，下面我就以 Nginx 为例，介绍一下 Nginx 和 PHP-FPM 的配置方法。

4. Nginx与PHP-FPM的配置

首先我们得装好 Nginx，PHP 和 PHP-FPM，具体安装过程可参考其它的教程。

由于不同的发行版的安装后的文件路径不太一样，所以这里只会提到一些比较关键的配置部分。

我们需要明确 Nginx、PHP-FPM 各自的角色，Nginx 本身可以是一个提供静态文件分发的 Web 服务器、也可以是一个反向代理服务器，它的工作模式十分灵活，取决于我们怎么配置Nginx。在这里我的预期是，当 Nginx 收到请求以后，如果请求的是静态文件，那么将这个静态文件返回；如果它是一个要执行 PHP 程序的请求，Nginx 需要将其转发到 PHP-FPM 处理，PHP-FPM 收到请求以后，调用 PHP 内核执行 PHP 脚本，把脚本的输出返回给 Nginx，Nginx 再把响应通过 HTTP 响应的方式返回给用户。

上文我们提到了，FastCGI 的请求、响应是遵循 FastCGI 协议的，而 Web 服务器处理的是 HTTP 协议，所以 Nginx 与 PHP-FPM 一起工作时，就涉及到了 HTTP 协议的请求、响应与 FastCGI 协议的请求、响应的互相转换。这个转换的工作，是通过 Nginx 内置的 fastcgi 模块来实现的。所以，我们需要解决的问题是，如何配置 Nginx，调用 fastcgi 模块来让需要执行PHP的请求正确地转发到 PHP-FPM 中运行呢？

这里我们需要关注两个配置文件，一个是 Nginx 的 nginx.conf ，另一个是 PHP-FPM 的 php-fpm.conf

4.1 PHP-FPM 的配置文件

首先是 php-fpm.conf，这是 PHP-FPM 主要的配置文件，不同的安装方式的路径可能不一样，用 Ubuntu 16.04 的 apt 安装的 PHP-FPM，路径位于 /etc/php/7.0/fpm/php-fpm.conf ，如果是手动编译安装的话，假设 prefix 是 /usr/local/php，它一般会位于 /usr/local/php/etc/php-fpm.conf 。

php-fpm.conf 里面默认是 PHP-FPM 的基本配置，这里一般没有多少需要改动的地方，我们的目光放在最后一行的 include=xxxxx ，apt 安装的 PHP-FPM 默认是 include=/etc/php/7.0/fpm/pool.d/*.conf ，手动编译安装的是 include=/usr/local/php/etc/php-fpm.d/*.conf ，顾名思义，这是一个 include 操作，就是引入 pool.d 或者是 php-fpm.d 目录下所有的 .conf 文件的意思。这个目录下的文件主要的功能是定义了 php-fpm 监听端口等的信息。

定位到 pool.d (也可能是 php-fpm.d ) 目录下可以发现，它里面一般只有一个 www.conf，打开可以看到，里面每个配置项前面，都有一大堆详细的注释。这个文件是我们要配置 PHP-FPM 如何处理 PHP 的关键，它定义了 PHP-FPM 监听哪个端口或是 unix socket 的 FastCGI 请求，脚本执行环境的用户，用户组，权限等等。

一般如果对权限没有特殊要求的话我们不需要对它进行修改。这里我们需要记下里面 listen 选项的内容，listen 的值可以分为两种，一种是 TCP socket 地址，另一种是 unix socket 地址。如果我们这里看到的 listen 的值可能是 127.0.0.1:9000，它是 TCP socket，如果它是一个具体的文件路径类似 /run/php/php7.0-fpm.sock 的值，那么它是一个 unix socket，unix socket 是一种进程间的通信方式，它的操作类似网络套接字，但它实际的数据传输是不用经过网络层的，具体的内容可以查找相关的资料。

4.2 Nginx.conf 的配置

找到了 PHP-FPM 监听的 socket 之后，我们下一个目标就是配置 Nginx 让路径后缀 .php 的请求转发到这个 socket 上了。

关于 Nginx 配置，推荐阅读官方文档 NGINX Web Server | NGINX 下面解释几个关键的部分

一般来说 Nginx 配置的基本结构是这样的，把 Nginx 用作 Web 服务器，则需要配置 nginx.conf 中的 http 块（英文为block，为代码块的意思）：

http {
    server {
        # Server configuration
        location / {

        }
        location ~ \.php$ {

        }
    }
}

一个 http 块中可以有多个 server 块，每个 server 块代表了一个 Web 服务器，负责不同的域名、端口的请求的处理。在 server 块中，我们还可以配置不同的 location 块，每个 location 块都设置了它所匹配的 request-URI 规则，符合规则的 request-URI 将会跳到相应的 location 块中来处理。

4.3 location 语句块

利用 location 的强大功能，我们可以把所有 request-URI 后缀为 .php 的请求交给一个 location 来处理。

查询 Nginx 文档中关于 location 的描述，我们可以发现，location 的匹配 request-URI 有两种方式：前缀匹配(prefix) 和 正则表达式匹配。由于.php属于后缀，不能通过前缀匹配来实现，所以需要正则表达式来处理。

这里的正则表达式是 \.php$，按照这个配置，Nginx将会以 request-URI 是不是以.php结尾来判断。区分前缀匹配与正则匹配的关键是 location 后的 ~，如果 location 后用了 ~ ，代表接下来的字符是一个正则表达式匹配规则，若没有 ~，Nginx 将按照前缀来为请求匹配 location。

# 匹配 .php 后缀的 location 块
location ~ \.php$ {

}

4.4 fastcgi 模块

启用 fastcgi 转发，需要用到 fastcgi 模块，在 location 块中配置与 fastcgi 相关的指令就可以了，官方文档对 fastcgi 模块的各个配置指令有很详细的介绍 Module ngx_http_fastcgi_module

一般我们使用的时候，我们只需用到 fastcgi 模块的其中两条指令，分别是 fastcgi_pass, fastcgi_param.

fastcgi_pass 这个参数是最最关键的，设置请求通过 fastcgi 协议转发的地址，需要设置为我们刚刚找到的 PHP-FPM 监听的地址。具体用法参考官网文档
fastcgi_param 这条指令描述了请求的一些关键参数的设定，比如要执行的脚本文件路径，请求的 QueryString，请求方法（GET还是POST），请求是否为 HTTPS 等等。详情继续参考官网文档

4.5 fastcgi_params

fastcgi_param 一般的用法如下

fastcgi_param parameter value [if_not_empty];

parameter 为当前 fastcgi 协议请求的参数名，value 为 Nginx 要设定此参数的参数值。这个value可以是一个固定的值，也可以是一个变量。我们可以根据实际的需要，来设置不同的 paramter 的参数值 Nginx配置文件的变量的参考文档

parameter 中有一个参数是最关键的，它就是 SCRIPT_FILENAME，这个参数定义了这个请求让 PHP-FPM 运行的 php 文件的完整路径，如果没有它，PHP-FPM 就不知道该运行什么脚本，将会返回一个内容为空白的 200 响应。（实测在 PHP 7 环境中缺少 REQUEST_METHOD 也会有这种情况）

这个最关键的参数一般是这么设置的，意思是把 SCRIPT_FILENAME 设置为之前用 root 或 alias 指定的路径 + 脚本的相对路径：

fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;

举个例子，假如当前的网站根路径设置为 /var/www/html，我们访问的 .php 文件的地址是 http://example.com/test/test.php ，那么，这时候的 $document_root 的值为 /var/www/html ，$fastcgi_script_name 的值就是 /test/test.php 了。此时的 SCRIPT_FILENAME 将会被设置为　/var/www/html/test/test.php ，PHP-FPM 就会按照这个路径读取 php 代码了。

特殊情况下，我们可以直接把一个确定的路径代替 $document_root，不过不推荐这么做：

fastcgi_param  SCRIPT_FILENAME    /var/www/html$fastcgi_script_name;

除了最关键的参数外还有一系列的参数需要设置，参考 Nginx 的文档 PHP FastCGI Example | NGINX

大部分时候，fastcgi_param 的设置是固定的，由于太多人瞎粘贴配置，各种混乱，所以 Nginx 后来为我们提供了一个现成的 fastcgi_param 配置的集合，位于 nginx.conf 同目录的 fastcgi_params 和 fastcgi.conf 中，fastcgi_params 的内容如下：


fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;
fastcgi_param  REQUEST_SCHEME     $scheme;
fastcgi_param  HTTPS              $https if_not_empty;

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;

所以，我们在配置 location 时，在 fastcgi_param 的设定上，我们设置完最关键的 SCRIPT_FILENAME 以后，只需要直接 include fastcgi_params; 就能完成任务了，下面是一个 location 配置 PHP 的例子。

location ~ \.php$ {
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
}

这时候又衍生出了一个问题，fastcgi.conf 是做什么的呢？

fastcgi.conf 和 fastcgi_params 的内容相比，除了多了刚刚我们提到的最最关键的一行，其它完全一致。

fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;

因为我们平常配置 PHP 环境的时候，直接指出文件的根路径反而会造成许多麻烦，配置文件也不灵活，所以 Nginx 为了缓解这种情况，引入了一个 fastcgi.conf 来作为最一般的配置。

有了 fastcgi.conf ，我们的配置又可以更简单一些了～

location ~ \.php$ {
    fastcgi_pass 127.0.0.1:9000;
    include fastcgi.conf;
}

关于 fastcgi_params 和 fastcgi.conf 的关系，可以参考这篇文章：FASTCGI_PARAMS VERSUS FASTCGI.CONF – NGINX CONFIG HISTORY

4.6 一些安全的因素

参考如何正确配置Nginx+PHP | 火丁笔记的描述，我们还需要在 nginx 这一层判断一下访问的 PHP 文件是否存在，避免出现因为 php.ini 开启了 cgi.fix_pathinfo=1 导致任意后缀文件都能通过 PHP 解释器解析产生的可能引发的安全问题，虽然这个漏洞在高版本 PHP (>=5.3.9) 已经被补上，最好还是注意一下，多一层保护或许风险就能再小一些呢。这时候我们可以在负责 php 的 location 块增加一个 try_files 来解决。修改后的配置如下：

location ~ \.php$ {
    try_files $uri =404;
    fastcgi_pass 127.0.0.1:9000;
    include fastcgi.conf;
}

4.7 PATH_INFO 的配置

许多著名的 PHP 程序、框架如 WordPress、Typecho、Moodle、ThinkPHP 等，会支持形如 /xxxx.php/archives/2333 的 request-URI，比如说，Moodle许多文件的路径就是 http://xxx.com/lib/javascript.php/1512059879/lib/requirejs/jquery-private.js 这种类型。这样的URL看起来比较神奇，仿佛 php 文件就是一个文件夹一样，看起来也更加友好一些。

一般 PHP 程序要处理这样的 request-URI ，是通过超全局变量 $_SERVER 的一个参数 $_SERVER['PATH_INFO'] 来实现的，这是一个很实用的参数，PHP 文档对它的描述如下：

包含由客户端提供的、跟在真实脚本名称之后并且在查询语句（query string）之前的路径信息，如果存在的话。例如，如果当前脚本是通过 URL

http://www.example.com/php/path_info.php/some/stuff?foo=bar

我们可以看见，PATH_INFO 的信息必须是“客户端提供的”，也就是说需要由 Web 服务器提供，并且它的内容是跟在脚本名称后，在查询语句（query string）前的路径信息。Nginx 默认不会提供 PHP_INFO，因此，如果需要这个功能，我们需要为 Nginx 的 fastcgi_param 设置关于 PATH_INFO 的信息。

首先第一步我们要知道，面对 /xxx.php/xxxx 这样的链接，其实 Nginx 会把它当做一个文件夹来解析，而我们之前的配置使用了 .php$ 正则，其中的 $ 说明请求必须保证 request-URI 是 .php 结尾才会被匹配。所以我们第一个目标，就是要保证 /xxx.php/xxxx 能交给处理 PHP 的 location 块。我们把匹配规则变通一下，增加一种匹配 xxx.php/ 的情况：

至于为什么 .php 后一定要有 / 或者是 $(代表文件结尾)，主要是考虑到一种风险，有的网站会有上传功能，若用户上传了一个 xxx.php.jpg ，配置不当的时候可能导致这个 xxx.php.jpg 被当做PHP代码传入 PHP 解释器，增加被渗透的可能性。

location ~ \.php(/|$) {

}

这时候请求已经可以转到这个 location 来处理了，但是，这时候，对于 /xxx.php/xxx，Nginx 转发给 PHP-FPM 的 fastcgi 请求中，SCRIPT_FILENAME 就成了 /xxx.php/xxx ，“xxx.php 目录下的 xxx 文件”。PHP 实际执行脚本的路径就需要依靠 PHP 内部去解析了，而且 PHP 并不知道 PATH_INFO 是什么。所以我们需要进一步操作，把正确的 SCRIPT_FILENAME 和 PATH_INFO 交给 PHP ，这里就用到了 Nginx 的 fastcgi_split_path_info 指令了。

fastcgi_split_path_info 在 Nginx 官方文档的描述是这样的：Module ngx_http_fastcgi_module

Defines a regular expression that captures a value for the $fastcgi_path_info variable. The regular expression should have two captures: the first becomes a value of the$ fastcgi_script_name variable, the second becomes a value of the $fastcgi_path_info variable. For example, with these settings

location ~ ^(.+.php)(.*) $\{ fastcgi_split_path_info ^(.+\.php)(.*)$ ; fastcgi_param SCRIPT_FILENAME /path/to/php $fastcgi_script_name; fastcgi_param PATH_INFO$ fastcgi_path_info;

and the “/show.php/article/0001” request, the SCRIPT_FILENAME parameter will be equal to “/path/to/php/show.php”, and the PATH_INFO parameter will be equal to “/article/0001”.

使用 fastcgi_split_path_info ，需要设置一个含有两对分组匹配括号正则表达式，Nginx按照这个正则解析的 request-URI 的时候，第一个括号匹配的值将放入 $fastcgi_script_name 变量中，第二个括号的值放入 $fastcgi_path_info 变量中。再结合之前提到的 fastcgi_param 设置，SCRIPT_FILE_NAME 就已经正确设置啦，这里就不用劳烦 PHP 去解析了，同时，我们再指定 fastcgi_param PATH_INFO 就能把 PATHINFO 设置好了。

这种情况的 location 配置如下：

location ~ \.php(/|$) {
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_split_path_info ^(.+?\.php)(.*)$; #加入 ? 是为了避免类似 /test.php/t.php 匹配出错
    fastcgi_param PATH_INFO $fastcgi_path_info;
    include fastcgi.conf;
}

但这个配置还有一些问题，它没有考虑当请求的PHP对应文件不存在的情况，访问文件不存在的 PHP 请求还是交给了 PHP-FPM 处理，这时候仍存在一定风险（信息泄露之类），如果力求完美的话，还需要继续改进一下。

之前的配置我们用了 try_files $uri =404; 由于这时候的 request-URI 并没有一个文件与之对应，所以使用 try_files $uri =404; 的话，肯定是直接返回 404 Not Found 。联想到开始的 fastcgi_split_path_info，在这里我们可以这么想：直接判断 $uri 的路径 request-URI 系统没有对应的文件，那我们改成 try_files $fastcgi_script_name =404; 不就可以判断文件存在与否的问题啦！

这时候的配置类似下面这样，值得注意的是，Nginx 解析配置文件以后，处理顺序并不是完全按照指令在配置文件里面的先后顺序来判断，经过测试，fastcgi_split_path_info 有着更高的优先级，所以 try_files 不管加在 location 里面哪一个位置，其实都能得到正确的结果，这里放在 fastcgi_split_path_info 后面是为了符合我们的直觉。

location ~ \.php(/|$) {
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_split_path_info ^(.+?\.php)(.*)$;
    try_files $fastcgi_script_name =404;
    fastcgi_param PATH_INFO $fastcgi_path_info;
    include fastcgi.conf;
}

经过测试，这样的配置又衍生出了新的问题，使用这个配置的时候，虽然 PHP 可以正常执行，但PHP脚本是获取不到 PATH_INFO 信息，这是为什么呢？

我们需要理解一下 try_files 指令的执行流程。根据 Nginx 关于 try_files 的文档：

Checks the existence of files in the specified order and uses the first found file for request processing; the processing is performed in the current context. The path to a file is constructed from the *file* parameter according to the root and alias directives. It is possible to check directory’s existence by specifying a slash at the end of a name, e.g. “$uri/”. If none of the files were found, an internal redirect to the *uri* specified in the last parameter is made.

try_files 会依次检测传入的参数对应的文件路径是否存在对应的文件，若存在，则按参数所在 location 对应的 request-URI 来处理，正如我标注的第一句加粗字体所述，try_files 的处理是取决于这个语句所在的上下文的，当这个 location 设置了 fastcgi_pass ，则这个请求会交给 fastcgi 模块发到后端 PHP-FPM 处理，如果这个 location 内部什么都没有，则会按照默认的文件读取返回来处理；如果前面所有的参数都不匹配的话，则会跳转到最后一个参数描述的"内部重定向"请求，跳到其他的 location 或返回状态码。

参考科大LUG的一位老板踩过的 Nginx try_files 里的一个坑 – What's up, LUG Servers

回到刚刚的 try_files $fastcgi_script_name =404; 这里首先尝试的是 $fastcgi_script_name ，也就是说，跳到这一步以后，交回给这个 location 处理的 request-URI 变成了 $fastcgi_script_name 这个变量所代表的，由于$fastcgi_script_name 只保留了 .php 以前的信息。后面的 PATH_INFO 已经丢失了，这时候再执行 fastcgi_split_path_info 以后，显然 $fastcgi_pathinfo 的值也变成了空白。

但是，我们第一步我们已经拿到了正确的 PATH_INFO 了，我们有没有什么办法可以把这个变量临时保存下来而不是在下一次匹配的时候就被覆盖掉呢？答案当然是有的～

这里就需要用到 Nginx 的 rewrite 模块的变量机制了，关于变量，我找到一篇讲解十分详细的文章 Nginx 变量漫谈（一）_agentzh_新浪博客

这里用到的指令是 set ，变量需要注意的一点是，变量设置以后，变量名的可见范围是整个 Nginx 配置，在不同的请求中，变量值是独立的。所以，我们可以定义一个变量取名为 $real_path_info ，用来暂时存放这个值，增加了 set 指令以后的配置如下：

location ~ \.php(/|$) {
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_split_path_info ^(.+?\.php)(.*)$;
    set $real_path_info $fastcgi_path_info;
    try_files $fastcgi_script_name =404;
    fastcgi_param PATH_INFO $real_path_info;
    include fastcgi.conf;
}

有些通用的程序和框架，为了兼容各种各样千奇百怪配置的服务器主机环境，会使用多种不同手段来获取 URL 上的 .php 后的内容，不一定用到 PATH_INFO，所以在不配置得那么详细仍然可以正常工作，但这带来的更多的是使用者们的一知半解。只有当我们在了解了具体的执行流程的情况下，遇到故障，我们可以更容易更好地排查问题所在，这也是了解 PATH_INFO 的意义所在。

4.8 针对单入口程序的 rewrite 设置

许多 PHP 框架（如 Laravel）采用了统一程序入口的方式，即它是通过 index.php 作为程序的入口，当我把 index 设置为 index.php 以后， /archives/2333 内部会转换成 /index.php/archives/2333 来进一步处理。显然前者更加美观一些，这样还能实现“URI路由分发”操作，让不同 controller 来处理不同的 request-URI，也就是我们常说的“伪静态”啦。

那么，“伪静态”该怎么实现呢，这里也用到了 Nginx 的 try_files 指令，方法是加一个 location / 的块：

location / {
  try_files $uri $uri/ /index.php$is_args$args
}
location ~ \.php$ {
  fastcgi_pass 127.0.0.1:9000;
  include fastcgi.conf;
}

当访问的文件或目录不存在时，程序将重定向到 /index.php 处理，后面的 $is_args$args 是因为重定向以后 QueryString 丢失了，需要加回来。

我们可以发现，按照这样的配置重定向以后，request-URI 变成了 /index.php?xxxx 了，传给 PHP 的 PATHINFO 信息也随即丢失，所以一般这种单入口的程序或框架会对环境有所判断，这些程序会通过 REQUEST_URI 参数来获得 index.php 后的路径信息实现路由，抛弃了 PATH_INFO。

需要把路径信息传递到 PATH_INFO 的话，还有一种方案，就是通过 rewrite 来实现，假若请求的 request-URI 所对应路径没有找到文件，则在 request-URI 之前加上 /index.php 再重新解析。

参考 Typecho 的 Github 代码：

server {
    listen 80 default_server;
    server_name _;

    root /www;
    index index.html index.php;

    if (!-e $request_filename) {
        rewrite ^(.*)$ /index.php$1 last;
    }

    location ~ \.php(/|$) {
      fastcgi_pass 127.0.0.1:9000;
      fastcgi_split_path_info ^(.+?\.php)(.*)$;
      fastcgi_param PATH_INFO $fastcgi_path_info;
      include fastcgi.conf;
    }

}

由于始终都有 index.php 的存在，这时候也不需要 try_files 来判断是否有请求对应文件存在了。

4.9 可以复制粘贴的 server 配置总结

以上是具体的分析，如果需要直接使用的话，这里也留下了各种思路的具体配置。使用时需要注意把 fastcgi_pass 设定为服务器中 PHP-FPM 监听的连接。

如果只是想单纯地配一个 .php 的解析，不关心 PATH_INFO 信息等

server {
    listen 80 default_server;
    server_name _;

    root /www;
    index index.html index.php;

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_pass 127.0.0.1:9000;
        include fastcgi.conf;
    }

}

如果想让脚本支持 “PATH_INFO”

类似 Moodle 的文件下载那种

如果程序是通过 REQUEST_URI 来获取路径而不需要 PATH_INFO 的话：

server {
    listen 80 default_server;
    server_name _;

    root /www;
    index index.html index.php;

    location ~ \.php(/|$) {
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_split_path_info ^(.+?\.php)(.*)$;
        try_files $fastcgi_script_name =404;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        include fastcgi.conf;
    }
}

如果一定要完整获取 PATH_INFO 可以用这个完美支持的版本：

server {
    listen 80 default_server;
    server_name _;

    root /www;
    index index.html index.php;

    location ~ \.php(/|$) {
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_split_path_info ^(.+?\.php)(.*)$;
        set $real_path_info $fastcgi_path_info;
        try_files $fastcgi_script_name =404;
        fastcgi_param PATH_INFO $real_path_info;
        include fastcgi.conf;
    }
}

--- 2018年7月7日补充 ----

最近发现 Ubuntu 16.04 的 apt 安装的 Nginx 有自带 try_files 的 PATH_INFO 支持的配置代码片段。位于 /etc/nginx/snippets/fastcgi-php.conf，文件内容为：

# regex to split $uri to $fastcgi_script_name and $fastcgi_path
fastcgi_split_path_info ^(.+\.php)(/.+)$;

# Check that the PHP script exists before passing it
try_files $fastcgi_script_name =404;

# Bypass the fact that try_files resets $fastcgi_path_info
# see: http://trac.nginx.org/nginx/ticket/321
set $path_info $fastcgi_path_info;
fastcgi_param PATH_INFO $path_info;

fastcgi_index index.php;
include fastcgi.conf;

我们可以在 debian 的官方打包代码仓库里面找到这个变化提交，在3年前，Debian社区开始引入了这个配置 Introduce a php-fastcgi snippet (c15f3917) · Commits · Nginx / nginx · GitLab

所以说，使用 Debian 系的 Linux 发行版的话，配置的过程可以简化为

server {
    listen 80 default_server;
    server_name _;

    root /www;
    index index.html index.php;

    location ~ \.php(/|$) {
        include snippets/fastcgi-php.conf;
        fastcgi_pass 127.0.0.1:9000;
    }
}

--- 补充完毕 ----

如果部署的是一个单入口程序，并且对 PATH_INFO 没有要求

server {
    listen 80 default_server;
    server_name _;

    root /www;
    index index.html index.php;

    location / {
          try_files $uri $uri/ /index.php$is_args$args
    }

    location ~ \.php$ {
        fastcgi_pass 127.0.0.1:9000;
        include fastcgi.conf;
    }

}

如果部署的是一个单入口程序，需要支持 PATH_INFO 的话

server {
    listen 80 default_server;
    server_name _;

    root /www;
    index index.html index.php;

    if (!-e $request_filename) {
        rewrite ^(.*)$ /index.php$1 last;
    }

    location ~ \.php(/|$) {
      fastcgi_pass 127.0.0.1:9000;
      fastcgi_split_path_info ^(.+?\.php)(.*)$;
      fastcgi_param PATH_INFO $fastcgi_path_info;
      include fastcgi.conf;
    }

}

关于 Nginx 配置文件的内部执行机理，博主目前还不是非常了解 =_=，有些问题也难以解释，现在只能是从外部的表现，官网文档一点点推敲和纠正，待博主有时间有能力搞清楚它的时候，博主会不断地修正这里的描述的，也希望能与各位高手多多交流完善。

以上是博主的一些理解与实践的经验，由于博主的水平有限，可能有一些地方的描述不太妥当，若你发现了本文有不妥甚至错误之处，希望可以尽快在评论区中指出。要深入地理解 Nginx + PHP 配置，还得多参考一下官方的文档、源代码和一些高质量的博客文章。