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

In fact, I haven't touched nginx for a long time. Suddenly, a task came and I could only bite the bullet.

Let's start with the background:

Our service is deployed in the form of containers, and nginx does the reverse structure. When the user request arrives at the nginx server, it is determined whether the corresponding static file exists in the root directory of nginx configuration. If it does not exist, it will be forwarded.

Error_page 404 jump rule is configured in nginx. The expected effect is to jump to our custom 404 page when the requested resource/path does not exist, instead of the big and bold cold "404 Not found".

Specific configuration segments are as follows:

error_page 404 500/404.html; #Define display page with status code 404 500 location =/404.html { root /usr/share/nginx/html;#Location of this resource}

The initial idea is that location already has many processing rules that correctly match the resource path, and the lowest priority location / {rule X} means that the resource that fails to match is processed according to rule X.

Well, then, isn't it possible to return 404 directly?

It turned out to be okay, but... The correct page does not load, F12 enters debug mode, and many resource requests in the page are also 404. Embarrassed that this problem has not been considered, this idea is temporarily abandoned.

Now the problem is that the default 404 page file on the nginx server has been deleted, and careful observation, found that the more strange is that the following nginx version number information shows 1.13.0, and this server version is 1.12.2 ah!

Calm down. Calm down.

Well, it seems that the problem can be basically located, this time by nginx proxy backend cluster in one of the 404 page response, rather than as we imagined, nginx-server directly respond to custom 404 page.

Well, now that we've found the reason, let's see if there's any relevant way to stop it. After looking up all kinds of information, I finally found two related parameters, and fortunately these two parameters are off by default.

fastcgi_intercept_errors and proxy_intercept_errors

Here is the official introduction:

Syntax: fastcgi_intercept_errors on | off;Default: fastcgi_intercept_errors off;Context: http, server, locationDetermines whether FastCGI server responses with codes greater than or equal to 300 should be passed to a client or be intercepted and redirected to nginx for processing with the error_page directive.

Links: http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_intercept_errors

Syntax: proxy_intercept_errors on | off;Default: proxy_intercept_errors off;Context: http, server, locationDetermines whether proxied responses with codes greater than or equal to 300 should be passed to a client or be intercepted and redirected to nginx for processing with the error_page directive.

Links: nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_intercept_errors

What do you mean? When the response status code of the backend server is greater than or equal to 300, it is decided whether to send the response directly to the client or forward the response to nginx for processing by the error_page instruction.

When on, nginx intercepts the error status code explicitly specified by the error_page directive. If the response status code from the proxied server does not match the error_page directive, the response is sent to the client as usual.

After opening, check and reload the configuration file. Test again, success! Normal pages can also be accessed.

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.