HTTP常见的错误返回代码处理过程

  1. 云栖社区>
  2. 博客>
  3. 正文

HTTP常见的错误返回代码处理过程

技术小阿哥 2017-11-27 12:01:00 浏览597
展开阅读全文

1xx响应信息提示 
这些状态代码表示临时的响应。客户端在收到常规响应之前,应准备接收一个或多个1xx 
100 - Continue 初始的请求已经接受,客户应当继续发送请求的其余部分。(HTTP 1.1新) 
101 - Switching Protocols 服务器将遵从客户的请求转换到另外一种协议(HTTP 1.1新) 
2xx - 成功 
这类状态代码表明服务器成功地接受了客户端请求。 
 200 - OK 一切正常,对GET和POST请求的应答文档跟在后面。 
201 - Created 服务器已经创建了文档,Location头给出了它的URL。 
202 - Accepted 已经接受请求,但处理尚未完成。 
203 - Non-Authoritative Information 文档已经正常地返回,但一些应答头可能不正确,因为使用的是文档的拷贝,非权威性信息(HTTP 1.1新)。 
204 - No Content 没有新文档,浏览器应该继续显示原来的文档。如果用户定期地刷新页面,而Servlet可以确定用户文档足够新,这个状态代码是很有用的。 
205 - Reset Content 没有新的内容,但浏览器应该重置它所显示的内容。用来强制浏览器清除表单输入内容(HTTP 1.1新)。 
206 - Partial Content 客户发送了一个带有Range头的GET请求(分块请求),服务器完成了它(HTTP 1.1新)。 
3xx - 重定向 
客户端浏览器必须采取更多操作来实现请求。例如,浏览器可能不得不请求服务器上的不同的页面,或通过代理服务器重复该请求。 
300 - Multiple Choices 客户请求的文档可以在多个位置找到,这些位置已经在返回的文档内列出。如果服务器要提出优先选择,则应该在Location应答头指明。 
 301 - Moved Permanently 客户请求的文档在其他地方,新的URL在Location头中给出,GET、HEAD请求时浏览器应该自动地访问新的URL。 
 302 - Found 类似于301,但新的URL应该被视为临时性的替代,而不是永久性的。注意,在HTTP1.0中对应的状态信息是“Moved Temporatily”。出现该状态代码时,浏览器能够自动访问新的URL,因此它是一个很有用的状态代码。注意这个状态代码有时候可以和301替换使 用。例如,如果浏览器错误地请求 http://host/~user (缺少了后面的斜杠),有的服务器返回301,有的则返回302。严格地说,我们只能假定只有当原来的请求是GET、HEAD时浏览器才会自动重定向。请参见307。 


首先看一个完整代码示例,关于nginx 301 302跳转的。

301跳转设置:

server {
listen 80;
server_name 123.com;
rewrite ^/(.*) http://456.com/$1 permanent;
access_log off;
}

302跳转设置:

server {
listen 80;
server_name 123.com;
rewrite ^/(.*) http://456.com/$1 redirect;
access_log off;
}

在看下关于nginx 301 302跳转的详细说明文档

server {
server_name test.com;
rewrite ^/(.*) http://www.test1.com/$1 permanent;
}

last – 基本上都用这个Flag。
break – 中止Rewirte,不在继续匹配
redirect – 返回临时重定向的HTTP状态302
permanent – 返回永久重定向的HTTP状态301

Nginx的重定向用到了Nginx的HttpRewriteModule,下面简单解释以下如何使用的方法:
rewrite命令

nginx的rewrite相当于apache的rewriterule(大多数情况下可以把原有apache的rewrite规则加上引号就可以直接使用),它可以用在server,location 和IF条件判断块中,命令格式如下:
rewrite 正则表达式 替换目标 flag标记
flag标记可以用以下几种格式:
last – 基本上都用这个Flag。
break – 中止Rewirte,不在继续匹配
redirect – 返回临时重定向的HTTP状态302
permanent – 返回永久重定向的HTTP状态301


特别注意:

last和break用来实现URL重写,浏览器地址栏的URL地址不变,但是在服务器端访问的路径发生了变化;

redirect和permanent用来实现URL跳转,浏览器地址栏会显示跳转后的URL地址;


例如下面这段设定nginx将某个目录下面的文件重定向到另一个目录,$2对应第二个括号(.*)中对应的字符串:
location /download/ {
rewrite ^(/download/.*)/m/(.*)\..*$ $1/nginx-rewrite/$2.gz break;
}
nginx重定向的IF条件判断

在server和location两种情况下可以使用nginx的IF条件判断,条件可以为以下几种:
正则表达式

如:
匹配判断
~ 为区分大小写匹配; !~为区分大小写不匹配
~* 为不区分大小写匹配;!~为不区分大小写不匹配
例如下面设定nginx在用户使用ie的使用重定向到/nginx-ie目录下:
if ($http_user_agent ~ MSIE) {
rewrite ^(.*)$ /nginx-ie/$1 break;
}
文件和目录判断
-f和!-f判断是否存在文件
-d和!-d判断是否存在目录
-e和!-e判断是否存在文件或目录
-x和!-x判断文件是否可执行
例如下面设定nginx在文件和目录不存在的时候重定向:
if (!-e $request_filename) {
proxy_pass http://127.0.0.1;
}
return

返回http代码,例如设置nginx防盗链:
location ~* \.(gif|jpg|png|swf|flv)$ {
valid_referers none blocked www.test.com www.test1.com;
if ($invalid_referer) {
return 404;
}


303 - See Other 类似于301/302,不同之处在于,如果原来的请求是POST,Location头指定的重定向目标文档应该通过GET提取,即该状态码存在的最主要意义是为了处理POST请求重定向到GET请求的情况(HTTP 1.1新)。 
 304 - Not Modified 客户端有缓冲的文档并发出了一个条件性的请求(一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档)。服务器告诉客户,原来缓冲的文档还可以继续使用。


200是正常,304是内容没有修改

当你第一次访问时,服务器会返回给你200状态码,同时在头里追加ETag值给你。浏览器拿到后将其缓存。

下一次再访问时,因浏览器已经有该地址的ETag值了。会将其缓存的ETag值内容放在请求头的If-None-Match中,服务器检查其自身内容的ETag值是否与其一致,如果一致就会返回304状态码,告诉你内容和你保存的一致,没有发生改变过。

举例来说,
C:S,你几岁了?
S:C,我18岁了
===========
C:S,你几岁了?我猜你18岁了
S:靠,你知道还问我?(304)
===========
C:S,你几岁了?我猜你18岁了
S:C,我19岁了。(200)

以上就是200和304的解释


305 - Use Proxy 客户请求的文档应该通过Location头所指明的代理服务器提取(HTTP 1.1新)。 
307 - Temporary Redirect 许多浏览器会错误地响应302应答进行重定向,即使原来的请求是POST,即使它实际上只能在POST请求的应答是303时 才能重定向。由于这个原因,HTTP 1.1新增了307,以便更加清除地区分几个状态代码:当出现303应答时,浏览器可以跟随重定向的GET和POST请求;如果是307,301,302应答,则浏览器只能跟随对GET、HEAD请求的重定向。(HTTP 1.1新) 
4xx - 客户端错误 
发生错误,客户端似乎有问题。例如,客户端请求不存在的页面,客户端未提供有效的身份验证信息。 
400 - Bad Request 请求出现语法错误。 
401 - Unauthorized 访问被拒绝,客户试图未经授权访问受密码保护的页面。应答中会包含一个WWW-Authenticate头,浏览器据此显示用户名字/密码对话框,然后在 填写合适的Authorization头后再次发出请求。IIS 定义了许多不同的 401 错误,它们指明更为具体的错误原因。这些具体的错误代码在浏览器中显示,但不在 IIS 日志中显示: 
401.1 - 登录失败。 
401.2 - 服务器配置导致登录失败。 
401.3 - 由于 ACL 对资源的限制而未获得授权。 
401.4 - 筛选器授权失败。 
401.5 - ISAPI/CGI 应用程序授权失败。 
401.7 –访问被 Web 服务器上的 URL 授权策略拒绝。这个错误代码为 IIS 6.0 所专用。 
 403 - Forbidden 资源不可用。服务器理解客户的请求,但拒绝处理它。通常由于服务器上文件或目录的权限设置导致。禁止访问:IIS 定义了许多不同的 403 错误,它们指明更为具体的错误原因: 
403.1 - 执行访问被禁止。 
403.2 - 读访问被禁止。 
403.3 - 写访问被禁止。 
403.4 - 要求 SSL。 
403.5 - 要求 SSL 128。 
403.6 - IP 地址被拒绝。 
403.7 - 要求客户端证书。 
403.8 - 站点访问被拒绝。 
403.9 - 用户数过多。 
403.10 - 配置无效。 
403.11 - 密码更改。 
403.12 - 拒绝访问映射表。 
403.13 - 客户端证书被吊销。 
403.14 - 拒绝目录列表。 
403.15 - 超出客户端访问许可。 
403.16 - 客户端证书不受信任或无效。 
403.17 - 客户端证书已过期或尚未生效。 
403.18 - 在当前的应用程序池中不能执行所请求的 URL。这个错误代码为 IIS 6.0 所专用。 
403.19 - 不能为这个应用程序池中的客户端执行 CGI。这个错误代码为 IIS 6.0 所专用。 
403.20 - Passport 登录失败。这个错误代码为 IIS 6.0 所专用。 
 404 - Not Found 无法找到指定位置的资源。这也是一个常用的应答。 
404.0 -(无) – 没有找到文件或目录。 
404.1 - 无法在所请求的端口上访问 Web 站点。 
404.2 - Web 服务扩展锁定策略阻止本请求。 
404.3 - MIME 映射策略阻止本请求。 
405 - Method Not Allowed 请求方法(GET、POST、HEAD、DELETE、PUT、TRACE等)对指定的资源不适用,用来访问本页面的 HTTP 谓词不被允许(方法不被允许)(HTTP 1.1新) 
406 - Not Acceptable 指定的资源已经找到,但它的MIME类型和客户在Accpet头中所指定的不兼容,客户端浏览器不接受所请求页面的 MIME 类型(HTTP 1.1新)。 
407 - Proxy Authentication Required 要求进行代理身份验证,类似于401,表示客户必须先经过代理服务器的授权。(HTTP 1.1新) 
408 - Request Timeout 在服务器许可的等待时间内,客户一直没有发出任何请求。客户可以在以后重复同一请求。(HTTP 1.1新) 
409 - Conflict 通常和PUT请求有关。由于请求和资源的当前状态相冲突,因此请求不能成功。(HTTP 1.1新) 
410 - Gone 所请求的文档已经不再可用,而且服务器不知道应该重定向到哪一个地址。它和404的不同在于,返回407表示文档永久地离开了指定的位置,而404表示由于未知的原因文档不可用。(HTTP 1.1新) 
411 - Length Required 服务器不能处理请求,除非客户发送一个Content-Length头。(HTTP 1.1新) 
412 - Precondition Failed 请求头中指定的一些前提条件失败(HTTP 1.1新)。 
413 – Request Entity Too Large 目标文档的大小超过服务器当前愿意处理的大小。如果服务器认为自己能够稍后再处理该请求,则应该提供一个Retry-After头(HTTP 1.1新)。 
414 - Request URI Too Long URI太长(HTTP 1.1新)。 
415 – 不支持的媒体类型。 
416 – Requested Range Not Satisfiable 服务器不能满足客户在请求中指定的Range头。(HTTP 1.1新)  417 – 执行失败。 
423 – 锁定的错误。 
5xx - 服务器错误 
服务器由于遇到错误而不能完成该请求。 
500 - Internal Server Error 服务器遇到了意料不到的情况,不能完成客户的请求。 
500.12 - 应用程序正忙于在 Web 服务器上重新启动。 
500.13 - Web 服务器太忙。 
500.15 - 不允许直接请求 Global.asa。 
500.16 – UNC 授权凭据不正确。这个错误代码为 IIS 6.0 所专用。 
500.18 – URL 授权存储不能打开。这个错误代码为 IIS 6.0 所专用。 
500.100 - 内部 ASP 错误。 
501 - Not Implemented 服务器不支持实现请求所需要的功能,页眉值指定了未实现的配置。例如,客户发出了一个服务器不支持的PUT请求。 
 502 - Bad Gateway 服务器作为网关或者代理时,为了完成请求访问下一个服务器,但该服务器返回了非法的应答。 亦说Web 服务器用作网关或代理服务器时收到了无效响应。

502.1 - CGI 应用程序超时。 
502.2 - CGI 应用程序出错。 


Nginx 502 Bad Gateway错误的解决方案 彻底解决lnmp出现的502错误

Nginx  502 Bad Gateway错误的解决方案:

之前服务器是手工安装的,未发生过任何问题,后来使用Lnmp一键安装包部署Nginx环境,却发现经常出现 502 Bad Gateway 错误,比如在不停的刷新过程中,时不时就出现一次502错误;

经过本人摸索,终于发现了一个解决方法:

lnmp安装后,Fastcgi 默认的监听端口是这样的:fastcgi_pass  unix:/tmp/php-cgi.sock;

而随心微博之前没发生502错误的配置文件是:fastcgi_pass  127.0.0.1:9000;

换成监听9000端口后,再次狂刷新页面,没有出现;找一个外地朋友测试一下:刷新50+,没有出现502。而之前我是基本上刷新了八九次就会出现一次502错误;

所以,确定应该就是fastcgi监听端口的问题引起的;

具体步骤:

1.修改nginx.conf

nginx安装目录:/usr/local/nginx/conf/ ,打开nginx.conf,查找到:

fastcgi_pass  unix:/tmp/php-cgi.sock;

改为:

fastcgi_pass  127.0.0.1:9000;

2.修改php-fpm.conf

php安装目录:,/usr/local/php/etc/,打开php-fpm.conf

查找到第26行:

<value name="listen_address">/tmp/php-cgi.sock</value>

改为

<value name="listen_address">127.0.0.1:9000</value>

3.依次重启Nginx和php-fpm

nginx 重启:
/usr/local/nginx/sbin/nginx -t
/usr/local/nginx/sbin/nginx -s reload

php-fpm重启:

/usr/local/php/sbin/php-fpm restart

okay,完成操作,现在试试是否还存在502错误了吧,如果还存在,可能就是fastcgi进程数不够,可适当根据自身服务器内存需要,修改cgi进程数目,在php-fpm.conf修改max_children最大数目,如我的服务器2G内存,修改为  <value name="max_children">72</value>。


可能还会修改:

<value name="request_terminate_timeout">9999s</value>

<value name="request_slowlog_timeout">999s</value>


解决办法

遇到502问题,可以优先考虑按照以下两个步骤去解决。

1、查看当前的PHP FastCGI进程数是否够用:

netstat -anpo | grep "php-cgi" | wc -l

如果实际使用的“FastCGI进程数”接近预设的“FastCGI进程数”,那么,说明“FastCGI进程数”不够用,需要增大。

2、部分PHP程序的执行时间超过了Nginx的等待时间,可以适当增加nginx.conf配置文件中FastCGI的timeout时间,例如:

http  {
  fastcgi_connect_timeout 300;
  fastcgi_send_timeout 300;
  fastcgi_read_timeout 300;
  ......
  }
  ......

  php.ini中memory_limit设低了会出错,修改了php.ini的memory_limit为64M,重启nginx,发现好了,原来是PHP的内存不足了。

  如果这样修改了还解决不了问题,可以参考下面这些方案:

一、max-children和max-requests

  一台服务器上运行着nginx php(fpm) xcache,访问量日均 300W pv左右。

  最近经常会出现这样的情况:php页面打开很慢,cpu使用率突然降至很低,系统负载突然升至很高,查看网卡的流量,也会发现突然降到了很低。这种情况只持续数秒钟就恢复了。

  检查php-fpm的日志文件发现了一些线索。

Sep 30 08:32:23.289973 [NOTICE] fpm_unix_init_main(), line 271: getrlimit(nofile): max:51200, cur:51200  Sep 30 08:32:23.290212 [NOTICE] fpm_sockets_init_main(), line 371: using inherited socket fd=10, “127.0.0.1:9000″  Sep 30 08:32:23.290342 [NOTICE] fpm_event_init_main(), line 109: libevent: using epoll  Sep 30 08:32:23.296426 [NOTICE] fpm_init(), line 47: fpm is running, pid 30587

  在这几句的前面,是1000多行的关闭children和开启children的日志。

  原来,php-fpm有一个参数 max_requests,该参数指明了,每个children最多处理多少个请求后便会被关闭,默认的设置是500。因为php是把请求轮询给每个 children,在大流量下,每个childre到达max_requests所用的时间都差不多,这样就造成所有的children基本上在同一时间 被关闭。

  在这期间,nginx无法将php文件转交给php-fpm处理,所以cpu会降至很低(不用处理php,更不用执行sql),而负载会升至很高(关闭和开启children、nginx等待php-fpm),网卡流量也降至很低(nginx无法生成数据传输给客户端)

  解决问题很简单,增加children的数量,并且将 max_requests 设置未 0 或者一个比较大的值:

  打开 /usr/local/php/etc/php-fpm.conf调大以下两个参数(根据服务器实际情况,过大也不行)

<value name="max_children">5120</value>  <value name="max_requests">600</value>

  然后重启php-fpm。

二、增加缓冲区容量大小

  将nginx的error log打开,发现“pstream sent too big header while reading response header from upstream”这样的错误提示。查阅了一下资料,大意是nginx缓冲区有一个bug造成的,我们网站的页面消耗占用缓冲区可能过大。参考老外写的修 改办法增加了缓冲区容量大小设置,502问题彻底解决。后来系统管理员又对参数做了调整只保留了2个设置参数:client head buffer,fastcgi buffer size。

三、request_terminate_timeout

  如果主要是在一些post或者数据库操作的时候出现502这种情况,而不是在静态页面操作中常见,那么可以查看一下php-fpm.conf设置中的一项:

request_terminate_timeout

这个值是max_execution_time,就是fast-cgi的执行脚本时间。

0s

0s为关闭,就是无限执行下去。(当时装的时候没仔细看就改了一个数字)问题解决了,执行很长时间也不会出错了。优化fastcgi中,还可以改改这个值5s 看看效果。

php-cgi进程数不够用、php执行时间长、或者是php-cgi进程死掉,都会出现502错误

 
 503 - Service Unavailable 服务不可用,服务器由于维护或者负载过重未能应答。例如,Servlet可能在数据库连接池已满的情况下返回503。服务器返回503时可以提供一个 Retry-After头。这个错误代码为 IIS 6.0 所专用。 
 504 - Gateway Timeout 网关超时,由作为代理或网关的服务器使用,表示不能及时地从远程服务器获得应答。(HTTP 1.1新) 


出现“504连接源站超时”一般是如下原因: 

1、您的服务器宕机

如果网站服务器宕机,如断网、关机、网络不稳定

关闭IIS/nginx/apache等,均会造成节点无法取源,从而显示504

2、机房或服务器防火墙拦截了节点

服务器是否有安全狗、D盾等防火墙等软件拦截了服务器安全节点IP

造成服务器的安全节点暂时无法访问您的网站

可设置知道服务器安全的节点IP为白名单,就能够解决此问题


505 - HTTP Version Not Supported 服务器不支持请求中所指明的HTTP版本。(HTTP 1.1新) 


一、502和504错误提示说明:


  Nginx 502 Bad Gateway的意思是请求PHP-CGI已经执行,但是由于某种原因(比如读取资源的问题)没有执行完毕而导致PHP-CGI进程终止。


  Nginx 504 Gateway Time-out的意思是所请求的没有到达网关,简单来说就是没有请求到可以执行的PHP-CGI。


二、502和504错误提示原因分析:


解决这两个问题其实是需要综合考虑的,一般来说Nginx 502 Bad Gateway和php-fpm.conf的设置有关,


而Nginx 504 Gateway Time-out则是与nginx.conf的设置有关


php-fpm.conf有两个至关重要的参数,一个是”max_children”,另一个是”request_terminate_timeout” ,但是这个值不是通用的,而是需要根据自己服务器相关计算的。


那么计算的方式如下:


  如果你的服务器性能足够好,且宽带资源足够充足,PHP脚本没有死循环或BUG的话你可以直接将"request_terminate_timeout"设置成0s。0s的含义是让PHP-CGI一直执行下去而没有时间限制。而如果你做不到这一点,也就是说你的PHP-CGI可能出现某个BUG,或者你的宽带不够充足或者其他的原因导致你的PHP-CGI出现假死。那么就建议你给"request_terminate_timeout"赋一个值,这个值可以根据你服务器的性能进行设定。一般来说性能越好你可以设置越高,20分钟 -30分钟都可以。由于我的服务器PHP脚本需要长时间运行,有的可能会超过10分钟因此我设置了900秒,这样不会导致PHP-CGI死掉而出现502 Bad gateway这个错误。


 然而"max_children"这个值又是怎么计算出来的呢?这个值原则上是越大越好,php-cgi的进程多了就会处理的很快,排队的请求就会很少。设置"max_children"也需要根据服务器的性能进行设定,一般来说一台服务器正常情况下每一个php-cgi所耗费的内存在20M 左右,因此我的"max_children"我设置成40个,20M*40=800M也就是说在峰值的时候所有PHP-CGI所耗内存在800M以内,低于我的有效内存1Gb。而如果我的"max_children"设置的较小,比如5-10个,那么php-cgi就会出现处理速度很慢,等待的时间很长的现象。如果长时间没有得到处理的请求就会出现504 Gateway Time-out这个错误,而正在处理的很累的那几个php-cgi如果遇到了问题就会出现502 Bad gateway这个错误。


三、临时解决办法:


综上所述,Nginx提示502和504错误的临时解决办法是:


1、调整php-fpm.conf的相关设置:


<value name="max_children">32</value>


<value name="request_terminate_timeout">30s</value>


2、调整nginx.conf的相关设置:


server_tokens off;

sendfile on;

tcp_nopush on;

server_names_hash_bucket_size 256;

client_header_buffer_size 256k;

large_client_header_buffers 4 256k;

client_body_buffer_size 256k;

client_header_timeout 3m;

client_body_timeout 3m;

send_timeout 3m;

client_max_body_size 50m;

keepalive_timeout 120;


#fastcgi_connect_timeout 300; 

#fastcgi_send_timeout 300;

#fastcgi_read_timeout 300;

#fastcgi_buffer_size 64k;

#fastcgi_buffers 4 64k;

#fastcgi_busy_buffers_size 128k;

#fastcgi_temp_file_write_size 128k;


fastcgi_intercept_errors on;

fastcgi_connect_timeout 600;

fastcgi_send_timeout 600;

fastcgi_read_timeout 600;

fastcgi_buffer_size 256k;

fastcgi_buffers 16 256k;

fastcgi_busy_buffers_size 512k; 

fastcgi_temp_file_write_size 512k;


四、解决方案:

A、crontab里写入php-fpm的平滑重启命令

B、适当提高children的数值,降低max_requests的数值。

建议一般云主机 的children在5-10,max_requests在1000-2000,具体自行调整。 

对了,降低max_requests的数值可使php-cgi重启的周期缩短

偶然的高内存操作造成的问题影响时间也会缩短。



本文转自 2012hjtwyf 51CTO博客,原文链接:http://blog.51cto.com/hujiangtao/1919673,如需转载请自行联系原作者

网友评论

登录后评论
0/500
评论
技术小阿哥
+ 关注