----------------------------下面梳理几个常见的php不恰当配置引发的问题-----------------------------
1）request_terminate_timeout的值如果设置为0或者过长的时间，可能会引起file_get_contents的资源问题。 如果访问请求的远程资源反应过慢，php-cgi进程就会一直卡在那里不会超时。虽然php.ini文件里面max_execution_time可以设置PHP脚本的最大执行时间，但是，在php-cgi(php-fpm) 中该参数不会起效。真正能够控制PHP脚本最大执行时间的是php-fpm.conf配置文件中的request_terminate_timeout参数。 request_terminate_timeout默认值为0秒，也就是说，PHP脚本会一直执行下去。这样当所有的php-cgi进程都卡住时，这台Nginx+PHP的WebServer已经无法再处理新的PHP请求了，Nginx 将给用户返回“502 Bad Gateway”。 修改该参数，设置一个PHP脚本最大执行时间是必要的，但是治标不治本。例如改成30s，如果发生访问获取网页内容较慢的情况，这就意味着150个php-cgi进程，每秒钟只能处理5个请求，WebServer同样很难避免”502 Bad Gateway”。 解决办法是request_terminate_timeout设置为10s或者一个合理的值。 2）max_requests参数配置不当，可能会引起间歇性502错误 设置每个子进程重生之前服务的请求数. 对于可能存在内存泄漏的第三方模块来说是非常有用的. 如果设置为0，则一直接受请求，等同于php_fcgi_max_requests环境变量。默认值为 0. 比如：pm.max_requests = 1000 这个配置的意思是，当一个 php-cgi 进程处理的请求数累积到500个后，自动重启该进程。 但是为什么要重启进程呢？ 一般在项目中，多多少少都会用到一些PHP的第三方库，这些第三方库经常存在内存泄漏问题，如果不定期重启php-cgi进程，势必造成内存使用量不断增长。因此php-fpm作为php-cgi的管理器，提供了这么一项监控功能，对请求达到指定次数的php-cgi进程进行重启，保证内存使用量不增长。正是因为这个机制，在高并发的站点中，经常导致502错误， 目前解决方法是，把这个值尽量设置大些，尽可能减少php-cgi重新SPAWN的次数，同时也能提高总体性能。在实际的生产环境中发现，内存泄漏如果不明显，可以将这个值设置得非常大（比如204800）。要根据自己的实际情况设置这个值（比如我们线上设置1024），不能盲目地加大。 话说回来，这套机制目的只为保证php-cgi不过分地占用内存，为何不通过检测内存的方式来处理呢？通过设置进程的峰值内在占用量来重启php-cgi进程，会是更好的一个解决方案。 3）php-fpm的慢日志，debug及异常排查神器 request_slowlog_timeout设置一个超时的参数，slowlog设置慢日志的存放位置
以上这篇php安全配置记录和常见错误梳理(总结)就是小编分享给大家的全部内容了，希望能给大家一个参考，也希望大家多多支持易采站长站。
