nginx配置的常见陷阱及错误
转自：http://article.yeeyan.org/view/550060/489491
不管是新老用户都可能掉进同样的陷阱里。下面我们列举了觉的问题同时也给出了解决办法。在Freenode的IRC频道#nginx里，我们经常遇到这类问题。
导言
这些常见问题，一般是因某人试图从别人的配置里直接拷贝后拿来用，并不是所有拷贝的都有问题，可惜的是，大部分都有问题。即使是Linode文档库里也存在因社区成员不去维护导致质量差的信息。
这个文档由大量NGINX社区成员创建和审查，这个特殊文档的存在也是因为这些太过来常见了并经常发生。
如果你的问题并未列明
你可能并没有找你跟你直接有关的特殊问题，也许我们确实是没有指出你经常的特殊问题。但，不要以为你来到这个页面是没有原因的，你被带到这个页面至少表示你在下面的问题里遇到过问题：）
Chmod 777
永远不要使用777。不要以为这只是一个漂亮的数字，即使在测试环境也表明你会没有线索查你正在做的事。你可以对整个路径的权限进行检查，可以考虑你正在做的事实。
要检查路径的权限，你可以：
namei -om /path/to/check
Location 里的 root 配置
劣：
server {
servername www.example.com;
location / {
root /var/www/nginx-default/;
# [...]
}
location /foo {
root /var/www/nginx-default/;
# [...]
}
location /bar {
root /var/www/nginx-default/;
# [...]
}
}
可以工作。每个location块里都加上root指令没有错，也能很好的工作。那会有什么问题呢？如果某一个location块你路径写错了，将导致没有根目录。来看下什么是优的配置。
优：
server {
servername www.example.com;
root /var/www/nginx-default/;
location / {
# [...]
}
location /foo {
# [...]
}
location /bar {
# [...]
}
}
多个Index指令
劣：
http {
index index.php index.htm index.html;
server {
servername www.example.com;
location / {
index index.php index.htm index.html;
# [...]
}
}
server {
servername 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 {
servername www.example.com;
location / {
# [...]
}
}
server {
servername example.com;
location / {
# [...]
}
location /foo {
# [...]
}
}
}
使用if指令
只有少数一些讨论if的文章，有篇叫 if是魔鬼 的你一定要看，下面举些列子说明为何if如果坏。
servername指令与if
劣：
server {
servername example.com .example.com;
if ($host ~ ^www.(.+)) {
set $rawdomain $1;
rewrite ^/(.)$ $rawdomain/$1 permanent;
}
# [...]
}
}
这里实际上有三个问题。首先看看if，也是我们现在要关注的，为何是劣的？你读过这篇文章 If是魔鬼 吗？当nginx接收到一个请求不管子域名是什么，即使是www.example.com或example.com，if指令也是每次都要调用，因为NGINX需要每次对请求头Host做处理，这特别没有效率，你要千万注意避免它。可以替换为两个server区块，如下面的列子：
优：
server {
servername www.example.com;
return 301 $scheme://example.com$requesturi;
}
server {
servername example.com;
# [...]
}
这种配置也可以使配置更好阅读，这种方法减少了NGINX的处理需求。我们去除了谬误的if，同时我们使用了$schema避免了硬编码URI，如http或https。
检查文件是否存在（if）
使用if来判断一个文件是否存在太可怕了。也就是说如果你有最新版的NGINx，使用tryfiles指令将更加容易。
劣：
server {
root /var/www/example.com;
location / {
if (!-f $requestfilename) {
break;
}
}
}
优：
server {
root /var/www/example.com;
location / {
tryfiles $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支持这个：
try_files $uri $uri/ /index.php;
如果你不关心检查目录，只要去掉$uri/。
当然，你可能遇到些特殊情况，需要更复杂的配置，但对一般站点，这些就够了。
传递未受控的请求到PHP
很多NGINX+PHP的配置会传递所有以.php结尾的请求给php，但这里会出现一个严重的安全问题，可能导致精心构造的代码被执行。
这类问题看起来如：
location ~ .php$ {
fastcgipass 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 ~* (filea|fileb|filec).php$ {
fastcgipass backend;
# [...]
}
指定用户上传的目录不可以执行php
location /uploaddir {
location ~ .php$ {return 403;}
# [...]
}
使用tryfles指令过滤有问题的条件
location ~* .php$ {
tryfiles $uri =404;
fastcgipass backend;
# [...]
}
使用嵌套location过滤
location ~* .php$ {
location ~ ../..php$ {return 404;}
fastcgipass backend;
# [...]
}
脚本文件中的FastCGI路径
太多例子说用绝对路径来指定路径的错误做法。通常见于php配置块。当你从svn中安装NGINX，通常会有include fastcgiparams;在你的配置中，目录一般在/etc/nginx。
优：
fastcgiparam SCRIPTFILENAME $documentroot$fastcgiscriptname;
劣：
fastcgiparam SCRIPTFILENAME /var/www/yoursite.com/$fastcgiscriptname;
$docmentroot在哪设的？通常是在你的server块里，不在？看看上面的第一个坑。
费力的Rewrites
在这不要犯糊，很容易被正则表达式搞蒙，事实上，很简单，只要努力做到足够简单就行。
劣：
rewrite ^/(.*)$ http://example.com/$1 permanent;
优：
rewrite ^ http://example.com$request_uri? permanent;
更优：
return 301 http://example.com$request_uri;
看看上面的例子，第一个规则是获取全部url然后减fcfu最一个反斜杆，事实上使用内置变量$request_uri可以更简单。
Rewrite丢失的http://
非常简单，rewrites规则都是相对路径，除非你告诉NGINX不是，使用rewrite的绝对路径也很简单，添加一个schema。
劣：
rewrite ^ example.com permanent;
优：
rewrite ^ http://example.com permanent;
上面的例子中只是添加了http://，简单而有效。
代理 所有内容
劣：
server {
server_name _;
root /var/www/site;
location / {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/tmp/phpcgi.socket;
}
}
恶心。这个例子中，什么内容都代理给了PHP，为什么？Apache也许用来替代，但没必要。try_files指令神奇的地方是：它按一定的顺序尝试使用文件。NGINX可以首先尝试静态文件，如果没有，继续尝试。意思是PHP不一定要处理所有文件。速度将更快！例如你有个1M的图片比较下通过用PHP来处理和用服务器直接处理的速度。看看优化后的方案：
server {
server_name _;
root /var/www/site;
location / {
try_files $uri $uri/ @proxy;
}
location @proxy {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/tmp/phpcgi.socket;
}
}
同样也是好的方案
server {
server_name _;
root /var/www/site;
location / {
try_files $uri $uri/ /index.php;
}
location ~ .php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/tmp/phpcgi.socket;
}
}
很容易不是吗？如果请求的URI存在，NGINX可以直接处理，如果不存在，如果是个目录也可以处理，如果还不是，再传递给代理。仅当NGINX不能处理时才传递给代理。
考虑下你的多少内容是静态的（图片、css、javascript等），可能能节省下大量的消耗。
配置不生效的修改
浏览器缓存的问题。你的配置也许很完善但也有撞墙的时候。出现问题的原因就是浏览器缓存。当下载页面时，浏览器会做缓存，同时也保存了文件怎么更新，如果你在测试 types{}指令，你可能需要通过以下方法来清缓存
- 在firefox使用ctrl+shift+delete，清掉缓存；
- 使用curl查看文件是否更新
VirtualBox虚拟机
如果nginx工作不正常可能是因为sendfile指令，只要注释掉再试下。
丢失的HTTP头信息
如果你没有设置underscores_in_headers on;指令，NGINX将把包括下划线的头信息丢掉（依据http标准），这也是为了一种保护机制，防止异常的头信息与CGI变量冲突。
没有使用标准的Document Root 位置信息
所有系统都有些不能使用的目录，如/和root，永远不要设置成document root目录。一般都是放在/var/www或/srv或/usr/share/www/。
使用默认的Document Root
不要使用系统安装包默认的DocumentRoot目录，因为软件升级或重新安装时，有可能修改该目录，如果你的业务刚好在使用这个目录，oops，目录有可能被删除并安装它的默认文件。小心。
使用主机名来解析地址
劣：
upstream {
server http://someserver;
}
优：
server {
listen myhostname:80;
# [...]
}
永远不要在listen指令中使用主机名。虽然可以工作，但会带来很多问题，一个是系统启动或service启动时hostname不一定能解析，这将导致nginx不能绑定到指令的tcp socket并启动失败。
安全的做法是指令ip地址来代替主机名。避免了域名解析的成本。同理，在upstream也一样，尽量避免使用主机名。
优：
upstream {
server http://10.48.41.12;
}
注：多虚拟主机名时还是避免不了。
HTTPS使用SSLv3
SSLv3因为有安全风险，建议不要使用，而用TLS代替。
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;