Shulou(Shulou.com)06/02 Report--

The purpose of this article is to share with you what to do when requesting native Host under Nginx. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

Phenomenon

A Discuzied X3.4 forum is installed on this machine, which logs in as a unified user using UCenter. On its application management page, the communication is always prompted as "connecting":

Reason

With regard to this problem, the vast majority of people on the Internet say that there is a problem with the nginx server on Windows. It is suggested to change it to Apache. I changed it to Apache, and it is true that the problem has been solved, but I still think that nginx will not have this kind of problem. There must be a solution.

After further searching, we found that a 499 error was reported in the nginx log. It is said on the Internet that the reason for the 499 error is that the client took the initiative to disconnect from the server. However, looking at the ucenter code, it seems that there is no disconnection operation. Instead, look at the time reported in the log and find some clues:

127.0.0.1-[18/Jul/2018:22:35:48 + 0800] "GET / uc_server/admin.php?m=app&a=ls& …

127.0.0.1-[18/Jul/2018:22:36:19 + 0800] "GET / api/uc.php?code=434eRMR%2FD%2FtjZ357V3sA9RLPqp0rpGfi7ryntpyVEEYay3xgen8Oqk9ETjgEXNbyEbKItHYPZqs HTTP/1.0" 499...

127.0.0.1-[18/Jul/2018:22:36:19 + 0800] "GET / uc_server/admin.php?m=app&a=ping&inajax=1&url= …

The first line of log is the link to the ucenter application management center page, where ucenter sends a communication authentication request to the local Discuz server (line 3 log), and the second line of log is the communication authentication request received by the Discuz server.

If you take a closer look at the time of these three logs, we find that the interval between item 2, 3 and item 1 is about 29 seconds. We know that the default timeout time of PHP is 30 seconds, including a little error, 29 seconds is about the same. Therefore, it can be assumed that this 499 error is due to the fact that the ucenter server initiated a ping request (line 3 log) and never received a return value, resulting in a timeout disconnection, resulting in a 499 error on the discuz server.

The whole process is shown below:

Knowing that it was a 499 error, they looked for how to solve the 499 problem, and most of them proposed to add the following configuration to the nginx server:

Proxy_ignore_client_abort on

Fastcgi_ignore_client_abort on

The above configuration has been added to the configuration item of Discuz:

Location ~\ .php$ {

Root C:/PHPackage/workspace/github/DiscuzX/bbs

Fastcgi_pass 127.0.0.1:9090

Fastcgi_index index.php

Fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name

Include fastcgi_params

Proxy_ignore_client_abort on

Fastcgi_ignore_client_abort on

}

After running the server, it is found that the 499 problem is gone, but the communication problem is still not solved, but the log is changed to the following:

127.0.0.1-[18/Jul/2018:22:35:48 + 0800] "GET / uc_server/admin.php?m=app&a=ls& …

127.0.0.1-[18/Jul/2018:22:36:19 + 0800] "GET / api/uc.php?code=434eRMR%2FD%2FtjZ357V3sA9RLPqp0rpGfi7ryntpyVEEYay3xgen8Oqk9ETjgEXNbyEbKItHYPZqs HTTP/1.0" 200...

127.0.0.1-[18/Jul/2018:22:36:19 + 0800] "GET / uc_server/admin.php?m=app&a=ping&inajax=1&url= …

The configuration has taken effect, but there is a gross use, ah, communication is still not successful. There is still a difference of about 30 seconds between the first log and the following two logs. Looking back to carefully analyze the above two configuration items, we should ask the nginx server to ignore the error caused by the disconnection of the client. Note that the server only ignores this error, that is, when the ucenter request times out and disconnects, the discuz server ignores the error and returns 2000.However, ucenter has actually been disconnected and cannot receive the return value of discuz, so the communication actually fails.

However, after a further analysis of the above process, from the relationship between nginx and php, it is found that the whole request processing is as follows:

After receiving the request, nginx found that the PHP code needed to be executed, so it transferred the request to the PHP-CGI process, which found the PHP code and executed it. But in the PHP code, it sent a HTTP request to another server on this machine again. After receiving the request, nginx found that it also needed to execute the PHP code, so it transferred the request back to the PHP-CGI process, but only one PHP-CGI process was opened in the system. The later PHP code cannot be executed until the above execution is complete, while the subsequent PHP code is generated by the above code request, so it is blocked.

1.1.3 Resolution

At this point, the solution is very clear. Since one PHP-CGI thread cannot handle it, add one more thread. Modify the batch code to start the nginx server as follows. Just modify one number, see the red font section:

@ echo off

Invalid under REM Windows

REM set PHP_FCGI_CHILDREN=5

The maximum number of requests processed by REM per process, or set to the Windows environment variable

Set PHP_FCGI_MAX_REQUESTS=1000

Echo Starting PHP FastCGI...

Rem RunHiddenConsole C:/PHPackage/PHP/php-cgi.exe-b 127.0.0.1 9090-c C:/PHPackage/PHP/php.ini

RunHiddenConsole xxfpm "C:/PHPackage/PHP/php-cgi.exe-c C:/PHPackage/PHP/php.ini"-n 2-I 127.0.0.1-p 9090

Echo Starting nginx...

RunHiddenConsole C:/PHPackage/nginx-1.15.1/nginx.exe-p C:/PHPackage/nginx-1.15.1

The number used to be 1, but now it's changed to 2. Restart the server and look at the task manager. Indeed, there are two PHP-CGI processes:

Go back to the application management page of ucenter and refresh it. The result is as follows:

What's going on? We have been tossing about for a long time, but from "connecting" to "communication failure", the problem has not been solved!

However, the tracking code can verify that the problem of 499 has indeed been completely solved, and why it is still a "communication failure" is another question.

Thank you for reading! This is the end of this article on "what to do when requesting local Host under Nginx?". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.