414 Request-URI Too Large

#客戶端請求頭緩沖區大小，如果請求頭總長度大于小于128k，則使用此緩沖區，#請求頭總長度大于128k時使用large_client_header_buffers設置的緩存區client_header_buffer_size 128k;#large_client_header_buffers 指令參數4為個數，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中的其他參數的size一般比較固定，只有cookie可能被寫入較大的數據

場景2.請求參數太長，比如發布一個文章正文，用urlencode后，使用get方式傳到后臺。

GET http://www.264.cn/ HTTP/1.1Host: www.264.cnConnection: keep-aliveCache-Control: max-age=0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.31 Accept-Encoding: gzip,deflate,sdchAccept-Language: zh-CN,zh;q=0.8Accept-Charset: GBK,utf-8;q=0.7,*;q=0.3Cookie: 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。

解決辦法：這時可以調大上述兩個值。

client_header_buffer_size 512k;large_client_header_buffers 4 512k;

504 Gateway Time-out
之前網站一直是使用nginx做代理后端的apache運行php來提供服務。

apache經常會不定期不定時間的出現不能服務失去響應，然后nginx出現"504 Gateway Time-out"

查看錯誤日志也看不到任何東西，以為是apache的bug(其實不是，下面會說原因）。

也許年齡大了人就不愛折騰，愿意保持原狀不動，使用監控工具，每次收到報警后都重新啟動apache勉強維持著。

終于有一天我煩了，不就是處理php嗎，我不用apache總行了吧，一怒之下使用源安裝php-fpm轉移到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上來跑。

原以為這樣就可以高枕無憂了，遷移完成是也確實沒什么問題，但是如果你不去分析問題的根本原因在哪。