1 Introduction

As the expiration date of my Tencent Cloud Lightweight Application Server draws closer, I have been hesitating about whether to renew. The first year was 99 RMB/year, and the second year, if I remember correctly, was around 300 RMB/year (I don't remember exactly, somewhere around there). But what is the price for the third year? I took a look, and boy:

I already felt that ICP filing was pretty useless (Telecom is cracking down on residential broadband with public IPs that have inbound HTTP traffic. As a result, the method of having domestic CDN origin servers point directly to the dynamic domain name corresponding to the residential broadband public IP no longer works). Coupled with the various inconveniences of using domestic VPS in daily life (unable to access docker, git, apt, etc. normally, having to constantly fiddle with them, which is extremely annoying), I've wanted to give up on it for a long time. I just thought about keeping the ICP filing just in case it might come in handy someday.

But adding this renewal price completely shattered my last bit of hope, which made me finally make up my mind: cancel the domain name registration (ICP filing) and migrate it to Cloudflare as well; at the same time, my redundant data center in the cloud will also be migrated to an overseas VPS. So, the first question I face next is, where should I move it to?

2 VPS Selection and Purchase

1 Selection Criteria

There are really too many overseas VPS providers to choose from. Logically, the options should be very broad. However, for me, under a few evaluation metrics, the choices are actually very narrow, mainly considered from the following aspects:

1.1 Price

Previously, when the Tencent Cloud server was around 280 RMB a year, my tolerance was almost at its limit, so the price of the target VPS is capped at this, which is about 40 USD a year.

Generally speaking, VPS is sold in monthly and annual payments. My requirement of a 40 USD annual limit (which is 3.3 USD per month) basically rules out the vast majority of choices. If we further exclude the condition of ”packages that can only be purchased during special periods like Black Friday every year”—meaning the requirement of ”can be purchased at ordinary times”—then in the end, there is only one choice left: Racknerd.

Provider	Features	Cheap plans available daily?
RackNerd	Many discounts, many low-price plans	Often available (e.g., $10.99/year)
HostHatch	Great value when there are promotions	Usually on the expensive side
GreenCloud	Good routes, CN2 available	Basic plan > $40
VirMach	Extremely low prices but prone to issues	Unstable, not recommended for important uses
CloudCone	User-friendly control panel, average speed	Poor reputation for stability
BuyVM	Cheap and high quality, but sells out instantly	You won't be able to grab one
LiteServer (Netherlands)	Decent but unremarkable	Sometimes available for EUR 30/year
Netcup / Contabo	Resource giants, cheap prices	Usually over budget or has many restrictions daily

1.2 Performance

Looking at the lowest-end domestic Tencent Cloud Lighthouse server I purchased before, the lowest performance configuration is: 2-core 2G RAM, 40-50G SSD system disk, and the 15% off prices are 459/year and 510/year respectively (I got the 510/year one, lured in by the 99 yuan promotional price):

Relatively speaking, it would actually have been cheaper to choose Hong Kong or other overseas regions at the beginning. Unfortunately, because I needed to complete the ICP filing at the time, I had to bite the bullet and get on board with the mainland China region (of course, the price factor of 99 yuan/year also accounted for half the reason):

If you really want to run some Docker containers normally (including applications like WordPress), a 2-core 2G RAM + 40GB hard drive should be considered the minimum configuration. Actually, a 40G hard drive is a bit tight, and you need to constantly monitor and clean up the disk. Otherwise, if there is a slight issue and the log policy is not configured in advance, it is easy to fill up the hard drive. The disk of my Tencent Cloud Lighthouse server is often at 80% to 90% capacity:

So in terms of performance, my requirement is a minimum of 2-core 2G RAM + 40G hard drive, with no upper limit.

1.3 Traffic

1.3.1 Metering Method

---

I don't really have any requirements in this regard, because I don't directly use the VPS's public IPv4 address to publish websites or for proxy purposes (even if I do, it's just a backup). I always use Cloudflare CDN, so the traffic is only used for Cloudflare's origin pull to the application, which is basically negligible. However, if some friends have special needs, such as seeding PT traffic or using it as a proxy tool, then the more traffic, the better.

---

When purchasing a VPS,traffic billing methodsare an easily overlooked but highly critical aspect. Especially when you need to perform a large amount of inbound and outbound data transfer, the billing logic of different providers will directly affect your usage cost and availability.

Below is a comparison of traffic measurement methods between major domestic cloud providers and overseas VPS providers:

Item	Domestic VPS (such as Alibaba Cloud, Tencent Cloud)	Overseas VPS (categories need to be distinguished)
Inbound Traffic (Ingress)	Usually free or unlimited (free no matter how much you download)	One-way billing providers(such as Vultr, DO, Linode): Not billed Two-way billing providers(such as RackNerd, Hetzner):Billed
Outbound Traffic (Egress)	Pay-as-you-go or limited (e.g., some packages include 1Mbps for free)	Almost all overseas providers bill for this, regardless of one-way or two-way mode
Traffic statistics method	Only countsupload (outbound)direction traffic	– One-way billing: Only counts outbound (egress) traffic – Two-way billing:Inbound and outbound traffic are combined into the total traffic
Traffic limit manifestation	Commonly “outbound speed limit” or “pay-as-you-go for excess”	Based on “total monthly traffic package”, and if exceeded, speed is limited or network is disconnected (e.g., 1500GB/month)
Recommended scenarios	PT, cache mirror sites, low-frequency tasks, personal idle scripts, etc.	Website hosting, reverse proxy transit, proxy services, cross-border access services, etc.

1.3.2 Practical Case Illustration

Domestic VPS example:

• Download 100GB of data from the public network → No traffic counted
• Upload seed files or data 30GB → Traffic counted
• Total monthly traffic consumption:30GB

Overseas VPS example:

• Vultr / DigitalOcean (One-way)：
  • Download 100GB → Not billed
  • Upload 30GB → Counted towards the traffic package
  • Total consumption:30GB
• RackNerd / Hetzner (bidirectional)：
  • Download 100GB + Upload 30GB → Counted as 130GB
  • Assuming the plan is 1500GB/month, remaining:1370GB

Practical advice:

• For tasks requiring high download volumes (such as scraping mirrors, caching, web scraping), domestic VPS are very suitable, especially since although the data package is small,only upload is counted。
• For website hosting, proxy services, or CDN origin servers, foreign VPS are recommended,with priority given to choosing one-way billing providers, such as Vultr.
• When choosing cheap annual-payment VPS like RackNerd, note that theirtraffic is calculated bidirectionally, so if you are relaying high traffic, please plan your budget and restriction strategies accordingly.

1.4 Geographical Location

Generally speaking, for friends who have requirements for VPS geographical location, they do not necessarily have requirements for the ”physical location itself”, but essentially fordomestic direct connection access latencyrequirements: this latency is mainly limited bythe routing quality of the data center where the VPS is located和and the direct connection status with Chinese operators, rather than the geographical distance itself.

Sometimes, physically closer nodes actually perform worse, while physically further ones have lower latency and faster speeds. This is because:

• China's international export bandwidth itself is congested,
• and most ordinary VPS usedetoured backbone networks of the three major operators(such as Hong Kong routing through the US or Singapore and then returning) orinternational transit return routing，
• Truly low-latency, high-quality access relies on routes like CN2, GIA, CUVIP, CTG and other routes with direct connection attributes.

To give a common example:

• Los Angeles (especially data centers like Cera/Krypt) is physically further than Chicago, but because some VPS providers have deployed CN2 GIA return routing, the actual access latency can be kept within 140ms, which is even faster than some ”non-direct connection” data centers in Hong Kong, Tokyo, and Seoul.
• Conversely, some Hong Kong and Singapore data centers, if they do not use high-quality routes, will instead have latencies as high as 250ms or more due to detoured return routing.

Therefore, when choosing a VPS,Geographic Locationyou should not just look at the map, but pay more attention to itsreturn routing quality: Many people choose Los Angeles or San Jose, not because they really care about the location of these two cities, but because these places concentrate manyChina-friendly, high-quality return routingdata centers.

Note 1: For friends who care about domestic direct connection access latency, if the VPS can only be chosen within the United States and there are choices for Los Angeles or San Jose, try to choose these two.

Note 2: A VPS in Los Angeles or San Jose is not necessarily on premium routes like CN2 or GIA; it also depends on the purchased plan. You certainly can't expect it with plans that are too cheap (such as $10.99/year). Of course, even without them, the latency will still be relatively low. Taking the latency of my two VPSs as an example, the ping latency for Chicago is over 220ms (ping is currently disabled, so it's hard to take a screenshot, and I'm too lazy to change the configuration), and San Jose is over 180ms:

If it uses premium routes like CN2 or GIA, the domestic direct connection latency can be below 140ms, or even below 100ms. Of course, at the level of tens of dollars per year, there is a high probability that you won't have the chance to use premium routes.

---

There is one issue that everyone needs to realize:ICMP Ping Latency ≠ Actual TCP Application Quality, because:ICMP is one of the least reliable ”quality of service” metrics:

• ICMP (which is ping packets) was originally widelyrate-limited、discarded、extremely low QoS priorityprotocols;
• Many VPS host machines directly apply policy restrictions to ICMP: causing high latency and the illusion of packet loss;
• Under the GFW environment, ICMP and UDP are not favored at all, only TCP 443 (HTTPS) is the most ”friendly treated”, even with an illusion of stability;

The final result could be:seeing a stable ping and low latency does not mean TCP will definitely work well, and it could also be the other way around: terrible ping but very stable TCP.

Truly reliable direct connection access evaluation methods:

Protocol	Transmission Stability	GFW Interference	Description
TCP Port 443	Extremely High	Lowest	Ideal choice for the main channel (this is how Cloudflare Tunnel works)
Other TCP Ports	Relatively High	Slight to Moderate	Such as 22/80/8080 may be rate-limited or identified
Any UDP Port	Unstable	Moderate to High	Easily rate-limited, QoS deprioritized, or even poisoned (especially DNS)
ICMP (ping)	Very Poor	High	Only for simple connectivity reference, cannot be used as a basis for performance evaluation

To sum it up in one sentence:Ping can only serve as a reachability reference and does not represent actual network usage quality, especially in cross-border/cross-cloud environments. Actual communication quality order: TCP Port 443 > Other TCP > UDP > ICMP.

---

Note 3: Actually, if you do not use the VPS's public IP to directly publish websites (such as directly opening port 443 for users to access), and do not plan to deploy censorship circumvention tools that require ”domestic direct connection” on it, then the metric of ”domestic direct connection access latency” becomes less important—especially under the architecture where you use Cloudflare Tunnel to publish applications.

In this architecture, users” access traffic does not actually hit the VPS directly; instead, it first enters Cloudflare's global edge nodes, and then Cloudflare's own internal network ”pulls" data from the origin server. Therefore, what really matters at this point is:The connectivity, stability, and origin-pull response time between the origin server and the Cloudflare network。

From this perspective, Chicago is actually, compared to West Coast nodes like Los Angeles and San Jose,a more suitable origin server candidate: On one hand, although the West Coast is physically closer to China, a large number of cheap VPS are crowded in that area, making line congestion and soaring packet loss/latency during evening peak hours long-standing norms; on the other hand, Chicago, as a central node, although slightly further from China, maintains more stable network quality with fewer fluctuations year-round, making origin-pull performance much more controllable.

More importantly, Cloudflare often has stronger backbone connection resources in US East and US Central nodes, resulting in shorter and faster origin-pull paths. Under the Tunnel architecture, what we truly rely on is the stable ”pulling” capability between Cloudflare and the origin server, rather than the direct connection speed between domestic users and the origin server. So by comparison, Chicago is more like aquiet but reliable rear base, which is very suitable for hosting Class C core services, such as WordPress blogs, personal homepages, and other businesses that are sensitive to access quality but have zero dependence on direct connections.

So, if I initially felt a bit of ”premium line anxiety” because I didn't choose San Jose/Los Angeles, I can now say with peace of mind:The Chicago node is the best origin server choice under my current architecture—stable, low-cost, and balancing fast origin-pull for both US and European users.

2 Final Choice: Racknerd's 882

Actually, for me, as long as the price factor is considered, Racknerd is the only choice. Of course, if the performance did not meet the requirements (geographic location and traffic are irrelevant to me, but indeed a must-have for many friends who need a direct connection experience), I wouldn't choose it even for the price, because I still have high requirements for performance. After all, as the cloud redundant data center for my home data center, quite a few applications have to run on it. As for traffic and geographic location, due to Cloudflare's ”equality for all,” I have absolutely no requirements.

In the end, I chose the 882 (2024 Black Friday promotion package:Racknerd_High-Spec 1_882), which is considered the most cost-effective in the high-end tier:

The performance fully meets my requirements, there is so much traffic that I can't possibly use it all, it provides a SolusVM control panel, and most importantly, the price is 40 USD, which is basically the upper limit of around 280 RMB, perfect!

Note 1: Racknerd's high, medium, and low configurations also have multiple choices, starting as low as 10.99 USD/year. Of course, that configuration is very low and can only be used as a jump box~ For more configurations, please refer to the article:Wudi Recommendations。

Note 2: For friends who have requirements for domestic direct connection latency, don't be too quick when placing an order. You must select the location first. For example, choose San Jose (DC02 data center). The default is Chicago (DC03 data center). The domestic direct connection access latency is at least 40 milliseconds more. Don't ask me how I know (although the difference is actually not big, and I don't have much requirement for direct connection, but I was still unhappy for a few days~):

Note 3: After purchase, the login method, account, and password will be sent to the email address used during registration.

3 Migrating Domains

After choosing the VPS, I directly migrated my previously registered domain name from DNSPod to Cloudflare. This way, in addition to my main ”.com” domain, the domain previously used for registration serves as a backup domain for some comparative testing, while the ”.xyz” domain was simply abandoned after it expired (there are too many adult websites ending in .xyz, which lowers the class of this domain suffix~).

Below is a brief record of the process of migrating the domain from Tencent Cloud DNSPod to Cloudflare. I migrated it once before but forgot to record it, so I'm making up for it this time:

Then DNS records will be added according to the selected method, followed by the final step:

Then click Continue at the bottom of the page:

The subsequent operations will be on Tencent Cloud's DNSPod.

Confirm that the DNSSEC function is not enabled:

If the security lock is enabled, it needs to be disabled in advance:

After that, just wait for the email from Cloudflare:

The above steps are to migrate domain hosting from Tencent DNSPod to Cloudflare, but the actual domain registration (renewal) is still at Tencent DNSPod. If you want to migrate the domain registrar to Cloudflare as well, you still need an additional step of ”Transfer Domain”:

Because I forgot to take screenshots when I transferred the domain back then, and I don't have any idle domains to operate on now, I won't take screenshots. Actually, it's mainly about selecting the domain to be transferred to Cloudflare, then generating an authorization code on Tencent Cloud's side, entering the authorization code here, and finally paying a fee in the third step ”Contact and Payment Information” (it seemed to be 8 USD? I can't remember clearly), and then waiting for 5-7 working days.

4 Upgrade of Disaster Recovery Methods for Key Applications

1 Disaster Recovery Mode during the Tencent Cloud VPS Era

Previously, I divided the applications into three categories: Class A, Class B, and Class C:

• Class A: Applications that consume a large amount of resources or rely on the intranet data or computing resources of the home data center, such as Emby, lobechat-database, SafeLine WAF, etc. These applications only run inside the home data center (Emby needs to regularly scan video resources on the local NAS; lobechat-database is relatively resource-intensive and sometimes needs to call the local Ollama model running on the local M4 Pro Mac mini; SafeLine is too resource-intensive—deploying it on Tencent Cloud's pitiful 2-core 2GB RAM lightweight server basically means the VPS can't do anything else~).
• Class B: Applications suitable for deployment on Tencent Cloud lightweight servers, such as Bitwarden, Tailscale DERP relay servers, and some other relatively lightweight applications can be counted as Class B. Try to put them on cloud servers as much as possible (however, since the 2-core 2GB configuration is only an entry-level configuration, it won't hold up if too many are put on~).
• Class C: This is my most core application. At that time, there was only one: the blog. In order to perform disaster recovery for the core application, the blog was deployed simultaneously in the home data center and on the Tencent Cloud lightweight server. Combined with the database synchronization mechanism (home data center database export, Syncthing synchronization to the Tencent Cloud node, and automatic import by the Tencent Cloud node) and the Tencent Cloud node's monitoring of the home data center's accessibility, automatic takeover of the blog service can be achieved when the home data center loses power or network (refer to the article:Home Data Center Series: Flexibly utilizing Cloudflare Tunnel to achieve automatic takeover by disaster recovery site when the main WordPress site fails)。

Therefore, when the home data center is normal, the inbound access traffic of the application is as follows:

When the home data center loses power or network, the inbound access traffic of the application is as follows:

Therefore, the purpose of the previous disaster recovery method was merely to ensure that when there was a problem with the home data center, the Class C core application (which was only the blog at that time) would not be interrupted.

However, the original disaster recovery switching logic was actually not perfect. The root of the problem lay in how the Tencent Cloud node detected the health status of the home data center:

Since my home broadband uses a dynamic public IP, which generally changes about every three days, this makes it impossible to perform reliable detection through a fixed IP (not to mention that most people's home broadband doesn't even have a public IP, and only commercial networks can have a fixed IP).

Theoretically, dynamic domain names can be used to solve the problem of IP changes, but in reality, the refresh time of DNS cache is uncertain. Once the public IP has changed but the DNS has not yet updated, a short-term ”active-active” state will occur, where Tencent Cloud and the home data center are online at the same time, making it impossible for Class C applications (such as the blog) to guarantee access consistency, which is unacceptable to me.

Ultimately, I chose the Tailscale IP of the Mac mini where the blog is deployed as the detection target (the Tencent Cloud lightweight server also has Tailscale deployed). The principle of this solution is: even if the public IP changes, as long as Tailscale can quickly restore the connection after the change, the Tailscale communication status can be used to determine whether the home data center is available, thereby controlling whether to switch the blog's primary node.

However, even so, there are hidden dangers: what if Tailscale on the Mac mini does not work properly (which is also a lesson learned through blood and tears, see the article:Home Data Center Series: A Tragedy Caused by a ”Steamed Bun”: A Record of the Abnormal Blog Access Phenomenon in the Past Few Days Caused by Upgrading Tailscale)?

Therefore, I have always been very dissatisfied with the previous disaster recovery method, but there was no good solution to think of.

---

Why not accept active-active? Mainly because when my Cloudflare was still on the free subscription plan, the so-called free WAF managed rules were essentially completely useless, so I relied on the ”SafeLine WAF Community Edition” deployed inside the home data center to bear the brunt of security issues. If the active-active mechanism were enabled normally, then nearly half or more than half of the visits might be sent directly to the Tencent Cloud node. A Tencent Cloud node whose performance is far from sufficient to deploy a SafeLine WAF would be like an undefended ”beauty”—you can't expect the free version of Wordfence to resist everything, right?

Therefore, under the conditions at that time, the Tencent Cloud node could at most serve as a ”true disaster recovery center” for the blog to temporarily hold the line, and once the home data center restored access, it would give up taking over the Class C applications.

---

2 Active-Active Mode during the Racknerd VPS Era

As I ”half-reluctantly” became a noble Cloudflare Pro subscriber in early March, after observing for these two months, the ”SafeLine WAF” on the intranet of the home data center basically has no security alerts, fully proving that the WAF managed rule set indeed played a huge role (sure enough, the treatment after paying is completely on a different level compared to getting it for free):

Therefore, at this time, ”SafeLine WAF” has ended its historical mission, which also means that the ”active-active” of Class C applications has officially stepped onto the stage of history.

Taking advantage of this VPS relocation, I re-organized the existing applications. Since the configuration of Racknerd 882 is not low (3 cores, 4.5G RAM, 100G pure SSD hard drive), I classified more applications into Class C. At this time, the normal inbound access traffic is as follows:

When the home data center loses power or network, the inbound access traffic of the application is as follows:

It looks like the switching when the home data center loses power or network is the same as before, but actually the internal logic is completely different: this switching behavior is not controlled by me (previously it relied on detection scripts), but is dominated by the default mechanism of Cloudflare Tunnel: when it is found that one of the multiple connectors of the same tunnel is working abnormally, that connector is excluded from the multiple targets of traffic distribution, and when the connector is found to have recovered, it is automatically added back to the traffic distribution targets. Therefore, the current switching logic is very perfect.

Similarly, when the VPS of the Racknerd node has a problem, all origin-pull requests of Class C applications will only be sent to the home data center:

Of course, Class A and Class B applications do not have this treatment. No matter which node fails, the corresponding services will be interrupted. However, these applications are basically for my own use, so it's no big deal.

---

This mechanism is provided by default by Cloudflare Tunnel, supporting the deployment of up to 4 connectors in the same tunnel:

For a detailed description of the connector, refer to the article:Home Data Center Series Cloudflare Tutorial (9) Introduction to Common Zero Trust Features and Multi-Scenario Usage Tutorial。

---

Currently, I have a total of 3 Cloudflare Tunnels: wudihome (corresponding to Class A applications), racknerd-chicago (corresponding to Class B applications), and loadbalance_w_r (corresponding to Class C applications):

Among them, the tunnel corresponding to Class C applications: ”loadbalance_w_r” has 2 connectors, corresponding to the home data center and Racknerd's Chicago node respectively:

At the same time, Class C applications have also expanded from just a blog before to 9 applications now:

Class C core services, including the blog, have achieved close to 9994% availability—Theoretically, the annual service downtime does not exceed 3 minutes. Even if either side fails, the other side can automatically take over, ensuring the service is always online.

---

The availability of 99.9994% is not just a casual claim. Based on my experience, the total time of power and internet outages at home in a year will not exceed 1 day, which is 1440 minutes (mostly routine maintenance of the power system, internet outages have basically never occurred, except for that time I was directly blocked by the Communications Administration for 3 days~); while Racknerd's high availability, referring to the industry's 99.9%, is calculated as 8 hours, which is 480 minutes, then the following results can be obtained:

Basis for estimating high availability of Class C services (dual-node deployment)

Item	Home Data Center	Racknerd Chicago Node
Estimated maximum annual downtime	1 day = 1440 minutes	8 hours = 480 minutes
Annual availability	99.73%	99.9%
Whether Class C services are deployed	是	是
Common Causes of Failure	Power outages, network disconnections, local equipment anomalies	VPS network fluctuations, ISP maintenance, data center failures
Failover Methods	Automatic takeover by Racknerd after loss of connection	Automatic takeover by home data center after loss of connection

Overall service availability estimation (Active-Active architecture)

Item	Description
Failure independence assumption	Downtime of the two nodes are mutually independent events
Probability of simultaneous downtime of both nodes	≈ (1 ÷ 365) × (0.33 ÷ 365) ≈ 0.0000025
Theoretical annual downtime	365 × 24 × 60 × 0.0000025 ≈ 3 minutes
Theoretical blog service availability	99.9994%(Industry ”five nines" level)
High availability assurance mechanism	Data synchronization (Syncthing + auto-import) + Cloudflare Tunnel Automatic failover for multiple connectors

---

Note 1: The capability of Cloudflare Tunnel is not justactive-active and failover of multiple Connectorsthat simple. Wait, that sounds a bit familiar:

At the same time,it can also select the nearest origin server based on the visitor's location, achieving ”best-effort” nearby access (if it works, great; if not, so be it—very easygoing). Crucially, it does not provide visitor-based origin stickiness (meaning this origin pull might go to the Chicago node, and the next one might go to the home data center). But even so, I am very satisfied; after all, getting this level of service for free is already something to be grateful for. So, in fact, my Racknerd Chicago node is now the primary origin server for Class C applications when they need origin pull (since domestic traffic is mostly routed to US West data centers, the Chicago node is naturally much closer than the home data center located in China~). Although most of the time it's just accessing cached data and origin pulls are rare, for some reason, I always feel that Class C applications open faster now—not sure if it's just an illusion~.

Note 2: Friends familiar with active-active or multi-active data center architectures should know that one of the prerequisites for deploying multi-data center active-active or multi-active applications is that the service content provided by each node must be consistent. That is, applications across multiple nodes must remain synchronized, and no discrepancies should occur in either static resources or dynamic data. Especially in scenarios involving databases, the requirements are even stricter—data across all nodes must be highly consistent to prevent data corruption or state loss when user requests switch between different nodes.

Therefore, although Cloudflare Tunnel provides multi-connector support, allowing automatic request distribution and disaster recovery failover by running the same tunnel configuration on multiple nodes, this does not mean all types of applications can directly achieve ”active-active”. If your service contains state information, database write operations, or user sessions, you must ensure these states can be synchronized across multiple nodes, or design them as stateless services, to truly leverage the redundancy and high availability benefits brought by multiple connectors (for my data synchronization solution between multiple WordPress sites, please refer to the article:Home Data Center Series: WordPress Multi-Node ”Semi-Automatic”, ”Near” Real-Time Synchronization Solution)。

Note 3: For Cloudflare Tunnels created via the Zero Trust dashboard, connectors can be deployed in two ways: service mode and docker mode. Among them, service mode is the officially recommended deployment method, using the command “cloudflared service install ” to create a system service. However, since multiple systemd services with the same name cannot exist on the same machine, this method can only deploy one tunnel by default. If you need to deploy multiple tunnels using the service method, you can also run multiple connectors by manually modifying the systemd configuration and using different service names.

In contrast, docker mode is much more flexible: since each container is an isolated runtime environment, you can easily deploy multiple connector instances, and even if they correspond to different tunnels, they will not conflict with each other. Therefore, from the perspective of deploying multiple tunnels, Docker is a more suitable way to run multiple connectors on the same node (though it is less stable than the service method).

Note 4: There is another key issue that needs to be resolved in active-active deployment, and that isread-write separation. Under the premise of ensuring consistent content between the two WordPress nodes, ”read” requests (to be precise, origin pull requests triggered by user visits) can be distributed to any node, which can effectively share the load and improve access speed. However, ”write” requests are completely different, especially operations involving database writes such as updating website content or posting comments, which mustbe strictly restricted to being submitted to only one primary node, otherwise it can easily lead to data confusion or even lost comments.

In my architecture, this ”primary node” is the WordPress deployed on the Mac mini in my home data center, which is also the node with the Cloudflare plugin installed that is responsible for automatically flushing the APO cache. Updating website content is easy enough to manage by logging into the ”primary node” yourself to control the write node, but comments are tricky because they are controlled by Cloudflare's multi-connector mechanism. To force comment requests to be written to the primary node, I thought of quite a few clever workarounds before finally finding the simplest implementation. I ran into a lot of pitfalls along the way, which really put me through the wringer.

Due to the enablement of the active-active architecture, many configuration details are already different from what I wrote in ”Home Data Center Series: Utilizing Cloudflare Tunnel to Achieve Automatic Takeover by Disaster Recovery Site When WordPress Main Site Fails“, and with the addition of the ”read-write separation” implemented this time, I will write a separate article later to introduce the entire concept, configuration scheme, and troubleshooting record in detail.

5 Racknerd VPS's ”Fully Closed” Security Strategy

1 What is the “Fully Closed” Security Strategy?

Regarding the security strategy of VPS, I have actually always pursued a ”fully closed” strategy. What is ”fully closed”? Simply put, it means no ports are opened by default, and no active connection requests from the public network are accepted. Even for basic services like SSH, I try my best not to expose them to the public network. If it can be accessed through the intranet, it will never go through the public network; if it can communicate through point-to-point encrypted tunnels, plaintext or traditional port exposure will never be used.

In practice, this means I usually set the firewall's inbound traffic policy to ”default deny”, which means UFW is set to deny all inbound TCP and UDP packets:

---

In fact, the most ideal state is for the entire VPS to look ”invisible”: no open ports to the outside, no scanners can scan any services, and hackers have nowhere to start. However, relying solely on ”default deny” does not achieve an ”invisible” effect. To be completely ”invisible”, you need to drop inbound access for ICMP echo packets, and also drop all inbound TCP and UDP packets, which cannot be achieved by UFW's conventional configuration rules alone; you must use iptables or nftables.

---

Of course, this strategy sounds radical, but it is actually not complicated to operate. The key is to use some modern tools as assistance: for example, I use Tailscale to build a point-to-point intranet network and use Tailscale's IP for daily operations and maintenance management. In this way, I achieve ”communication only within the private network”. From the ISP's perspective, they can only see that I am communicating using the WireGuard protocol, but they cannot see the actual communication content (of course, even if they can't see it, they can still interfere with you: active packet loss or even directly blocking you from using it~).

2 The Core Technology of the “Fully Closed” Security Strategy: Cloudflare Tunnel

The ”fully closed” concept understood by many people is just a defensive posture in one direction—such as closing ports, not accepting connections, and not exposing SSH. But here comes the question: if you really do this, how do you use the services running on the VPS yourself? Can you not even log in via SSH? Are the services just playing with themselves? How do you access the website without opening port 443? At this point, ”fully closed” is no longer a security strategy, but boring self-amusement.

Therefore,A fully closed setup must be paired with ”tunnel-based reverse access” capability, otherwise it is just isolating yourself. And Cloudflare Tunnel is one of the core technologies to resolve this contradiction: it can safely expose intranet services without exposing ports or setting up complex reverse proxies. As long as the local network can access the internet and connect to Cloudflare, a secure channel can be established. This is very friendly for scenarios that require public network access to services but do not want to open any external ports.

Its principle is essentially to let the VPS actively initiate a connection to Cloudflare, and then reverse-expose local services through Cloudflare's network. Because it is an ”active connection”, the VPS does not need to open any ports; just like a client, as long as it can access the internet, it can establish a tunnel.

It has several benefits:

1. No need to expose any ports: No matter whether you are running a web service, a backend management page, or your own mini-program on the VPS, you can provide services to the outside world through the tunnel. Public network access only goes through Cloudflare, and the VPS remains ”fully closed” to the outside.
2. Support for access control: Cloudflare Access allows you to perform access control based on identity (such as a Google account), or even MFA. It is equivalent to having a built-in authentication gateway, avoiding the need to reinvent the wheel on the service itself.
3. Dealing with Port Restrictions and ISP Blocking: Some VPS, especially domestic cloud service providers, have various ”bizarre” restrictions on ports, especially 80/443. Cloudflare Tunnel does not rely on these ports at all and penetrates directly, making it a weapon against restrictions.
4. Flexible Routing + High Availability: Combining Cloudflare's load balancing and multi-endpoint tunnel capabilities allows for highly flexible backend switching. For example, I am currently running a tunnel instance in both my home data center and an overseas VPS. Cloudflare's load balancing mechanism automatically determines who is online and switches traffic. All of this is achieved under the premise of being ”fully closed”.

It can be said that Cloudflare Tunnel is essentially a“stealth service exposure”method, which perfectly aligns with my unreasonable philosophy of ”absolutely refusing to open ports yet insisting on publishing applications to the outside world.”

For detailed configuration steps of Cloudflare Tunnel, please refer to the article:Home Data Center Series: Using Tunnel Technology to Enable Home Broadband Without Public IP to Leverage Cloudflare for Free to Achieve Rapid Website Setup (Recommended)。

3 “Fully Closed” is Not a Panacea for All Security Problems

Although a ”fully closed” security strategy can indeed solve many daily minor hassles—such as preventing port scans, mitigating brute-force attacks, bypassing strange rules of cloud providers, and even largely eliminating complex firewall policy configurations—it does not mean once and for all, let alone that you can rest easy.

First,Fully closed does not equal absolute securityFrom a network perspective, although all inbound connections are blocked, this machine still actively initiates connections, such as running Cloudflare Tunnel, software updates, and data synchronization. These outbound traffic flows can still become potential attack surfaces, especially when there is a possibility of local services being hijacked or DNS spoofed.

Secondly,Attackers do not always ”come from the outside”Many times, the real risks come from the services you deploy yourself, especially various applications (including WordPress) quickly set up via containers or scripts. Even if the external access path is ”fully closed”, a misconfigured service, an out-of-control shell command, or a pull of a low-quality image can still cause lasting internal damage to the system, which is precisely what the ”fully closed” strategy cannot prevent.

There is also a very realistic point:Security strategies are never staticYou block all ports today, but tomorrow project requirements change, and you might need to temporarily expose a service; you run only one Tunnel today, but tomorrow you might need to add a bypass proxy or a control panel... This change itself means increased risk. With the slightest loosening, gaps can appear in the entire ”fully closed” structure. And human habit is often: once you taste convenience, you start to slack off, and eventually ”fully closed” might turn into ”leaving a small leak is fine.”

Therefore, my consistent understanding is:“Fully closed” is a basic posture, not an ultimate solutionIt can greatly reduce the risk of passive exposure, but you still need continuous security awareness, including:

• Regularly auditing which services you have running;
• Checking the logic behind every outbound connection;
• Trying to run services with the least privilege;
• Remaining vigilant about all containers, scripts, and dependencies;
• It is best to implement logging and anomaly monitoring for critical applications.

Just like a house with tightly closed doors does not mean the inside is absolutely safe. The wiring, gas, and outlets inside still need daily attention. Network security is never something that can be solved solely by ”closing the door.”

4 Disadvantages of the “Fully Closed” Security Strategy

“Although the ”fully closed" security strategy brings significant protection benefits, it is not without cost. The most direct problem is thata large number of services that could originally be easily accessed via direct connection become extremely complex under the ”fully closed” strategy, or even difficult to use, such as:

1. Setting up proxy services based on trojan-go, xray, etc., which originally only required opening a port and binding a TLS certificate to connect. However, in a fully closed state, all inbound ports are rejected, making such direct-connection-dependent solutions completely undeployable, forcing one to look for other ways.
2. If accessing services on a VPS via a Tailscale address, you will find that third-party proxy acceleration tools (such as Surge, Clash, Quantumult) cannot directly take over the traffic. This is because these tools often only support proxying public IPv4 addresses rather than virtual intranet addresses like Tailscale, resulting in high latency and instability when accessing certain Tailscale-only services from domestic networks, compromising the experience.
3. File transfer becomes troublesomeFor services like rsync, SFTP, and WebDAV, if active inbound connections cannot be established, they often need to rely on reverse connections or transit services. Otherwise, they can only be replaced by cloud synchronization solutions like Cloudflare R2, OneDrive, or iCloud, which greatly reduces flexibility.
4. In some remote operations scenarios, such as using tools like mosh, VS Code Remote, x11 over ssh, frp/nps, etc.,many rely on two-way connections or a certain connection sequence, in a fully closed environment, direct connection is impossible, which means the entire operations path must be redesigned.
5. The fully closed inbound policy also easily affects normal communication between containers and the host machine, especially in Docker's default bridge network mode. Since UFW blocks all inbound connections by default, even if these connections originate from containers on the same host, as long as the data flows through the host's network interface (such as docker0), it may be treated as “external inbound traffic” and rejected, preventing containers from accessing services on the host. For example, when deploying Cloudflare Tunnel using Docker, if the --network=host mode is not used, the Tunnel container may fail to connect to services on the host; similarly, even if the Nginx Proxy Manager (NPM) container's local listening port is normal, it cannot access the host's WordPress service via reverse proxy. This situation causes communication failures between many components that should have been “locally connected”, increasing the complexity of debugging and deployment.

Therefore, ”fully closed” is not actually a strategy that can be simply applied; itis more like a basic posture control: On top of this, you need to choose a suitable supplementary method based on your own scenario: for example, using proxy tools like AnyTLS that support embedded reverse connections and can be used in conjunction with Cloudflare Tunnel, or building a transit layer yourself (such as a unified entry point based on Cloudflare Tunnel). Therefore, there are gains and losses, but the art of application lies in one's own mind.

Note: Actually, purchasing a cheap VPS separately (such as the $10.99/year kind) to use as an SSH jump box or a self-built proxy machine can solve the vast majority of problems~.

6 Afterword

The subsequent VPS initialization and deployment of various applications are just manual labor with little technical content, so I won't write about them.

After this week's busy work, Racknerd's Chicago node has officially gone into operation. During this period, I also conducted several downtime tests for Class C applications in both my home data center and the Chicago node, and found no issues. So it can be considered to have passed the initial acceptance, and whether it can ultimately pass the final acceptance will only be known after running stably for a period of time.