List some problems and troubleshooting methods found on the Internet related to the 502 Bad Gateway error. First, start with FastCGI configuration:
1. Check whether the FastCGI process has been started.
NGINX 502 error indicates that sock and port are not listened. First, check whether fastcgi is running.
2. Check the Fastcgi process running status.
In addition to the first case, fastcgi processes are insufficient, php execution takes a long time, or the php-cgi process is dead, which may also cause nginx 502 errors.
Run the following command to check whether the number of FastCGI processes is close to the value set in the configuration file. If the number of fastcgi processes is close to that set in the configuration file, the number of worker processes is too small.
The code is as follows: |
Copy code |
Netstat-anpo | grep "php-cgi" | wc-l
|
3. FastCGI execution time is too long
Increase the following parameter values based on actual conditions:
The code is as follows: |
Copy code |
Fastcgi_connect_timeout 300; Fastcgi_send_timeout 300; Fastcgi_read_timeout 300; |
4. The header is too large.
Like apache, nginx has front-end buffer restrictions. You can adjust the buffer parameters.
The code is as follows: |
Copy code |
Fastcgi_buffer_size 32 k; Fastcgi_buffers 8 32 k; |
If you are using nginx server load balancer Proxying, adjust
The code is as follows: |
Copy code |
Proxy_buffer_size 16 k; Proxy_buffers 4 16 k; |
5. https forwarding configuration error
Correct configuration method
The code is as follows: |
Copy code |
Server_name www.111cn.net; Location/myproj/repos { Set $ fixed_destination $ http_destination; If ($ http_destination ~ * ^ Https (. *) $) { Set $ fixed_destination http $1; } Proxy_set_header Host $ host; Proxy_set_header X-Real-IP $ remote_addr; Proxy_set_header Destination $ fixed_destination; Proxy_pass http: // subversion_hosts; } |
Of course, it depends on the type of FastCGI you use at the backend. I have used php-fpm and the traffic is about 0.4 million PV (dynamic page) on a single machine ), currently, it is basically not 502.
If the above method still cannot be solved, refer to the following article.
========================================================== Another article ================================================= =====
Therefore, if your server concurrency is very large, you can only increase the number of machines first, and then optimization will achieve better results as follows; but if your concurrency is not large, it will show 502, generally, it can be attributed to the configuration problem and the script timeout problem.
1. Insufficient number of php-fpm processes
Use netstat-napo | grep "php-fpm" | wc-l to check the number of fastcgi processes. If the number is close to the upper limit configured in conf, you need to increase the number of processes.
However, you cannot increase the number of php-fpm sub-processes to 100 or more based on the server memory.
2. Increase the number of files opened in the Linux kernel.
You can use these commands (must be a root account)
The code is as follows: |
Copy code |
Echo 'ulimit-HSn 65536 '>/etc/profile Echo 'ulimit-HSn 65536 '>/etc/rc. local Source/etc/profile |
3. The script execution time has timed out.
If the script does not return after a long wait for some reason, the new request cannot be processed, you can adjust the following configurations as appropriate.
Nginx. conf mainly includes the following:
The code is as follows: |
Copy code |
Fastcgi_connect_timeout 300; Fastcgi_send_timeout 300; Fastcgi_read_timeout 300; |
If the php-fpm.conf is as follows
The code is as follows: |
Copy code |
Request_terminate_timeout = 10 s |
4. Relatively small cache settings
Modify or add configuration to nginx. conf
The code is as follows: |
Copy code |
Proxy_buffer_size 64 k; Proxy_buffers 512 k; Proxy_busy_buffers_size 128 k; |
5. recv () failed (104: Connection reset by peer) while reading response header from upstream
Possible cause: network packet loss in the IDC or access to this domain name is prohibited by the hardware firewall in the IDC
But the most important thing is to set the timeout in the program. Do not use the request_terminate_timeout of php-fpm,
It is best to set it
The code is as follows: |
Copy code |
Request_terminate_timeout = 0; |
Because this parameter will directly kill the php process and restart the php process, the front-end nginx will return 104: Connection reset by peer. This process is very slow. The general feeling is that the website is very stuck.
May 01 10:50:58. 044162 [WARNING] [pool www] child 4074, script'/usr/local/nginx/html/quancha/sameip/detail. php 'execution timed out (15.129933 sec), terminating May 01 10:50:58. 045725 [WARNING] [pool www] child 4074 exited on signal 15 SIGTERM after 90.227060 seconds from start May 01 10:50:58. 046818 [NOTICE] [pool www] child 4082 started
The most important thing about one thousand-way 10 thousand is to control the timeout in the program. For functions such as gethostbyname, curl, and file_get_contents, you must set the timeout time.