我基本都是用同一个配置文件在centos下配置lnmp组合，从来没有出现过任何问题。但是最近在一个vps上安装了同样的环境后，10多人在线时网站打开速度非常慢。有几次，nginx中设置的脚本最大超时时间直接达到了300秒。结果nginx向客户端浏览器发送了一个504网关超时错误代码，经过分析，更改了几个配置文件。
从错误码来看，基本可以确定与nginx本身无关，主要是提交给php-fpm的请求未能被正确反馈。一般在提交动态请求时，nginx会直接将请求转发给php-fpm，PHP-fpm再重新分配php-cgi进程处理相关请求，然后依次返回。最后，nginx会将结果反馈给客户端浏览器。但是，我的vps目前运行的是纯php应用内容。事实上，所有用户的请求都是php请求，其中一些请求需要很长时间，php-cgi进程总是被用完。但是php- fpm本身的配置文件只开放10组php-cgi进程，这样如果在线用户多一点，请求就不能正常处理，就会出错。
分析了原因之后，就比较容易做到以下几点了。首先，改变php-fpm的几个配置：
把max_children从之前的10个改成现在的30个，这样可以用足够多的php-cgi进程；
将request_terminate_timeout由之前的0s改为60s，这样php-cgi进程处理脚本的超时为60秒，可以防止所有进程被挂起，提高利用效率。
然后改变nginx的几个配置项，减少FastCGI的请求数量，尽量保持缓冲区不变：
Fastcgi_buffers从4 64k更改为2 256k；
fastgi _ buffer _ size由64k改为128K；
fastgi _ busy _ buffers _ size从128K更改为256K；
fastgi _ temp _ file _ write _ size从128K更改为256K。
好了，重新加载php-fpm和nginx的配置，再次测试。到现在两周没有504网关超时，就是这个结果。
另一个例子：
Ie管用。别人用FF。但是一个人使用FF浏览并报告错误502。
查看后台错误日志，找到一句话
从上游读取响应标头时，上游发送了太大的标头
只是反馈头信息太大了。
它通常被放在饼干里。
怀疑是FF中的一个插件导致返回过多的头信息。
一个接一个。最后发现是萤火虫引起的。
由于fastcgi返回的头太大，所以应该是可配置的。
搜了一下资料，发现应该和fastcgi_buffer_*有关
增加相关配置。解决发现的问题。
这里使用的是
fastcgi _ buffer _ size 32k
fastcgi _ buffers 8 32k
它比原来默认的4k/8k大得多
Http400错误：
NGX的HTTP400错误，而且这个HTTP400错误也不是每次都有。经过检查，发现nginx 400错误是由于请求头过大，通常是由cookie中写入的长字符串引起的。解决方法是不要在cookie中记录太多数据。如有必要，考虑调整nginx.conf中的client_header_buffer_size(默认1k)。
如果cookie太大，可能需要调整large_client_header_buffers(默认值为4k)。该参数描述如下：
如果请求行超出缓冲区，它将报告HTTP 414错误(URI太长)
Nginx接受最长的HTTP头大小必须大于缓冲区的大小，否则它将报告400 HTTP错误(错误请求)。
Http413错误：
Nginx上传时返回413错误。查看日志文件，显示的错误信息是“413请求实体太大”，于是上网搜索“nginx 413错误”，发现需要进行以下设置：
在nginx.conf中添加client_max_body_size的设置，默认为1m，可以增加到8m。
