导读 | 对很多人而言,配置Nginx PHP无外乎就是搜索一篇教程,然后拷贝粘贴。听上去似乎也没什么问题,可惜实际上网络上很多资料本身年久失修,漏洞百出,如果大家不求甚解,一味的拷贝粘贴,早晚有一天会为此付出代价。 |
Suppose we use PHP to implement a front-end controller, or to put it bluntly, it is a unified entrance: send all PHP requests to the same file, and then parse them in this file "REQUEST_URI" implements routing.
At this time, many tutorials will teach you to configure Nginx PHP like this:server { listen 80; server_name foo.com; root /path; location / { index index.html index.htm index.php; if (!-e $request_filename) { rewrite . /index.php last; } } location ~ \.php$ { include fastcgi_params; fastcgi_param SCRIPT_FILENAME /path$fastcgi_script_name; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; }}
There are many errors here, or at least bad smells. Let’s take a look and find a few.
…
We need to first understand the inheritance relationship of the instructions in the Nginx configuration file:
The Nginx configuration file is divided into many blocks. The common ones from outside to inside are "http", "server", "location", etc., the default inheritance relationship is from outside to inside, which means that the inner block will automatically obtain the value of the outer block as the default value.
Let's start with the "index" directiveIn the problem configuration it is defined in "location":
location / { index index.html index.htm index.php;}
Once a new "location" needs to be added in the future ", there will inevitably be repeatedly defined "index" instructions. This is because multiple "locations" are in a horizontal relationship and there is no inheritance. At this time, "index" should be defined in "server". With the help of the inheritance relationship, "index" ” command is valid in all “locations”.
Let’s take a look at the “if” commandIt is no exaggeration to say that it is the most misunderstood Nginx command:
if (!-e $request_filename) { rewrite . /index.php last;}
Many people like to use the “if” command to do something A series of checks, but this is actually the responsibility of the "try_files" command:
try_files $uri $uri/ /index.php;
除此以外,初学者往往会认为「if」指令是内核级的指令,但是实际上它是rewrite模块的一部分,加上Nginx配置实际上是声明式的,而非过程式的,所以当其和非rewrite模块的指令混用时,结果可能会非你所愿。
下面看看「fastcgi_params」配置文件:
include 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;
server { listen 80; server_name foo.com; root /path; index index.html index.htm index.php; location / { try_files $uri $uri/ /index.php$is_args$args; } location ~ \.php$ { try_files $uri =404; include fastcgi.conf; fastcgi_pass 127.0.0.1:9000; }}
免费提供最新Linux技术教程书籍,为开源技术爱好者努力做得更多更好:http://www.linuxprobe.com