最近新配置的 Nginx + PHP-FPM 环境遇到了几次 Nginx 500（Internal Server Error） 和 504（gateway timeout） 错误。就索性把配置修改的过程记录下来，已备后查。

先说一下 500 错误，这个一般是 PHP 代码错了，看一下 PHP 的 error 日志就清楚了。但有时候是 Nginx 和 PHP-FPM 配置不当导致的，比如说上传文件的场景。我们都知道 php.ini 文件里面 post_max_size 和 upload_max_filesize 两个配置项决定了文件上传的大小。但上调配置后发现大文件上传还是会 500，原来是因为 Nginx 也会限制上传文件的大小，有 client_max_body_size 配置项决定。这里还有一个比较重要的参数：client_body_buffer_size。为了节省资源 Nginx 不会把 request body 里面的数据一口气读到内存中，而是分片处理，这个参数就是设置缓存区的大小（一般也不用改），大于缓冲区大小的数据会以一个个小文件（buffer_size）形式存储到 client_body_temp_path，为了避免高并发下缓存文件冲突和一些文件系统限制（比如 ext3 磁盘格式文件夹下一级文件个数限制为 3.2w 个）以及提高性能可根据业务需要设置多级子目录。还需特别注意的是路径要有被 Nginx 进程写的权限，不然又会 500 错误了。

然后是 504 错误，除了业务代码本身超时更多是配置问题。还是先说 PHP 的配置，很多人都知道 PHP 脚本有执行时间限制（php.ini 中的 max_execution_time），但在 PHP-FPM 却是 php-fpm.conf 中的 request_terminate_timeout 配置项控制的。还有就是 max_input_time 配置项，值比较小的话在接收大文件或大数据量 POST 请求的时候可能会超时，一般不用做改动，因为大部分场景都是上游 web server 接收好数据后传给 PHP-FPM 进程的，传输的非常快，几乎不会超时，但也不能一概而论，要看具体业务场景。然后就是 Nginx 的锅了，刚也说到是 Nginx 接收好（或者说是转发）数据后传给下游，在这个承上启下的环节很容易超时。几个比较重要的配置项：fastcgi_send_timeout 控制向下游（这里是 PHP-FPM）发送数据的超时时间，与之对应的一个配置项是 fastcgi_read_timeout，表示读取下游 response 的超时时间，这里需要注意的是要和前面说的 request_terminate_timeout 保持一致（或大于）。还有一个配置项 fastcgi_connect_timeout，表示和下游 FastCGI 建立连接的超时时间，不过这个值就不用设置的太长了，不然下游某个节点挂了就会夯住 Nginx 的处理线程，影响业务。

我所遇到的场景就是上面这些，可能还有其它一些情况，具体问题具体分析应该也很好解决。

参考资料：

https://nginx.org/en/docs/http/ngx_http_core_module.html

https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html

《PHP-CGI 进程 CPU 100% 与 file_get_contents 函数的关系》 http://zyan.cc/tags/request_terminate_timeout/1/

《PHP超时处理全面总结》 https://segmentfault.com/a/1190000000313184

《PHP file upload affected or not by max_input_time?》 https://stackoverflow.com/questions/11387113/php-file-upload-affected-or-not-by-max-input-time