Nginx常見錯誤及處理方法(轉)

時間  2020-07-10
標籤 nginx 常見 錯誤 處理 方法 欄目 Nginx 简体版
原文   原文鏈接

404 bad requestjavascript

通常緣由:請求的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=10M
  2. 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.conf
  1. * soft nofile 65535
  2. * 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 128k
  1. send_timeout 60;
  
upstream jira_Cluster_web {
    #ip_hash;
        server 10.143.50.15:8081 ;      
        server 10.143.50.16:8081 backup;      
}

server {
        listen       80;
        server_name   jira1.gomeholdings.com;
    index index.html index.htm;
    #root html;
        location / {
        proxy_redirect off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        client_body_buffer_size 128k;
        proxy_connect_timeout 90;
        proxy_send_timeout 90;
        proxy_read_timeout 90;
        proxy_buffer_size 4k;
        proxy_buffers 4 32k;
        proxy_busy_buffers_size 64k;
        proxy_temp_file_write_size 64k;
        #proxy_set_header X-Forwarded-Host $host;
                #proxy_set_header X-Forwarded-Server $host;
                #proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass  http://jira_Cluster_web/;
        #proxy_pass  http://10.143.50.15:8081;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        }
}
View Code

 

######Nginx配置文件nginx.conf中文詳解#####

#定義Nginx運行的用戶和用戶組
user www www;

#nginx進程數，建議設置爲等於CPU總核心數。
worker_processes 8;
 
#全局錯誤日誌定義類型，[ debug | info | notice | warn | error | crit ]
error_log /usr/local/nginx/logs/error.log info;

#進程pid文件
pid /usr/local/nginx/logs/nginx.pid;

#指定進程能夠打開的最大描述符：數目
#工做模式與鏈接數上限
#這個指令是指當一個nginx進程打開的最多文件描述符數目，理論值應該是最多打開文件數（ulimit -n）與nginx進程數相除，可是nginx分配請求並非那麼均勻，因此最好與ulimit -n 的值保持一致。
#如今在linux 2.6內核下開啓文件打開數爲65535，worker_rlimit_nofile就相應應該填寫65535。
#這是由於nginx調度時分配請求到進程並非那麼的均衡，因此假如填寫10240，總併發量達到3-4萬時就有進程可能超過10240了，這時會返回502錯誤。
worker_rlimit_nofile 65535;


events
{
    #參考事件模型，use [ kqueue | rtsig | epoll | /dev/poll | select | poll ]; epoll模型
    #是Linux 2.6以上版本內核中的高性能網絡I/O模型，linux建議epoll，若是跑在FreeBSD上面，就用kqueue模型。
    #補充說明：
    #與apache相類，nginx針對不一樣的操做系統，有不一樣的事件模型
    #A）標準事件模型
    #Select、poll屬於標準事件模型，若是當前系統不存在更有效的方法，nginx會選擇select或poll
    #B）高效事件模型
    #Kqueue：使用於FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X.使用雙處理器的MacOS X系統使用kqueue可能會形成內核崩潰。
    #Epoll：使用於Linux內核2.6版本及之後的系統。
    #/dev/poll：使用於Solaris 7 11/99+，HP/UX 11.22+ (eventport)，IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+。
    #Eventport：使用於Solaris 10。 爲了防止出現內核崩潰的問題， 有必要安裝安全補丁。
    use epoll;

    #單個進程最大鏈接數（最大鏈接數=鏈接數*進程數）
    #根據硬件調整，和前面工做進程配合起來用，儘可能大，可是別把cpu跑到100%就行。每一個進程容許的最多鏈接數，理論上每臺nginx服務器的最大鏈接數爲。
    worker_connections 65535;

    #keepalive超時時間。
    keepalive_timeout 60;

    #客戶端請求頭部的緩衝區大小。這個能夠根據你的系統分頁大小來設置，通常一個請求頭的大小不會超過1k，不過因爲通常系統分頁都要大於1k，因此這裏設置爲分頁大小。
    #分頁大小能夠用命令getconf PAGESIZE 取得。
    #[root@web001 ~]# getconf PAGESIZE
    #4096
    #但也有client_header_buffer_size超過4k的狀況，可是client_header_buffer_size該值必須設置爲「系統分頁大小」的整倍數。
    client_header_buffer_size 4k;

    #這個將爲打開文件指定緩存，默認是沒有啓用的，max指定緩存數量，建議和打開文件數一致，inactive是指通過多長時間文件沒被請求後刪除緩存。
    open_file_cache max=65535 inactive=60s;

    #這個是指多長時間檢查一次緩存的有效信息。
    #語法:open_file_cache_valid time 默認值:open_file_cache_valid 60 使用字段:http, server, location 這個指令指定了什麼時候須要檢查open_file_cache中緩存項目的有效信息.
    open_file_cache_valid 80s;

    #open_file_cache指令中的inactive參數時間內文件的最少使用次數，若是超過這個數字，文件描述符一直是在緩存中打開的，如上例，若是有一個文件在inactive時間內一次沒被使用，它將被移除。
    #語法:open_file_cache_min_uses number 默認值:open_file_cache_min_uses 1 使用字段:http, server, location  這個指令指定了在open_file_cache指令無效的參數中必定的時間範圍內可使用的最小文件數,若是使用更大的值,文件描述符在cache中老是打開狀態.
    open_file_cache_min_uses 1;
    
    #語法:open_file_cache_errors on | off 默認值:open_file_cache_errors off 使用字段:http, server, location 這個指令指定是否在搜索一個文件是記錄cache錯誤.
    open_file_cache_errors on;
}
 
 
 
#設定http服務器，利用它的反向代理功能提供負載均衡支持
http
{
    #文件擴展名與文件類型映射表
    include mime.types;

    #默認文件類型
    default_type application/octet-stream;

    #默認編碼
    #charset utf-8;

    #服務器名字的hash表大小
    #保存服務器名字的hash表是由指令server_names_hash_max_size 和server_names_hash_bucket_size所控制的。參數hash bucket size老是等於hash表的大小，而且是一路處理器緩存大小的倍數。在減小了在內存中的存取次數後，使在處理器中加速查找hash表鍵值成爲可能。若是hash bucket size等於一路處理器緩存的大小，那麼在查找鍵的時候，最壞的狀況下在內存中查找的次數爲2。第一次是肯定存儲單元的地址，第二次是在存儲單元中查找鍵 值。所以，若是Nginx給出須要增大hash max size 或 hash bucket size的提示，那麼首要的是增大前一個參數的大小.
    server_names_hash_bucket_size 128;

    #客戶端請求頭部的緩衝區大小。這個能夠根據你的系統分頁大小來設置，通常一個請求的頭部大小不會超過1k，不過因爲通常系統分頁都要大於1k，因此這裏設置爲分頁大小。分頁大小能夠用命令getconf PAGESIZE取得。
    client_header_buffer_size 32k;

    #客戶請求頭緩衝大小。nginx默認會用client_header_buffer_size這個buffer來讀取header值，若是header過大，它會使用large_client_header_buffers來讀取。
    large_client_header_buffers 4 64k;

    #設定經過nginx上傳文件的大小
    client_max_body_size 8m;

    #開啓高效文件傳輸模式，sendfile指令指定nginx是否調用sendfile函數來輸出文件，對於普通應用設爲 on，若是用來進行下載等應用磁盤IO重負載應用，可設置爲off，以平衡磁盤與網絡I/O處理速度，下降系統的負載。注意：若是圖片顯示不正常把這個改爲off。
    #sendfile指令指定 nginx 是否調用sendfile 函數（zero copy 方式）來輸出文件，對於普通應用，必須設爲on。若是用來進行下載等應用磁盤IO重負載應用，可設置爲off，以平衡磁盤與網絡IO處理速度，下降系統uptime。
    sendfile on;

    #開啓目錄列表訪問，合適下載服務器，默認關閉。
    autoindex on;

    #此選項容許或禁止使用socke的TCP_CORK的選項，此選項僅在使用sendfile的時候使用
    tcp_nopush on;
     
    tcp_nodelay on;

    #長鏈接超時時間，單位是秒
    keepalive_timeout 120;

    #FastCGI相關參數是爲了改善網站的性能：減小資源佔用，提升訪問速度。下面參數看字面意思都能理解。
    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;

    #gzip模塊設置
    gzip on; #開啓gzip壓縮輸出
    gzip_min_length 1k;    #最小壓縮文件大小
    gzip_buffers 4 16k;    #壓縮緩衝區
    gzip_http_version 1.0;    #壓縮版本（默認1.1，前端若是是squid2.5請使用1.0）
    gzip_comp_level 2;    #壓縮等級
    gzip_types text/plain application/x-javascript text/css application/xml;    #壓縮類型，默認就已經包含textml，因此下面就不用再寫了，寫上去也不會有問題，可是會有一個warn。
    gzip_vary on;

    #開啓限制IP鏈接數的時候須要使用
    #limit_zone crawler $binary_remote_addr 10m;



    #負載均衡配置
    upstream piao.jd.com {
     
        #upstream的負載均衡，weight是權重，能夠根據機器配置定義權重。weigth參數表示權值，權值越高被分配到的概率越大。
        server 192.168.80.121:80 weight=3;
        server 192.168.80.122:80 weight=2;
        server 192.168.80.123:80 weight=3;

        #nginx的upstream目前支持4種方式的分配
        #一、輪詢（默認）
        #每一個請求按時間順序逐一分配到不一樣的後端服務器，若是後端服務器down掉，能自動剔除。
        #二、weight
        #指定輪詢概率，weight和訪問比率成正比，用於後端服務器性能不均的狀況。
        #例如：
        #upstream bakend {
        #    server 192.168.0.14 weight=10;
        #    server 192.168.0.15 weight=10;
        #}
        #二、ip_hash
        #每一個請求按訪問ip的hash結果分配，這樣每一個訪客固定訪問一個後端服務器，能夠解決session的問題。
        #例如：
        #upstream bakend {
        #    ip_hash;
        #    server 192.168.0.14:88;
        #    server 192.168.0.15:80;
        #}
        #三、fair（第三方）
        #按後端服務器的響應時間來分配請求，響應時間短的優先分配。
        #upstream backend {
        #    server server1;
        #    server server2;
        #    fair;
        #}
        #四、url_hash（第三方）
        #按訪問url的hash結果來分配請求，使每一個url定向到同一個後端服務器，後端服務器爲緩存時比較有效。
        #例：在upstream中加入hash語句，server語句中不能寫入weight等其餘的參數，hash_method是使用的hash算法
        #upstream backend {
        #    server squid1:3128;
        #    server squid2:3128;
        #    hash $request_uri;
        #    hash_method crc32;
        #}

        #tips:
        #upstream bakend{#定義負載均衡設備的Ip及設備狀態}{
        #    ip_hash;
        #    server 127.0.0.1:9090 down;
        #    server 127.0.0.1:8080 weight=2;
        #    server 127.0.0.1:6060;
        #    server 127.0.0.1:7070 backup;
        #}
        #在須要使用負載均衡的server中增長 proxy_pass http://bakend/;

        #每一個設備的狀態設置爲:
        #1.down表示單前的server暫時不參與負載
        #2.weight爲weight越大，負載的權重就越大。
        #3.max_fails：容許請求失敗的次數默認爲1.當超過最大次數時，返回proxy_next_upstream模塊定義的錯誤
        #4.fail_timeout:max_fails次失敗後，暫停的時間。
        #5.backup： 其它全部的非backup機器down或者忙的時候，請求backup機器。因此這臺機器壓力會最輕。

        #nginx支持同時設置多組的負載均衡，用來給不用的server來使用。
        #client_body_in_file_only設置爲On 能夠講client post過來的數據記錄到文件中用來作debug
        #client_body_temp_path設置記錄文件的目錄 能夠設置最多3層目錄
        #location對URL進行匹配.能夠進行重定向或者進行新的代理 負載均衡
    }
     
     
     
    #虛擬主機的配置
    server
    {
        #監聽端口
        listen 80;

        #域名能夠有多個，用空格隔開
        server_name www.jd.com jd.com;
        index index.html index.htm index.php;
        root /data/www/jd;

        #對******進行負載均衡
        location ~ .*.(php|php5)?$
        {
            fastcgi_pass 127.0.0.1:9000;
            fastcgi_index index.php;
            include fastcgi.conf;
        }
         
        #圖片緩存時間設置
        location ~ .*.(gif|jpg|jpeg|png|bmp|swf)$
        {
            expires 10d;
        }
         
        #JS和CSS緩存時間設置
        location ~ .*.(js|css)?$
        {
            expires 1h;
        }
         
        #日誌格式設定
        #$remote_addr與$http_x_forwarded_for用以記錄客戶端的ip地址；
        #$remote_user：用來記錄客戶端用戶名稱；
        #$time_local： 用來記錄訪問時間與時區；
        #$request： 用來記錄請求的url與http協議；
        #$status： 用來記錄請求狀態；成功是200，
        #$body_bytes_sent ：記錄發送給客戶端文件主體內容大小；
        #$http_referer：用來記錄從那個頁面連接訪問過來的；
        #$http_user_agent：記錄客戶瀏覽器的相關信息；
        #一般web服務器放在反向代理的後面，這樣就不能獲取到客戶的IP地址了，經過$remote_add拿到的IP地址是反向代理服務器的iP地址。反向代理服務器在轉發請求的http頭信息中，能夠增長x_forwarded_for信息，用以記錄原有客戶端的IP地址和原來客戶端的請求的服務器地址。
        log_format access '$remote_addr - $remote_user [$time_local] "$request" '
        '$status $body_bytes_sent "$http_referer" '
        '"$http_user_agent" $http_x_forwarded_for';
         
        #定義本虛擬主機的訪問日誌
        access_log  /usr/local/nginx/logs/host.access.log  main;
        access_log  /usr/local/nginx/logs/host.access.404.log  log404;
         
        #對 "/" 啓用反向代理
        location / {
            proxy_pass http://127.0.0.1:88;
            proxy_redirect off;
            proxy_set_header X-Real-IP $remote_addr;
             
            #後端的Web服務器能夠經過X-Forwarded-For獲取用戶真實IP
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
             
            #如下是一些反向代理的配置，可選。
            proxy_set_header Host $host;

            #容許客戶端請求的最大單文件字節數
            client_max_body_size 10m;

            #緩衝區代理緩衝用戶端請求的最大字節數，
            #若是把它設置爲比較大的數值，例如256k，那麼，不管使用firefox仍是IE瀏覽器，來提交任意小於256k的圖片，都很正常。若是註釋該指令，使用默認的client_body_buffer_size設置，也就是操做系統頁面大小的兩倍，8k或者16k，問題就出現了。
            #不管使用firefox4.0仍是IE8.0，提交一個比較大，200k左右的圖片，都返回500 Internal Server Error錯誤
            client_body_buffer_size 128k;

            #表示使nginx阻止HTTP應答代碼爲400或者更高的應答。
            proxy_intercept_errors on;

            #後端服務器鏈接的超時時間_發起握手等候響應超時時間
            #nginx跟後端服務器鏈接超時時間(代理鏈接超時)
            proxy_connect_timeout 90;

            #後端服務器數據回傳時間(代理髮送超時)
            #後端服務器數據回傳時間_就是在規定時間以內後端服務器必須傳完全部的數據
            proxy_send_timeout 90;

            #鏈接成功後，後端服務器響應時間(代理接收超時)
            #鏈接成功後_等候後端服務器響應時間_其實已經進入後端的排隊之中等候處理（也能夠說是後端服務器處理請求的時間）
            proxy_read_timeout 90;

            #設置代理服務器（nginx）保存用戶頭信息的緩衝區大小
            #設置從被代理服務器讀取的第一部分應答的緩衝區大小，一般狀況下這部分應答中包含一個小的應答頭，默認狀況下這個值的大小爲指令proxy_buffers中指定的一個緩衝區的大小，不過能夠將其設置爲更小
            proxy_buffer_size 4k;

            #proxy_buffers緩衝區，網頁平均在32k如下的設置
            #設置用於讀取應答（來自被代理服務器）的緩衝區數目和大小，默認狀況也爲分頁大小，根據操做系統的不一樣多是4k或者8k
            proxy_buffers 4 32k;

            #高負荷下緩衝大小（proxy_buffers*2）
            proxy_busy_buffers_size 64k;

            #設置在寫入proxy_temp_path時數據的大小，預防一個工做進程在傳遞文件時阻塞太長
            #設定緩存文件夾大小，大於這個值，將從upstream服務器傳
            proxy_temp_file_write_size 64k;
        }
         
         
        #設定查看Nginx狀態的地址
        location /NginxStatus {
            stub_status on;
            access_log on;
            auth_basic "NginxStatus";
            auth_basic_user_file confpasswd;
            #htpasswd文件的內容能夠用apache提供的htpasswd工具來產生。
        }
         
        #本地動靜分離反向代理配置
        #全部jsp的頁面均交由tomcat或resin處理
        location ~ .(jsp|jspx|do)?$ {
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_pass http://127.0.0.1:8080;
        }
         
        #全部靜態文件由nginx直接讀取不通過tomcat或resin
        location ~ .*.(htm|html|gif|jpg|jpeg|png|bmp|swf|ioc|rar|zip|txt|flv|mid|doc|ppt|
        pdf|xls|mp3|wma)$
        {
            expires 15d; 
        }
         
        location ~ .*.(js|css)?$
        {
            expires 1h;
        }
    }
}
######Nginx配置文件nginx.conf中文詳解#####
View Code

 

 

中文配置詳解： php

http://tool.oschina.net/apidocs/apidoc?api=nginx-zhcss

http://shouce.jb51.net/nginx/left.htmlhtml

官方文檔：前端

http://nginx.org/en/docs/http/ngx_http_core_module.htmljava

 

附表：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 服務器成功處理了請求，但不須要返回任何實體內容，而且但願返回更新了的元信息。響應可能經過實體頭部的形式，返回新的或更新後的元信息。若是存在這些頭部信息，則應當與所請求的變量相呼應。 　　若是客戶端是瀏覽器的話，那麼用戶瀏覽器應保留髮送了該請求的頁面，而不產生任何文檔視圖上的變化，即便按照規範新的或更新後的元信息應當被應用到用戶瀏覽器活動視圖中的文檔。 　　因爲204響應被禁止包含任何消息體，所以它始終以消息頭後的第一個空行結尾。
205 服務器成功處理了請求，且沒有返回任何內容。可是與204響應不一樣，返回此狀態碼的響應要求請求者重置文檔視圖。該響應主要是被用於接受用戶輸入後，當即重置表單，以便用戶可以輕鬆地開始另外一次輸入。 　　與204響應同樣，該響應也被禁止包含任何消息體，且以消息頭後的第一個空行結束。
206 服務器已經成功處理了部分 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-Range 強緩存驗證，那麼本次響應不該該包含其餘實體頭；假如本響應的請求使用了 If-Range 弱緩存驗證，那麼本次響應禁止包含其餘實體頭；這避免了緩存的實體內容和更新了的實體頭信息之間的不一致。不然，本響應就應當包含全部本應該返回200響應中應當返回的全部實體頭部域。 　　假如 ETag 或 Last-Modified 頭部不能精確匹配的話，則客戶端緩存應禁止將206響應返回的內容與以前任何緩存過的內容組合在一塊兒。 　　任何不支持 Range 以及 Content-Range 頭的緩存都禁止緩存206響應返回的內容。
207 由WebDAV(RFC 2518)擴展的狀態碼，表明以後的消息體將是一個XML消息，而且可能依照以前子請求數量的不一樣，包含一系列獨立的響應代碼。
300 被請求的資源有一系列可供選擇的回饋信息，每一個都有本身特定的地址和瀏覽器驅動的商議信息。用戶或瀏覽器可以自行選擇一個首選的地址進行重定向。 　　除非這是一個 HEAD 請求，不然該響應應當包括一個資源特性及地址的列表的實體，以便用戶或瀏覽器從中選擇最合適的重定向地址。這個實體的格式由 Content-Type 定義的格式所決定。瀏覽器可能根據響應的格式以及瀏覽器自身能力，自動做出最合適的選擇。固然，RFC 2616規範並無規定這樣的自動選擇該如何進行。 　　若是服務器自己已經有了首選的回饋選擇，那麼在 Location 中應當指明這個回饋的 URI；瀏覽器可能會將這個 Location 值做爲自動重定向的地址。此外，除非額外指定，不然這個響應也是可緩存的。
301 被請求的資源已永久移動到新位置，而且未來任何對此資源的引用都應該使用本響應返回的若干個 URI 之一。若是可能，擁有連接編輯功能的客戶端應當自動把請求的地址修改成從服務器反饋回來的地址。除非額外指定，不然這個響應也是可緩存的。 　　新的永久性的 URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求，不然響應的實體中應當包含指向新的 URI 的超連接及簡短說明。 　　若是這不是一個 GET 或者 HEAD 請求，所以瀏覽器禁止自動進行重定向，除非獲得用戶的確認，由於請求的條件可能所以發生變化。 　　注意：對於某些使用 HTTP/1.0 協議的瀏覽器，當它們發送的 POST 請求獲得了一個301響應的話，接下來的重定向請求將會變成 GET 方式。
302 請求的資源如今臨時從不一樣的 URI 響應請求。因爲這樣的重定向是臨時的，客戶端應當繼續向原有地址發送之後的請求。只有在Cache-Control或Expires中進行了指定的狀況下，這個響應纔是可緩存的。 　　新的臨時性的 URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求，不然響應的實體中應當包含指向新的 URI  的超連接及簡短說明。 　　若是這不是一個 GET 或者 HEAD 請求，那麼瀏覽器禁止自動進行重定向，除非獲得用戶的確認，由於請求的條件可能所以發生變化。 　　注意：雖然RFC 1945和RFC 2068規範不容許客戶端在重定向時改變請求的方法，可是不少現存的瀏覽器將302響應視做爲303響應，而且使用 GET 方式訪問在 Location 中規定的 URI，而無視原先請求的方法。狀態碼303和307被添加了進來，用以明確服務器期待客戶端進行何種反應。
303 對應當前請求的響應能夠在另外一個 URI 上被找到，並且客戶端應當採用 GET 的方式訪問那個資源。這個方法的存在主要是爲了容許由腳本激活的POST請求輸出重定向到一個新的資源。這個新的 URI 不是原始資源的替代引用。同時，303響應禁止被緩存。固然，第二個請求（重定向）可能被緩存。 　　新的 URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求，不然響應的實體中應當包含指向新的 URI 的超連接及簡短說明。 　　注意：許多 HTTP/1.1 版之前的 瀏覽器不能正確理解303狀態。若是須要考慮與這些瀏覽器之間的互動，302狀態碼應該能夠勝任，由於大多數的瀏覽器處理302響應時的方式偏偏就是上述規範要求客戶端處理303響應時應當作的。
304 若是客戶端發送了一個帶條件的 GET 請求且該請求已被容許，而文檔的內容（自上次訪問以來或者根據請求的條件）並無改變，則服務器應當返回這個狀態碼。304響應禁止包含消息體，所以始終以消息頭後的第一個空行結尾。 　　該響應必須包含如下的頭信息： 　　Date，除非這個服務器沒有時鐘。假如沒有時鐘的服務器也遵照這些規則，那麼代理服務器以及客戶端能夠自行將 Date 字段添加到接收到的響應頭中去（正如RFC 2068中規定的同樣），緩存機制將會正常工做。 　　ETag 和/或 Content-Location，假如一樣的請求本應返回200響應。 　　Expires, Cache-Control，和/或Vary，假如其值可能與以前相同變量的其餘響應對應的值不一樣的話。 　　假如本響應請求使用了強緩存驗證，那麼本次響應不該該包含其餘實體頭；不然（例如，某個帶條件的 GET 請求使用了弱緩存驗證），本次響應禁止包含其餘實體頭；這避免了緩存了的實體內容和更新了的實體頭信息之間的不一致。 　　假如某個304響應指明瞭當前某個實體沒有緩存，那麼緩存系統必須忽視這個響應，而且重複發送不包含限制條件的請求。 　　假如接收到一個要求更新某個緩存條目的304響應，那麼緩存系統必須更新整個條目以反映全部在響應中被更新的字段的值。
305 被請求的資源必須經過指定的代理才能被訪問。Location 域中將給出指定的代理所在的 URI 信息，接收者須要重複發送一個單獨的請求，經過這個代理才能訪問相應資源。只有原始服務器才能創建305響應。 　　注意：RFC 2068中沒有明確305響應是爲了重定向一個單獨的請求，並且只能被原始服務器創建。忽視這些限制可能致使嚴重的安全後果。
306 在最新版的規範中，306狀態碼已經再也不被使用。
307 請求的資源如今臨時從不一樣的URI 響應請求。因爲這樣的重定向是臨時的，客戶端應當繼續向原有地址發送之後的請求。只有在Cache-Control或Expires中進行了指定的狀況下，這個響應纔是可緩存的。 　　新的臨時性的URI 應當在響應的 Location 域中返回。除非這是一個HEAD 請求，不然響應的實體中應當包含指向新的URI 的超連接及簡短說明。由於部分瀏覽器不能識別307響應，所以須要添加上述必要信息以便用戶可以理解並向新的 URI 發出訪問請求。 　　若是這不是一個GET 或者 HEAD 請求，那麼瀏覽器禁止自動進行重定向，除非獲得用戶的確認，由於請求的條件可能所以發生變化。
400 一、語義有誤，當前請求沒法被服務器理解。除非進行修改，不然客戶端不該該重複提交這個請求。 　　二、請求參數有誤。
401 當前請求須要用戶驗證。該響應必須包含一個適用於被請求資源的 WWW-Authenticate 信息頭用以詢問用戶信息。客戶端能夠重複提交一個包含恰當的 Authorization 頭信息的請求。若是當前請求已經包含了 Authorization 證書，那麼401響應表明着服務器驗證已經拒絕了那些證書。若是401響應包含了與前一個響應相同的身份驗證詢問，且瀏覽器已經至少嘗試了一次驗證，那麼瀏覽器應當向用戶展現響應中包含的實體信息，由於這個實體信息中可能包含了相關診斷信息。參見RFC 2617。
402 該狀態碼是爲了未來可能的需求而預留的。
403 服務器已經理解請求，可是拒絕執行它。與401響應不一樣的是，身份驗證並不能提供任何幫助，並且這個請求也不該該被重複提交。若是這不是一個 HEAD 請求，並且服務器但願可以講清楚爲什麼請求不能被執行，那麼就應該在實體內描述拒絕的緣由。固然服務器也能夠返回一個404響應，假如它不但願讓客戶端得到任何信息。
404 請求失敗，請求所但願獲得的資源未被在服務器上發現。沒有信息可以告訴用戶這個情況究竟是暫時的仍是永久的。假如服務器知道狀況的話，應當使用410狀態碼來告知舊資源由於某些內部的配置機制問題，已經永久的不可用，並且沒有任何能夠跳轉的地址。404這個狀態碼被普遍應用於當服務器不想揭示到底爲什麼請求被拒絕或者沒有其餘適合的響應可用的狀況下。
405 請求行中指定的請求方法不能被用於請求相應的資源。該響應必須返回一個Allow 頭信息用以表示出當前資源可以接受的請求方法的列表。 　　鑑於 PUT，DELETE 方法會對服務器上的資源進行寫操做，於是絕大部分的網頁服務器都不支持或者在默認配置下不容許上述請求方法，對於此類請求均會返回405錯誤。
406 請求的資源的內容特性沒法知足請求頭中的條件，於是沒法生成響應實體。 　　除非這是一個 HEAD 請求，不然該響應就應當返回一個包含可讓用戶或者瀏覽器從中選擇最合適的實體特性以及地址列表的實體。實體的格式由 Content-Type 頭中定義的媒體類型決定。瀏覽器能夠根據格式及自身能力自行做出最佳選擇。可是，規範中並無定義任何做出此類自動選擇的標準。
407 與401響應相似，只不過客戶端必須在代理服務器上進行身份驗證。代理服務器必須返回一個 Proxy-Authenticate 用以進行身份詢問。客戶端能夠返回一個 Proxy-Authorization 信息頭用以驗證。參見RFC 2617。
408 請求超時。客戶端沒有在服務器預備等待的時間內完成一個請求的發送。客戶端能夠隨時再次提交這一請求而無需進行任何更改。
409 因爲和被請求的資源的當前狀態之間存在衝突，請求沒法完成。這個代碼只容許用在這樣的狀況下才能被使用：用戶被認爲可以解決衝突，而且會從新提交新的請求。該響應應當包含足夠的信息以便用戶發現衝突的源頭。 　　衝突一般發生於對 PUT 請求的處理中。例如，在採用版本檢查的環境下，某次 PUT 提交的對特定資源的修改請求所附帶的版本信息與以前的某個（第三方）請求向衝突，那麼此時服務器就應該返回一個409錯誤，告知用戶請求沒法完成。此時，響應實體中極可能會包含兩個衝突版本之間的差別比較，以便用戶從新提交歸併之後的新版本。
410 被請求的資源在服務器上已經再也不可用，並且沒有任何已知的轉發地址。這樣的情況應當被認爲是永久性的。若是可能，擁有連接編輯功能的客戶端應當在得到用戶許可後刪除全部指向這個地址的引用。若是服務器不知道或者沒法肯定這個情況是不是永久的，那麼就應該使用404狀態碼。除非額外說明，不然這個響應是可緩存的。 　　410響應的目的主要是幫助網站管理員維護網站，通知用戶該資源已經再也不可用，而且服務器擁有者但願全部指向這個資源的遠端鏈接也被刪除。這類事件在限時、增值服務中很廣泛。一樣，410響應也被用於通知客戶端在當前服務器站點上，本來屬於某個我的的資源已經再也不可用。固然，是否須要把全部永久不可用的資源標記爲'410 Gone'，以及是否須要保持此標記多長時間，徹底取決於服務器擁有者。
411 服務器拒絕在沒有定義 Content-Length 頭的狀況下接受請求。在添加了代表請求消息體長度的有效 Content-Length 頭以後，客戶端能夠再次提交該請求。
412 服務器在驗證在請求的頭字段中給出先決條件時，沒能知足其中的一個或多個。這個狀態碼容許客戶端在獲取資源時在請求的元信息（請求頭字段數據）中設置先決條件，以此避免該請求方法被應用到其但願的內容之外的資源上。
413 服務器拒絕處理當前請求，由於該請求提交的實體數據大小超過了服務器願意或者可以處理的範圍。此種狀況下，服務器能夠關閉鏈接以避免客戶端繼續發送此請求。 　　若是這個情況是臨時的，服務器應當返回一個 Retry-After 的響應頭，以告知客戶端能夠在多少時間之後從新嘗試。
414 請求的URI 長度超過了服務器可以解釋的長度，所以服務器拒絕對該請求提供服務。這比較少見，一般的狀況包括： 　　本應使用POST方法的表單提交變成了GET方法，致使查詢字符串（Query String）過長。 　　重定向URI 「黑洞」，例如每次重定向把舊的 URI 做爲新的 URI 的一部分，致使在若干次重定向後 URI 超長。 　　客戶端正在嘗試利用某些服務器中存在的安全漏洞攻擊服務器。這類服務器使用固定長度的緩衝讀取或操做請求的 URI，當 GET 後的參數超過某個數值後，可能會產生緩衝區溢出，致使任意代碼被執行[1]。沒有此類漏洞的服務器，應當返回414狀態碼。
415 對於當前請求的方法和所請求的資源，請求中提交的實體並非服務器中所支持的格式，所以請求被拒絕。
416 若是請求中包含了 Range 請求頭，而且 Range 中指定的任何數據範圍都與當前資源的可用範圍不重合，同時請求中又沒有定義 If-Range 請求頭，那麼服務器就應當返回416狀態碼。 　　假如 Range 使用的是字節範圍，那麼這種狀況就是指請求指定的全部數據範圍的首字節位置都超過了當前資源的長度。服務器也應當在返回416狀態碼的同時，包含一個 Content-Range 實體頭，用以指明當前資源的長度。這個響應也被禁止使用 multipart/byteranges 做爲其 Content-Type。
417 在請求頭 Expect 中指定的預期內容沒法被服務器知足，或者這個服務器是一個代理服務器，它有明顯的證據證實在當前路由的下一個節點上，Expect 的內容沒法被知足。
421 從當前客戶端所在的IP地址到服務器的鏈接數超過了服務器許可的最大範圍。一般，這裏的IP地址指的是從服務器上看到的客戶端地址（好比用戶的網關或者代理服務器地址）。在這種狀況下，鏈接數的計算可能涉及到不止一個終端用戶。
422 從當前客戶端所在的IP地址到服務器的鏈接數超過了服務器許可的最大範圍。一般，這裏的IP地址指的是從服務器上看到的客戶端地址（好比用戶的網關或者代理服務器地址）。在這種狀況下，鏈接數的計算可能涉及到不止一個終端用戶。
422 請求格式正確，可是因爲含有語義錯誤，沒法響應。（RFC 4918 WebDAV）423 Locked 　　當前資源被鎖定。（RFC 4918 WebDAV）
424 因爲以前的某個請求發生的錯誤，致使當前請求失敗，例如 PROPPATCH。（RFC 4918 WebDAV）
425 在WebDav Advanced Collections 草案中定義，可是未出如今《WebDAV 順序集協議》（RFC 3658）中。
426 客戶端應當切換到TLS/1.0。（RFC 2817）
449 由微軟擴展，表明請求應當在執行完適當的操做後進行重試。
500 服務器遇到了一個不曾預料的情況，致使了它沒法完成對請求的處理。通常來講，這個問題都會在服務器的程序碼出錯時出現。
501 服務器不支持當前請求所須要的某個功能。當服務器沒法識別請求的方法，而且沒法支持其對任何資源的請求。
502 做爲網關或者代理工做的服務器嘗試執行請求時，從上游服務器接收到無效的響應。
503 因爲臨時的服務器維護或者過載，服務器當前沒法處理請求。這個情況是臨時的，而且將在一段時間之後恢復。若是可以預計延遲時間，那麼響應中能夠包含一個 Retry-After 頭用以標明這個延遲時間。若是沒有給出這個 Retry-After 信息，那麼客戶端應當以處理500響應的方式處理它。 　　注意：503狀態碼的存在並不意味着服務器在過載的時候必須使用它。某些服務器只不過是但願拒絕客戶端的鏈接。
504 做爲網關或者代理工做的服務器嘗試執行請求時，未能及時從上游服務器（URI標識出的服務器，例如HTTP、FTP、LDAP）或者輔助服務器（例如DNS）收到響應。 　　注意：某些代理服務器在DNS查詢超時時會返回400或者500錯誤
505 服務器不支持，或者拒絕支持在請求中使用的 HTTP 版本。這暗示着服務器不能或不肯使用與客戶端相同的版本。響應中應當包含一個描述了爲什麼版本不被支持以及服務器支持哪些協議的實體。
506 由《透明內容協商協議》（RFC 2295）擴展，表明服務器存在內部配置錯誤：被請求的協商變元資源被配置爲在透明內容協商中使用本身，所以在一個協商處理中不是一個合適的重點。
507 服務器沒法存儲完成請求所必須的內容。這個情況被認爲是臨時的。WebDAV (RFC 4918)
509 服務器達到帶寬限制。這不是一個官方的狀態碼，可是仍被普遍使用。
510 獲取資源所須要的策略並無沒知足。（RFC 2774）
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程