414 Request-URI Too Large
#客戶端請求頭緩沖區(qū)巨細(xì)，假如請求頭總長度大于小于128k，則利用此緩沖區(qū)，
#請求頭總長度大于128k時(shí)利用large_client_header_buffers配置的緩存區(qū)
client_header_buffer_size 128k;
#large_client_header_buffers 指令參數(shù)4為個(gè)數(shù)，128k為巨細(xì)，默認(rèn)是8k。申請4個(gè)128k。
large_client_header_buffers 4 128k;
當(dāng)http 的URI太長可能request header過大時(shí)會(huì)報(bào)414 Request URI too large或400 bad request錯(cuò)誤。
大概原因
場景1.cookie中寫入的值太大造成的，因?yàn)閔eader中的其他參數(shù)的size一般較量牢靠，只有cookie大概被寫入較大的數(shù)據(jù)
場景2.請求參數(shù)太長，好比宣布一個(gè)文章正文，用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
當(dāng)請求頭過大時(shí)，高出large_client_header_buffer時(shí)，
nginx大概返回"Request URI too large" (414)可能"Bad-request"(400)錯(cuò)誤,
如上例HTTP請求頭由多行組成，
個(gè)中"GET http://www.264.cn/ HTTP/1.1"暗示Request line
當(dāng)Request line的長度大于large_client_header_buffer的一個(gè)buffer(128k)時(shí)，nginx會(huì)返回"Request URI too large" (414)錯(cuò)誤，對應(yīng)上面的場景2。
請求投中最長的一行也要小于large_client_header_buffer，當(dāng)不是Request line的最長行大于一個(gè)buffer(128k)時(shí)，會(huì)返回"Bad-request"(400)錯(cuò)誤，對應(yīng)上面的場景1。
辦理步伐：這時(shí)可以調(diào)大上述兩個(gè)值。
client_header_buffer_size 512k;
large_client_header_buffers 4 512k;
504 Gateway Time-out
之前網(wǎng)站一直是利用nginx做署理后端的apache運(yùn)行php來提供處事。
apache常常會(huì)不按期不按時(shí)間的呈現(xiàn)不能處事失去響應(yīng)，然后nginx呈現(xiàn)"504 Gateway Time-out"
查察錯(cuò)誤日志也看不到任何對象，覺得是apache的bug(其實(shí)不是，下面會(huì)說原因）。
也許年數(shù)大了人就不愛折騰，愿意保持原狀不動(dòng)，利用監(jiān)控東西，每次收到報(bào)警后都從頭啟動(dòng)apache委曲維持著。
終于有一天我煩了，不就是處理懲罰php嗎，我不消apache總行了吧，，一怒之下利用源安裝php-fpm轉(zhuǎn)移到php-fpm來運(yùn)行php。
安裝php并不貧苦，利用源安裝照舊很順利的，獨(dú)一需要做的就是配置php worker事情歷程的日志輸出php錯(cuò)誤日志。
一切籌備停當(dāng)后把本來的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;
就可以把a(bǔ)pache上跑的php遷移到php-fpm上來跑。
原覺得這樣就可以安枕無憂了，遷移完成是也確實(shí)沒什么問題，可是假如你不去闡明問題的基礎(chǔ)原因在哪。
問題照舊會(huì)找上門來，第二天nginx又報(bào)了504的gateway timeout。
這回沒apache什么事了吧，apache總算撇清了干系。
那應(yīng)該照舊在nginx和php-fpm身上，查察nginx的錯(cuò)誤日志，可以看到
[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"超時(shí)退出了。
頓時(shí)重啟php-fpm，問題沒有了，網(wǎng)站可以會(huì)見了。
再次會(huì)見該頁面，依然沒有響應(yīng)，但同時(shí)會(huì)見此外頁面正常，該頁面刷新屢次后，整個(gè)網(wǎng)站都是bad gateway timeout了。
問題就縮小到這個(gè)php劇本上了。
netstat -napo |grep "php5-fpm" | wc -l
查察php事情歷程已經(jīng)到達(dá)了設(shè)置文件里的上限10，有種感受就是各人都被open.php這個(gè)劇本卡住了。
這個(gè)劇本是干什么的呢？這個(gè)劇本就是收羅快遞信息的，內(nèi)里用到了php_curl。
PHP劇本假如執(zhí)行時(shí)間高出php.ini中的設(shè)置項(xiàng)max_execution_time不出功效就會(huì)強(qiáng)制退出。
查察了php.ini中max_execution_time確實(shí)配了，值為30。
萬能google派上用場了，顛末不絕google后獲得下面這句話
