404 bad request
⼀般原因:请求的Header过⼤
解决⽅法：配置nginx.conf相关设置1. client_header_buffer_size 16k;2. large_client_header_buffers 4 64k;
413 Request Entity Too Large
⼀般原因:⼀般出现在上传⽂件
解决⽅法：配置nginx.conf相关设置1. client_max_body_size 10m;
配置php.ini如下(必须和nginx.conf配置⼀致)1. post_max_size=10M2. upload_max_filesize=2M
499 Client Closed Request
⼀般原因:客户端在为等到服务器相应返回前就关闭了客户端描述符。⼀般出现在客户端设置超时后，主动关闭socket.解决⽅法：根据实际Nginx后端服务器的处理时间修改客户端超时时间。 500 Internal Server Rrror
⼀般原因：脚本错误，（php语法错误、lua语法错误） 访问量过⼤，系统资源限制，不能打开过多⽂件
磁盘空间不⾜。（access log开启可能导致磁盘满溢 关闭）解决⽅法：语法错误查看nginx_err_log php_err_log。 ⽂件访问量：
1.修改nginx配置⽂件1. worker_rlimit_nofile 65535; 2.修改/etc/security/limits.conf1. * soft nofile 655352. * hard nofile 65535
502 Bad Gateway、503 Serveice Unavailable⼀般原因:后端服务⽆法处理，业务中断。
解决⽅法：从后端⽇志获取错误原因，解决后端服务器问题。 504 Gateway Timeout
⼀般原因:后端服务器在超时时间内，未响应Nginx代理请求
解决⽅法：根据后端服务器实际处理情况，调正后端请求超时时间。1. proxy_read_timeout 90;2. proxy_send_timeout 90;
⼀般原因:可能⽹站页⾯缓存⼤，⽽fastcgi默认进程响应缓存区8k解决⽅法：配置nginx.conf相关设置1. fastcgi_buffers 8 128k1. send_timeout 60;
1 upstream jira_Cluster_web { 2 #ip_hash;
3 server 10.143.50.15:8081 ;
4 server 10.143.50.16:8081 backup; 5 } 6
7 server {
8 listen 80;
9 server_name jira1.gomeholdings.com;10 index index.html index.htm;11 #root html;12 location / {
13 proxy_redirect off;
14 proxy_set_header Host $host;
15 proxy_set_header X-Real-IP $remote_addr;
16 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;17 client_body_buffer_size 128k;18 proxy_connect_timeout 90;19 proxy_send_timeout 90;20 proxy_read_timeout 90;21 proxy_buffer_size 4k;22 proxy_buffers 4 32k;
23 proxy_busy_buffers_size 64k;24 proxy_temp_file_write_size 64k;
25 #proxy_set_header X-Forwarded-Host $host;
26 #proxy_set_header X-Forwarded-Server $host;
27 #proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;28 proxy_pass http://jira_Cluster_web/;29 #proxy_pass http://10.143.50.15:8081;30 proxy_http_version 1.1;
31 proxy_set_header Connection \"\";32 }33 }
解决图⽚⽆法加载
1 ######Nginx配置⽂件nginx.conf中⽂详解##### 2
3 #定义Nginx运⾏的⽤户和⽤户组 4 user www www; 5
6 #nginx进程数，建议设置为等于CPU总核⼼数。 7 worker_processes 8; 8
9 #全局错误⽇志定义类型，[ debug | info | notice | warn | error | crit ] 10 error_log /usr/local/nginx/logs/error.log info; 11
12 #进程pid⽂件
13 pid /usr/local/nginx/logs/nginx.pid; 14
15 #指定进程可以打开的最⼤描述符：数⽬ 16 #⼯作模式与连接数上限
17 #这个指令是指当⼀个nginx进程打开的最多⽂件描述符数⽬，理论值应该是最多打开⽂件数（ulimit -n）与nginx进程数相除，但是nginx分配请求并不是那么均匀，所以最好与ulimit -n 的值保持⼀致。 18 #现在在linux 2.6内核下开启⽂件打开数为65535，worker_rlimit_nofile就相应应该填写65535。
19 #这是因为nginx调度时分配请求到进程并不是那么的均衡，所以假如填写10240，总并发量达到3-4万时就有进程可能超过10240了，这时会返回502错误。 20 worker_rlimit_nofile 65535; 21 22
23 events 24 {
25 #参考事件模型，use [ kqueue | rtsig | epoll | /dev/poll | select | poll ]; epoll模型
26 #是Linux 2.6以上版本内核中的⾼性能⽹络I/O模型，linux建议epoll，如果跑在FreeBSD上⾯，就⽤kqueue模型。 27 #补充说明：
28 #与apache相类，nginx针对不同的操作系统，有不同的事件模型 29 #A）标准事件模型
30 #Select、poll属于标准事件模型，如果当前系统不存在更有效的⽅法，nginx会选择select或poll 31 #B）⾼效事件模型
32 #Kqueue：使⽤于FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X.使⽤双处理器的MacOS X系统使⽤kqueue可能会造成内核崩溃。 33 #Epoll：使⽤于Linux内核2.6版本及以后的系统。
34 #/dev/poll：使⽤于Solaris 7 11/99+，HP/UX 11.22+ (eventport)，IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+。 35 #Eventport：使⽤于Solaris 10。 为了防⽌出现内核崩溃的问题， 有必要安装安全补丁。 36 use epoll; 37
38 #单个进程最⼤连接数（最⼤连接数=连接数*进程数）
39 #根据硬件调整，和前⾯⼯作进程配合起来⽤，尽量⼤，但是别把cpu跑到100%就⾏。每个进程允许的最多连接数，理论上每台nginx服务器的最⼤连接数为。 40 worker_connections 65535; 41
42 #keepalive超时时间。 43 keepalive_timeout 60; 44
45 #客户端请求头部的缓冲区⼤⼩。这个可以根据你的系统分页⼤⼩来设置，⼀般⼀个请求头的⼤⼩不会超过1k，不过由于⼀般系统分页都要⼤于1k，所以这⾥设置为分页⼤⼩。 46 #分页⼤⼩可以⽤命令getconf PAGESIZE 取得。 47 #[root@web001 ~]# getconf PAGESIZE 48 #4096
49 #但也有client_header_buffer_size超过4k的情况，但是client_header_buffer_size该值必须设置为“系统分页⼤⼩”的整倍数。 50 client_header_buffer_size 4k; 51
52 #这个将为打开⽂件指定缓存，默认是没有启⽤的，max指定缓存数量，建议和打开⽂件数⼀致，inactive是指经过多长时间⽂件没被请求后删除缓存。 53 open_file_cache max=65535 inactive=60s; 54
55 #这个是指多长时间检查⼀次缓存的有效信息。
56 #语法:open_file_cache_valid time 默认值:open_file_cache_valid 60 使⽤字段:http, server, location 这个指令指定了何时需要检查open_file_cache中缓存项⽬的有效信息. 57 open_file_cache_valid 80s; 58
59 #open_file_cache指令中的inactive参数时间内⽂件的最少使⽤次数，如果超过这个数字，⽂件描述符⼀直是在缓存中打开的，如上例，如果有⼀个⽂件在inactive时间内⼀次没被使⽤，它将被移除。
60 #语法:open_file_cache_min_uses number 默认值:open_file_cache_min_uses 1 使⽤字段:http, server, location 这个指令指定了在open_file_cache指令⽆效的参数中⼀定的时间范围内可以使⽤的最⼩⽂件数,如果使⽤更⼤的值,⽂件描述符在c 61 open_file_cache_min_uses 1; 62
63 #语法:open_file_cache_errors on | off 默认值:open_file_cache_errors off 使⽤字段:http, server, location 这个指令指定是否在搜索⼀个⽂件是记录cache错误. 64 open_file_cache_errors on; 65 } 66 67 68
69 #设定http服务器，利⽤它的反向代理功能提供负载均衡⽀持 70 http 71 {
72 #⽂件扩展名与⽂件类型映射表 73 include mime.types; 74
75 #默认⽂件类型
76 default_type application/octet-stream; 77
78 #默认编码 79 #charset utf-8; 80
81 #服务器名字的hash表⼤⼩
82 #保存服务器名字的hash表是由指令server_names_hash_max_size 和server_names_hash_bucket_size所控制的。参数hash bucket size总是等于hash表的⼤⼩，并且是⼀路处理器缓存⼤⼩的倍数。在减少了在内存中的存取次数后，使在处理 83 server_names_hash_bucket_size 128; 84
85 #客户端请求头部的缓冲区⼤⼩。这个可以根据你的系统分页⼤⼩来设置，⼀般⼀个请求的头部⼤⼩不会超过1k，不过由于⼀般系统分页都要⼤于1k，所以这⾥设置为分页⼤⼩。分页⼤⼩可以⽤命令getconf PAGESIZE取得。 86 client_header_buffer_size 32k; 87
88 #客户请求头缓冲⼤⼩。nginx默认会⽤client_header_buffer_size这个buffer来读取header值，如果header过⼤，它会使⽤large_client_header_buffers来读取。 89 large_client_header_buffers 4 64k; 90
91 #设定通过nginx上传⽂件的⼤⼩ 92 client_max_body_size 8m; 93
94 #开启⾼效⽂件传输模式，sendfile指令指定nginx是否调⽤sendfile函数来输出⽂件，对于普通应⽤设为 on，如果⽤来进⾏下载等应⽤磁盘IO重负载应⽤，可设置为off，以平衡磁盘与⽹络I/O处理速度，降低系统的负载。注意：如果图⽚显⽰不 95 #sendfile指令指定 nginx 是否调⽤sendfile 函数（zero copy ⽅式）来输出⽂件，对于普通应⽤，必须设为on。如果⽤来进⾏下载等应⽤磁盘IO重负载应⽤，可设置为off，以平衡磁盘与⽹络IO处理速度，降低系统uptime。 96 sendfile on; 97
98 #开启⽬录列表访问，合适下载服务器，默认关闭。 99 autoindex on;100
101 #此选项允许或禁⽌使⽤socke的TCP_CORK的选项，此选项仅在使⽤sendfile的时候使⽤102 tcp_nopush on;103
104 tcp_nodelay on;105
106 #长连接超时时间，单位是秒107 keepalive_timeout 120;108
109 #FastCGI相关参数是为了改善⽹站的性能：减少资源占⽤，提⾼访问速度。下⾯参数看字⾯意思都能理解。110 fastcgi_connect_timeout 300;111 fastcgi_send_timeout 300;112 fastcgi_read_timeout 300;113 fastcgi_buffer_size 64k;114 fastcgi_buffers 4 64k;
115 fastcgi_busy_buffers_size 128k;116 fastcgi_temp_file_write_size 128k;117
118 #gzip模块设置
119 gzip on; #开启gzip压缩输出
120 gzip_min_length 1k; #最⼩压缩⽂件⼤⼩121 gzip_buffers 4 16k; #压缩缓冲区
122 gzip_http_version 1.0; #压缩版本（默认1.1，前端如果是squid2.5请使⽤1.0）123 gzip_comp_level 2; #压缩等级
124 gzip_types text/plain application/x-javascript text/css application/xml; #压缩类型，默认就已经包含textml，所以下⾯就不⽤再写了，写上去也不会有问题，但是会有⼀个warn。125 gzip_vary on;126
127 #开启限制IP连接数的时候需要使⽤
128 #limit_zone crawler $binary_remote_addr 10m;129 130 131
132 #负载均衡配置
133 upstream piao.jd.com {134
135 #upstream的负载均衡，weight是权重，可以根据机器配置定义权重。weigth参数表⽰权值，权值越⾼被分配到的⼏率越⼤。136 server 192.168.80.121:80 weight=3;137 server 192.168.80.122:80 weight=2;138 server 192.168.80.123:80 weight=3;139
140 #nginx的upstream⽬前⽀持4种⽅式的分配141 #1、轮询（默认）
142 #每个请求按时间顺序逐⼀分配到不同的后端服务器，如果后端服务器down掉，能⾃动剔除。143 #2、weight
144 #指定轮询⼏率，weight和访问⽐率成正⽐，⽤于后端服务器性能不均的情况。145 #例如：
146 #upstream bakend {
147 # server 192.168.0.14 weight=10;148 # server 192.168.0.15 weight=10;149 #}
150 #2、ip_hash
151 #每个请求按访问ip的hash结果分配，这样每个访客固定访问⼀个后端服务器，可以解决session的问题。152 #例如：
153 #upstream bakend {154 # ip_hash;
155 # server 192.168.0.14:88;156 # server 192.168.0.15:80;157 #}
158 #3、fair（第三⽅）
159 #按后端服务器的响应时间来分配请求，响应时间短的优先分配。160 #upstream backend {161 # server server1;162 # server server2;163 # fair;164 #}
165 #4、url_hash（第三⽅）
166 #按访问url的hash结果来分配请求，使每个url定向到同⼀个后端服务器，后端服务器为缓存时⽐较有效。
167 #例：在upstream中加⼊hash语句，server语句中不能写⼊weight等其他的参数，hash_method是使⽤的hash算法168 #upstream backend {169 # server squid1:3128;170 # server squid2:3128;171 # hash $request_uri;172 # hash_method crc32;173 #}174
175 #tips:
176 #upstream bakend{#定义负载均衡设备的Ip及设备状态}{177 # ip_hash;
178 # server 127.0.0.1:9090 down;179 # server 127.0.0.1:8080 weight=2;180 # server 127.0.0.1:6060;
181 # server 127.0.0.1:7070 backup;182 #}
183 #在需要使⽤负载均衡的server中增加 proxy_pass http://bakend/;184
185 #每个设备的状态设置为:
186 #1.down表⽰单前的server暂时不参与负载187 #2.weight为weight越⼤，负载的权重就越⼤。
188 #3.max_fails：允许请求失败的次数默认为1.当超过最⼤次数时，返回proxy_next_upstream模块定义的错误189 #4.fail_timeout:max_fails次失败后，暂停的时间。
190 #5.backup： 其它所有的⾮backup机器down或者忙的时候，请求backup机器。所以这台机器压⼒会最轻。191
192 #nginx⽀持同时设置多组的负载均衡，⽤来给不⽤的server来使⽤。
193 #client_body_in_file_only设置为On 可以讲client post过来的数据记录到⽂件中⽤来做debug194 #client_body_temp_path设置记录⽂件的⽬录 可以设置最多3层⽬录195 #location对URL进⾏匹配.可以进⾏重定向或者进⾏新的代理 负载均衡196 }197 198 199
200 #虚拟主机的配置201 server202 {
203 #监听端⼝204 listen 80;205
206 #域名可以有多个，⽤空格隔开207 server_name www.jd.com jd.com;208 index index.html index.htm index.php;209 root /data/www/jd;210
211 #对******进⾏负载均衡212 location ~ .*.(php|php5)?$213 {
214 fastcgi_pass 127.0.0.1:9000;215 fastcgi_index index.php;216 include fastcgi.conf;217 }218
219 #图⽚缓存时间设置
220 location ~ .*.(gif|jpg|jpeg|png|bmp|swf)$221 {
222 expires 10d;223 }224
225 #JS和CSS缓存时间设置226 location ~ .*.(js|css)?$227 {
228 expires 1h;229 }230
231 #⽇志格式设定
232 #$remote_addr与$http_x_forwarded_for⽤以记录客户端的ip地址；233 #$remote_user：⽤来记录客户端⽤户名称；234 #$time_local： ⽤来记录访问时间与时区；235 #$request： ⽤来记录请求的url与http协议；236 #$status： ⽤来记录请求状态；成功是200，
237 #$body_bytes_sent ：记录发送给客户端⽂件主体内容⼤⼩；238 #$http_referer：⽤来记录从那个页⾯链接访问过来的；239 #$http_user_agent：记录客户浏览器的相关信息；
240 #通常web服务器放在反向代理的后⾯，这样就不能获取到客户的IP地址了，通过$remote_add拿到的IP地址是反向代理服务器的iP地址。反向代理服务器在转发请求的http头信息中，可以增加x_forwarded_for信息，⽤以记录原有客户端的IP241 log_format access '$remote_addr - $remote_user [$time_local] \"$request\" '242 '$status $body_bytes_sent \"$http_referer\" '243 '\"$http_user_agent\" $http_x_forwarded_for';244
245 #定义本虚拟主机的访问⽇志
246 access_log /usr/local/nginx/logs/host.access.log main;
247 access_log /usr/local/nginx/logs/host.access.404.log log404;248
249 #对 \"/\" 启⽤反向代理250 location / {
251 proxy_pass http://127.0.0.1:88;252 proxy_redirect off;
253 proxy_set_header X-Real-IP $remote_addr;254
255 #后端的Web服务器可以通过X-Forwarded-For获取⽤户真实IP
256 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;257
258 #以下是⼀些反向代理的配置，可选。259 proxy_set_header Host $host;260
261 #允许客户端请求的最⼤单⽂件字节数262 client_max_body_size 10m;
263
264 #缓冲区代理缓冲⽤户端请求的最⼤字节数，
265 #如果把它设置为⽐较⼤的数值，例如256k，那么，⽆论使⽤firefox还是IE浏览器，来提交任意⼩于256k的图⽚，都很正常。如果注释该指令，使⽤默认的client_body_buffer_size设置，也就是操作系统页⾯⼤⼩的两倍，8k或者16k，问题266 #⽆论使⽤firefox4.0还是IE8.0，提交⼀个⽐较⼤，200k左右的图⽚，都返回500 Internal Server Error错误267 client_body_buffer_size 128k;268
269 #表⽰使nginx阻⽌HTTP应答代码为400或者更⾼的应答。270 proxy_intercept_errors on;271
272 #后端服务器连接的超时时间_发起握⼿等候响应超时时间273 #nginx跟后端服务器连接超时时间(代理连接超时)274 proxy_connect_timeout 90;275
276 #后端服务器数据回传时间(代理发送超时)
277 #后端服务器数据回传时间_就是在规定时间之内后端服务器必须传完所有的数据278 proxy_send_timeout 90;279
280 #连接成功后，后端服务器响应时间(代理接收超时)
281 #连接成功后_等候后端服务器响应时间_其实已经进⼊后端的排队之中等候处理（也可以说是后端服务器处理请求的时间）282 proxy_read_timeout 90;283
284 #设置代理服务器（nginx）保存⽤户头信息的缓冲区⼤⼩
285 #设置从被代理服务器读取的第⼀部分应答的缓冲区⼤⼩，通常情况下这部分应答中包含⼀个⼩的应答头，默认情况下这个值的⼤⼩为指令proxy_buffers中指定的⼀个缓冲区的⼤⼩，不过可以将其设置为更⼩286 proxy_buffer_size 4k;287
288 #proxy_buffers缓冲区，⽹页平均在32k以下的设置
289 #设置⽤于读取应答（来⾃被代理服务器）的缓冲区数⽬和⼤⼩，默认情况也为分页⼤⼩，根据操作系统的不同可能是4k或者8k290 proxy_buffers 4 32k;291
292 #⾼负荷下缓冲⼤⼩（proxy_buffers*2）293 proxy_busy_buffers_size 64k;294
295 #设置在写⼊proxy_temp_path时数据的⼤⼩，预防⼀个⼯作进程在传递⽂件时阻塞太长296 #设定缓存⽂件夹⼤⼩，⼤于这个值，将从upstream服务器传297 proxy_temp_file_write_size 64k;298 }299 300
301 #设定查看Nginx状态的地址302 location /NginxStatus {303 stub_status on;304 access_log on;
305 auth_basic \"NginxStatus\";
306 auth_basic_user_file confpasswd;
307 #htpasswd⽂件的内容可以⽤apache提供的htpasswd⼯具来产⽣。308 }309
310 #本地动静分离反向代理配置
311 #所有jsp的页⾯均交由tomcat或resin处理312 location ~ .(jsp|jspx|do)?$ {
313 proxy_set_header Host $host;
314 proxy_set_header X-Real-IP $remote_addr;
315 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;316 proxy_pass http://127.0.0.1:8080;317 }318
319 #所有静态⽂件由nginx直接读取不经过tomcat或resin
320 location ~ .*.(htm|html|gif|jpg|jpeg|png|bmp|swf|ioc|rar|zip|txt|flv|mid|doc|ppt|321 pdf|xls|mp3|wma)$322 {
323 expires 15d; 324 }325
326 location ~ .*.(js|css)?$327 {
328 expires 1h;329 }330 }331 }
332 ######Nginx配置⽂件nginx.conf中⽂详解#####
Nginx配置⽂件详解中⽂配置详解： 官⽅⽂档：
附表：HTTP响应码
1XX代表提⽰信息，2XX代表成功信息，3XX代表重定向信息，4XX代表客户端错误信息，5XX代表服务器错误信息状态码含义
客户端应当继续发送请求。这个临时响应是⽤来通知客户端它的部分请求已经被服务器接收，且仍未被拒绝。客户端应当继续发送请求的剩余部分，或者如果请求已经
100
完成，忽略这个响应。服务器必须在请求完成后向客户端发送⼀个最终响应。
服务器已经理解了客户端的请求，并将通过Upgrade 消息头通知客户端采⽤不同的协议来完成这个请求。在发送完这个响应最后的空⾏后，服务器将会切换到在
101Upgrade 消息头中定义的那些协议。 只有在切换新的协议更有好处的时候才应该采取类似措施。例如，切换到新的HTTP 版本⽐旧版本更有优势，或者切换到⼀个
实时且同步的协议以传送利⽤此类特性的资源。
102由WebDAV（RFC 2518）扩展的状态码，代表处理将被继续执⾏。200请求已成功，请求所希望的响应头或数据体将随此响应返回。
请求已经被实现，⽽且有⼀个新的资源已经依据请求的需要⽽建⽴，且其 URI 已经随Location 头信息返回。假如需要的资源⽆法及时建⽴的话，应当返回 '202
201
Accepted'。
服务器已接受请求，但尚未处理。正如它可能被拒绝⼀样，最终该请求可能会也可能不会被执⾏。在异步操作的场合下，没有⽐发送这个状态码更⽅便的做法了。 返回202状态码的响应的⽬的是允许服务器接受其他过程的请求（例如某个每天只执⾏⼀次的基于批处理的操作），⽽不必让客户端⼀直保持与服务器的连接直到批处理
202
操作全部完成。在接受请求处理并返回202状态码的响应应当在返回的实体中包含⼀些指⽰处理当前状态的信息，以及指向处理状态监视器或状态预测的指针，以便⽤户能够估计操作是否已经完成。
服务器已成功处理了请求，但返回的实体头部元信息不是在原始服务器上有效的确定集合，⽽是来⾃本地或者第三⽅的拷贝。当前的信息可能是原始版本的⼦集或者超
203集。例如，包含资源的元数据可能导致原始服务器知道元信息的超级。使⽤此状态码不是必须的，⽽且只有在响应不使⽤此状态码便会返回200 OK的情况下才是合适
的。
服务器成功处理了请求，但不需要返回任何实体内容，并且希望返回更新了的元信息。响应可能通过实体头部的形式，返回新的或更新后的元信息。如果存在这些头部
204信息，则应当与所请求的变量相呼应。 如果客户端是浏览器的话，那么⽤户浏览器应保留发送了该请求的页⾯，⽽不产⽣任何⽂档视图上的变化，即使按照规范新
的或更新后的元信息应当被应⽤到⽤户浏览器活动视图中的⽂档。 由于204响应被禁⽌包含任何消息体，因此它始终以消息头后的第⼀个空⾏结尾。
服务器成功处理了请求，且没有返回任何内容。但是与204响应不同，返回此状态码的响应要求请求者重置⽂档视图。该响应主要是被⽤于接受⽤户输⼊后，⽴即重置表
205
单，以便⽤户能够轻松地开始另⼀次输⼊。 与204响应⼀样，该响应也被禁⽌包含任何消息体，且以消息头后的第⼀个空⾏结束。
服务器已经成功处理了部分 GET 请求。类似于 FlashGet 或者迅雷这类的 HTTP 下载⼯具都是使⽤此类响应实现断点续传或者将⼀个⼤⽂档分解为多个下载段同时下载。 该请求必须包含 Range 头信息来指⽰客户端希望得到的内容范围，并且可能包含 If-Range 来作为请求条件。 响应必须包含如下的头部域： Content-Range ⽤以指⽰本次响应中返回的内容的范围；如果是 Content-Type 为 multipart/byteranges 的多段下载，则每⼀ multipart 段中都应包含 Content-Range 域⽤以指⽰本段的内容范围。假如响应中包含 Content-Length，那么它的数值必须匹配它返回的内容范围的真实字节数。 Date ETag 和/或 Content-Location，假如同样的请求本应该返回200响应。 Expires, Cache-Control，和/或 Vary，假如其值可能与之前相同变量的其他响应对应的值不同的话。 假如本响应请求使⽤了 If-206
Range 强缓存验证，那么本次响应不应该包含其他实体头；假如本响应的请求使⽤了 If-Range 弱缓存验证，那么本次响应禁⽌包含其他实体头；这避免了缓存的实体内容和更新了的实体头信息之间的不⼀致。否则，本响应就应当包含所有本应该返回200响应中应当返回的所有实体头部域。 假如 ETag 或 Last-Modified 头部不能精确匹配的话，则客户端缓存应禁⽌将206响应返回的内容与之前任何缓存过的内容组合在⼀起。 任何不⽀持 Range 以及 Content-Range 头的缓存都禁⽌缓存206响应返回的内容。207
由WebDAV(RFC 2518)扩展的状态码，代表之后的消息体将是⼀个XML消息，并且可能依照之前⼦请求数量的不同，包含⼀系列独⽴的响应代码。
被请求的资源有⼀系列可供选择的回馈信息，每个都有⾃⼰特定的地址和浏览器驱动的商议信息。⽤户或浏览器能够⾃⾏选择⼀个⾸选的地址进⾏重定向。 除⾮这
300
301
302
303
304
305306307400401402403404405406407408409
410
411412413
414415416417421422422424425426449500501502503504505506507509
是⼀个 HEAD 请求，否则该响应应当包括⼀个资源特性及地址的列表的实体，以便⽤户或浏览器从中选择最合适的重定向地址。这个实体的格式由 Content-Type 定义的格式所决定。浏览器可能根据响应的格式以及浏览器⾃⾝能⼒，⾃动作出最合适的选择。当然，RFC 2616规范并没有规定这样的⾃动选择该如何进⾏。 如果服务器本⾝已经有了⾸选的回馈选择，那么在 Location 中应当指明这个回馈的 URI；浏览器可能会将这个 Location 值作为⾃动重定向的地址。此外，除⾮额外指定，否则这个响应也是可缓存的。
被请求的资源已永久移动到新位置，并且将来任何对此资源的引⽤都应该使⽤本响应返回的若⼲个 URI 之⼀。如果可能，拥有链接编辑功能的客户端应当⾃动把请求的地址修改为从服务器反馈回来的地址。除⾮额外指定，否则这个响应也是可缓存的。 新的永久性的 URI 应当在响应的 Location 域中返回。除⾮这是⼀个 HEAD 请求，否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。 如果这不是⼀个 GET 或者 HEAD 请求，因此浏览器禁⽌⾃动进⾏重定向，除⾮得到⽤户的确认，因为请求的条件可能因此发⽣变化。 注意：对于某些使⽤ HTTP/1.0 协议的浏览器，当它们发送的 POST 请求得到了⼀个301响应的话，接下来的重定向请求将会变成 GET ⽅式。
请求的资源现在临时从不同的 URI 响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进⾏了指定的情况下，这个响应才是可缓存的。 新的临时性的 URI 应当在响应的 Location 域中返回。除⾮这是⼀个 HEAD 请求，否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。 如果这不是⼀个 GET 或者 HEAD 请求，那么浏览器禁⽌⾃动进⾏重定向，除⾮得到⽤户的确认，因为请求的条件可能因此发⽣变化。 注意：虽然RFC 1945和RFC 2068规范不允许客户端在重定向时改变请求的⽅法，但是很多现存的浏览器将302响应视作为303响应，并且使⽤ GET ⽅式访问在 Location中规定的 URI，⽽⽆视原先请求的⽅法。状态码303和307被添加了进来，⽤以明确服务器期待客户端进⾏何种反应。
对应当前请求的响应可以在另⼀个 URI 上被找到，⽽且客户端应当采⽤ GET 的⽅式访问那个资源。这个⽅法的存在主要是为了允许由脚本激活的POST请求输出重定向到⼀个新的资源。这个新的 URI 不是原始资源的替代引⽤。同时，303响应禁⽌被缓存。当然，第⼆个请求（重定向）可能被缓存。 新的 URI 应当在响应的
Location 域中返回。除⾮这是⼀个 HEAD 请求，否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。 注意：许多 HTTP/1.1 版以前的 浏览器不能正确理解303状态。如果需要考虑与这些浏览器之间的互动，302状态码应该可以胜任，因为⼤多数的浏览器处理302响应时的⽅式恰恰就是上述规范要求客户端处理303响应时应当做的。
如果客户端发送了⼀个带条件的 GET 请求且该请求已被允许，⽽⽂档的内容（⾃上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个状态码。304响应禁⽌包含消息体，因此始终以消息头后的第⼀个空⾏结尾。 该响应必须包含以下的头信息： Date，除⾮这个服务器没有时钟。假如没有时钟的服务器也遵守这些规则，那么代理服务器以及客户端可以⾃⾏将 Date 字段添加到接收到的响应头中去（正如RFC 2068中规定的⼀样），缓存机制将会正常⼯作。 ETag 和/或Content-Location，假如同样的请求本应返回200响应。 Expires, Cache-Control，和/或Vary，假如其值可能与之前相同变量的其他响应对应的值不同的话。 假如本响应请求使⽤了强缓存验证，那么本次响应不应该包含其他实体头；否则（例如，某个带条件的 GET 请求使⽤了弱缓存验证），本次响应禁⽌包含其他实体头；这避免了缓存了的实体内容和更新了的实体头信息之间的不⼀致。 假如某个304响应指明了当前某个实体没有缓存，那么缓存系统必须忽视这个响应，并且重复发送不包含限制条件的请求。 假如接收到⼀个要求更新某个缓存条⽬的304响应，那么缓存系统必须更新整个条⽬以反映所有在响应中被更新的字段的值。
被请求的资源必须通过指定的代理才能被访问。Location 域中将给出指定的代理所在的 URI 信息，接收者需要重复发送⼀个单独的请求，通过这个代理才能访问相应资源。只有原始服务器才能建⽴305响应。 注意：RFC 2068中没有明确305响应是为了重定向⼀个单独的请求，⽽且只能被原始服务器建⽴。忽视这些限制可能导致严重的安全后果。
在最新版的规范中，306状态码已经不再被使⽤。
请求的资源现在临时从不同的URI 响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进⾏了指定的情况下，这个响应才是可缓存的。 新的临时性的URI 应当在响应的 Location 域中返回。除⾮这是⼀个HEAD 请求，否则响应的实体中应当包含指向新的URI 的超链接及简短说明。因为部分浏览器不能识别307响应，因此需要添加上述必要信息以便⽤户能够理解并向新的 URI 发出访问请求。 如果这不是⼀个GET 或者 HEAD请求，那么浏览器禁⽌⾃动进⾏重定向，除⾮得到⽤户的确认，因为请求的条件可能因此发⽣变化。
1、语义有误，当前请求⽆法被服务器理解。除⾮进⾏修改，否则客户端不应该重复提交这个请求。 2、请求参数有误。
当前请求需要⽤户验证。该响应必须包含⼀个适⽤于被请求资源的 WWW-Authenticate 信息头⽤以询问⽤户信息。客户端可以重复提交⼀个包含恰当的 Authorization 头信息的请求。如果当前请求已经包含了 Authorization 证书，那么401响应代表着服务器验证已经拒绝了那些证书。如果401响应包含了与前⼀个响应相同的⾝份验证询问，且浏览器已经⾄少尝试了⼀次验证，那么浏览器应当向⽤户展⽰响应中包含的实体信息，因为这个实体信息中可能包含了相关诊断信息。参见RFC 2617。该状态码是为了将来可能的需求⽽预留的。
服务器已经理解请求，但是拒绝执⾏它。与401响应不同的是，⾝份验证并不能提供任何帮助，⽽且这个请求也不应该被重复提交。如果这不是⼀个 HEAD 请求，⽽且服务器希望能够讲清楚为何请求不能被执⾏，那么就应该在实体内描述拒绝的原因。当然服务器也可以返回⼀个404响应，假如它不希望让客户端获得任何信息。
请求失败，请求所希望得到的资源未被在服务器上发现。没有信息能够告诉⽤户这个状况到底是暂时的还是永久的。假如服务器知道情况的话，应当使⽤410状态码来告知旧资源因为某些内部的配置机制问题，已经永久的不可⽤，⽽且没有任何可以跳转的地址。404这个状态码被⼴泛应⽤于当服务器不想揭⽰到底为何请求被拒绝或者没有其他适合的响应可⽤的情况下。
请求⾏中指定的请求⽅法不能被⽤于请求相应的资源。该响应必须返回⼀个Allow 头信息⽤以表⽰出当前资源能够接受的请求⽅法的列表。 鉴于 PUT，DELETE ⽅法会对服务器上的资源进⾏写操作，因⽽绝⼤部分的⽹页服务器都不⽀持或者在默认配置下不允许上述请求⽅法，对于此类请求均会返回405错误。
请求的资源的内容特性⽆法满⾜请求头中的条件，因⽽⽆法⽣成响应实体。 除⾮这是⼀个 HEAD 请求，否则该响应就应当返回⼀个包含可以让⽤户或者浏览器从中选择最合适的实体特性以及地址列表的实体。实体的格式由 Content-Type 头中定义的媒体类型决定。浏览器可以根据格式及⾃⾝能⼒⾃⾏作出最佳选择。但是，规范中并没有定义任何作出此类⾃动选择的标准。
与401响应类似，只不过客户端必须在代理服务器上进⾏⾝份验证。代理服务器必须返回⼀个 Proxy-Authenticate ⽤以进⾏⾝份询问。客户端可以返回⼀个 Proxy-Authorization 信息头⽤以验证。参见RFC 2617。
请求超时。客户端没有在服务器预备等待的时间内完成⼀个请求的发送。客户端可以随时再次提交这⼀请求⽽⽆需进⾏任何更改。
由于和被请求的资源的当前状态之间存在冲突，请求⽆法完成。这个代码只允许⽤在这样的情况下才能被使⽤：⽤户被认为能够解决冲突，并且会重新提交新的请求。该响应应当包含⾜够的信息以便⽤户发现冲突的源头。 冲突通常发⽣于对 PUT 请求的处理中。例如，在采⽤版本检查的环境下，某次 PUT 提交的对特定资源的修改请求所附带的版本信息与之前的某个（第三⽅）请求向冲突，那么此时服务器就应该返回⼀个409错误，告知⽤户请求⽆法完成。此时，响应实体中很可能会包含两个冲突版本之间的差异⽐较，以便⽤户重新提交归并以后的新版本。
被请求的资源在服务器上已经不再可⽤，⽽且没有任何已知的转发地址。这样的状况应当被认为是永久性的。如果可能，拥有链接编辑功能的客户端应当在获得⽤户许可后删除所有指向这个地址的引⽤。如果服务器不知道或者⽆法确定这个状况是否是永久的，那么就应该使⽤404状态码。除⾮额外说明，否则这个响应是可缓存的。 410响应的⽬的主要是帮助⽹站管理员维护⽹站，通知⽤户该资源已经不再可⽤，并且服务器拥有者希望所有指向这个资源的远端连接也被删除。这类事件在限时、增值服务中很普遍。同样，410响应也被⽤于通知客户端在当前服务器站点上，原本属于某个个⼈的资源已经不再可⽤。当然，是否需要把所有永久不可⽤的资源标记为'410 Gone'，以及是否需要保持此标记多长时间，完全取决于服务器拥有者。
服务器拒绝在没有定义 Content-Length 头的情况下接受请求。在添加了表明请求消息体长度的有效 Content-Length 头之后，客户端可以再次提交该请求。
服务器在验证在请求的头字段中给出先决条件时，没能满⾜其中的⼀个或多个。这个状态码允许客户端在获取资源时在请求的元信息（请求头字段数据）中设置先决条件，以此避免该请求⽅法被应⽤到其希望的内容以外的资源上。
服务器拒绝处理当前请求，因为该请求提交的实体数据⼤⼩超过了服务器愿意或者能够处理的范围。此种情况下，服务器可以关闭连接以免客户端继续发送此请求。 如果这个状况是临时的，服务器应当返回⼀个 Retry-After 的响应头，以告知客户端可以在多少时间以后重新尝试。
请求的URI 长度超过了服务器能够解释的长度，因此服务器拒绝对该请求提供服务。这⽐较少见，通常的情况包括： 本应使⽤POST⽅法的表单提交变成了GET⽅法，导致查询字符串（Query String）过长。 重定向URI “⿊洞”，例如每次重定向把旧的 URI 作为新的 URI 的⼀部分，导致在若⼲次重定向后 URI 超长。 客户端正在尝试利⽤某些服务器中存在的安全漏洞攻击服务器。这类服务器使⽤固定长度的缓冲读取或操作请求的 URI，当 GET 后的参数超过某个数值后，可能会产⽣缓冲区溢出，导致任意代码被执⾏[1]。没有此类漏洞的服务器，应当返回414状态码。
对于当前请求的⽅法和所请求的资源，请求中提交的实体并不是服务器中所⽀持的格式，因此请求被拒绝。
如果请求中包含了 Range 请求头，并且 Range 中指定的任何数据范围都与当前资源的可⽤范围不重合，同时请求中⼜没有定义 If-Range 请求头，那么服务器就应当返回416状态码。 假如 Range 使⽤的是字节范围，那么这种情况就是指请求指定的所有数据范围的⾸字节位置都超过了当前资源的长度。服务器也应当在返回416状态码的同时，包含⼀个 Content-Range 实体头，⽤以指明当前资源的长度。这个响应也被禁⽌使⽤ multipart/byteranges 作为其 Content-Type。
在请求头 Expect 中指定的预期内容⽆法被服务器满⾜，或者这个服务器是⼀个代理服务器，它有明显的证据证明在当前路由的下⼀个节点上，Expect 的内容⽆法被满⾜。
从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最⼤范围。通常，这⾥的IP地址指的是从服务器上看到的客户端地址（⽐如⽤户的⽹关或者代理服务器地址）。在这种情况下，连接数的计算可能涉及到不⽌⼀个终端⽤户。
从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最⼤范围。通常，这⾥的IP地址指的是从服务器上看到的客户端地址（⽐如⽤户的⽹关或者代理服务器地址）。在这种情况下，连接数的计算可能涉及到不⽌⼀个终端⽤户。
请求格式正确，但是由于含有语义错误，⽆法响应。（RFC 4918 WebDAV）423 Locked 当前资源被锁定。（RFC 4918 WebDAV）由于之前的某个请求发⽣的错误，导致当前请求失败，例如 PROPPATCH。（RFC 4918 WebDAV）
在WebDav Advanced Collections 草案中定义，但是未出现在《WebDAV 顺序集协议》（RFC 3658）中。客户端应当切换到TLS/1.0。（RFC 2817）
由微软扩展，代表请求应当在执⾏完适当的操作后进⾏重试。
服务器遇到了⼀个未曾预料的状况，导致了它⽆法完成对请求的处理。⼀般来说，这个问题都会在服务器的程序码出错时出现。服务器不⽀持当前请求所需要的某个功能。当服务器⽆法识别请求的⽅法，并且⽆法⽀持其对任何资源的请求。作为⽹关或者代理⼯作的服务器尝试执⾏请求时，从上游服务器接收到⽆效的响应。
由于临时的服务器维护或者过载，服务器当前⽆法处理请求。这个状况是临时的，并且将在⼀段时间以后恢复。如果能够预计延迟时间，那么响应中可以包含⼀个Retry-After 头⽤以标明这个延迟时间。如果没有给出这个 Retry-After 信息，那么客户端应当以处理500响应的⽅式处理它。 注意：503状态码的存在并不意味着服务器在过载的时候必须使⽤它。某些服务器只不过是希望拒绝客户端的连接。
作为⽹关或者代理⼯作的服务器尝试执⾏请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。 注意：某些代理服务器在DNS查询超时时会返回400或者500错误
服务器不⽀持，或者拒绝⽀持在请求中使⽤的 HTTP 版本。这暗⽰着服务器不能或不愿使⽤与客户端相同的版本。响应中应当包含⼀个描述了为何版本不被⽀持以及服务器⽀持哪些协议的实体。
由《透明内容协商协议》（RFC 2295）扩展，代表服务器存在内部配置错误：被请求的协商变元资源被配置为在透明内容协商中使⽤⾃⼰，因此在⼀个协商处理中不是⼀个合适的重点。
服务器⽆法存储完成请求所必须的内容。这个状况被认为是临时的。WebDAV (RFC 4918)服务器达到带宽限制。这不是⼀个官⽅的状态码，但是仍被⼴泛使⽤。
510()
获取资源所需要的策略并没有没满⾜。（RFC 2774）
因篇幅问题不能全部显示，请点此查看更多更全内容