Talking about the magical slash in nginx reverse proxy

When configuring nginx reverse proxy, the slashes in location and proxy_pass will cause all kinds of troubles. Sometimes one more or less slash will cause completely different results, so the situation with or without slashes after location and proxy_pass is specially arranged and combined, and a complete test is carried out to find out the principle in order to improve the posture level.

0. Environmental information

Two nginx servers

Nginx A: 192.168.1.48

Nginx B: 192.168.1.56

one。 Testing 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 looking at the $request field in the log

two。 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 all dizzy when you see here? in fact, it is regular.

Now arrange these cases in a table, and the results indicate the requests received by nginx B.

Table 1

Case locationproxy_pass result 1/foo/ http://192.168.1.48//api2/foohttp://192.168.1.48///api3/foo/http://192.168.1.48/foo/api4/foohttp://192.168.1.48/foo/api

Table 2

Case locationproxy_pass result 5/foo/ http://192.168.1.48/bar//bar/api6/foohttp://192.168.1.48/bar//bar//api7/foo/http://192.168.1.48/bar/barapi8/foohttp://192.168.1.48/bar/bar/api

three。 Analysis

Original request path: unified as "/ foo/api" in this article

Location: the location column in the table above

Proxy_pass: the proxy_ pass column in the table above

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

Focus on the analysis of proxy_pass, which can be divided into three forms

Then, according to whether the string is received after 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. These two situations are described below.

When the string is not received after the ip:port of the proxy_pass, the nginx will transfer the original request path intact to the next station nginx, such as cases 3 and 4

When the ip:port of proxy_pass is followed by a string, nginx removes the location from the original request path, splices the remaining strings into proxy_pass to generate a new request path, and then transfers the new request path to the next station nginx (the above case is actually the same as this one, except that the removed string is an empty string)

Take the most puzzling example: case 7. 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 changed to "api", and 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 station is "/ barapi".

The ip:port of case 6:proxy_pass is followed by the string "/ bar/", so location: "/ foo" is removed from the original request path "/ foo/api" and changed to "/ 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.

Other cases can be analogous, and now that it is finally understood, there is no need to be confused.

The above is the whole content of this article, I hope it will be helpful to your study, and I also hope that you will support it.