2013-07-29 34 views
5

配置:無法上傳大文件與Nginx的(反向代理+ SSL協議)和Tomcat

  • 的Nginx作爲反向代理+ SSL協商
  • 的Apache Tomcat。

除文件上傳以外,一切似乎都正常。由於某些原因,文件上傳從未完成。通過下面列出的配置,我可以上傳小文件(4K)。上傳失敗的194K文件。當我將「client_body_buffer_size」增加到256K時,我可以上傳194K文件,但是500K文件上傳失敗。將「client_body_buffer_size」增加到256K以上不會產生任何影響。

注意:當我直接訪問Tomcat並上傳500K文件時,它在幾毫秒內完成。

所以,貌似Nginx配置有問題。任何建議,非常感謝。

upstream tomcat_server { 
     server 127.0.0.1:9090 fail_timeout=0; 
     keepalive 16; 
    } 

location/{ 
       root /xyz; 
       proxy_http_version 1.1; 
      proxy_pass http://tomcat_server; 
      proxy_set_header Connection ""; 
      proxy_set_header Host $host; 
      proxy_set_header X-Real-IP $remote_addr; 
      proxy_set_header X-Forwarded-Server $host; 
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 

      proxy_buffering   on; 
      proxy_connect_timeout 75; 
      proxy_send_timeout 180; 
      proxy_read_timeout 1200; 

     keepalive_timeout 120; 
     proxy_buffer_size 128k; 
     proxy_buffers 4 256k; 
     proxy_busy_buffers_size 256k; 
     proxy_temp_path /tmp/nginx/proxy; 
     proxy_temp_file_write_size 1000m; 

      } 

我曾嘗試添加其它幾個參數來配置nginx的(client_body_temp_path,proxy_temp_path,proxy_temp_file_write_size)。他們似乎沒有幫助。

====

更新 - 2013年7月30日:

進一步調查顯示,我們有問題上傳196K的文件和向上。 194K文件的作品。 「client_body_buffer_size」值設置爲256K。

Nginx的調試日誌顯示在功能衰竭的情況下執行以下操作:

2013/07/30 16:29:57 [debug] 14208#0: *1 recv: fd:11 2606 of 16384 
2013/07/30 16:29:57 [debug] 14208#0: *1 http proxy status 200 "200 OK" 
2013/07/30 16:29:57 [debug] 14208#0: *1 http proxy header: "Server: Apache-Coyote/1.1" 
2013/07/30 16:29:57 [debug] 14208#0: *1 http proxy header: "Content-Type: text/html;charset=utf-8" 
2013/07/30 16:29:57 [debug] 14208#0: *1 http proxy header: "Date: Tue, 30 Jul 2013 22:29:57 GMT" 
2013/07/30 16:29:57 [debug] 14208#0: *1 http proxy header: "Connection: close" 
2013/07/30 16:29:57 [debug] 14208#0: *1 http proxy header done 
2013/07/30 16:29:57 [debug] 14208#0: *1 xslt filter header 
2013/07/30 16:29:57 [debug] 14208#0: *1 HTTP/1.1 200 OK^M 
Server: nginx/1.5.2^M 
Date: Tue, 30 Jul 2013 22:29:57 GMT^M 
Content-Type: text/html;charset=utf-8^M 
Transfer-Encoding: chunked^M 
Connection: keep-alive^M 

2013/07/30 16:29:57 [debug] 14208#0: *1 write new buf t:1 f:0 000000001E61DAD8, pos 000000001E61DAD8, size: 168 file: 0, size: 0 
2013/07/30 16:29:57 [debug] 14208#0: *1 http write filter: l:0 f:0 s:168 
2013/07/30 16:29:57 [debug] 14208#0: *1 http cacheable: 0 
2013/07/30 16:29:57 [debug] 14208#0: *1 posix_memalign: 000000001E62D450:4096 @16 
2013/07/30 16:29:57 [debug] 14208#0: *1 http proxy filter init s:200 h:0 c:0 l:-1 
2013/07/30 16:29:57 [debug] 14208#0: *1 http upstream process upstream 
2013/07/30 16:29:57 [debug] 14208#0: *1 pipe read upstream: 1 
2013/07/30 16:29:57 [debug] 14208#0: *1 pipe preread: 2465 
2013/07/30 16:29:57 [debug] 14208#0: *1 readv: 1:13778 
2013/07/30 16:29:57 [debug] 14208#0: *1 readv() not ready (11: Resource temporarily unavailable) 
2013/07/30 16:29:57 [debug] 14208#0: *1 pipe recv chain: -2 
2013/07/30 16:29:57 [debug] 14208#0: *1 pipe buf free s:0 t:1 f:0 000000001E61DBD0, pos 000000001E61DC5D, size: 2465 file: 0, size: 0 
2013/07/30 16:29:57 [debug] 14208#0: *1 pipe length: -1 
2013/07/30 16:29:57 [debug] 14208#0: *1 pipe write downstream: 1 
2013/07/30 16:29:57 [debug] 14208#0: *1 pipe write busy: 0 
2013/07/30 16:29:57 [debug] 14208#0: *1 pipe write: out:0000000000000000, f:0 
2013/07/30 16:29:57 [debug] 14208#0: *1 pipe read upstream: 0 
2013/07/30 16:29:57 [debug] 14208#0: *1 pipe buf free s:0 t:1 f:0 000000001E61DBD0, pos 000000001E61DC5D, size: 2465 file: 0, size: 0 
2013/07/30 16:29:57 [debug] 14208#0: *1 pipe length: -1 
2013/07/30 16:29:57 [debug] 14208#0: *1 event timer add: 11: 180000:1375223577332 
2013/07/30 16:29:57 [debug] 14208#0: *1 http upstream request: "/upload/html?" 
2013/07/30 16:29:57 [debug] 14208#0: *1 http upstream send request handler 
2013/07/30 16:29:57 [debug] 14208#0: timer delta: 6 
2013/07/30 16:29:57 [debug] 14208#0: posted events 0000000000000000 
2013/07/30 16:29:57 [debug] 14208#0: worker cycle 
2013/07/30 16:29:57 [debug] 14208#0: epoll timer: 179994 

我注意到在以上的日誌段「HTTP上游發送請求處理程序」,其中如在成功的情況下,我看到:

2013/07/30 16:29:44 [debug] 14208#0: *1 http upstream dummy handler 

任何想法「http上游發送請求處理程序」和「http上游虛擬處理程序」是什麼意思,以及它們表示什麼?

回答

12

您正在尋找的設置可能是client_max_body_size

語法:client_max_body_size size;
默認值:client_max_body_size 1m;
上下文:http,服務器,位置

設置客戶端請求主體的最大允許大小,在「內容長度」請求頭字段指定。如果請求中的大小超過配置的值,則413(請求實體太大)錯誤將返回給客戶端。請注意,瀏覽器無法正確顯示此錯誤。將大小設置爲0將禁用客戶端請求主體大小的檢查。

+1

我確實在「http」級別指定了client_max_body_size:client_max_body_size 1000M; client_body_buffer_size 256k; – kpdev

7

我有同樣的問題。邁克爾哈特爾的答案是正確的。在我的情況下,這是伎倆的設置:

在nginx中。conf添加:

http { 
    # at the END of this segment! 
    client_max_body_size 1000m; 
}