In the previous article, we introduced how to deploy reverse proxy for home broadband in different situations. In the next article, we will introduce the working principles and configuration points of reverse proxy.
For the reverse proxy to work properly, two problems need to be solved: binding the application to the domain name and correctly configuring the passed parameters.
1. Reasonably plan the third-level domain name and resolution results corresponding to the application
Because the basic principle of reverse proxy is to identify the target application that the request needs to access based on the content of the host field in the http request, the first step is to assign corresponding third-level domain names to different applications (for example, if the second-level domain name is example.com, then app1 corresponds to app1.example.com, app2 corresponds to app2.example.com, and so on), and the address resolved from each third-level domain name needs to correspond to the public IPv4 address of the home broadband (if it is multi-dial, it needs to correspond to the IPv4 public network address of different WAN ports according to the plan, and you can choose a port you like for external release. Tencent and Alibaba Cloud CDN can customize the port of the source station).
Why not talk about IPv6? We also mentioned in the previous article that it is much simpler to have an IPv6 public network address. All the third-level domain names corresponding to the application can be resolved to the public network IPv6 of the reverse proxy device. The IPv4 environment is more complicated, so we will take the IPv4 address as an example. In addition, if the home broadband mentioned in the previous article does not have a public network address, you can only use Cloudflare's tunnel method for deployment. In fact, the access speed feels similar to the deployment method of Cloudflare with a public network address, or even faster (because it is easier to be targeted and negatively optimized through the public network).
To achieve this step, each application's corresponding third-level domain name must be dynamically resolved to the public IP of the home broadband. It is recommended to use the dynamic domain name client built into iKuai, which supports multiple mainstream domain name providers and has no limit on the number of third-level domain names that can be resolved:
Other methods are also fine, such as the dynamic domain name plug-in DDNS-Go in the Merlin Software Market (if I remember correctly, it should also support multiple domain name providers), as long as there is no limit on the number of records supported. One is far from enough.
2. Pass the required parameters to the upstream application server
The server side of many applications needs to make some policy judgments based on the content of the request sent by the client (such as host, refer, X-Real-IP, X-Forwarded-For and other information in the http request). However, after passing through the reverse proxy, the request sent by the reverse proxy may not carry this information by default (as we said in the previous article, the client to reverse proxy and the reverse proxy to application are two completely independent processes). As a result, the policy of the application server cannot be matched, resulting in access failure. Therefore, the reverse proxy needs to insert some required information brought by the client request into the request it sends.
To achieve this step, you only need to configure the reverse proxy software correctly according to the actual needs of the application (for example, nextcloud and wordpress must hard-code the access domain name in the application in advance). There is no specific requirement for the software to implement the reverse proxy. You can use the one you are used to: Baota Linux Panel, 1Panel Panel, NPM, and NGINX deployed by source code.
Take my NGINX configuration as an example to briefly explain the key parameters (this configuration can be placed in the nginx main configuration, but for more organization, it is recommended to create a separate reverse proxy configuration file for each domain name, and then reference it in the main configuration):
#PROXY-START/ location ^~ / { proxy_pass http://192.168.1.1:8080; #Specify the protocol, IP address, and port for accessing a specific application, also known as the upstream server. proxy_set_header Host host:server_port; # Determine the host field content and access port when the reverse proxy sends a request to the application proxy_set_header X-Real-IP remote_addr; #Set the variable 'The value of remote_addr' is assigned to the X-Real-IP field proxy_set_header X-Forwarded-For proxy_add_x_forwarded_for; #Add the variable 'proxy_add_x_forwarded_for' assigns the value of X-Forwarded-For field proxy_set_header REMOTE-HOST remote_addr; #Set the variable 'The value of remote_addr' is assigned to the REMOTE-HOST field proxy_set_header Upgrade http_upgrade; proxy_set_header Connectionconnection_upgrade; proxy_http_version 1.1; # proxy_hide_header Upgrade; add_header X-Cache upstream_cache_status; #Set Nginx Cache setstatic_filesDpoqv14 0; if ( uri ~* "\.(gif|png|jpg|css|js|woff|woff2)" ) { set static_filesDpoqv14 1; expires 1m; } if (static_filesDpoqv14 = 0 ) { add_header Cache-Control no-cache; } } #PROXY-END/The proxy_set_header Host parameter is highlighted. There are several ways to assign variables:
1,$host
Only the domain name is passed without port information. This situation is suitable for the case where the reverse proxy has ports 80 and 443 (for example, the reverse proxy is built on a cloud server). Because they are well-known ports 80 and 443, there is no need to explain them specifically. This is called tacit understanding.
2,$host:$server_port
The domain name and port information that the client request accesses when it reaches the reverse proxy is usually the case when the reverse proxy's external listening port is non-standard (not port 80 and 443). By default, this is the case when the home broadband has a public IP address and is directly published to the outside world. In this case, the information of the reverse proxy listening port needs to be told to the application (in fact, the statement here is inaccurate. Strictly speaking, this listening port should be the actual port that the client requests to access, and the public IP address and port are on the router, so it should be the port mapped on the egress router, but for convenience, I set the reverse proxy listening port and the port mapped on the router to be the same). The reason for this is that some applications will directly generate an access link in the response, and this access link cannot be accessed without the real port information published to the outside world.
3.$host:$proxy_port
Pass the domain name accessed by the client request to the reverse proxy and the port of the backend application (not used yet, not sure what scenario it is used in)
4.$http_host
The content of the host field when the client request reaches the reverse proxy, which is normally equivalent to$host:$server_portIn abnormal cases, if the host field is empty, nothing will be displayed, which is quite embarrassing, so it is generally safer to use$host:$server_port
in addition,proxy_set_header X-Real-IP $remote_addr,proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for,proxy_set_header REMOTE-HOST $remote_addrAll three are used to pass the client's real access address to the backend application (because the application can only see the reverse proxy IP address by default), so what is the difference between these?
X-Real-IPandREMOTE-HOSTThere is no difference between these two in my configuration. You can see that the values of these two fields are variables.$remote_addrThe corresponding source IP address is the source IP address of the client request when it reaches this reverse proxy.X-Forwarded-For, and its corresponding variable$proxy_add_x_forwarded_for, this variable is composed of 2 parts:$http_x_forwarded_forand$remote_addr, separated by commas. So if you go through multiple proxy servers, and each proxy server is configured withproxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for,SoX-Forwarded-ForThe displayed results in this field are: proxy server 3 IP, proxy server 2 IP, proxy server 1 IP, client real address.
Finally, the upstream server of the reverse proxy may not be the application, but may be another reverse proxy, such as a web application firewall that works in the form of a reverse proxy, and CDN is essentially a reverse proxy. It can be seen that when the client request reaches the real application end, it may pass through N layers of proxies, which further illustrates the importance of correctly configuring the transmission parameters of each layer of proxy.
For specific reverse proxy configuration steps, see the article:Linux panel series configure reverse proxy and use non-443 port for publishingandDocker series uses Docker to build its own reverse proxy based on NPM.
