The magic slash in the Nginx reverse proxy

The magic slash in the Nginx reverse proxy

In the Nginx reverse proxy configuration, the location and Proxy_pass in the slash will cause a variety of problems, and sometimes one or less a slash, will result in completely different results, so specifically the location and Proxy_ After pass there is no diagonal line in the case of a combination of a complete test, to find out the principle to improve posture level ~

0. Environmental information

Two Nginx servers

Nginx a:192.168.1.48

Nginx b:192.168.1.56

I. TEST methods

1. Configure different rules in Nginx A, then request Nginx A:http://192.168.1.48/foo/api
2. Observe the request received by Nginx B to view 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/;}nginx B收到的请求：/api

Case 2

Nginx a configuration:

location /foo/ {   proxy_pass http://192.168.1.56/;}nginx B收到的请求：//api

Case 3

Nginx a configuration:

location /foo/ {   proxy_pass http://192.168.1.56/;}nginx B收到的请求：/foo/api

Case 4

Nginx a configuration:

location /foo/ {   proxy_pass http://192.168.1.56/;}nginx B收到的请求：/foo/api

Case 5

Nginx a configuration:

location /foo/ {   proxy_pass http://192.168.1.56/bar/;}nginx B收到的请求：/bar/api

Case 6

Nginx a configuration:

location /foo {   proxy_pass http://192.168.1.56/bar/;}nginx B收到的请求：/bar//api

Case 7

Nginx a configuration:

location /foo/ {   proxy_pass http://192.168.1.56/bar;}nginx B收到的请求：/barapi

Case 8

Nginx a configuration:

location /foo {   proxy_pass http://192.168.1.56/bar;}nginx B收到的请求：/bar/api

See here is not all dizzy, in fact there is a regular

These cases are now sorted by table, which indicates that Nginx B received the request

Table I.

Location

Case		Proxy_pass	Results
1	/foo/	http://192.168.1.48/	/api
2	/foo	http://192.168.1.48/	Api
3	/foo/	http://192.168.1.48	/foo/api
4	/foo	http://192.168.1.48	/foo/api

Table II

Location

Case		Proxy_pass	Results
5	/foo/	http://192.168.1.48/bar/	/bar/api
6	/foo	http://192.168.1.48/bar/	/bar//api
7	/foo/	Http://192.168.1.48/bar	/barapi
8	/foo	Http://192.168.1.48/bar	/bar/api

Three. Parsing

Original request Path: This article is unified as "/foo/api"

Location: The location column in the table above

Proxy_pass: Proxy_pass column in the table above

New request path: Nginx string after processing the original request path

Focus on the proxy_pass analysis, can be divided into 3 kinds of forms

1. Http://ip:port
2. http://ip:port/
3. Http://ip:port/xxx

Then follow the Ip:port after the string is classified as 2 class, "/" is also a string, so 1 is classified as a class, 2, 3 is a class, the following two types of cases are described

When the string is not received after the Proxy_pass Ip:port, Nginx will transfer the original request path unchanged to the next station Nginx, such as cases 3 and 4

When the Proxy_pass Ip:port is followed by a string, Nginx will remove the location from the original request path, then stitch the remaining string into the Proxy_pass to generate a new request path, and then forward the new request path to the next Nginx (above a The situation is actually the same as this one, except that the string to be removed is empty string ~ ~)

One of the most puzzling examples: Case 7. Proxy_pass's Ip:port is followed by the string "/bar", so the location: "/foo/" from the original request path: "/foo/api" to the "API", and then splicing "API" to proxy_pass:http:// 192.168.1.48/bar became a new request URL: "Http://192.168.1.48/barapi", so the next station Nginx received the request is "/barapi".

The ip:port of the case 6:proxy_pass is followed by the string "/bar/", so location: "/foo" is removed from the original request path "/foo/api" to "/api", then "/api" is stitched to proxy_pass:http: 192.168.1.48/bar/became a new request path: "Http://192.168.1.48/bar//api", so the next station Nginx received the request is/BAR//API.

Other cases can be and so on, and now finally understand, no longer confused.