Once the home data center has completed the deployment of hardware, software, and applications, it is necessary to publish the applications externally. Unlike traditional home broadband which has few applications, application publishing for a home data center involves many applications, which is far from being resolved by simply mapping a few ports on the router (provided there is a public IP address). Since modern applications are basically published in a B/S architecture, reverse proxy technology naturally becomes our best choice.

Speaking of reverse proxy, we must mention forward proxy. Here, I will briefly share my understanding of forward and reverse proxies.

First of all, everyone must understand that whether it is forward or reverse, a proxy is always for access requests. In a normal access flow, the client initiates a request to the server side (application), and then the server side (application) responds. This process only involves two participants:

In this scenario, the object to which the web client actually initiates requests is the proxy server, and it does not know the existence of the actual application; all requests received by the application side come from the proxy server, and the only client it knows is the proxy server device. Whether it is a forward proxy or a reverse proxy, the process is the same. So, what is the difference between a forward proxy and a reverse proxy? Actually, the main difference lies in the objects they serve.

Forward Proxy:

If the proxy server mainly serves the client, and its main purpose of existence is to aggregate client requests and then hide the client's IP address when sending requests to the application side (there are also cases where the client's IP address needs to be passed, which requires separate settings), this is a forward proxy. Generally, a forward proxy is located closer to the client, and may even be in the same security domain. Because it proxies client requests to the server, which is in the same direction as the client's direct access traffic, it is called “forward”. Generally, a forward proxy needs to be configured in the browser.

Reverse Proxy:

If the proxy server mainly serves the server side (application), and its main purpose of existence is to receive requests from clients and then distribute them to different servers (or different ports of the same server) based on different host content, this is a reverse proxy. Generally, a reverse proxy is located closer to the server side, and may even be in the same security domain. Because it mainly faces the server side, which is exactly opposite to the forward proxy facing the client, it is called “reverse”.

In addition, there is also a “transparent proxy”, which mainly refers to a forward proxy that does not require configuration, so I won't mention it much here.

Depending on whether the home broadband has a public IP address, there are different recommended deployment methods.

With a public IPv4 address

In this case, it is recommended to deploy a reverse proxy in the internal network (assuming the internal IP is 192.168.1.1, using the HTTPS protocol to listen on port 443), and then use a certain port on the router as the unified entry port (assuming 44444), pointing to port 443 of 192.168.1.1 through port mapping. Next, you only need to map each application to a different third-level domain name (assuming the third-level domain name for app1 is app1.example.com), and then you can access it via:https://app1.example.com:44444Direct access (of course, provided that the relevant configuration for app1.example.com is correctly set up on the reverse proxy).

Note: Regarding the issue of domain name and application binding, since it is home broadband, it must be a dynamic domain name solution. Currently, the most optimized way is for the egress router to act as the dynamic domain name client. When the public IP of the interface changes, the router automatically goes to the domain name provider to modify the record (if the egress supports multi-dialing, the router's dynamic domain name function must also support modifying multiple interface IPs). From my experience, iKuai's dynamic routing client is very powerful. For details, see my other article:iKuai Soft Router Series - The Strongest Multi-Dialing Soft Router: iKuai

If you don't like the access method of adding a port after the link, you will need to put in some effort and spend some money:
Purchase a cloud host, complete the ICP filing, and then configure a first-level reverse proxy on the cloud host pointing to the home reverse proxy; or use a CDN to use the home site as the origin server (requires a public IP address, both IPv4 and IPv6 are fine). The most critical point is that the CDN's origin port can be customized, so it can perfectly avoid the problem of home broadband not having ports 80 and 443.
The free version of Cloudflare also allows customizing the origin port, which can also solve the problem of ports 443 and 80. It is the first choice for friends who do not want to go through the ICP filing process. However, the access experience is slightly worse, and it might be 2-3 seconds slower than using a domestic CDN. For specific configuration, please refer to my other article:Home Data Center Series: Solving the Problem of Having a Public IP but No Legal 80 or 443 Ports for Website Building via Cloudflare's Origin Rules）。

With a public IPv6 address

In this case, port mapping is no longer needed on the router (obviously, every device has a public IP). Theoretically, a reverse proxy is not needed either, and the CDN can directly point to the corresponding port of the application's IPv6 address (the protocol between the CDN and the origin server can be IPv4 or IPv6, though you can forget about ports 80 and 443). However, if it is just for simply accessing your own application, it is fine. But if you want to build a home data center to provide external access, this definitely won't work: who dares to deploy a bare application directly on the public network? Therefore, in the end, even with a public IPv6 address, you still need to honestly set up a reverse proxy. After receiving access requests, they are filtered through backend security devices (such as WAF, anti-DDoS devices, etc.) before forwarding the requests to the application (just enable public IPv6 on the reverse proxy device; the device where the specific application is located does not need to enable IPv6, and communication between the reverse proxy and the application can just use the internal network address, which is safer, although there are so many IPv6 addresses that you don't need to fear scanning~).

Without a public IP address

In this case, there is only one optional operation: use Cloudflare's Tunnel feature. For specific configuration, please refer to my other article:Home Data Center Series: Getting Cloudflare for Free via Home Broadband Without Public IP to Achieve Fast Website Building (Universal)。

Overall, no matter what type of home broadband you have, you can build a home data center. It's just that having a public IP offers more choices and higher playability.