了解并在 Nginx 中实施 FastCGI 代理

介绍

Nginx已成为可用的最灵活和最强大的Web服务器解决方案之一,但从设计上来说,它首先是代理服务器,这意味着 Nginx在与其他服务器处理请求时非常出色。

Nginx 可以使用 http、FastCGI、uwsgi、SCGI 或 memcached 进行代理请求. 在本指南中,我们将讨论 FastCGI 代理,这是最常见的代理协议之一。

为什么要使用 FastCGI Proxying?

在 Nginx 中,FastCGI 代理通常用于为应用程序服务器翻译客户端请求,而该服务器不直接处理或不应该处理客户端请求。FastCGI 是一个基于早期 CGI 或通用网关接口的协议,旨在通过不将每个请求运行为一个单独的过程来提高性能。

在 Nginx 中,FastCGI 代理的主要用途之一是用于PHP处理,而非 Apache,它可以直接使用mod_php模块来处理PHP处理,但 Nginx 必须依赖一个单独的PHP处理器来处理PHP请求。

Nginx with FastCGI 可以与使用其他语言的应用程序一起使用,只要有一个可访问的组件被配置为响应 FastCGI 请求。

FastCGI Proxying 基本内容

一般来说,代理请求涉及代理服务器,在这种情况下 Nginx,将客户端请求转发到后端服务器. Nginx用来定义实际服务器使用FastCGI协议的代理服务器的指令是fastcgi_pass

例如,要将任何对应的 PHP 请求转发到用于使用 FastCGI 协议处理 PHP 处理的后端,一个基本的位置块可能看起来像这样:

1# server context
2
3location ~ \.php$ {
4    fastcgi_pass 127.0.0.1:9000;
5}
6
7. . .

上面的片段实际上不会工作,因为它提供了太少的信息. 每次进行代理连接时,必须翻译原来的请求,以确保代理请求对后端服务器有意义。

虽然 http-to-http 代理主要涉及增加 http 标题,以确保后端具有代表客户端响应代理服务器所需的信息,但 FastCGI 是一个独立的协议,无法读取 http 标题。

使用 FastCGI 协议时传输额外信息的主要方法是使用参数. 背景服务器应配置以读取和处理这些,根据其发现而修改其行为。

在PHP的FastCGI代理场景中实际工作的最低配置是这样的:

1# server context
2
3location ~ \.php$ {
4    fastcgi_param REQUEST_METHOD $request_method;
5    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
6    fastcgi_pass 127.0.0.1:9000;
7}
8
9. . .

在上面的配置中,我们设置了两个FastCGI参数,称为REQUEST_METHODSCRIPT_FILENAME。这两种参数都是必要的,以便后端服务器了解请求的性质。

在示例中,我们使用了一些 Nginx 变量来设置这些参数的值. $request_method 变量将始终包含客户端要求的 http 方法。

SCRIPT_FILENAME参数被设置为$document_root变量和$fastcgi_script_name变量的组合。$document_root将包含根据root指令设置的基准目录的路径。$fastcgi_script_name变量将被设置为请求URI。如果请求URI以缩略(/)结束,则将附加到端的fastcgi_index指令的值。这种类型的自参考位置定义是可能的,因为我们在与我们的 Nginx 实例相同的机器上运行 FastCGI 处理器。

让我们来看看另一个例子:

 1# server context
 2root /var/www/html;
 3
 4location /scripts {
 5    fastcgi_param REQUEST_METHOD $request_method;
 6    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 7    fastcgi_index index.php;
 8    fastcgi_pass unix:/var/run/php5-fpm.sock;
 9}
10
11. . .

如果上面的位置被选中来处理对 /scripts/test/ 的请求,那么 SCRIPT_FILENAME 的值将是对 root 指令、请求 URI 和 fastcgi_index 指令的值的组合。

我们对上面的配置进行了另一个重大变化,即我们使用Unix插槽而不是网络插槽来指定FastCGI后端。 Nginx可以使用任何类型的接口连接到FastCGI上流。

打破FastCGI配置

可维护的代码的一个关键规则是尝试遵循DRY(不要重复自己)原则,这有助于减少错误,增加可重复使用性,并允许更好的组织。

在处理 FastCGI 代理配置时,大多数使用实例将共享绝大多数配置,这就是为什么,以及 Nginx 继承模型的运作方式,在一般范围内宣布参数几乎总是有利的。

声明FastCGI配置细节在家长背景下

减少重复的一种方法是将配置细节声明在更高、较高背景下。实际fastcgi_pass之外的所有参数可以在更高层次中指定。

例如,我们可以修改上面的部分中的最后一个配置片段,使其在多个位置有用:

 1# server context
 2root /var/www/html;
 3
 4fastcgi_param REQUEST_METHOD $request_method;
 5fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 6fastcgi_index index.php;
 7
 8location /scripts {
 9    fastcgi_pass unix:/var/run/php5-fpm.sock;
10}
11
12location ~ \.php$ {
13    fastcgi_pass 127.0.0.1:9000;
14}
15
16. . .

在上面的示例中,既有fastcgi_param声明,又有fastcgi_index指令可在随后的两个位置块中使用。

但是,上面的配置有一个严重的缺点:如果在下面的文本中声明任何fastcgi_param,则从母文本中不会继承任何fastcgi_param值。

fastcgi_param指令是一个 array 指令在 Nginx 语言中。从用户的角度来看,一个数组指令基本上是任何指令,可以在一个单一的背景下使用一次以上。每一个后续的声明将新信息附加到 Nginx 从以前的声明中知道的东西。

数组指令将与其他一些指令不同的方式继承到儿童环境中。从数组指令的信息将继承到儿童环境中,如果它们不在儿童环境中的任何地方,这意味着如果您在您的位置中使用fastcgi_param,它将有效地清除从父母环境中继承的值。

例如,我们可以稍微修改上面的配置:

 1# server context
 2root /var/www/html;
 3
 4fastcgi_param REQUEST_METHOD $request_method;
 5fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 6fastcgi_index index.php;
 7
 8location /scripts {
 9    fastcgi_pass unix:/var/run/php5-fpm.sock;
10}
11
12location ~ \.php$ {
13    fastcgi_param QUERY_STRING $query_string;
14    fastcgi_pass 127.0.0.1:9000;
15}
16
17. . .

乍一看,您可能认为REQUEST_METHODSCRIPT_FILENAME参数将继承到第二个位置块中,而QUERY_STRING参数还可用于该特定背景。

实际发生的事情是,在第二个背景中删除了 all 母值 fastcgi_param 值,并且只设置了 QUERY_STRING 参数。

在同一背景下对参数的多个值的注释

在这一点上绝对值得一提的是,在一个单一的背景下为相同参数设置多个值的影响,让我们以以下示例作为讨论点:

 1# server context
 2
 3location ~ \.php$ {
 4    fastcgi_param REQUEST_METHOD $request_method;
 5    fastcgi_param SCRIPT_FILENAME $request_uri;
 6
 7    fastcgi_param DOCUMENT_ROOT initial;
 8    fastcgi_param DOCUMENT_ROOT override;
 9
10    fastcgi_param TEST one;
11    fastcgi_param TEST two;
12    fastcgi_param TEST three;
13
14    fastcgi_pass 127.0.0.1:9000;
15}
16
17. . .

在上面的示例中,我们已经在单个背景下多次设置了TESTDOCUMENT_ROOT参数,因为fastcgi_param是一个数组指令,因此每一个后续的声明都被添加到 Nginx 的内部记录中。

在这一点上,重要的是要意识到,所有这些都将被传送到FastCGI后端,而不会再由Nginx进行任何处理,这意味着它完全取决于所选择的FastCGI处理器决定如何处理这些值。

例如,如果 PHP-FPM 接收了上述参数,则 final 值将被解释为超出任何前面的值,因此在这种情况下,‘TEST’ 参数将被设置为‘三’。

但是,如果上面的值被传递到类似于FsgiWrap的某些东西,则值会被解释得非常不同。 首先,它会进行初步传输来决定使用哪些值来运行脚本。 它会使用DOCUMENT_ROOT值的初始来搜索脚本。

这种不一致性和不可预测性意味着,在设置相同参数多次时,您不能并且不应该依赖后端来正确解释您的意图.唯一安全的解决方案是只宣布每个参数一次。

使用包括源从单独文件的 FastCGI 配置

我们可以使用包括指令在单独文件的内容中阅读指令声明的位置。

这意味着我们可以将所有常见的配置项目保存在一个文件中,并在我们需要的配置中的任何地方包含它,因为 Nginx 会将实际的文件内容放置到包括的位置,所以我们不会从父母的背景下继承给孩子。

首先,我们可以将我们共同的 FastCGI 配置值设置为我们的配置目录中的一个单独的文件,我们将这个文件命名为 fastcgi_common:

1fastcgi_param REQUEST_METHOD $request_method;
2fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

现在,我们可以在我们想要使用这些配置值的任何地方阅读这个文件:

 1# server context
 2root /var/www/html;
 3
 4location /scripts {
 5    include fastcgi_common;
 6
 7    fastcgi_index index.php;
 8    fastcgi_pass unix:/var/run/php5-fpm.sock;
 9}
10
11location ~ \.php$ {
12    include fastcgi_common;
13    fastcgi_param QUERY_STRING $query_string;
14    fastcgi_param CONTENT_TYPE $content_type;
15    fastcgi_param CONTENT_LENGTH $content_length;
16
17    fastcgi_index index.php;
18    fastcgi_pass 127.0.0.1:9000;
19}
20
21. . .

在这里,我们已经在我们的默认 Nginx 配置目录中将一些常见的 fastcgi_param 值移动到一个名为 fastcgi_common 的文件中。

对于这种配置,有几点要注意。

首先,我们没有将任何我们可能希望根据位置定制的值放置到我们计划源的文件中,因为我们上面提到的解释问题发生在为相同参数设置多个值时,并且因为非数组指令只能按背景设置一次,只会放置您不希望更改的常见文件项目。

您可能注意到的另一件事是,我们在第二个位置块中设置了一些额外的FastCGI参数,这是我们希望实现的能力,我们可以根据需要设置额外的‘fastcgi_param’参数,而不删除常见值。

使用 fastcgi_params 文件或 fastcgi.conf 文件

考虑到上述策略,Nginx开发人员和许多分销包装团队一直致力于提供一套合理的常见参数,您可以将其纳入您的FastCGI通道位置。

这两个文件在很大程度上是相同的,唯一的差异实际上是我们之前讨论过关于传递单个参数的多个值的问题的结果。

fastcgi_params文件已经可用了很长一段时间,为了避免破坏依赖于fastcgi_params的配置,当决定为SCRIPT_FILENAME提供默认值时,需要创建一个新的文件。

许多流行的发行版的包维护者选择只包括其中一个文件,或者精确地反映其内容. 如果您只有其中一个,请使用您拥有的文件。

如果您有这两个文件可供使用,对于大多数 FastCGI 通行位置,可能最好包括 fastcgi.conf 文件,因为它包含对 SCRIPT_FILENAME 参数的声明。

这些可以通过引用它们的位置与根 Nginx 配置目录有关,而根 Nginx 配置目录通常是 `/etc/nginx’ 类似的,当 Nginx 已与包管理器安装时。

你可以添加这样的文件:

1# server context
2
3location ~ \.php$ {
4    include fastcgi_params;
5    # You would use "fastcgi_param SCRIPT_FILENAME . . ." here afterwards
6
7    . . .
8
9}

或者这样的:

1# server context
2
3location ~ \.php$ {
4    include fastcgi.conf;
5
6    . . .
7
8}

重要的 FastCGI 指令、参数和变量

在上述部分中,我们已经设置了相当数量的参数,通常为 Nginx 变量,作为示范其他概念的手段。我们还引入了一些 FastCGI 指令,没有太多的解释。

FastCGI 指令

以下是使用FastCGI通道工作的一些最有用的指南:

      • Fastcgi_pass * * * * * 翻译: 将当前上下文中的请求传递到后端的实际指令 。 这定义了 FastCGI 处理器可以到达的位置 。
  • _QFastcgi_param **: 用于设定值参数的数组指令 。 最常见的是,它与Nginx变量结合使用,将FastCGI参数设定为请求所特有的值. (_ ( )* QQTry_文件QQ: 不是FastCGI的特有指令,而是FastCGI通过位置内使用的通用指令. 这常被作为请求的卫生例行的一部分,以确保所请求的文件在传递到FastCGI处理器之前存在. (_) ( )* QQincluding : 再一次, 不是一个 FastCGI 专用指令, 而是一个在 FastCGI 上下文中获得大量使用 。 最常见的是,这被用于包括多个位置的常见共享配置细节. (_) ) * * *\ fastcgi_split_path_info_{}: 该指令定义了由被捕获的两个组组成的正则表达式. 第一个被捕获的群体被用作$fastcgi_script_name'变量的值。 第二个捕获组被用作`$fastcgi_path_info'变量的值。 这两种信息经常用来正确解析请求,以使处理器知道请求中哪些是要运行的文件,哪些是要传递到脚本的附加信息.
  • QQFastcgi_index_: 这定义了应该附加到 $fastcgi_script_name 的索引文件 以斜线(/')结尾的数值。 如果将 SCRIPT_ FILENAME 参数设置为 $document_root$fastcgi_script_name` , 并配置位置块以接受文件后的信息请求, 则此选项往往有用 。
    • fastcgi intercept_ errors `**: 此指令定义了从FastCGI服务器收到的错误是否应该由Nginx处理或直接传递给客户端. (单位:千美元) (英语)

上面的指南代表了你在设计典型的FastCGI通道时会使用的大部分东西,你可能不会总是使用这些,但我们可以开始看到它们与FastCGI参数和变量有非常密切的相互作用,我们将在下一步讨论。

FastCGI 使用的常见变量

在我们可以谈论您可能使用的FastCGI通道的参数之前,我们应该谈谈一些常见的Nginx变量,我们将利用这些参数设置。

  • $query_string " 或 " $args " : 在原始客户端请求中给出的参数
  • 时间轴: 如果请求中存在参数, 否则将被设定为空字符串, 将等于 。 这在构建可能或可能没有参数的参数时是有用的。 (_) ) * $ 要求_方法: 这表示原始客户端请求方法. 这对于确定在当前背景下是否允许操作是有用的。
  • $content_type: 此处设定为Content-Type请求标题。 如果用户的请求是POST,则代理用户需要这些信息,以便正确处理随后的内容. () ) * * $内容_长度 : 这被设定为客户端的 " Content-Length " 信头的值。 任何客户 POST 请求都需要这种信息。 () ) * * *$fastcgi_script_name_____________________: 这将包含要运行的脚本文件 。 如果请求以斜线(/)结束,则快克吉-index'指令的值将附在末尾。 如果使用 fastcgi_split_path_info` 指令,则该变量将被设定为该指令定义的第一个捕获组。 此变量的值应显示要运行的实际脚本 。
  • $ request filename_}: 此变量将包含所请求文件的文件路径 。 它通过采用当前文档根的值,考虑到根'和别名'指令,以及$fastcgi_script_name'的值,获得这一价值。 这是一个非常灵活的方式,可以指定SCRIPT-FILENME ' 参数。 (_) ) * $ 请求: 从客户收到的全部请求。 这包括脚本,任何额外的路径信息,加上任何查询字符串.
  • *$fastcgi_path_info_: 此变量包含在请求中的脚本名称后可能可获得的额外路径信息 。 此值有时包含要执行的脚本应该知道的另一个位置 。 当使用 fastcgi_split_path_info 指令时,此变量从第二个捕获的 regex 组获得其值 。 () ) * $document_root: 此变量包含当前文档根值 。 这将按照根'或别名'指令确定。
  • \ $uri\ : 此变量包含当前应用的 URI 。 由于某些重写或内部重定向的指示会对URI产生影响,这个变量会表达这些变化. ( (英语)

正如你所看到的,当你决定如何设置FastCGI参数时,有很多变量可用,其中许多相似,但有一些微妙的差异会影响你的脚本的执行。

常见的FastCGI参数

FastCGI 参数代表了我们希望向我们发送请求的 FastCGI 处理器提供的关键值信息,并非每个应用程序都需要相同的参数,因此您通常需要查阅应用程序的文档。

其中一些参数是必要的,以便处理器正确识别运行脚本,而其他参数则可供脚本使用,如果它配置为依赖设置的参数,则可能改变其行为。

。 。 。 。 。 此参数应设定为客户端提供的任何查询字符串 。 这通常是URI中一个"?"之后提供的密钥值对. 通常,这一参数被设定为 " $query_string " 或 " $args " 变量,两者应包含相同的数据。 (_ ( )* 请求你。 此参数向 FastCGI 处理器显示客户端请求的动作类型 。 这是需要设置的为数不多的参数之一,以使通行证能够正确运行. (_ ( )* 时间轴: 如果上述请求方法为"POST",这个参数必须设置. 它表示FastCGI处理器所期望的内容类型. 这几乎总是被设定为$content_type变量,该变量是根据原始请求中的信息设置的。 (_ ( )* (笑声) 如果请求方法为"POST",这个参数必须设置. 这表示内容长度. 这几乎总是被设定为$content_w长',这个变量从原始客户端请求中的信息中获得其价值。 (_) ( )* 说吧, 此参数用于表示将运行的主要脚本的名称. 这是一个极为重要的参数,可以根据您的需要以多种方式设定. 这往往被设定为$fastcgi_script_name',这应该是请求URI,请求URI和fastcgi_index' 如果它以斜线结束,则附加;如果使用 fastcgi_fix_path_info ,则附加第一个被捕获的组。 [永久失效連結] (中文(简体) ). 此参数指定要运行的脚本磁盘上的实际位置 。 由于它与SCRIPT-NAME'参数的关系,一些指南建议您使用$document_root$fastcgi_script_name'。 另一个具有许多好处的办法是使用$request_filename'。 () ( )* 请您了 这应该包含完整,未修改的请求 URI, 包含要运行的脚本, 附加路径信息, 以及任何参数 。 一些应用程序更喜欢分析此信息本身. 此参数为他们提供了这样做的必要信息。 () ( )* QQPATH_INFO**:如果在 PHP 配置文件中将 cgi.fix_pathinfo' 设置为" 1",此选项将包含在脚本名称后添加的任何附加路径信息. 这常被用来定义一个脚本应该采取行动的文件参数. 把cgi.fix_pathinfo'设置到"1",如果脚本请求没有通过其他方式进行消毒,可能会有安全影响(我们将稍后讨论这个问题). 有时它被设定为$fastcgi_path_info'变量,其中包含从`fastcgi_split_path_info'指令中捕获的第二个组。 其他时候,需要使用一个临时变量,因为该值有时被其他处理所打乱.

  • {\fn黑体\fs22\bord1\shad0\3aHBE\4aH00\fscx67\fscy66\2cHFFFFFF\3cH808080}我很高兴见到你 此参数将 PATH_INFO 中的路径信息映射到一个实际的文件系统路径。 通常,它会被设定为 $document_root$fastcgi_ path_info , 但有时后面的变量必须被上述临时保存的变量所取代。 (_) (英语)

在转移到 FastCGI 之前检查请求

我们尚未讨论的一个非常重要的话题是如何安全地将动态请求传送到应用程序服务器。将所有请求传送到后端应用程序,无论其有效性如何,不仅不高效,而且危险。

为了解决这个问题,我们应该确保我们只向我们的 FastCGI 处理器发送合法请求,这取决于我们的特定设置的需求,以及 FastCGI 处理器是否生活在与我们的 Nginx 实例相同的系统上。

一个基本规则应该告诉我们如何设计我们的配置是,我们永远不应该允许任何处理和解释用户文件。恶意用户在看似无辜的文件,如图像中嵌入有效代码相对容易。

我们在这里试图解决的主要问题是实际上在CGI规格中指定的一个问题. 该规格允许您指定要运行的脚本文件,然后是可由脚本使用的额外路径信息。

如果您的配置简单地将每一个在.php 中结束的请求传递给您的处理器而不测试其合法性,则处理器如果遵循规格,将检查该位置并在可能的情况下执行它。如果它找不到文件,则将遵循规格并尝试执行 /test.jpg 文件,标记 `/index.php 作为脚本的额外路径信息。

有几种不同的方法来解决这个问题. 最简单的,如果你的应用程序不依赖这个额外的路径信息来处理,就是在你的处理器中关闭它。 对于PHP-FPM,你可以在你的php.ini文件中关闭它。 例如,在Ubuntu系统中,你可以编辑这个文件:

1sudo nano /etc/php5/fpm/php.ini

只需搜索cgi.fix_pathinfo选项,删除评论并将其设置为0,以禁用此功能:

1cgi.fix_pathinfo=0

重新启动您的 PHP-FPM 流程以进行更改:

1sudo service php5-fpm restart

因此,在上面的例子中,如果 /test.jpg/index.php 文件不存在,则 PHP 会正确地错误,而不是试图执行 `/test.jpg。

另一种选择,如果我们的 FastCGI 处理器与我们的 Nginx 实例相同的机器上,就是在传送到处理器之前,简单地检查磁盘上的文件是否存在。如果 /test.jgp/index.php 文件不存在,请错误。

1location ~ \.php$ {
2        try_files $uri =404;
3
4        . . .
5
6}

如果您的应用程序 does 依靠路径信息行为进行正确的解释,则您可以在决定是否将请求发送到后端之前安全地允许此行为。

例如,如果我们的应用程序的上传目录是 /uploads/,我们可以创建一个像这样的位置块,在任何常规表达式被评估之前匹配:

1location ^~ /uploads {
2}

内部,我们可以禁用任何类型的PHP文件处理:

1location ^~ /uploads {
2    location ~* \.php$ { return 403; }
3}

父母位置将匹配任何从/uploads开始的请求,任何处理PHP文件的请求都会返回一个403错误,而不是将其发送到后端。

您还可以使用fastcgi_split_path_info指令手动定义应该被解释为脚本的请求部分和使用常规表达式定义为额外路径信息的部分。

例如,我们可以设置一个位置块,将以.php结束的路径组件的第一个实例视为要运行的脚本,其余的将被视为额外路径信息,这意味着在对/test.jpg/index.php的请求的情况下,整个路径可以被发送到处理器作为脚本名称,没有额外路径信息。

这个位置可能看起来像这样的东西:

 1location ~ [^/]\.php(/|$) {
 2
 3    fastcgi_split_path_info ^(.+?\.php)(.*)$;
 4    set $orig_path $fastcgi_path_info;
 5
 6    try_files $fastcgi_script_name =404;
 7
 8    fastcgi_pass unix:/var/run/php5-fpm.sock;
 9    fastcgi_index index.php;
10    include fastcgi_params;
11
12    fastcgi_param SCRIPT_FILENAME $request_filename;
13    fastcgi_param PATH_INFO $orig_path;
14    fastcgi_param PATH_TRANSLATED $document_root$orig_path;
15}

上面的区块应该适用于PHP配置,其中cgi.fix_pathinfo设置为1,以允许额外的路径信息。

在区块内,fastcgi_split_path_info指令定义了两个带有常规表达式的捕捉组。第一个组匹配了从.php开始到第一个实例的URI部分,并将其放置在$fastcgi_script_name变量中。

我们使用设置指令来存储此时的$fastcgi_path_info中的值,并将其存储在称为$orig_path的变量中,这是因为$fastcgi_path_info变量将在一瞬间被我们的try_files指令删除。

我们测试了我们上面捕获的脚本名称,使用try_files。这是一种文件操作,将确保我们试图运行的脚本在磁盘上,但这也有清除$fastcgi_path_info变量的副作用。

经过传统的 FastCGI 通行,我们将SCRIPT_FILENAME设置为通常的值,我们还将PATH_INFO设置为我们将$orig_path变量下载的值,虽然我们的$fastcgi_path_info已清除,但其原始值仍保留在这个变量中。我们还将PATH_TRANSLATED参数设置为将额外的路径信息映射到磁盘上的位置。

这使我们能够构建/index.php/users/view等请求,以便我们的/index.php文件能够处理有关/users/view目录的信息,同时避免运行/test.jpg/index.php的情况。

如果我们需要更改我们的脚本文件的位置,我们甚至可以使用一个字母指令来完成这项工作,我们只需要在我们的位置标题和fastcgi_split_path_info定义中考虑这一点:

 1location ~ /test/.+[^/]\.php(/|$) {
 2
 3    alias /var/www/html;
 4
 5    fastcgi_split_path_info ^/test(.+?\.php)(.*)$;
 6    set $orig_path $fastcgi_path_info;
 7
 8    try_files $fastcgi_script_name =404;
 9
10    fastcgi_pass unix:/var/run/php5-fpm.sock;
11    fastcgi_index index.php;
12    include fastcgi_params;
13
14    fastcgi_param SCRIPT_FILENAME $request_filename;
15    fastcgi_param PATH_INFO $orig_path;
16    fastcgi_param PATH_TRANSLATED $document_root$orig_path;
17}

这些将允许您安全地运行使用PATH_INFO参数的应用程序. 请记住,您必须在您的php.ini文件中更改cgi.fix_pathinfo选项为1,以便此操作正确。 您也可能需要在您的php-fpm.conf文件中关闭security.limit_extensions

结论

希望现在你能够更好地了解 Nginx 的 FastCGI 代理功能,这种能力允许 Nginx 在快速连接处理和提供静态内容方面发挥其优势,同时将动态内容的责任转移到更合适的软件中。

Published At
Categories with 技术
comments powered by Disqus