Detailed explanation of the "/" problem when proxy_pass forwards according to the path path

When configuring proxy_pass in nginx, if you match the path according to ^~, pay attention to the last / in the URL after proxy_pass. When / is added, it is equivalent to the absolute root path, and nginx will not proxy the matching path part in location; if there is no /, the matching path part will also be proxied.

For example, the following settings:

location ^~ /wangshibo/
{
proxy_cache js_cache;
proxy_set_header Host js.test.com;
proxy_pass http://js.test.com/;
}

As shown in the above configuration, if the requested URL is http://servername/wangshibo/test.html, it will be proxied to http://js.test.com/test.html

If you configure it like this

location ^~ /wangshibo/
{
proxy_cache js_cache;
proxy_set_header Host js.test.com;
proxy_pass http://js.test.com;
}

The requested URL is http://servername/wangshibo/test.html and will be proxied to http://js.test.com/wangshibo/test.html

Of course, you can use the following rewrite to implement the function of /

location ^~ /wangshibo/
{
proxy_cache js_cache;
proxy_set_header Host js.test.com;
rewrite /wangshibo/(.+)$ /$1 break;
proxy_pass http://js.test.com;
}

Here is an example

1) The first configuration

[root@BJLX_16_202_V vhosts]# cat ssl-wangshibo.conf
upstream at {
  server 192.168.1.202:8080 max_fails=3 fail_timeout=30s;
}
  
server {
  listen 443;
  server_name www.wangshibo.com;
  ssl on;
  
  ### SSL log files ###
  access_log logs/wangshibo_access.log;
  error_log logs/wangshibo_error.log;
  
### SSL cert files ###
  ssl_certificate ssl/wang.cer;  
  ssl_certificate_key ssl/wang.key;
  
  location /attendance/ {
  proxy_pass http://at; //No need to add "/"          
  proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto https;
  proxy_redirect off;
    }
  
}

The results of accessing https://www.wangshibo.com/attendance/ and http://192.168.1.202:8080/attendance are consistent.

2) Second configuration

[root@BJLX_16_202_V vhosts]# cat ssl-wangshibo.conf
upstream at {
  server 192.168.1.202:8080 max_fails=3 fail_timeout=30s;
}
  
server {
  listen 443;
  server_name www.wangshibo.com;
  ssl on;
  
  ### SSL log files ###
  access_log logs/wangshibo_access.log;
  error_log logs/wangshibo_error.log;
  
### SSL cert files ###
  ssl_certificate ssl/wang.cer;  
  ssl_certificate_key ssl/wang.key;
  
  location / {
  proxy_pass http://at/attendance/; //Be sure to add "/"            
  proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto https;
  proxy_redirect off;
    }  
}

The results of accessing https://www.wangshibo.com and http://192.168.1.202:8080/attendance are consistent.

The following configuration is what we want to achieve:

192.168.1.27 is the real server at the backend, and port 8080 is the company's EHR personnel system port.

Since the system involves WeChat interface access, namely http://ehr.wang.com/attendance and http://ehr.wang.com/app

Since it is an internal system, for security reasons, the following requirements are required:

1) When logging into the EHR personnel system, you are required to use the intranet login, that is, http://192.168.1.27:8080. You must log in to the company VPN before accessing
2) Log in to the WeChat interface http://ehr.wang.com/attendance and http://ehr.wang.com/app using the external network, that is, use the resolved domain name to log in.
3) Visit http://ehr.wang.com and force a redirect to https://ehr.wang.com/attendance

[root@BJLX_4_21_P vhosts]# cat ehr.conf
server {
  listen 80;
  server_name ehr.wang.com;
  
  access_log logs/ehr_access.log;
  error_log logs/ehr_error.log;
 
  return 301 https://$server_name$request_uri;   
}
 
[root@BJLX_4_21_P vhosts]# cat ssl-ehr.conf
upstream ehr {
  server 192.168.1.27:8080 max_fails=3 fail_timeout=30s;
}
 
server {
  listen 443;
  server_name ehr.wang.com;
  ssl on;
 
  ### SSL log files ###
  access_log logs/ehr_access.log;
  error_log logs/ehr_error.log;
 
### SSL cert files ###
  ssl_certificate ssl/wang.cer;   
  ssl_certificate_key ssl/wang.key; 
  #ssl_session_timeout 5m;
 
  location / {
    return 301 https://ehr.wang.com/attendance;
  }
 
  location /attendance/ {
  proxy_pass http://ehr;
  proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # proxy_set_header X-Forwarded-Proto https;
  #proxy_set_header X-Forwarded-Proto https;
  proxy_redirect off;
  }
 
  location /app/ {
  proxy_pass http://ehr;
  proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # proxy_set_header X-Forwarded-Proto https;
  #proxy_set_header X-Forwarded-Proto https;
  proxy_redirect off;
  }
 }

Notice:

Since the access from the browser (http) to the real server of the origin station has to go through the Nginx reverse proxy layer (https)

You need to comment out the line proxy_set_header X-Forwarded-Proto https;, otherwise the above configuration will be invalid.

If there is no proxy layer in the middle, and nginx is directly reverse-proxyed on the real server (that is, the local nginx is reverse-proxyed to port 8080 of the local server), then this parameter is invalid (it has been verified)

HTTP header fields (proxy_set_header) list and explanation

The HTTP header field is the header information in the request and response in the HTTP protocol. In fact, it is the operating parameter of HTTP communication, telling the web server and browser how to handle the communication.

The HTTP header starts from the second line of a request or response message (the first line is the request line or response line) and ends with two CR-LF character groups (CR: carriage return, \r, LF: line feed \n).

Each HTTP header is in string form, with key-value pairs separated by colons, and multiple HTTP headers are separated by CR-LF character groups.

Some http headers can have comments, such as user-agent, server, via. However, these comments will be ignored by the server or browser. The IETF organization has defined some core HTTP headers in the RFC2616 specification.
These HTTP headers must be implemented by every HTTP-based software, and some other updated and extended header fields must also be implemented by HTTP-based software. Of course, each software can also define its own header field.

On the other hand, the RFC2616 specification does not limit the length of each HTTP header, or the number of HTTP headers, but for performance and security reasons, most servers will make their own regulations, such as Apache 2.3
It stipulates that each HTTP header cannot exceed 8190 bytes, and each request cannot exceed 100 HTTP headers.

Let's take a look at the various HTTP headers that may be included when sending a request and their explanations.

Standard request headers --

Accept: The content types that the browser (or other HTTP-based client program) can accept, such as Accept: text/plain

Accept-Charset: The character set that the browser can recognize, for example, Accept-Charset: utf-8

Accept-Encoding: The encoding method that the browser can handle. Note that the encoding method here is different from the character set. The encoding method here usually refers to gzip, deflate, etc. For example, Accept-Encoding: gzip, deflate

Accept-Language: The language accepted by the browser, which is actually the language region of the user. For example, Simplified Chinese is Accept-Language: zh-CN

Authorization: In HTTP, the server can authenticate and protect some resources. If you want to access these resources, you must provide a username and password. The username and password are included in the Authorization header. The format is the base64 encoding of the "username:password" string. For example: Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==, basic means using the basic authentication method, QWxhZGRpbjpvcGVuIHNlc2FtZQ== decoded using base64 is "Aladdin:open sesame"

Cache-Control: This directive is present in both the request and the response, and is used to instruct the cache system (on the server or the browser) on how to handle the cache. Because this header field is quite important, especially when you want to use caching to improve performance, and there is a lot of content, I would like to mainly introduce it in the next blog post.

Connection: Tells the server what connection method the user agent (usually a browser) wants to use. The values ​​are keep-alive and close. The default setting for http1.1 is keep-alive. Keep-alive means that the communication connection between the browser and the server will be continuously saved and will not be closed immediately, while close will be closed immediately after the response. But one thing to note here is that when we say HTTP is stateless, it has nothing to do with whether keep-alive is used. Don't think that keep-alive is an improvement on the stateless feature of HTTP.

Cookie: When a browser sends a request to a server, or when a server attaches a cookie to a browser, the cookie is placed here. For example: Cookie:user=admin

Content-Length: The memory length of the request body of a request, in bytes. The request body refers to the content after the two CR-LF character groups after the HTTP header. Common content includes form data submitted by POST. The Content-Length does not include the data length of the request line and HTTP header.

Content-MD5: The MD5 checksum of the request body encoded using base64. For example: Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==

Content-Type: The mime type of the content in the request body. Usually only used in POST and PUT method requests. For example: Content-Type: application/x-www-form-urlencoded

Date: The GMT time when the request was sent. For example: Date: Tue, 15 Nov 1994 08:12:31 GMT

Expect: Indicates that some special functions of the server need to be used. (I am not very clear about this)

From: The email address of the user sending this request. For example: From: [email protected]

Host: The domain name or IP address of the server. If it is not a common port, it also includes the port number, for example: Host: www.some.com:182

If-Match: Usually used in requests that use the PUT method to update server resources. It means asking the server whether the tag of the resource being requested is different from the tag of this If-Match. If they are the same, it proves that the resource on the server is still old and can be updated now. If they are different, it proves that the resource has been updated and does not need to be updated again (otherwise it may overwrite the changes made by others).

If-Modified-Since: Asks the server whether the resource being requested has been modified since a certain time. If not, the server returns a 304 status to tell the browser to use the browser's own local cache. If it has been modified, it returns a 200 and sends the new resource (of course, if the resource does not exist, it returns a 404.)

If-None-Match: It has a similar purpose to If-Modified-Since, but it is not determined based on time, but based on something called ETag. I would like to introduce etag in the next blog.

If-Range: tells the server that if the resource has not been changed (based on the Etag given after If-Range), it will send the missing parts of the resource to the browser. If the resource has been modified, it will resend a copy of the entire resource to the browser.

If-Unmodified-Since: Asks the server whether the resource currently being requested has not been modified since a certain time.

Max-Forwards: Limits the number of times request information is passed forward in the proxy server or gateway.

Pragma: It seems that there is only one value, which is: no-cache. Pragma:no-cache is the same as cache-control:no-cache, except that cache-control:no-cache is specifically specified in http1.1, while Pragma:no-cache can be used in http1.0 and 1.1

Proxy-Authorization: Authentication information used when connecting to a proxy, similar to the Authorization header. For example: Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Range: In the HTTP header, the word "Range" means "the sequential arrangement of the byte-format data of the resource, and taking a certain section of the data." The Range header indicates the data from a certain value to a certain value of the requested resource. For example, Range: bytes=500-999 indicates the data from 500 to 999 bytes of the requested resource. The segmented downloading and multi-threaded downloading of data are achieved by using this.

Referer: refers to the address from which the currently requested URL is referenced. For example, if you click a hyperlink pointing to www.b.com on the www.a.com/index.html page, then the Referer in the request for www.b.com is www.a.com/index.html. The image hotlink protection we usually see is implemented in this way.

Upgrade: Request the server to upgrade to another protocol, for example: Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

User-Agent: Usually the user's browser related information. For example: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0

Via: Used to record which proxies or gateways a request passes through before being sent to the target server. For example, a request originates from a browser (assuming http/1.0 is used), is sent to an internal proxy named SomeProxy, is then forwarded to a public proxy named www.somenet.com (using http/1.1), and is finally forwarded to the target server www.someweb.com. The via header received in someweb.com should be: via:1.0 someProxy 1.1 www.someweb.com (apache 1.1)

Warning: Record some warning information.

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.