414 Request-URI Too Large
#客戶端請求頭緩沖區(qū)巨細，假如請求頭總長度大于小于128k，則利用此緩沖區(qū)，
#請求頭總長度大于128k時利用large_client_header_buffers配置的緩存區(qū)
client_header_buffer_size 128k;
#large_client_header_buffers 指令參數(shù)4為個數(shù)，128k為巨細，默認是8k。申請4個128k。
large_client_header_buffers 4 128k;
當http 的URI太長可能request header過大時會報414 Request URI too large或400 bad request錯誤。
大概原因
場景1.cookie中寫入的值太大造成的，因為header中的其他參數(shù)的size一般較量牢靠，只有cookie大概被寫入較大的數(shù)據(jù)
場景2.請求參數(shù)太長，好比宣布一個文章正文，用urlencode后，利用get方法傳到靠山。
GET http://www.264.cn/ HTTP/1.1
Host: www.264.cn
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.31
Accept-Encoding: gzip,deflate,sdch
Accept-Language: zh-CN,zh;q=0.8
Accept-Charset: GBK,utf-8;q=0.7,*;q=0.3
Cookie: bdshare_firstime=1363517175366;
If-Modified-Since: Mon, 13 May 2013 13:40:02 GMT
當請求頭過大時，高出large_client_header_buffer時，
nginx大概返回"Request URI too large" (414)可能"Bad-request"(400)錯誤,
如上例HTTP請求頭由多行組成，
個中"GET http://www.264.cn/ HTTP/1.1"暗示Request line
當Request line的長度大于large_client_header_buffer的一個buffer(128k)時，nginx會返回"Request URI too large" (414)錯誤，對應上面的場景2。
請求投中最長的一行也要小于large_client_header_buffer，當不是Request line的最長行大于一個buffer(128k)時，會返回"Bad-request"(400)錯誤，對應上面的場景1。
辦理步伐：這時可以調(diào)大上述兩個值。
client_header_buffer_size 512k;
large_client_header_buffers 4 512k;
504 Gateway Time-out
之前網(wǎng)站一直是利用nginx做署理后端的apache運行php來提供處事。
apache常常會不按期不按時間的呈現(xiàn)不能處事失去響應，然后nginx呈現(xiàn)"504 Gateway Time-out"
查察錯誤日志也看不到任何對象，覺得是apache的bug(其實不是，下面會說原因）。
也許年數(shù)大了人就不愛折騰，愿意保持原狀不動，利用監(jiān)控東西，每次收到報警后都從頭啟動apache委曲維持著。
終于有一天我煩了，不就是處理懲罰php嗎，我不消apache總行了吧，，一怒之下利用源安裝php-fpm轉(zhuǎn)移到php-fpm來運行php。
安裝php并不貧苦，利用源安裝照舊很順利的，獨一需要做的就是配置php worker事情歷程的日志輸出php錯誤日志。
一切籌備停當后把本來的proxy_pass換成fastcgipass就可以了。
upstream apachephp {
server www.quancha.cn:8080; #Apache1
}
....
proxy_pass http://apachephp;
替換成成
upstream php {
server 127.0.0.1:9000;
}
...
fastcgi_pass php;
就可以把apache上跑的php遷移到php-fpm上來跑。
原覺得這樣就可以安枕無憂了，遷移完成是也確實沒什么問題，可是假如你不去闡明問題的基礎原因在哪。
問題照舊會找上門來，第二天nginx又報了504的gateway timeout。
這回沒apache什么事了吧，apache總算撇清了干系。
那應該照舊在nginx和php-fpm身上，查察nginx的錯誤日志，可以看到
[error] 6695#0: *168438 upstream timed out (110: Connection timed out) while reading response header from upstream,
...
request: "GET /kd/open.php?company=chinapost&number=PA24977020344 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.quancha.cn"
看到這里根基上就解除了nginx嫌疑，nginx是在期待php處理懲罰"GET /kd/open.php?company=chinapost&number=PA24977020344 HTTP/1.1"超時退出了。
頓時重啟php-fpm，問題沒有了，網(wǎng)站可以會見了。
再次會見該頁面，依然沒有響應，但同時會見此外頁面正常，該頁面刷新屢次后，整個網(wǎng)站都是bad gateway timeout了。
問題就縮小到這個php劇本上了。
netstat -napo |grep "php5-fpm" | wc -l
查察php事情歷程已經(jīng)到達了設置文件里的上限10，有種感受就是各人都被open.php這個劇本卡住了。
這個劇本是干什么的呢？這個劇本就是收羅快遞信息的，內(nèi)里用到了php_curl。
PHP劇本假如執(zhí)行時間高出php.ini中的設置項max_execution_time不出功效就會強制退出。
查察了php.ini中max_execution_time確實配了，值為30。
萬能google派上用場了，顛末不絕google后獲得下面這句話
