Configuration solution for 414 errors and 504 errors in the Nginx server _nginx

414 Request-uri Too Large

#客户端请求头缓冲区大小, this buffer is used if the total length of the request header is greater than 128k,
#请求头总长度大于128k时使用large_client_header_buffers设置的缓存区
Client_header _buffer_size 128k;

#large_client_header_buffers instruction Parameter 4 is the number, 128k is the size, and the default is 8k. Apply for 4 128k.
large_client_header_buffers 4 128k;

The 414 request URI too large or bad request error is reported when the HTTP URI is too long or the request header is too large.

Possible causes

The value written in scenario 1.cookie is too large because the size of the other parameters in the header is generally fixed and only cookies may be written to larger data

Scenario 2 The request parameter is too long, such as publishing an article body, with UrlEncode, using get way to the background.

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, May 2013 13:40:02 GMT

When the request header is too large, when the large_client_header_buffer is exceeded,
Nginx may return "Request URI too Large" (414) or "bad-request" (400) error.

As in the previous example, the HTTP request header is composed of multiple lines,
where "get http://www.264.cn/HTTP/1.1" means request line

When the request line is longer than a buffer (128k) of Large_client_header_buffer, Nginx returns the "Request URI too Large" (414) error, which corresponds to scenario 2 above.

The longest row in the request is also less than Large_client_header_buffer, which returns a "Bad-request" (400) error, which corresponds to the scenario 1 above, when the longest line is not the one of the request lines greater than a buffer (128k).

Solution: Then you can increase the above two values.

Client_header_buffer_size 512k;
Large_client_header_buffers 4 512k;

504 Gateway Time-out
The site has been using Nginx to do proxy back-end Apache running PHP to provide services.

Apache often does not have a regular time to be unable to service loss of response, and then nginx appear "504 Gateway time-out"

Looking at the error log also does not see anything that is the Apache bug (in fact not, the following will say why).

Perhaps older people do not love tossing, willing to stay the same, using monitoring tools, each received the alarm after the restart of the Apache barely maintained.

Finally one day I am bored, is not handles the PHP, I do not use the Apache row, Rage uses the source installation php-fpm to move to the PHP-FPM to run the PHP.

Installing PHP is not troublesome, the use of source installation is still very smooth, the only thing to do is to set up the PHP worker worker process log output PHP error log.

When everything is ready, change the original proxy_pass to Fastcgipass.

Upstream apachephp {
  server www.quancha.cn:8080; #Apache1
} ...

.
Proxy_pass http://apachephp;

Replace into

Upstream PHP {
    server 127.0.0.1:9000;
}

...
Fastcgi_pass PHP;

You can move Apache running PHP to PHP-FPM to run.

I thought this would be a peace of the day, and the migration is really no problem, but if you don't analyze the root cause of the problem.

The problem will come to the door, the next day Nginx also reported 504 of the gateway timeout.

This time there is no Apache, Apache has finally cleared the relationship.

That should still be on nginx and PHP-FPM, check out the Nginx error log, you can see

[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 "

See here basically ruled out nginx suspicion, Nginx is waiting for PHP processing "get/kd/open.php?company=chinapost&number=pa24977020344 http/1.1" timeout out.

Restart PHP-FPM immediately, the problem is gone, the website can be accessed.

Visit the page again, still no response, but at the same time access to other pages normal, the page refresh a few times, the entire site is bad Gateway timeout.

The problem is narrowed down to the PHP script.

Netstat-napo |grep "PHP5-FPM" | Wc-l

To view the PHP process has reached the upper limit of 10 in the configuration file, there is a feeling that everyone has been open.php this script jammed.

What is this script for? This script is to collect The courier information, which used the Php_curl.

PHP script will force out if the execution time exceeds the configuration item in php.ini max_execution_time not result.

Check out the php.ini max_execution_time is really good, the value is 30.

Universal Google put in use, after the continuous Google to get the following words

The Set_time_limit () function and the configuration instruction Max_execution_time only affect the time that the script itself executes. Any execution of a script that occurs in a system call, such as a systems (), a stream operation, a database operation, and so on, is not included when the script is run.

This means that if the script performs other operations in the time that is not counted in the script run time, if you do not set the timeout, then PHP will wait for the result of the call.

View open.php source file a look, sure enough, did not set the Curl timeout time.

Add the following two lines and refresh again after the problem is resolved.

curl_setopt ($ch, Curlopt_connecttimeout, 10); Timeout on connect
curl_setopt ($ch, Curlopt_timeout, ten);//timeout on response

Of course, in addition to this method, PHP-FPM also provides parameters for us to force the killing of long, sterile processes, except that the parameter is not turned on by default.

A PHP-FPM configuration file can be set up with a parameter request_terminate_timeout, a timeout to request termination, and kill if the request executes more than this time.

It also has a parameter request_slowlog_timeout, which is used to record the slow request log.

command line to run PHP, you can use this code

$real _execution_time_limit = 60; Time limit

if (pcntl_fork ())
{
//Some long code which should is
//terminated after $real _execution_tim E_limit seconds passed if it isn't
//finished by this time
}
else {sleep
($real _execution_time_ limit);
Posix_kill (Posix_getppid (), SIGKILL);
}