Nginx upload large file timeout solution
The situation is as follows: When using nginx as a proxy server, when uploading a large file (I test uploading a 50m file), it prompts that the upload is overtime or the file is too large.
The reason is that nginx has a limit on the size of uploaded files, and the default is 1M. In addition, if the uploaded file is large, the upload timeout period must be adjusted appropriately.
The solution is to add the following configuration under the nginx configuration file:
| 1 2 3 4 5 6 |
|
The meaning of each parameter:
client_max_body_size
Limit the size of the request body. If it exceeds the set size, a 413 error will be returned.
client_header_timeout
If the timeout time for reading the request header exceeds the set size, a 408 error will be returned.
client_body_timeout
If the timeout period for reading the request entity exceeds the set size, an error 413 will be returned.
proxy_connect_timeout
The http request cannot be processed by the container (tomcat, netty, etc.) immediately, and is placed in the pending pool of nginx waiting to be processed. This parameter is the maximum time to wait, the default is 60 seconds, the official recommendation is not to exceed 75 seconds.
proxy_read_timeout
After the http request is processed by the container (tomcat, netty, etc.), nginx will wait for the processing result, which is the response returned by the container. This parameter is the server response time, and the default is 60 seconds.
proxy_send_timeout
After the http request is processed by the server, the time it takes to send the data back to Nginx is 60 seconds by default.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
nginx.conf
In the process of using nginx and uploading files, it is usually necessary to set the nginx message size limit. Avoid 413 Request Entity Too Large.
So the strange problem was encountered by us. Please refer to the following for detailed configuration. Our problem is that no matter where the client_max_body_size is set, after nginx-s reload, it still keeps reporting 413. Reload has been tried many times, but it is always invalid. Finally decided to kill the process, restart, and it was finally done.
This shows that nginx reload is not necessarily easy to use. Sometimes, just to be on the safe side. Restart is more reliable. I don’t know if anyone else has encountered the same problem. I hope everyone has to help! ~~
The settings are as follows:
| Syntax: | client_max_body_size |
|---|---|
| Default: | |
| Context: | http, server, location |
Sets the maximum allowed size of the client request body, specified in the “Content-Length” request header field.
If the size in a request exceeds the configured value, the 413 (Request Entity Too Large) error is returned to the client.
Please be aware that browsers cannot correctly display this error.
Setting size to 0 disables checking of client request body size.
You can choose to set in http{ }: client_max_body_size 20m;
You can also choose to set in server{ }: client_max_body_size 20m;
You can also choose to set in location{ }: client_max_body_size 20m;
The difference between the three is: http{} controls all requests received by nginx. The message size limit is set in the server {} to control the size of the request message received by the server. Similarly, if it is configured in the location, the message size limit will only take effect for the requests that match the location routing rule.
http{
#Control the size of all request messages in global nginx
#client_max_body_size 20m;
server{
#Control the size of all request packets of the server
#client_max_body_size 20m;
location a {
}
location b{
#Control the size of the request message that satisfies the routing rule
#client_max_body_size 20m;
}
}
server {
}
}
Record a knowledge point: restart the nginx command, and execute the command in the /usr/sbin directory: ./nginx -s reload
If the restart fails, please refer to: https://blog.csdn.net/qq_16014497/article/details/80650905 (execute first sudo nginx -c /etc/nginx/nginx.conf, then execute nginx -s reload)