半夜还在维护服务器！公司有一定的基础用户量，春节期间用户量暴增，导致服务器鸭梨山大报警了！没办法，这些都是应该经历的。下面就总结一下nginx的一些问题，希望以后不要再犯同样的错误。
- 499错误
官方解释：
ngx_string(ngx_http_error_495_page), /* 495, https certificate error*/
ngx_string(ngx_http_error_496_page), /* 496, https no certificate */
ngx_string(ngx_http_error_497_page), /* 497, http to https */
ngx_string(ngx_http_error_404_page), /* 498, canceled */
ngx_null_string, /* 499, client has closed connection */499，客户端关闭连接，这个状态码并不是http协议中定义的status code，而是nginx自己定义的一个状态码。由于服务器处理请求较多，客户端在有效时间内没有得到答复，主动关闭了连接。有人说把时间设置长一些或者使用proxy_ignore_client_abort on（让代理服务端不要主动关闭客户端的连接）。但是这样也有一定的风险，会拖垮服务器。发生这个错误，如果服务器CPU和内存不算太高，一般是数据库和程序的问题，数据库处理较慢或者程序线程较低。结合情况调整，比如读写分离或者程序线程数调高。
- recv() failed (104: Connection reset by peer) while reading response header from upstream
程序执行太久而被终止，在代理处添加fail_timeout和max_fails，加在代理服务的后面。这2个参数一起配合，来控制nginx怎样认为upstream中的某个server是失效的。当在fail_timeout的时间内，某个server连接失败了max_fails次，则nginx会认为该server不工作了。同时，在接下来的 fail_timeout时间内，nginx不再将请求分发给失效的server。如果不设置这2个参数，fail_timeout默认为10s，max_fails默认为1。就是说，只要某个server失效一次，则在接下来的10s内，就不会分发请求到该server上。为了避免因为意外原因导致的错误判断，所以要根据实际并发情况填写合理的值。max_fails=0则表示不做判断，即使有多次失败请求，后面的请求也会继续发给它处理。
- accept() failed (24: Too many open files)
打开文件数太多，受到限制。ulimit -n,查看Linux可打开文件总数。解决这个问题，把worker_rlimit_nofile和worker_connections设置高一些就好了。worker_rlimit_nofile 更改worker进程的最大打开文件数限制，worker_connections 设置可由一个worker进程同时打开的最大连接数。最大客户数也由系统的可用socket连接数限制（~ 64K），所以设置不切实际的高没什么好处。注意worker_connections不要超过worker_rlimit_nofile。