This pit has been engaged for a long time, and now it is recorded.
1. First of all, it must be clear that the 504 error is a nginx configuration problem, so it is useful to debug other configurations such as PHP. In this way, the target has been reduced a lot.
2.Secondly, to clarify what this nginx does, there are generally two types:
a. Just forward the request proxy, we can see the word proxy_pass ip in the configuration
b. Forward the request to php-fpm via fastcgi, with fastcgi_pass ip:port in the configuration
3.Finally , for the above different classification symptomatic configuration:
Both are added as follows under the http block in the nginx configuration file:
a plus: proxy_read_timeout 3600s;
b plus: fastcgi_read_timeout 3600s ;
In fact, many online say that a situation needs to be added proxy_connect_timeout 3600s; proxy_send_timeout 3600s; configuration
b case to add fastcgi_connect_timeout 3600s; fastcgi_read_timeout 3600s; configuration
But in essence, the most important thing is the read_timeout parameter. The other two generally don't time out very much, and they can be matched or not.
Note: In some cases, there may be multiple layers of nginx on a request link, so there must be both cases a and b. The specific nginx is which case, and the corresponding nginx configuration authentication will be known.
After the above configuration, the nginx504 error can be solved, but if the xdebug appears after a period of time after the above problem is solved, it will automatically disconnect and jump out of the debugging problem. Because it is nginx+php-fpm mode, then this The problem can only be a php problem. This is the PHP script execution timeout limit. If you use the fpm mode, then just modify the php-fpm configuration and find that the request_terminate_timeout field is set to a larger value, or set to 0 to indicate permanent No timeout, the default value of fpm is never timeout. Then restart your pph-fpm to take effect the modified configuration.