Detailed explanation of the murder caused by a / slash in Nginx proxy_pass

background

An nginx server module needs to proxy to two servers, so different paths of location are used to distinguish and forward to different servers.

This is what it was written at the beginning

location / {
   proxy_pass http://server1/;
}

location /index {
   proxy_pass http://server2/;
}

But I forgot that there is a service path /indexNew on server1, so it was proxied to server1, resulting in a 404 problem. Then I urgently modified the configuration as follows:

location /indexNew {
   proxy_pass http://server1/;
}

location / {
   proxy_pass http://server1/;
}

location /index {
   proxy_pass http://server2/;
}

Problem phenomenon

As a result, the request reaches server1, but the error message is POST not supported.

{
	"status": 500,
	"message": "http://172.28.72.117/-Request method 'POST' not supported",
	"result": {}
}

This was the error returned by the application at that time. I checked nginx and there was no error either. It was very strange. I saw in the code that /indexNew was indeed the POST method, so why did it report an error saying it was not supported?

First, here is the matching order of various location writing methods in nginx:

analyze

There is no error in the nginx log, so try to capture the packet from nginx to the application

Capture packets using the tcpdump command

tcpdump -w dataAll_normal.pcap -i eth0 -s0 port 8888

Similar to the above command to capture the packet, and then through wireshark, it is found that no http traffic packets related to /indexNew are found at all.

Try to modify the location as follows

location /indexNew {
   proxy_pass http://server1;
}

location / {
   proxy_pass http://server1/;
}

location /index {
   proxy_pass http://server2/;
}

The only difference is that the last slash / in proxy_pass of /indexNew is removed. Continue to capture packets and find that the /indexNew packet can be searched

This indicates that the modification is correct.

Continue to change the error back and try to capture the package, but still can't search for the /indexNew package, then remote debug the application through IDE

I found that there was no /indexNew in the URL of the application, so of course I couldn’t find it in the wireshark package. . .

This is because when nginx forwards the application, the access path is only / .

The interface with the request path / in the project is indeed the GET method

Take a closer look at the syntax of proxy_pass in location. It is indeed like this. There is a / at the end of proxy_pass, which will remove the path in the matching location and intercept the subsequent URL PATH for forwarding.

Therefore, we must pay attention to the meaning of the last / in proxy_pass and use it with caution. It will change the path request information instead of 100% information forwarding.

This is the end of this article about the bloody case caused by a / slash in Nginx proxy_pass. For more related Nginx proxy_pass slash content, please search 123WORDPRESS.COM's previous articles or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!