Nginx configuration reverse proxy or redirection 400 problem handling records, nginx400

Nginx configuration reverse proxy or redirection 400 problem handling records, nginx400

After lunch break, my colleague said that the 400 Bad Request Header Or Cookie Too Large prompt appeared on the test site access interface. I thought it was a problem with the test server, but it had little impact, however, I also rushed to the server for testing and viewing, opened the nginx and ugwsi logs and configurations, and found that the backend service logs were normal, the access logs of the test site are more than 7 hundred MB (only two or three days without several accesses, and a few MB is normal ), direct access to the back-end service interface in the browser is normal (our server software architecture is a microservice architecture. After many modules are split, they are deployed separately. The front-end is a pure HTML site, when AJAX is used to access various backend services, the nginx configuration of the front-end site is used as a reverse proxy to access other backend services, in this way, there will be no cross-origin and the need to handle multiple subdomain names-that is, when accessing different services, you only need to use the current domain name, in this way, front-end developers do not need to know how many services are mounted on the backend to access the corresponding domain name ). Access to other sites on this server can be normally accessed, and the html page of the problematic site can also be opened ...... during the test, it is found that the access log is increased by more than 30 mb every time the problematic interface is accessed, and the volume of nginx logs is increased several times ......

Because the logs are large, you can only use tail-n 5000 xxx_access.log> xxx. log captures the latest log records and downloads them. When you open the log, you can see that one access at a time produces more than 2000 repeated loop access records, while the $ http_x_forwarded_for part at the end of the log, the same IP string from many to few is regularly stored, that is, the last one has an IP string (real IP ), the second to last has two IP strings (real IP address + local server IP address), the third to last has three IP strings (real IP address + local IP address of two servers), and so on.

Baidu uses "400 Bad Request Header Or Cookie Too Large" to find out that "nginx 400 Bad request is caused by a Large request header, and the request is Too Large, it is usually caused by a large value written in the cookie. In nginx. in conf, increase the client_header_buffer_size and large_client_header_buffers values to solve the problem. "At first glance, we can see that this is definitely not my solution to this situation, this is because you do not know why the endless loop writes the IP address string to the request header and returns 400 until the cache burst. If you set the cache to a greater value, it will only increase the log speed. From the analysis, it should be a problem with nginx.

There is no way to open the nginx configuration file analysis, the configuration file of the problematic site, for example, and no problems found

Start nginx. conf for further research and find several more lines of code

proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

This is used to pass the IP address of the currently accessed user to the backend server. After deleting the IP addresses and restarting the nginx server, we tested the IP address and found that the access was normal... o my god, put it back, restart, access, mount, remove, restart, access, normal ...... after several retries, I finally confirmed that it was caused by the sudden addition of several lines of code. (I asked my colleague later to know that he added it to the server)

Is it true that it cannot be used? I remember that I used it normally before. Try to access the pre-production environment interface. Open the nginx configuration in the pre-production environment. The package contains the three lines of code, as shown in figure

After comprehensive comparison, we found that the nginx configuration used in the production environment is a domain name, while the pre-production environment uses an IP address + port. In addition, there is no difference. The redirection method and reverse code method are used for testing, the results are the same. The configuration of port_in_redirect and server_name_in_redirect cannot be solved.

In a comprehensive analysis, if nginx directly uses the domain name and needs to submit the IP address currently accessed to the backend when using proxy_pass for redirection, The nginx bug will cause an endless loop, I wonder if you have ever encountered this situation.

# Reverse proxy
# Normal upstream xxx {server 127.0.0.1: 23456;} upstream yyy {server 127.0.0.1: 123455;} # upstream xxx1 {server xx.xxx.com;} upstream yyy2 {server yyy.xxx.com ;}

# Use jump mode # normal proxy_pass http: // 127.0.0.1: 23456; # proxy_pass http://xx.xxx.com configuration exception;

 

 

Copyright:

This article is original and published by AllEmpty in the blog Park. Copyright is jointly owned by the blog Park. You are welcome to reprint this article. You must keep this statement without your consent and provide the original article link clearly on the article page,Otherwise, the right to pursue legal liability is reserved.. If you have any questions, you can use1654937@qq.comThank you very much for contacting me.

Publish the content of this series,MasterYesIt is to learn and make progress together with everyone. If you are interested, you can add Q group: 327360708. Let's discuss it together.

For more information, please refer to blog: http://www.cnblogs.com/EmptyFS/