Nginx应对Permission denied和File not found的配置
13:Permissiondenied
前段时间把程序员的wordpress升级到3.5.1，本身如果没有特别的插件，在后台更新就能完成。
更新完成后在后台发布文章，编辑器不能点击可视化标签，只能显示html标签，看了下js控制台提示ReferenceError:tinyMCEisnotdefined3.5。
直觉以为升级哪里有问题，简单粗暴的重装了，可是还是不行，这时候就觉得可能是nginx哪里配置的问题了。
查看了一下日志文件，发现有下面的错误提示：
2013/03/1301:22:17[crit]3331#0:*10open()"/usr/local/lnmp/nginx/fastcgi_temp/3/00/0000000003"failed(13:Permissiondenied)whilereadingupstream,client:124.42.13.230,server:264.cn,request:"GET/wp-admin/load-scripts.php?c=0&load%5B%5D=jquery,utils,plupload,plupload-html5,plupload-flash,plupload-silverlight,plupload-html4,json2&ver=3.5.1HTTP/1.1",upstream:"fastcgi://127.0.0.1:9000",host:"264.cn",referrer:"http://www.nginx.cn/wp-admin/post-new.php"
很明浏览器只加载了部分页面，原因是Permissiondenied。
首先确认工作进程(workerprocess)的用户:
检查配置文件nginx.conf的user指令
userwww-data;
后者执行命令
#psaux|grep"nginx:workerprocess"|awk'{print$1}'
www-data
都可以得到nginx工作进程的运行用户
检查nginx的proxy_temp目录的所有者，
drwx------2rootroot4096Mar303:28proxy_temp
可以看到proxy_temp的所有者不是www-data，修改目录所有者为www-data即可。
chown-Rwww-data:www-dataproxy_temp
通过以上的步骤，wordpress就可以正常的显示，不会出现后台的js错误了。
分析下failed(13:Permissiondenied)whilereadingupstream问题的原因
首先看一下nginx反向代理参数说明
- proxy_connect_timeout600;#nginx跟后端服务器连接超时时间(代理连接超时)
- proxy_read_timeout600;#连接成功后，后端服务器响应时间(代理接收超时)
- proxy_send_timeout600;#后端服务器数据回传时间(代理发送超时)
- proxy_buffer_size32k;#设置代理服务器（nginx）保存用户头信息的缓冲区大小
- proxy_buffers432k;#proxy_buffers缓冲区，网页平均在32k以下的话，这样设置
- proxy_busy_buffers_size64k;#高负荷下缓冲大小（proxy_buffers*2）
- proxy_temp_file_write_size64k;#设定缓存文件夹大小，大于这个值，将从upstream服务器传
问题就出在proxy_temp_file_write_size上，当你的文件超过该参数设置的大小时，nginx会先将文件写入临时目录(缺省为nginx安装目下/proxy_temp目录),
如果nginx对prxoy_temp没有权限就会写不进去，结果就是只显示部分页面。
我遇到这个案例用工具查看了一下，post-new.php这个页面大小事94，超过了64k就要符合我们上面的分析。
Filenotfound错误
使用php-fpm解析PHP，"Noinputfilespecified"，"Filenotfound"是令nginx新手头疼的常见错误，原因是php-fpm进程找不到SCRIPT_FILENAME配置的要执行的.php文件，php-fpm返回给nginx的默认404错误提示。
比如我的网站doucument_root下没有test.php，访问这个文件时通过抓包可以看到返回的内容。
HTTP/1.1404NotFound Date:Fri,21Dec201208:15:28GMT Content-Type:text/html Proxy-Connection:close Server:nginx/1.2.5 X-Powered-By:PHP/5.4.7 Via:1.1c3300(NetCacheNetApp/6.0.7) Content-Length:16 Filenotfound.
很多人不想用户直接看到这个默认的404错误信息，想自定义404错误.
给出解决办法前我们来先分析下如何避免出现这类404错误，然后再说真的遇到这种情况(比如用户输入一个错误不存在的路径)时该怎么办，才能显示自定义的404错误页。
一、错误的路径被发送到php-fpm进程
出现这类错误，十个有九个是后端fastcgi进程收到错误路径(SCRIPT_FILENAME)，而后端fastcgi收到错误路径的原因大都是配置错误。
常见的nginx.conf的配置如下：
server{
listen[::]:80;
server_nameexample.comwww.example.com;
access_log/var/www/logs/example.com.access.log;
location/{
root/var/www/example.com;
indexindex.htmlindex.htmindex.pl;
}
location/images{
autoindexon;
}
location~.php${
fastcgi_pass127.0.0.1:9000;
fastcgi_indexindex.php;
fastcgi_paramSCRIPT_FILENAME/var/www/example.com$fastcgi_script_name;
includefastcgi_params;
}
}
这个配置中有很多不合理的地方，其中一个明显的问题就是root指令被放到了location/块。如果root指令被定义在location块中那么该root指令只能对其所在的location生效。其它locaiont中没有root指令，像location/images块不会匹配任何请求，需要在每个请求中重复配置root指令来解决这个问题。因此我们需要把root指令放在server块，这样各个location就会继承父server块定义的$document_root，如果某个location需要定义一个不同的$document_root，则可以在location单独定义一个root指令。
另一个问题就是fastCGI参数SCRIPT_FILENAME是写死的。如果修改了root指令的值或者移动文件到别的目录，php-fpm会返回“Noinputfilespecified”错误，因为SCRIPT_FILENAME在配置中是写死的并没有随着$doucument_root变化而变化，我们可以修改SCRIPT_FILENAME配置如下：
fastcgi_paramSCRIPT_FILENAME$document_root$fastcgi_script_name;
所以我们不能忘记在server块中配置root指令，不然$document_root的值为空，只会传$fastcgi_script_name到php-fpm，这样就会导致“Noinputfilespecified”错误。
二、请求的文件真的不存在
当nginx收到一个不在的.php文件的请求时,因为nginx只会检查$uri是否是.php结尾，不会对文件是否存在进行判断，.php结尾的请求nginx会直接发给php-fpm处理。php-fpm处理时找不到文件就会返回“Noinputfilespecified”带着“404NotFound”头。
解决办法
我们在nginx拦截不存在的文件，请求并返回自定义404错误
使用try_files捕捉不存在的urls并返回错误。
location~.php${
try_files$uri=404;
fastcgi_pass127.0.0.1:9000;
fastcgi_indexindex.php;
fastcgi_paramSCRIPT_FILENAME....
...................................
...................................
}
上面的配置会检查.php文件是否存在，如果不存在，会返回404页面。