HTTP處理請求流程：
uWSGI是一個Web服務器，它實現了WSGI協議、uwsgi、http等協議。Nginx中HttpUwsgiModule的作用是與uWSGI服務器進行交換。WSGI是一種Web服務器網關接口。
一個普通的http請求處理流程，如上圖所示：
A -> client端發起請求給nginx
B -> nginx處理后，將請求轉發到uwsgi（線路協議，不是通信協議），並等待結果
C -> uwsgi處理完請求后，返回數據給nginx
D -> nginx將處理結果返回給客戶端
每個階段都會有一個預設的超時時間，由於網絡、機器負載、代碼異常等等各種原因，如果某個階段沒有在預期的時間內正常返回，就會導致這次請求異常，進而產生不同的狀態碼。
503
503是服務不可用的返回狀態。由於在nginx配置中，設置了limit_req的流量限制，導致許多請求返回503錯誤代碼，在限流的條件下，為提高用戶體驗，希望返回正常Code 200，且返回操作頻繁的信息：
location /test {
...
limit_req zone=zone_ip_rm burst=1 nodelay;
error_page 503 =200 /dealwith_503?callback=$arg_callback;
}
location /dealwith_503{
set $ret_body '{"code": "V00006","msg": "操作太頻繁了，請坐下來喝杯茶。"}';
if ( $arg_callback != "" )
{
return 200 'try{$arg_callback($ret_body)}catch(e){}';
}
return 200 $ret_body;
}
504
504主要是針對B、C階段。一般nginx配置中會有：
location / {
...
uwsgi_connect_timeout 6s;
uwsgi_send_timeout 6s;
uwsgi_read_timeout 10s;
uwsgi_buffering on;
uwsgi_buffers 80 16k;
...
}
這個代表nginx與上游服務器（uwsgi）通信的超時時間，也就是說，如果在這個時間內，uwsgi沒有響應，則認為這次請求超時，返回504狀態碼。
具體的日志如下：
access_log
[16/May/2016:22:11:38 +0800] 10.4.31.56 201605162211280100040310561523 15231401463407888908 10.*.*.* 127.0.0.1:8500 "GET /api/media_article_list/?count=10&source_type=0&status=all&from_time=0&item_id=0&flag=2&_=1463407896337 HTTP/1.1" 504 **.***.com **.**.**.39, **.**.**.60 10.000 10.000 "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.71 Safari/537.36" ... error_log 2016/05/16 22:11:38 [error] 90674#0: *947302032 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 10.6.19.81, server: **.***.com, request: "GET /api/media_article_list/?count=10&source_type=0&status=all&from_time=0&item_id=0&flag=2&_=1463407896337 HTTP/1.1", upstream: "http://127.0.0.1:8500/**/**/api/media_article_list/?count=10&source_type=0&status=all&from_time=0&item_id=0&flag=2&_=1463407896337", host: "mp.toutiao.com", referrer: "https://**.***.com/articles/?source_type=0" error_log中upstream timed out (110: Connection timed out) while reading response header from upstream，
意思是說，在規定的時間內，沒有從header中拿到數據，即uwsgi沒有返回任何數據。
502
502主要針對B 、C階段。產生502的時候，對應的error_log中的內容會有好幾種：
access_log [16/May/2016:16:39:49 +0800] 10.4.31.56 201605161639490100040310562612 2612221463387989972 10.6.19.81 127.0.0.1:88 "GET /articles/?source_type=0 HTTP/1.1" 503 **.***.com **.**.**.4, **.**.**.160 0.000 0.000 "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36" "uuid=\x22w:546d345b86ca443eb44bd9bb1120e821\x22; tt_webid=15660522398; lasttag=news_culture; sessionid=f172028cc8310ba7f503adb5957eb3ea; sid_tt=f172028cc8310ba7f503adb5957eb3ea; _ga=GA1.2.354066248.1463056713; _gat=1"
error_log 2016/05/16 16:39:49 [error] 90693#0: *944980723 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 10.6.19.80, server: **.***.com, request: "GET /articles/ HTTP/1.1", upstream: "http://127.0.0.1:8500/**/**/articles/", host: "**.***.com", referrer: "http://**.***.com/new_article/"
列一下常見的幾種502對應的 error_log：
l recv() failed (104: Connection reset by peer) while reading response header from upstream
l upstream prematurely closed connection while reading response header from upstream
l connect() failed (111: Connection refused) while connecting to upstream
....
這些都代表，在nginx設置的超時時間內，上游uwsgi沒有給正確的響應（但是是有響應的，不然如果一直沒響應，就會變成504超時了），因此nginx這邊的狀態碼為502。
client_header_buffer_size 32k;
large_client_header_buffers 8 64k;
client_max_body_size 100m;
如上，access_log中出現503，為什么？
這個是因為nginx upstream的容災機制。如果nginx有如下配置：
upstream app_backup {
server 127.0.0.1:8500 max_fails=3 fail_timeout=5s;
server 127.0.0.1:88 backup;
}
l max_fails=3 說明嘗試3次后，會認為“ server 127.0.0.1:8500” 失效，於是進入 “server 127.0.0.1:88 backup”，即訪問本機的88端口;
l nginx upstream的容災機制，默認情況下，Nginx 默認判斷失敗節點狀態以connect refuse和time out狀態為准，不過location里加了這個配置：
proxy_next_upstream error http_502;
proxy_connect_timeout 1s;
proxy_send_timeout 6s;
proxy_read_timeout 10s;
proxy_set_header Host $host;
l 這個配置是說，對於http狀態是502的情況，也會走upstream的容災機制；
l 概括一下就是，如果連續有3次(max_fails=3)狀態為502的請求，則會任務這個后端server 127.0.0.1:8500 掛掉了，在接下來的5s(fail_timeout=5s)內，就會訪問backup，即server 127.0.0.1:88 ，看下88端口對應的是什么：
server {
listen 88;
access_log /var/log/nginx/failover.log;
expires 1m;
error_page 500 502 503 504 /500.html;
location / {
return 503;
}
location = /500.html {
root /**/**/**/nginx/5xx/;
}
}
這個的意思就是，對於訪問88端口的請求，nginx會返回503狀態碼，同時返回/opt/tiger/ss_conf/nginx/5xx/這個路徑下的500.html文件。因此，access_log中看到的是503
499
client發送請求后，如果在規定的時間內（假設超時時間為500ms）沒有拿到nginx給的響應，則認為這次請求超時，會主動結束，這個時候nginx的access_log就會打印499狀態碼。
A+B+C+D > 500ms 其實這個時候，server端有可能還在處理請求，只不過client斷掉了連接，因此處理結果也無法返回給客戶端。499如果比較多的話，可能會引起服務雪崩。
比如說，client一直在發起請求，客戶端因為某些原因處理慢了，沒有在規定時間內返回數據，client認為請求失敗，中斷這次請求，然后再重新發起請求。這樣不斷的重復，服務端的請求越來越多，機器負載變大，請求處理越來越慢，沒有辦法響應請求
官網總結nginx返回499的情況，是由於：
client has closed connection #客戶端主動關閉了連接。
解決的話，可以添加
proxy_ignore_client_abort on; #忽略掉客戶端請求
Php代碼需要做程序上的優化
500
服務器內部錯誤，也就是服務器遇到意外情況，而無法執行請求。發生錯誤，一般的幾種情況：
web腳本錯誤，如php語法錯誤，lua語法錯誤等。
訪問量大的時候，由於系統資源限制，而不能打開過多的文件句柄
分析錯誤的原因
查看nginx，php的錯誤日志
如果是too many open files，修改nginx的worker_rlimit_nofile參數，使用ulimit查看系統打開文件限制，修改/etc/security/limits.conf
如果腳本存在問題，則需要修復腳本錯誤，並優化代碼
各種優化都做好，還是出現too many open files，那就需要考慮做負載均衡，把流量分散到不同服務器上去
http_code一覽表
200：服務器成功返回網頁
403：服務器拒絕請求。
404：請求的網頁不存在
499：客戶端主動斷開了連接。
500：服務器遇到錯誤，無法完成請求。
502：服務器作為網關或代理，從上游服務器收到無效響應。
503 - 服務不可用
504：服務器作為網關或代理，但是沒有及時從上游服務器收到請求。
這些狀態碼被分為五大類：
100-199 用於指定客戶端應相應的某些動作。
200-299 用於表示請求成功。
300-399 用於已經移動的文件並且常被包含在定位頭信息中指定新的地址信息。
400-499 用於指出客戶端的錯誤。 自己電腦瀏覽器這邊的問題）
500-599 用於支持服務器錯誤。 對方的問題）
---------------------------------------------------------------------------------------------
200 （成功） 服務器已成功處理了請求。 通常，這表示服務器提供了請求的網頁。
201 （已創建） 請求成功並且服務器創建了新的資源。
202 （已接受） 服務器已接受請求，但尚未處理。
203 （非授權信息） 服務器已成功處理了請求，但返回的信息可能來自另一來源。
204 （無內容） 服務器成功處理了請求，但沒有返回任何內容。
205 （重置內容） 服務器成功處理了請求，但沒有返回任何內容。
206 （部分內容） 服務器成功處理了部分 GET 請求。
---------------------------------------------------------------------------------------------
300 （多種選擇） 針對請求，服務器可執行多種操作。 服務器可根據請求者 (user agent) 選擇一項操作，或提供操作列表供請求者選擇。
301 （永久移動） 請求的網頁已永久移動到新位置。 服務器返回此響應（對 GET 或 HEAD 請求的響應）時，會自動將請求者轉到新位置。
302 （臨時移動） 服務器目前從不同位置的網頁響應請求，但請求者應繼續使用原有位置來進行以后的請求。
303 （查看其他位置） 請求者應當對不同的位置使用單獨的 GET 請求來檢索響應時，服務器返回此代碼。
304 （未修改） 自從上次請求后，請求的網頁未修改過。 服務器返回此響應時，不會返回網頁內容。
305 （使用代理） 請求者只能使用代理訪問請求的網頁。 如果服務器返回此響應，還表示請求者應使用代理。
307 （臨時重定向） 服務器目前從不同位置的網頁響應請求，但請求者應繼續使用原有位置來進行以后的請求。
---------------------------------------------------------------------------------------------
400 （錯誤請求） 服務器不理解請求的語法。
401 （未授權） 請求要求身份驗證。 對於需要登錄的網頁，服務器可能返回此響應。
403 （禁止） 服務器拒絕請求。
404 （未找到） 服務器找不到請求的網頁。
405 （方法禁用） 禁用請求中指定的方法。
406 （不接受） 無法使用請求的內容特性響應請求的網頁。
407 （需要代理授權） 此狀態代碼與 401（未授權）類似，但指定請求者應當授權使用代理。
408 （請求超時） 服務器等候請求時發生超時。
409 （沖突） 服務器在完成請求時發生沖突。 服務器必須在響應中包含有關沖突的信息。
410 （已刪除） 如果請求的資源已永久刪除，服務器就會返回此響應。
411 （需要有效長度） 服務器不接受不含有效內容長度標頭字段的請求。
412 （未滿足前提條件） 服務器未滿足請求者在請求中設置的其中一個前提條件。
413 （請求實體過大） 服務器無法處理請求，因為請求實體過大，超出服務器的處理能力。
414 （請求的 URI 過長） 請求的 URI（通常為網址）過長，服務器無法處理。
415 （不支持的媒體類型） 請求的格式不受請求頁面的支持。
416 （請求范圍不符合要求） 如果頁面無法提供請求的范圍，則服務器會返回此狀態代碼。
417 （未滿足期望值） 服務器未滿足"期望"請求標頭字段的要求。
---------------------------------------------------------------------------------------------
500 （服務器內部錯誤） 服務器遇到錯誤，無法完成請求。
501 （尚未實施） 服務器不具備完成請求的功能。 例如，服務器無法識別請求方法時可能會返回此代碼。
502 （錯誤網關） 服務器作為網關或代理，從上游服務器收到無效響應。
503 （服務不可用） 服務器目前無法使用（由於超載或停機維護）。 通常，這只是暫時狀態。
504 （網關超時） 服務器作為網關或代理，但是沒有及時從上游服務器收到請求。
505 （HTTP 版本不受支持） 服務器不支持請求中所用的 HTTP 協議版本。
