A brief discussion on the magical slash in nginx reverse proxy

When configuring nginx reverse proxy, the slashes in location and proxy_pass can cause various problems. Sometimes one more or one less slash will cause completely different results. Therefore, we specially arranged and combined the situations with and without slashes after location and proxy_pass, and conducted a complete test to find out the principle and improve our posture level~

0. Environmental Information

Two nginx servers

nginx A: 192.168.1.48

nginx B: 192.168.1.56

1. Test Method

Configure different rules in nginx A, and then request nginx A: http://192.168.1.48/foo/api

Observe the request received by nginx B by viewing the $request field in the log

2. Test process and results

Case 1

nginx A configuration:

location /foo/ {
  proxy_pass http://192.168.1.56/;
}

Request received by nginx B: /api

Case 2

nginx A configuration:

location /foo/ {
  proxy_pass http://192.168.1.56/;
}

Request received by nginx B: //api

Case 3

nginx A configuration:

location /foo/ {
  proxy_pass http://192.168.1.56/;
}

Request received by nginx B: /foo/api

Case 4

nginx A configuration:

location /foo/ {
  proxy_pass http://192.168.1.56/;
}

Request received by nginx B: /foo/api

Case 5

nginx A configuration:

location /foo/ {
  proxy_pass http://192.168.1.56/bar/;
}

Request received by nginx B: /bar/api

Case 6

nginx A configuration:

location /foo {
  proxy_pass http://192.168.1.56/bar/;
}

Request received by nginx B: /bar//api

Case 7

nginx A configuration:

location /foo/ {
  proxy_pass http://192.168.1.56/bar;
}

Request received by nginx B: /barapi

Case 8

nginx A configuration:

location /foo {
  proxy_pass http://192.168.1.56/bar;
}

Request received by nginx B: /bar/api

Are you dizzy after seeing this? Actually, there is a pattern.

Now arrange these cases in a table, and the result shows the request received by nginx B

Table 1

Table 2

3. Analysis

Original request path: This article uses the same name as "/foo/api"

location: The location column in the table above

proxy_pass: The proxy_pass column in the table above

New request path: the string after nginx processes the original request path

Focus on analyzing proxy_pass, which can be divided into 3 forms

Then, according to whether the string is followed by ip:port, it is classified into two categories. "/" is also a string, so 1 is classified into one category, and 2 and 3 are classified into one category. The following explains these two categories.

When the proxy_pass ip:port is not followed by a string, nginx will forward the original request path intact to the next nginx, as in cases 3 and 4.

When a string is added after the ip:port of proxy_pass, nginx will remove the location from the original request path, and then concatenate the remaining string to proxy_pass to generate a new request path, and then forward the new request path to the next station nginx (the above situation is actually the same as this one, except that the removed string is an empty string~~)

Let’s take the most confusing example: Case 7. The ip:port of proxy_pass is followed by the string "/bar", so the location: "/foo/" is removed from the original request path: "/foo/api" and becomes "api". Then "api" is concatenated to proxy_pass: http://192.168.1.48/bar to generate a new request url: "http://192.168.1.48/barapi", so the request received by nginx at the next stop is "/barapi".

Case 6: The ip:port of proxy_pass is followed by the string "/bar/", so location: "/foo" is removed from the original request path "/foo/api" and becomes "/api", and then "/api" is concatenated to proxy_pass: http://192.168.1.48/bar/ to generate a new request path: "http://192.168.1.48/bar//api", so the request received by nginx at the next stop is /bar//api.

The same can be applied to other cases. Now I finally understand it and I don’t have to be confused anymore.

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.