nginx配置的常见陷阱及错误
转自：http://article.yeeyan.org/view/550060/489491
不管是新老用户都可能掉进同样的陷阱里。下面我们列举了觉的问题同时也给出了解决办法。在Freenode的IRC频道#nginx里，我们经常遇到这类问题。
导言
这些常见问题，一般是因某人试图从别人的配置里直接拷贝后拿来用，并不是所有拷贝的都有问题，可惜的是，大部分都有问题。即使是Linode文档库里也存在因社区成员不去维护导致质量差的信息。
这个文档由大量NGINX社区成员创建和审查，这个特殊文档的存在也是因为这些太过来常见了并经常发生。
如果你的问题并未列明
你可能并没有找你跟你直接有关的特殊问题，也许我们确实是没有指出你经常的特殊问题。但，不要以为你来到这个页面是没有原因的，你被带到这个页面至少表示你在下面的问题里遇到过问题：）
Chmod 777
永远不要使用777。不要以为这只是一个漂亮的数字，即使在测试环境也表明你会没有线索查你正在做的事。你可以对整个路径的权限进行检查，可以考虑你正在做的事实。
要检查路径的权限，你可以：
namei -om /path/to/check
Location 里的 root 配置
劣：
server {
server<em>name <a href="http://www.example.com;">www.example.com;</a>
location / {
root /var/www/nginx-default/;
# [...]
}
location /foo {
root /var/www/nginx-default/;
# [...]
}
location /bar {
root /var/www/nginx-default/;
# [...]
}
}
可以工作。每个location块里都加上root指令没有错，也能很好的工作。那会有什么问题呢？如果某一个location块你路径写错了，将导致没有根目录。来看下什么是优的配置。
优：
<em>server {
server</em>name <a href="http://www.example.com;">www.example.com;</a>
root /var/www/nginx-default/;
location / {
# [...]
}
location /foo {
# [...]
}
location /bar {
# [...]
}
}
多个Index指令
劣：
http {
index index.php index.htm index.html;
server {
server<em>name <a href="http://www.example.com;">www.example.com;</a>
location / {
index index.php index.htm index.html;
# [...]
}
}
server {
server</em>name example.com;
location / {
index index.php index.htm index.html;
# [...]
}
location /foo {
index index.php;
# [...]
}
}
}
为何重复那么多不必要的行？其实只要简单的使用index指令一次，只要在http{}里使用一次，下面的区块将自动继承。
优：
http {
index index.php index.htm index.html;
server {
server<em>name <a href="http://www.example.com;">www.example.com;</a>
location / {
# [...]
}
}
server {
server</em>name example.com;
location / {
# [...]
}
location /foo {
# [...]
}
}
}
使用if指令
只有少数一些讨论if的文章，有篇叫 if是魔鬼 的你一定要看，下面举些列子说明为何if如果坏。
servername指令与if
劣：
server {
server<em>name example.com <em>.example.com;
if ($host ~</em> ^www.(.+)) {
set $raw</em>domain $1;
rewrite ^/(.<em>)$ $raw<em>domain/$1 permanent;
}
# [...]
}
}</em></em>
这里实际上有三个问题。首先看看if，也是我们现在要关注的，为何是劣的？你读过这篇文章 If是魔鬼 吗？当nginx接收到一个请求不管子域名是什么，即使是www.example.com或example.com，if指令也是每次都要调用，因为NGINX需要每次对请求头Host做处理，这特别没有效率，你要千万注意避免它。可以替换为两个server区块，如下面的列子：
优：
server {
server</em>name <a href="http://www.example.com;">www.example.com;</a>
return 301 $scheme://example.com$request<em>uri;
}
server {
server</em>name example.com;
# [...]
}
这种配置也可以使配置更好阅读，这种方法减少了NGINX的处理需求。我们去除了谬误的if，同时我们使用了$schema避免了硬编码URI，如http或https。
检查文件是否存在（if）
使用if来判断一个文件是否存在太可怕了。也就是说如果你有最新版的NGINx，使用tryfiles指令将更加容易。
劣：
server {
root /var/www/example.com;
location / {
if (!-f $request</em>filename) {
break;
}
}
}
优：
server {
root /var/www/example.com;
location / {
try<em>files $uri $uri/ /index.html;
}
}
我们只是修改了判断文件是否存在但又不使用if指令，使用tryfiles表示可以测试一系列文件，如果$uri不存在，再试$uri/，如果还不存在，就使用默认位置（index.html）。
在这个列子，如果$uri存在就使用它，如果不存在，再判断$uri/目录是否存在，如果不存在就使用index.html，必须要保证最后一个检测的文件存在。很简单吧！下面是另一个例子去掉if指令。
WEB应用的前端控制模式
"前端控制模式"-Front controller patterm在php开源界非常流行，但大都使用的比较复杂，如Drupal、jammla等，只要像这样：
try_files $uri $uri/ /index.php?q=$uri&$args;
注意-参数根据你使用的开源软件不同而不同。如：
- "q"是Drupal,Joomla,Wordpress的参数
- "page"是CMS Make Simple的参数
有些软件甚至不需要查询参数而是用REQUEST_URI参数，如，Wordpress支持这个：
<em>try_files $uri $uri/ /index.php;</em>
如果你不关心检查目录，只要去掉$uri/。
当然，你可能遇到些特殊情况，需要更复杂的配置，但对一般站点，这些就够了。
传递未受控的请求到PHP
很多NGINX+PHP的配置会传递所有以.php结尾的请求给php，但这里会出现一个严重的安全问题，可能导致精心构造的代码被执行。
这类问题看起来如：
location ~</em> .php$ {
fastcgi<em>pass backend;
# [...]
}
这里，每个以.php结尾的请求将传递给FastCGI后端。这会导致一个问题，PHP的默认配置对于找不到的文件，会对整个请求文件路径猜测哪个部分需要执行。
举例，如果请求是/forum/avatar/1232.jpg/file.php，文件并不存在，但/forum/avatar/1232.jpg存在，则php也会执行1232.jpg，如果1232.jpg包含php代码，也会被执行。
避免执行的选项有：
在php.ini设置cgi.fixpathinfo=0.这会导致php不尝试字面上的路径，如果文件没找到就停止处理。
保证NGINX只传递特定文件给PHP
location ~* (file<em>a|file</em>b|file<em>c).php$ {
fastcgi</em>pass backend;
# [...]
}
指定用户上传的目录不可以执行php
location /uploaddir {
location ~ .php$ {return 403;}
# [...]
}
使用tryfles指令过滤有问题的条件
location ~* .php$ {
try</em>files $uri =404;
fastcgi<em>pass backend;
# [...]
}
使用嵌套location过滤
location ~* .php$ {
location ~ ..<em>/.</em>.php$ {return 404;}
fastcgi</em>pass backend;
# [...]
}
脚本文件中的FastCGI路径
太多例子说用绝对路径来指定路径的错误做法。通常见于php配置块。当你从svn中安装NGINX，通常会有include fastcgiparams;在你的配置中，目录一般在/etc/nginx。
优：
<em>fastcgi</em>param SCRIPT<em>FILENAME $document</em>root$fastcgi<em>script</em>name;
劣：
fastcgi<em>param SCRIPT</em>FILENAME /var/www/yoursite.com/$fastcgi<em>script</em>name;
$docmentroot在哪设的？通常是在你的server块里，不在？看看上面的第一个坑。
