Shulou(Shulou.com)06/01 Report--

This article will explain in detail how to deal with the "/" problem when proxy_pass forwards according to the path path in nginx. The editor thinks it is very practical, so I share it with you as a reference. I hope you can get something after reading this article.

When configuring proxy_pass in nginx, if you match the path by ^ ~, you should pay attention to the last / of the url after proxy_pass. When / is added, which is equivalent to the absolute root path, nginx will not delegate part of the matching path in the location; if there is no /, it will also give the matching part of the path to the agent.

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 configured above, if the requested url is http://servername/wangshibo/test.html, it will be proxied as http://js.test.com/test.html.

And if configured in this way,

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

Then 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 achieve /

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

Give the following example

1) the first configuration

[root@BJLX_16_202_V vhosts] # cat ssl-wangshibo.confupstream at {server 192.168.1.202 server 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 visiting https://www.wangshibo.com/attendance/ and http://192.168.1.202:8080/attendance are consistent.

2) the second configuration

[root@BJLX_16_202_V vhosts] # cat ssl-wangshibo.confupstream at {server 192.168.1.202 server 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/; / / must 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 visiting https://www.wangshibo.com and http://192.168.1.202:8080/attendance are consistent.

The requirements you want to achieve are configured as follows:

192.168.1.27 is the back-end real server,8080 port and the company's ehr personnel system port.

And because the system involves Wechat interface access, that is, http://ehr.wang.com/attendance and http://ehr.wang.com/app

Because it is an internal system and security considerations, it is required that:

1) Log in to ehr personnel system using private network, that is, log in to the company's VPN before http://192.168.1.27:8080, access

2) Log in to Wechat APIs http://ehr.wang.com/attendance and http://ehr.wang.com/app using the public network, even if you use the domain name after resolution.

3) access http://ehr.wang.com to force the jump to https://ehr.wang.com/attendance

[root@BJLX_4_21_P vhosts] # cat ehr.confserver {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.confupstream ehr {server 192.168.1.27 cat ehr.confserver 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;}}

Note:

Because the real server from the browser access (http) to the origin server goes through the Nginx reverse proxy layer (https)

The line proxy_set_header X-Forwarded-Proto https; needs to be commented out, otherwise the above configuration is invalid.

If there is no proxy layer in the middle, the reverse proxy of nginx is directly performed on the native real server (that is, the native nginx is reversed to port 8080 of the native), then this parameter is invalid (verified)

List and explanation of HTTP header domain (proxy_set_header)

The HTTP header domain is the header information in the request (request) and response (response) in the HTTP protocol, which is actually the operation parameter of the HTTP communication, telling the web server and browser how to handle this communication.

The HTTP header starts with the second line of the request or response message (the first line is the request line or the response line) and ends with two CR-LF character sets (CR: carriage return,\ rfield LF: newline character\ n)

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

Some http headers can have comments, such as user-agent,server,via. But these comments can 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, while other updated and extended headers must also be implemented by HTTP-based software. Of course, each software can also define its own header domain.

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 make their own rules, such as apache2.3

It is stipulated 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 (request) and its interpretation.

Standard request header--

Accept: the type of content (Content-types) that browsers (or other HTTP-based client programs) can receive, such as Accept: text/plain

Accept-Charset: the character set that the browser can recognize, such as Accept-Charset: utf-8

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

Accept-Language: the language received by the browser, that is, the language region in which the user is located, for example, Accept-Language: zh-CN in simplified Chinese

Authorization: in HTTP, the server can authenticate and protect some resources. If you want to access these resources, you need to provide a user name and password. This user name and password are attached to the Authorization header, and the format is the base64 encoding of the "username:password" string. For example, in Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==, basic refers to the use of basic authentication, and QWxhZGRpbjpvcGVuIHNlc2FtZQ== uses base64 decoding to be "Aladdin:open sesame".

Cache-Control: this instruction is available in both request and response to instruct the caching system (on the server or on the browser) how to handle caching, because this header domain is more important, especially when you want to use caching to improve performance, so I want to focus on it in the next blog post.

Connection: tell the server what connection method the user agent (usually the browser) wants to use. Values are keep-alive and close. Http1.1 defaults to keep-alive. Keep-alive means that the communication connection between the browser and the server will be saved continuously and will not be closed immediately, while close will be closed immediately after response. But one thing to note here is that we say that HTTP is stateless, which has nothing to do with whether it is keep-alive or not. don't think that keep-alive is an improvement on the stateless feature of HTTP.

Cookie: the browser sends a cookie when it sends a request to the server, or the server attaches a cookie to the browser. This is where the cookie is located. For example: Cookie:user=admin

Content-Length: the memory length of the request body of a request, in byte. The request body refers to the content after two CR-LF character groups after the end of the HTTP header, usually the form data submitted by POST. This Content-Length does not contain the data length of the request line and the HTTP header.

Content-MD5: the MD5 checksum of the request body that is encoded using base64. For example: Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQQ =

Content-Type: the mime type of the content in the request body. It is usually only used in requests for POST and PUT methods. 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 you need to use some special features of the server. (I'm not very clear about this.)

From: the email address of the user who sent this request. For example: From: user@example.com

Host: the domain name or IP address of the server. if it is not a universal port, it also contains the port number, for example: Host: www.some.com:182

If-Match: usually used in requests for updating server resources using the PUT method, that is, asking the server that the tag of the resource being requested is different from the tag of this If-Match. If the same, it proves that the resource on the server is still old and can now be updated. If it is different, it proves that the resource has been updated. There is no need to update now (otherwise it is possible to overwrite changes made by others).

If-Modified-Since: asks the server if the resource it is requesting has been modified since a certain time. If not, the server returns a status of 304to tell the browser to use its own local cache. If so, it returns 200and sends a new resource (of course, if the resource does not exist, 404 is returned. )

If-None-Match: the intention is similar to that of If-Modified-Since, but it's not determined by time, but by something called ETag. I would like to introduce etag in the next blog post.

If-Range: tell the server that if the resource has not changed (based on the Etag given later in If-Range), send some missing parts of the resource to the browser, and if the resource has been modified, resend the entire resource to the browser.

If-Unmodified-Since: ask the server if the resource being requested has not been modified since some point in time.

Max-Forwards: limits the number of times the request information can be passed forward in the proxy server or gateway.

Pragma: there seems to be 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 by http1.1, while Pragma:no-cache can be used in http1.0 and 1.1

Proxy-Authorization: the authentication information used when connecting to an agent is similar to the Authorization header. For example: Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Range: in the HTTP header, the word "Range" means "the order of data in the byte form of a resource, and take a certain piece of data". The Range header represents the data from a certain value to a certain value of the requested resource. For example, Range: bytes=500-999 represents the data of the requested resource from 500to 999byte. Segmented downloading and multi-threaded downloading of data is realized by using this.

Referer: refers to the address where the URL of the current request is referenced. For example, if you click a hyperlink to www.b.com in the www.a.com/index.html page, the Referer in the request for this www.b.com is www.a.com/index.html. Usually we see the picture hotlink protection is realized with this.

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

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

Via: used to record which agents or gateways a request went through before it was sent to the target server. For example, if a request starts from a browser (assuming using http/1.0), is sent to an internal agent named SomeProxy, then is forwarded to the public agent of www.somenet.com (using http/1.1), and finally forwarded to the target server www.someweb.com, then the via header received in someweb.com should be: via:1.0 someProxy 1.1 www.someweb.com (apache 1.1)

Warning: log some warnings.

This is the end of the article on "how to deal with the problem when proxy_pass forwards according to the path path in nginx". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.