nginx173错误码

Posted 2023-04-23

附表：HTTP响应码

1XX代表提示信息
2XX代表成功信息
3XX代表重定向信息
4XX代表客户端错误信息
5XX代表服务器错误信息
 
状态码 含义
100 客户端应当继续发送请求。这个临时响应是用来通知客户端它的部分请求已经被服务器接收，且仍未被拒绝。客户端应当继续发送请求的剩余部分，或者如果请求已经完成，忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应。
101 服务器已经理解了客户端的请求，并将通过Upgrade 消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后，服务器将会切换到在Upgrade 消息头中定义的那些协议。 　　只有在切换新的协议更有好处的时候才应该采取类似措施。例如，切换到新的HTTP 版本比旧版本更有优势，或者切换到一个实时且同步的协议以传送利用此类特性的资源。
102 由WebDAV（RFC 2518）扩展的状态码，代表处理将被继续执行。
200 请求已成功，请求所希望的响应头或数据体将随此响应返回。
201 请求已经被实现，而且有一个新的资源已经依据请求的需要而建立，且其 URI 已经随Location 头信息返回。假如需要的资源无法及时建立的话，应当返回 ‘202 Accepted‘。
202 服务器已接受请求，但尚未处理。正如它可能被拒绝一样，最终该请求可能会也可能不会被执行。在异步操作的场合下，没有比发送这个状态码更方便的做法了。 　　返回202状态码的响应的目的是允许服务器接受其他过程的请求（例如某个每天只执行一次的基于批处理的操作），而不必让客户端一直保持与服务器的连接直到批处理操作全部完成。在接受请求处理并返回202状态码的响应应当在返回的实体中包含一些指示处理当前状态的信息，以及指向处理状态监视器或状态预测的指针，以便用户能够估计操作是否已经完成。
203 服务器已成功处理了请求，但返回的实体头部元信息不是在原始服务器上有效的确定集合，而是来自本地或者第三方的拷贝。当前的信息可能是原始版本的子集或者超集。例如，包含资源的元数据可能导致原始服务器知道元信息的超级。使用此状态码不是必须的，而且只有在响应不使用此状态码便会返回200 OK的情况下才是合适的。
204 服务器成功处理了请求，但不需要返回任何实体内容，并且希望返回更新了的元信息。响应可能通过实体头部的形式，返回新的或更新后的 参考技术A nginx173错误码（error ）是指人们在使用软、硬件的时候，软、硬件不能正常操作的一种现象。由于错误的类型很多，为了对错误进行区分，系统设定了错误代码（error code），软、硬件在运行中如果发生错误，将通过它内部的原有的设定判断、识别而通过错误代码的显示方式给操作者，操作者通过错误代码识别，快速找到软、硬件不能正常操作的具体原因。

HTTP 499 状态码 nginx下 499错误

HTTP 499 状态码 nginx下 499错误

    日志记录中HTTP状态码出现499错误有多种情况，我遇到的一种情况是nginx反代到一个永远打不开的后端，就这样了，日志状态记录是499、发送字节数是0。

    老是有用户反映网站系统时好时坏，因为线上的产品很长时间没有修改，所以前端程序的问题基本上可以排除，于是就想着是Get方式调用的接口不稳定，问了相关人员，说没有问题，为了拿到确切证据，于是我问相关人员要了nginx服务器的日志文件（awstats日志），分析后发现日志中很多错误码为499的错误，约占整个日志文件的1%，而它只占全部报错的70%左右（全部报错见下图），那么所有报错加起来就要超过1%了，这个量还是特别大的。

    499错误是什么？让我们看看NGINX的源码中的定义：

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对应的是 “client has closed connection”。这很有可能是因为服务器端处理的时间过长，客户端“不耐烦”了。

    Nginx 499错误的原因及解决方法
    打开Nginx的access.log发现在最后一次的提交是出现了HTTP1.1 499 0 -这样的错误，在百度搜索nginx 499错误，结果都是说客户端主动断开了连接。
    但经过我的测试这显然不是客户端的问题，因为使用端口+IP直接访问后端服务器不存在此问题，后来测试nginx发现如果两次提交post过快就会出现499的情况，看来是nginx认为是不安全的连接，主动拒绝了客户端的连接.

    但搜索相关问题一直找不到解决方法，最后终于在google上搜索到一英文论坛上有关于此错误的解决方法：
proxy_ignore_client_abort on;
Don’t know if this is safe.
    就是说要配置参数 proxy_ignore_client_abort on;
    表示代理服务端不要主要主动关闭客户端连接。

    以此配置重启nginx,问题果然得到解决。只是安全方面稍有欠缺，但比总是出现找不到服务器好多了。

    还有一种原因是 我后来测试发现 确实是客户端关闭了连接,或者说连接超时 ,无论你设置多少超时时间多没用 原来是php进程不够用了 改善一下php进程数 问题解决 默认测试环境才开5个子进程。