A. The simplest reverse proxy configuration
Under the HTTP node, use upstream to configure the service address and use the server's location to configure the agent mappings.
Upstream My_Server {
server 10.0.0.2:8080;
keepalive;
}
server {
listen ;
server_name 10.0.0.1;
Client_max_body_size 1024M;
location/my/{
Proxy_pass http://my_server/;
Proxy_set_header Host $host: $server _port
}
}
Through this configuration, requests to access the Nginx address http://10.0.0.1:80/my are forwarded to the My_Server service address http://10.0.0.2:8080/.
It should be noted that if you follow the following configuration:
Upstream My_Server {
server 10.0.0.2:8080;
keepalive;
}
server {
listen ;
server_name 10.0.0.1;
Client_max_body_size 1024M;
location/my/{
Proxy_pass http://my_server;
Proxy_set_header Host $host: $server _port
}
}
The request to access the Nginx address http://10.0.0.1:80/my is then forwarded to the My_Server service address http://10.0.0.2:8080/my. This is because if the path to the URL is not included in the Proxy_pass parameter, the path identified by the location pattern will be an absolute path.
Two. REDIRECT Message agent
Even if the Nginx agent is configured, when the service returns a redirected message (HTTP code 301 or 302), the redirected destination URL is placed in the Location field of the header of the HTTP response message. When the user's browser receives the redirected message, it resolves the field and makes a jump. At this point the new request message will be sent directly to the service address, not the Nginx address. In order for Nginx to intercept such requests, the location information of the redirected message must be modified.
location/my/{
Proxy_pass http://my_server;
Proxy_set_header Host $host: $server _port;
Proxy_redirect//my/;
}
Using Proxy_redirect, you can modify the location field of the redirected message, in which case the URL proxy under all the root paths is returned to the user under the Nginx/my/path. For example, the location original value of the redirected message returned by the service is/login, then after the Nginx proxy, the Location field of the message received by the user is/my/login. At this point, the browser will jump to Nginx's/my/login address for access.
It is important to note that the location field of the redirected message returned by the service sometimes fills in the absolute path (the ip/domain name and the port that contains the service), and sometimes it fills in the relative path, which needs to be screened according to the actual situation.
location/my/{
Proxy_pass http://my_server;
Proxy_set_header Host $host: $server _port;
Proxy_redirect http://my_server/http://$host: $server _port/my/;
}
The above configuration is to proxy all paths under the root path of the My_Server service to the/my/path of the Nginx address. The http://host:h o s t:server_port prefix can be omitted when the Nginx is configured with only one server.
Three. Message Data replacement
Using the Nginx Agent (Dan) Force (SUI) is the case that the HTTP response message is written in the service address or Web absolute path. It is rare to write dead service addresses, but there are occasional instances. The hardest thing is to write a dead web absolute path, especially if the absolute path does not have a public prefix. For example:
A typical Web page will contain the following similar paths:
/public: For static page resources, such as JS script/public/js, style sheet/public/css, picture/public/img/static
: and/public similar
/API: for the Background Service API interface
/login: For logon authentication
For such a service, the possible proxy configuration is as follows:
location/my/{
Proxy_pass http://my_server/;
Proxy_set_header Host $host: $server _port;
Proxy_redirect//my/;
}
location/login/{
Proxy_pass http://my_server/public;
Proxy_set_header Host $host: $server _port;
}
location/public/{
Proxy_pass http://my_server/public;
Proxy_set_header Host $host: $server _port;
}
location/api/{
Proxy_pass http://my_server/api;
Proxy_set_header Host $host: $server _port;
}
Because a similar absolute path is written to a Web page or static resource, the user will be asked to go to the Nginx service path when jumping through a link within the page. Once another service contains a similar path, and the Nginx is required to act as an agent, the paradox arises as to which service the request in the same path to the Nginx is forwarded to.
To solve this problem, you must add a uniform prefix, such as/my/public,/my/api,/my/login, to the absolute path contained in the packet's data before the user receives the message, so that the Nginx agent configuration can be simplified to:
location/my/{
Proxy_pass http://my_server/;
Proxy_set_header Host $host: $server _port;
Proxy_redirect//my/;
}
location/other/{
Proxy_pass http://other_server/;
Proxy_set_header Host $host: $server _port;
Proxy_redirect//other/;
}
Nginx's Ngx_http_sub_module module provides a similar message data replacement function, which is not installed by default, requires adding –with-http_sub_module parameters when compiling nginx, or directly downloads nginx rpm packages.
The syntax for replacing packets with Sub_filter is as follows:
location/my/{
Proxy_pass http://my_server/;
Proxy_set_header Host $host: $server _port;
Sub_filter ' href= '/' href= '/my/';
Sub_filter ' src= '/' src= '/my/';
Sub_filter_types text/html;
Sub_filter_once off ;
The above configuration will href= "/replace href="/my for all response message contents under/my/, and src= "/replace src=" to add a common prefix for all absolute paths.
Note that if you need to configure multiple sub_filter, you must ensure that nginx is above the 1.9.4 version.