-
504 Gateway Timeout
upstream timed out (110: Connection timed out) while reading response header from upstream
Means NGINX timed out reading the HTTP response header from upstream. This is controlled by:
fastcgi_read_timeout 60s;
-
502 Bad Gateway
recv() failed (104: Connection reset by peer) while reading response header from upstream readv() failed (104: Connection reset by peer) while reading upstream
Means PHP-FPM reset the connection while NGINX was trying to read the HTTP response header. It is not NGINX's fault.
This could happen due to either being killed, meeting a fatal error (possibly from extensions), hitting the memory limit, or the execution time limit inside PHP.
You can tune the parameters inside PHP-FPM and the php.ini and change these limits and see if anything works. For PHP-FPM see:
process_control_timeout = 0 request_terminate_timeout = 0 php_admin_value[memory_limit] = 128M listen.backlog = 65535 rlimit_files = 4096
For php.ini see:
max_execution_time = 80 max_input_time = 60 memory_limit = 128M default_socket_timeout = 60
It may not be your script per se, the worker might have just crashed due to PHP memory leaks, and you may need PHP-FPM to restart the worker, or kill zombie workers.
Also see: http://stackoverflow.com/questions/1434451/what-does-connection-reset-by-peer-mean
-
-
Save glavk/7ff39b755660dd8abde85a682af8a795 to your computer and use it in GitHub Desktop.
NGINX: Common FastCGI Errors involving PHP-FPM
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment