1 前言

随着腾讯云轻量服务器到底时间越来越近，我一直在犹豫是否续费，第一年是99元/年，第二年我记得是300元/年(记不太清楚了，左右吧)，而第三年的价格是多少呢？看了一下，好家伙：

本来我就觉得备案没啥用了(电信在打击有入向HTTP流量的、有公网IP的家宽，这样一来，国内CDN回源主机直接指向家宽公网IP对应的动态域名这种方式就没用了)，加上国内VPS平时使用中的各种不变(不能正常访问docker、git、apt等等，非要折腾，烦死了)，早就想放弃了，只是想着保留着备案，万一哪天排上用场了呢。

可是加上这次的续费价格，直接打破了我最后一点念想，这让我最终下定决心：域名注销备案，也迁到cloudflare；同时我的云上冗余数据中心也同步搬迁到境外的VPS，那么，接下来面临的第一个问题，就是往哪儿搬呢？

2 VPS的选购

2.1 选购标准

境外可选的VPS供应商实在是太多了，按理说选择面应该很宽，不过，对于我而言，几个衡量指标下，选择面其实很窄，主要从如下几个面来考虑：

2.1.1 价格

之前腾讯云服务器280左右一年的时候，我的忍受力就快到顶了，所以目标VPS的价格就以这个作为上限了，差不多就是40美金左右一年。

一般来说，VPS的售卖有月付和年付两种，我这一年40美金上限的要求(按月付算，3.3美金)，其实基本上把绝大部分的选择都排除掉了～，如果再排除”只有每年黑五之类等特殊时期才能买到的套餐”这个条件，也就是说，”平时都能买到”这个要求，其实最后只剩下了一个选择了：Racknerd。

厂商	特点	日常能买到的便宜方案？
RackNerd	打折多，低价方案多	经常有（如 $10.99/年）
HostHatch	有促销就香	日常偏贵
GreenCloud	线路不错，有CN2可选	基础款 > $40
VirMach	价格极低但容易翻车	时好时坏，不推荐重要用途
CloudCone	面板好用，速度一般	稳定性口碑差
BuyVM	便宜高质量，但秒没	你抢不到
LiteServer (荷兰)	中规中矩	有时候能买到 EUR 30/年
HostHatch / Netcup / Contabo	资源大户，价格便宜	日常一般超预算或限制较多

2.1.2 性能

我之前购买的国内最低端的腾讯云轻量服务器来看，最低性能的配置是：2核2G内存，40-50G SSD系统盘，85折价格分别是459/年和510/年(我就是510/年这个，被99元的优惠价忽悠进来的)：

相对而言，其实一开始选香港及其他境外地域更便宜，可惜我当时是因为要备案，所以只能硬着头皮上了内地地域这个车(当然，99元/年的价格因素也占了一半原因)：

如果真要正常跑一些docker(包括wordpress之类的应用)2核2G内存+40GB硬盘应该算是最低配置了。其实40G硬盘都有点紧张，还需要经常监测和清理磁盘，否则稍微有点问题，如果日志策略没提前配置好，都容易把硬盘占满，我腾讯云轻量服务器的磁盘经常性的80%～90%多：

所以性能方面，我的要求是2核2G内存 + 40G硬盘打底，上不封底。

2.1.3 流量

2.1.3.1 计量方式

---

这方面我其实没啥要求，因为我并不会直接用VPS的公网IPv4地址来发布网站或者用做科学用途(就算有也是备用)，我都是要套cloudflare CDN的，所以流量也是用在cloudflare对应用的回源上，基本可以忽略不计。不过，如果有些朋友有些特殊需求，比如刷PT流量，当科学工具等，那流量肯定越大越好。

---

在选购 VPS 时，流量计费方式是容易被忽视但非常关键的一环。尤其当你需要进行大量上下行传输时，不同厂商间的计费逻辑会直接影响你的使用成本和可用性。

以下是国内主流云厂商与国外 VPS 提供商的流量计量方式对比：

项目	国内 VPS（如阿里云、腾讯云）	国外 VPS（需区分类别）
下行流量（Ingress）	通常不计费或无限（拉多少都免费）	单向计费型厂商（如 Vultr、DO、Linode）：不计费 双向计费型厂商（如 RackNerd、Hetzner）：计费
上行流量（Egress）	按量计费或有限（如部分套餐含 1Mbps 免费）	几乎所有国外厂商都计费，无论单向或双向模式
流量统计方式	仅统计上传（出站）方向的流量	– 单向计费：仅统计上行（出站） – 双向计费：上下行合并计入总流量
流量限制表现形式	常见为“上行限速”或“超出部分按量计费”	按“月流量包总额”计，超出则限速或断网（例：1500GB/月）
适用场景推荐	PT、缓存镜像站、低频任务、自用挂机脚本等	建站、反代中转、代理服务、跨境访问服务等

2.1.3.2 实际案例说明

国内 VPS 示例：

• 从公网下载 100GB 数据 → 不计流量
• 上传种子文件或数据 30GB → 计流量
• 合计月流量消耗：30GB

国外 VPS 示例：

• Vultr / DigitalOcean（单向）：
  • 下载 100GB → 不计费
  • 上传 30GB → 计入流量包
  • 总计消耗：30GB
• RackNerd / Hetzner（双向）：
  • 下载 100GB + 上传 30GB → 计入 130GB
  • 假设套餐为 1500GB/月，剩余：1370GB

实用建议：

• 需要高下载量（如爬镜像、缓存、抓站）的任务，国内 VPS 非常适合，尤其流量包虽然小，但只计上传。
• 建站、做代理服务，或 CDN 回源服务器使用，推荐国外 VPS，优先选择单向计费型厂商，如 Vultr。
• 选择 RackNerd 等便宜年付 VPS 时，注意其流量为双向合计，若中转高流量请做好预算与限制策略。

2.1.4 地理位置

一般来说，对 VPS 地理位置有要求的朋友，其实并不一定是真的对”物理位置本身”有要求，本质上是对国内直连访问延迟有要求：这种延迟主要受限于VPS 所在机房的线路质量和与中国运营商之间的直连情况，而非地理距离本身。

有时候，物理上更近的节点反而表现更差，物理上更远的反而延迟更低、速度更快。这是因为：

• 中国的国际出口本身带宽紧张，
• 多数普通 VPS 走的是绕路三网骨干（比如香港绕美、绕新加坡再返回）或者国际中转回程，
• 真正低延迟、高质量的访问依赖的是像 CN2、GIA、CUVIP、CTG 等具有直连属性的线路。

举个常见的例子：

• 洛杉矶(特别是 Cera/Krypt 等机房) 物理上比芝加哥远，但由于一些 VPS 提供商部署了 CN2 GIA 回程线路，实际访问延迟能做到 140ms 内，比一些香港、东京、首尔的”非直连”机房还要快。
• 相反，有些香港、新加坡机房如果没有走高质量线路，反而会因为回程绕路导致延迟高达 250ms 以上。

因此，选 VPS 的地理位置时，不应该只看地图，更应该关注其回程线路质量：很多人选择洛杉矶或者圣何塞，并非真的在意这两个城市的位置，而是因为这些地方集中了很多对中国友好、回程走优质线路的机房。

注1：在意国内直连访问延迟的朋友，如果VPS只能在美国境内选择并且有Los Angeles或者San Jose的选择，尽量选择这2个。

注2：VPS在Los Angeles或者San Jose也未必就是CN2、GIA等精品线路，也和购买的套餐有关，太便宜的套餐(比如10.99美金/年)肯定别想，当然，即便没有，延迟也会比较低，以我2台VPS的延迟为例，芝加哥的ping包延迟在220多毫秒(现在禁ping了，不好截图了，懒得改配置)，圣何塞的180多毫秒：

如果是走的CN2、GIA等精品线路，国内直连延迟可以低于140毫秒，甚至100毫秒以下，当然，年付几十美金这种层次大概率也没机会使用精品线路。

---

有一个问题大家需要意识到：ICMP Ping 延迟 ≠ 实际 TCP 应用质量，因为：ICMP 是最不靠谱的”服务质量”指标之一：

• ICMP(就是 ping 包)本来是被广泛限速、丢弃、QoS 优先级极低的协议；
• 很多 VPS 宿主机直接对 ICMP 做策略限制：延迟高、丢包假象；
• 在 GFW 的环境下，ICMP、UDP 统统不被优待，只有 TCP 443（HTTPS）最”被友好”，甚至带有假象稳定性；

最终的结果可能是：你看到 ping 稳定、延迟低，并不代表 TCP 用起来一定好，也可能反过来：ping 很差但 TCP 很稳。

真正可靠的直连访问评估方式：

协议	传输稳定性	GFW干扰	说明
TCP 443端口	极高	最低	用作主通道的理想选择（Cloudflare Tunnel 就是这样）
TCP 其他端口	较高	轻微～中度	如 22/80/8080 可能被限速或识别
UDP 任意端口	不稳定	中～高	容易被限速、QOS 降优先级、甚至投毒（尤其是 DNS）
ICMP（ping）	很差	高	仅作简单连通性参考，不能做性能评估依据

一句话总结：Ping 只能当个可达性参考，不能代表实际网络使用质量，尤其是跨境/跨云环境中。 现实中的通信质量顺序：TCP 443端口 > TCP 其他 > UDP > ICMP。

---

注3：其实如果不使用 VPS 的公网 IP 直接发布网站（比如直接开放 443 端口让用户访问），也不打算在上面部署需要”国内直连”的科学上网工具，那么”国内直连访问延迟”这个指标就变得没那么重要了——尤其是在你采用 Cloudflare Tunnel 来发布应用的架构下。

在这种架构里，用户的访问流量实际上并不会直接打到 VPS，而是先进入 Cloudflare 的全球边缘节点，再由 Cloudflare 自己的内部网络去”拉取”源站的数据。因此，这时真正重要的是：源站和 Cloudflare 网络之间的连通性、稳定性和回源响应时间。

从这个角度看，芝加哥反而是比洛杉矶、圣何塞等西海岸节点更合适的源站候选:一方面，西海岸虽然物理距离中国更近，但大量廉价 VPS 都挤在那一带，线路拥堵、晚高峰时段丢包延迟飙升早已是常态；而另一方面，芝加哥作为中部节点，虽然离中国稍远，却常年保持网络质量更平稳、波动更小，回源表现更加可控。

更重要的是，Cloudflare 在美东、美中这些节点往往有更强的骨干连接资源，回源路径也更短更快。在 Tunnel 架构下，我们真正依赖的是 Cloudflare 与源站之间的稳定”拉通”能力，而不是国内用户与源站之间的直连速度。所以相比之下，芝加哥更像是一个安静但可靠的后方基地，非常适合托管 C 类核心服务，比如 WordPress 博客、个人首页等对访问质量敏感、对直连毫无依赖的业务。

所以，如果说我最初还因为没有选圣何塞/洛杉矶而心存些许”精品线路焦虑”，那么现在可以很安心地说：芝加哥节点才是我当前架构下的最佳源站选择，稳定、低成本、且兼顾了全美及欧洲用户的快速回源。

2.2 最终选择：Racknerd的882

其实，对于我而言，只要考虑了价格这个因素，就只有Racknerd这一个选择了，当然，如果性能不满足要求(地理位置和流量只是对我而言没无所谓，但是对很多需要直连体验的朋友来说确实刚需)，即便价格我也不会去选择，因为我对性能这一点还是有不低的要求的，毕竟要作为我家庭数据中心的云上冗余数据中心，相当多的应用都要跑在上面，而对于流量和地理位置，由于cloudflare的”众生平等”，我完全没有要求。

最终我选择了882(2024年黑五促销套餐：Racknerd_高配1_882)，其在高配档次中算是性价比最高的了：

性能完全符合我的要求，流量太多，根本用不完，提供SolusVM控制面板，最关键，价格40美金，基本就是280左右的上限，完美!

注1：Racknerd的高配、中配、低配也有多种选择，最低10.99美金/年，当然，那个配置很低，只能用来做跳板机～，更多配置参见文章：无敌推荐。

注2：对国内直连延迟有要求的朋友，下单的时候手不要太快，先就要选好位置，比如选择圣何塞(DC02机房)，默认是芝加哥(DC03机房)，国内直连访问延迟多了起码40毫秒，不要问我怎么知道的(虽然其实差别不大，我也对直连没啥要求，但是也不爽了好几天～)：

注3：购买之后登录方式和账号密码会发送到注册时候的邮箱里。

3 迁移域名

选好了VPS之后，我就直接把之前的备案域名从dnspod迁到cloudflare，这样我除了主用”.com”域，之前用来备案的域名就作为备用域名，来进行一些对比测试，而”.xyz”域名到期后就直接放弃了(.xyz结尾的颜色网站实在太多，拉低了这个域名后缀的档次～)。

以下简单记录下从腾讯云dnspod将域名迁移到cloudflare的过程，之前迁移过一次，不过忘记记录了，这次补上：

然后会根据选择的方式来添加DNS记录，之后是最后一步：

然后点击页面下方的继续：

之后的操作在在腾讯云的dnspod上了。

确认没有开启DNSSEC功能：

如果开了安全锁，需提前关闭：

之后就是等待cloudflare的邮件了:

以上步骤是将域名托管从腾讯dnspod迁移到cloudflare，但是实际的域名注册(续费)仍然在腾讯dnspod。如果想将域名注册机构也迁移到cloudflare，就还需要一步”转移域”：

因为我当时转移域的时候忘记截图了，现在也没有空闲域名供我操作，所以图就不截了，其实主要就是选择要转移到cloudflare的域名，然后在腾讯云那边生成一个授权码，在这边输入授权码即可，最后在第三步”联系人和付款信息”那里付了一笔费用(好像是8美金来着？记不清了)，之后等待5-7个工作日即可。

4 重点应用容灾方式的升级

4.1 腾讯云VPS时期容灾模式

之前，我将应用分为了3类：A类、B类和C类：

• A类：需要消耗大量资源，或者依托于家庭数据中心内网数据或者计算资源的，比如emby、lobechat-database、长亭雷池WAF等，这些应用只运行在家庭数据中心内部(emby需要定期扫描本地NAS上的影视资源；lobechat-database较为消耗资源，且有时候需要调用本地M4 pro的macmini上运行的ollama本地模型；长亭雷池太消耗资源了，在腾讯云上那可怜的2核2GB内存的轻量服务器上部署，基本上VPS就不用干别的了～)
• B类：适合部署在腾讯云轻量服务器上的应用，比如bitwarden、tailscale derp中继服务器，以及其他一些较为轻量的应用都可以算成B类，能上云服务器的尽量上(不过，由于2核2GB这个配置只能算入门级配置，上不了多少就撑不住了~)。
• C类：这就是我最核心的应用了，当时只有一个：博客，为了能对核心应用进行灾备，所以同时在家庭数据中心以及腾讯云轻量服务器上都部署了博客，配合数据库同步机制(家庭数据中心数据库导出、syncthing同步到腾讯云节点、腾讯云节点自动导入)以及腾讯云节点对家庭数据中心可达性的监控，可以实现当家庭数据中心断电、断网时博客服务的自动接管(参考文章：家庭数据中心系列 活用cloudflare tunnel实现wordpress主站点故障时灾备站点自动接管)。

所以，家庭数据中心正常时应用的入向访问流量如下：

当家庭数据中心断电或者断网的时候，应用的入向访问流量如下：

所以，之前的容灾方式，目的仅仅是保证家庭数据中心有问题时，C类核心应用(当时只有博客)不至于中断。

但是，原有的容灾切换逻辑其实并不完善，问题的根源在于腾讯云节点如何探测家庭数据中心的健康状态：

由于我家宽带使用的是动态公网 IP，一般三天左右就会变一次，这就导致无法通过固定 IP 来做可靠的探测（更别说大部分人家宽甚至没有公网 IP，只有商用网络才可能有固定 IP）。

理论上可以用动态域名来解决 IP 变更的问题，但现实中 DNS 缓存的刷新时间并不确定，一旦公网 IP 已变而 DNS 仍未更新，就会出现一个短时间内的”双活”状态，即腾讯云和家庭数据中心同时在线，导致 C 类应用（比如博客）无法保证访问一致性，这是我无法接受的。

最终，我选择以部署博客的 macmini 的 Tailscale IP 作为探测对象(腾讯云轻量服务器也部署了 Tailscale)。这个方案的原理是：即便公网 IP 改变，只要 Tailscale 能够在变化后快速恢复连接，就能用 Tailscale 通信状态来判断家庭数据中心是否可用，从而控制是否切换博客主节点。

但是，即便是这样也有隐患：如果macmini上的tailscale工作不正常怎么办(也是血泪的教训，参见文章：家庭数据中心系列 一个”馒头”引发的血案:记因为升级tailscale而引发的这几天博客访问异常的现象)?

所以，我一直对之前的容灾方式很不满意，可是又没有什么好的办法可想。

---

为什么不接受双活？主要在于之前我的cloudflare还是free订阅计划时，所谓WAF免费托管规则实质上就是完全没用，所以安全问题我是靠家庭数据中心内部署的”长亭雷池WAF社区版”来挑大梁的。如果平时启用了双活机制，那么有可能接近1半或者超过一半的访问会直接发送到腾讯云节点，而性能远远不足以部署一个长亭雷池WAF的腾讯云节点就是一个不设防的”美女”，总不可能都指望免费版的wordfence去抗吧？

所以，当时的条件，腾讯云节点最多就只能作为博客的”真·灾备中心”，临时顶一下，等家庭数据中心恢复访问就放弃对C类应用的接管。

---

4.2 Racknerd VPS时期的双活模式

随着我3月初”半推半就”的成为了高贵的cloudflare Pro订阅用户，经过这2个月以来的观察，家庭数据中心内网的”长亭雷池WAF”基本上没有任何安全警报了，充分证明了WAF的托管规则集的确发挥了巨大的作用(果然给了钱的待遇和白嫖完全不是一个档次的)：

所以，这个时候”长亭雷池WAF”已经结束了它的历史使命，也意味着C类应用的”双活”正式走上了历史的舞台。

趁着本次VPS搬家，我重新梳理了一下现有的应用，由于Racknerd 882的配置不低(3核4.5G内存100G纯SSD硬盘)，所以我将更多的应用划分到了C类，这时正常的入向访问流量如下：

当家庭数据中心断电或者断网的时候，应用的入向访问流量如下：

看起来家庭数据中心断电或者断网时候的切换和之前一样，但是其实内在逻辑完全不同了：这个切换行为不是由我来控制(之前是靠探测脚本)，而是由cloudfalre tunnel的默认机制来主导：当发现同一个tunnel的多个connector中有一个工作异常，就将该connector从流量分发的多个目标中排除掉，而当发现connector恢复时，又自动加入流量分发目标，所以，现在的切换逻辑就非常完美了。

同样的，当Racknerd节点的VPS出问题，C类应用的所有回源请求只会被发送到家庭数据中心：

当然，A 类和 B 类应用就没有这个待遇了，不管哪个节点故障，相应的服务都会随之中断。不过这些应用基本都是我自用的，无伤大雅。

---

这个机制是cloudflare tunnel默认提供的，最多支持同一个tunnel部署4个connector：

关于connector详细说明，参看文章：家庭数据中心系列 cloudflare教程(九) Zero Trust常用功能介绍及多场景使用教程。

---

目前，我一共有3个cloudflare tunnel，wudihome(对应于A类应用、racknerd-chicago(对应于B类应用和和loadbalance_w_r(对应于C类应用：

其中，对应C类应用的tunnel:”loadbalance_w_r”中有2个connector，分别对应家庭数据中心和Racknerd的芝加哥节点：

同时，C类应用也从之前只有博客，变成现在的9个应用：

包括博客在内的C 类核心服务，通过家庭数据中心和 Racknerd 节点的双重部署、数据库自动同步机制以及单一tunnel下多个connector智能故障切换逻辑，实现了接近 99.9994% 的可用性——理论上全年服务中断时间不超过 3 分钟，即便任意一侧故障，另一侧也能自动接管，确保服务始终在线。

---

99.9994%的可用性可不是随口一说，按照我的经验，目前一年中家里断电断网的总时间不会超过1天，也就是1440分钟(电力系统例行维护居多，断网基本没有发生过，除了那次我被通管局直接封号3天～)；而Racknerd参考行业的99.9%的高可用性，算8小时，也就是480分钟，那么可以得出下列结果：

C类服务高可用性估算依据(双节点部署)

项目	家庭数据中心	Racknerd 芝加哥节点
年度最大中断时间估算	1 天 = 1440 分钟	8 小时 = 480 分钟
年度可用性	99.73%	99.9%
是否部署C类服务	是	是
常见故障原因	停电、断网、本地设备异常	VPS 网络波动、运营商维护、机房故障
故障切换方式	失联后由 Racknerd 自动接管	失联后由家庭数据中心自动接管

整体服务可用性估算（双活架构）

项目	说明
故障独立性假设	两节点宕机为相互独立事件
双节点同时宕机概率	≈ (1 ÷ 365) × (0.33 ÷ 365) ≈ 0.0000025
年度理论中断时间	365 × 24 × 60 × 0.0000025 ≈ 3 分钟
理论博客服务可用性	99.9994%（业界”5 个 9″级别）
高可用性保障机制	数据同步（Syncthing + 自动导入） + cloudflare tunnel 多connector故障自动切换

---

注1：Cloudflare Tunnel 的能力不只是多个 Connector 的多活和故障切换那么简单，咦，有点耳熟：

同时，它还能根据访客位置的选择最近的源站，”尽力而为”的实现就近访问(行就行，不行就算了，非常的佛系)，关键还不提供基于访客的源站访问粘连(也就是说，这次回源可能是芝加哥节点，下一次回源就走家庭数据中心)，不过即便如此，我也很满意了，毕竟免费能用到这种程度已经很知足了。 所以，事实上现在我的Racknerd芝加哥节点已经是C类应用有回源需求时的主要源站了(因为国内访问基本都被分配到美西的数据中心，比起位于国内的家庭数据中心，当然芝加哥节点的源站要近得多～)，虽然说平时大多都是访问的缓存数据，回源其实并不多，但是不知道为什么，我总感觉C类应用的打开速度都变快了，也不知道是不是幻觉～。

注2：熟悉双活或多活数据中心架构的朋友应该都清楚，实现多数据中心的应用双活或多活部署，其前提之一是各节点提供的服务内容必须一致。也就是说，多个节点之间的应用需保持同步，无论是静态资源还是动态数据，都不能出现差异。特别是在涉及数据库的场景中，要求更为严格——各节点的数据必须高度一致，才能避免用户请求在不同节点之间切换时产生数据错乱或状态丢失的问题。

因此，虽然 Cloudflare Tunnel 提供了多 connector 支持，通过在多个节点运行相同的 tunnel 配置，可以实现请求的自动分发和容灾切换，但这并不意味着所有类型的应用都能直接实现”多活”。如果你的服务包含状态信息、数据库写操作、或用户会话等，就必须确保这些状态能在多个节点间同步，或者设计为无状态服务，才能真正发挥多 connector 带来的冗余与高可用优势(我的多wordpress站点之间的数据同步方案参见文章：家庭数据中心系列 wordpress多节点”半自动”、”近乎”实时同步方案)。

注3：通过 Zero Trust 仪表盘创建的 Cloudflare Tunnel，可以使用两种方式部署连接器(connector）：service 模式和 docker 模式。其中，service 模式是官方推荐的部署方式，使用命令 “cloudflared service install ” 来创建系统服务。但由于同一台机器上不能存在多个同名的 systemd 服务，这种方式默认情况下只能部署一个 tunnel，如果需要用service方式部署多个 tunnel，也可以通过手动修改 systemd 配置、使用不同的服务名称，来实现多个连接器的运行。

相比之下，docker 模式则更加灵活：由于每个容器都是相互隔离的运行环境，可以轻松部署多个 connector 实例，即便它们对应不同的 tunnel，也不会相互冲突。因此，从部署多 tunnel 的角度来看，Docker 是更适合在同一个节点上运行多个连接器的方式(当然，稳定性方面不如service方式)。

注4：双活部署还有一个关键问题需要解决，那就是读写分离。在确保两个 WordPress 节点内容一致的前提下，”读”请求（准确地说，是用户访问时触发的回源请求）可以分散到任意节点，这样可以有效分担负载、提升访问速度。但”写”请求就完全不同，尤其是更新网站内容或者发表评论这种涉及数据库写入的操作，必须严格限制只能提交到一个主节点，否则极容易引发数据混乱，甚至评论丢失。

在我的架构中，这个”主节点”是部署在家庭数据中心 mac mini 上的 WordPress，同时也是安装了 Cloudflare 插件、负责自动刷新 APO 缓存的节点。更新网站内容还好说，可以通过自己登录”主节点”操作来控制写入节点，但是评论就不好处理了，那个是由cloudflare的多connector的机制控制的。就为了实现评论请求强制写入主节点，我想了不少骚操作，最后才找到一种最简单的实现方式，期间真是踩了不少坑，着实把我折腾了一通。

由于启用了双活架构，许多配置细节与我在”家庭数据中心系列：活用 Cloudflare Tunnel 实现 WordPress 主站点故障时灾备站点自动接管“中写的内容已经有所不同，再加上这次补充实现的”读写分离”，我会在之后单独用一篇文章详细介绍整个思路、配置方案与踩坑记录。

5 Racknerd VPS的”全封闭”安全策略

5.1 “全封闭”安全策略是什么？

关于 VPS 的安全策略这一块，我其实一直奉行的是一种”全封闭”策略。何为”全封闭”呢？简单说，就是默认不开任何端口，不接受任何来自公网的主动连接请求。即使是像 SSH 这样的基本服务，我也尽量不暴露在公网之下。能通过内网访问的，绝不走公网；能通过点对点的加密隧道通信的，绝不使用明文或传统端口暴露。

在实际操作中，这意味着我通常会把防火墙入向流量的策略设为”默认拒绝”，也就是 UFW对所有入向的TCP和UDP数据包全部设为 deny：

---

其实，最理想的状态，是整个 VPS 看起来像是”隐形”的：对外没有开放端口，任何扫描器扫不到任何服务，黑客也无从下手。可是，仅靠”默认拒绝”并不能实现”隐形”效果，真要完全”隐形”，需要drop掉ICMP echo包的入向访问，同时对所有入向的TCP和UDP包也进行drop处理，而这仅靠UFW的常规配置规则是无法实现的，必须使用iptables或者nftables。

---

当然，这种策略听起来激进，但其实操作起来并不复杂，关键是需要用一些现代工具做辅助：比如，我会用 tailscale 搭建点对点的内网网络，使用tailscale的IP进行平时的运维管理，通过这种方式实现”只在私有网络中通信”，从运营商角度只能看到我在使用Wirdguard协议通信，但是实际通信内容却看不到(当然，就算看不到，也可以干扰你：主动丢包甚至直接屏蔽掉不让你用～)。

5.2 “全封闭”安全策略的核心技术：Cloudflare Tunnel

很多人理解的”全封闭”，只是一个方向上的防御姿态——比如关掉端口、不接受连接、不暴露 SSH。但问题来了：如果你真这么做了，那 VPS 上跑的服务你自己怎么用？难道连SSH登录都不能？服务也就只能自己玩自己？443端口不开如何访问网站？这时候，”全封闭”就不再是安全策略，而是无聊的自娱自乐了。

因此，全封闭必须和”基于隧道的反向访问”能力配套，否则就是在搞自闭。而 Cloudflare Tunnel 就是解决这个矛盾的核心技术之一：它能够把内网服务安全地暴露出去，但不需要暴露端口，也不需要设置复杂的反向代理，只要本地出得去网、能连上 Cloudflare，就能建立安全通道，这对于需要公网访问服务、但又不想开启任何外部端口的场景非常友好。

它的原理本质上就是让 VPS 主动向 Cloudflare 发起连接，然后把本地服务通过 Cloudflare 的网络反向暴露出去。因为是”主动连接”，所以 VPS 这边不需要开任何端口，就像一个客户端一样，只要能出得去网，就能建立隧道。

它的好处有几点：

1. 无需暴露任何端口：不管你在 VPS 上跑的是 web 服务、后台管理页面还是你自己写的小程序，都可以通过 tunnel 对外提供服务，公网访问只走 Cloudflare，VPS 对外依旧是”全封闭”的。
2. 支持访问控制：Cloudflare Access 让你可以基于身份（比如 Google 账号）来做访问控制，甚至 MFA。相当于自带认证网关，避免了在服务本身上重复造轮子。
3. 应对端口限制与运营商阻断：有些 VPS、尤其是国内云服务商对端口有各种”莫名其妙”的限制，尤其是 80/443，Cloudflare Tunnel 完全不依赖这些端口，直接穿透，是对抗限制的一种武器。
4. 灵活路由 + 高可用：结合 Cloudflare 的负载均衡和多端隧道能力，可以做到非常灵活的后端切换。例如，我目前就是在家庭数据中心和海外 VPS 各跑一个隧道实例，通过 Cloudflare 的负载均衡机制自动判断谁在线，自动切流量。这一切，都在”全封闭”的前提下实现了。

可以说，Cloudflare Tunnel 本质上是一种“隐身式服务暴露”手段，非常符合我的”打死不开放端口但是又偏偏要对外发布应用”的不讲理哲学。

关于cloudflare tunnel的详细配置步骤请参看文章：家庭数据中心系列 通过tunnel技术，让无公网IP的家庭宽带也能白嫖cloudflare实现快速建站(推荐)。

5.3 “全封闭”不是解决一切安全问题的灵丹妙药

虽然”全封闭”的安全策略确实能解决很多日常的小麻烦，比如防止端口扫描、缓解爆破攻击、规避云服务商的奇怪规则，甚至能在很大程度上免去复杂的防火墙策略配置，但这并不意味着一劳永逸，更谈不上可以高枕无忧。

首先，全封闭并不等于绝对安全。从网络层面看，虽然所有入站连接都被屏蔽了，但这台机器依然会主动发起连接，比如运行 Cloudflare Tunnel、软件更新、同步数据等，这些出站流量依然可能成为潜在的攻击面，尤其是当本地服务存在某种被劫持或 DNS 欺骗的可能性时。

其次，攻击者并不总是”从外面来”。很多时候，真正的风险来自你自己部署的服务，尤其是通过容器或脚本快速搭建的各种应用(包括wordpress)。就算外部访问路径是”全封闭”的，但一个配置不当的服务、一个失控的 shell 命令、一次低质量镜像的拉取，都有可能给系统带来持久的内伤，而这些恰恰是”全封闭”策略防不住的。

还有一点非常现实：安全策略从来不是静态的。你今天封住了所有端口，但明天项目需求一变，可能就要临时暴露某个服务；你今天只跑一个 Tunnel，明天也许要加个旁路代理、加个面板……这种变化本身就意味着风险增长，稍有松动，整个”全封闭”的结构就可能出现缝隙。而人的习惯往往是：一旦尝到便利，就会开始松懈，最后”全封闭”可能就变成”漏个小口不碍事”。

所以，我一贯的理解是：“全封闭”是一种基础态势，而不是终极方案。它可以极大地降低被动暴露的风险，但你依然需要持续的安全意识，包括：

• 定期审计自己有哪些服务在运行；
• 检查每一个出站连接背后的逻辑；
• 尽量使用最小权限运行服务；
• 对所有容器、脚本、依赖保持警觉；
• 关键应用最好还是做日志留痕 + 异常监控。

就像一个把门关得很紧的屋子，并不等于屋里就一定安全。屋里的电线、瓦斯、插座，照样需要天天注意。网络安全从来就不是只靠”关门”能解决的事。

5.4 “全封闭”安全策略的劣势

“全封闭”安全策略虽然带来了显著的防护收益，但它也并非没有代价。最直接的问题，就是大量原本可以简单通过直连访问的服务，在”全封闭”策略下变得异常复杂，甚至难以使用，比如：

1. 搭建基于 trojan-go、xray 等的代理服务时，原本只需要开放一个端口绑定 TLS 证书即可接入，但在全封闭状态下，入站端口一律被拒绝，这类依赖直连的方案完全无法部署，只能另寻他路。
2. 如果通过 Tailscale 地址来访问 VPS 上的服务，会发现第三方代理加速工具（如 Surge、Clash、Quantumult）无法直接接管流量。因为这些工具往往只支持代理公网 IPv4 地址，而不是 Tailscale 这种虚拟内网地址，这导致从国内访问某些 Tailscale-only 服务时延迟高、不稳定，体验打了折扣。
3. 文件传输变得麻烦。像 rsync、SFTP、WebDAV 这类服务，如果不能建立主动入站连接，往往需要借助反向连接或者中转服务，否则只能通过像 Cloudflare R2、OneDrive、iCloud 之类的云同步方案替代，灵活性大打折扣。
4. 在一些远程运维场景下，比如使用 mosh、VS Code Remote、x11 over ssh、frp/nps 等工具，很多都依赖双向连接或者一定的连接顺序，全封闭环境下无法直连，等于是要重新设计整个运维路径。
5. 全封闭的入站策略还容易影响容器与宿主机之间的正常通信，尤其在 Docker 默认的 bridge 网络模式下表现明显。由于 UFW 默认会拦截所有入站连接，即便这些连接源自同一台主机上的容器，只要数据流经宿主机的网络接口（如 docker0），也可能被当作“外部入站流量”而被拒绝，导致容器无法访问宿主机上的服务。例如，使用 Docker 部署 Cloudflare Tunnel 时，如果不是采用 –network=host 模式，Tunnel 容器可能连不上宿主机上的服务；又如 Nginx Proxy Manager（NPM）容器即使本地监听端口正常，也无法通过反向代理访问宿主机的 WordPress 服务。这种情况会导致很多本应“本地打通”的组件之间通信失败，增加调试和部署的复杂度。

因此，”全封闭”其实并不是一个可以简单套用的策略，它更像是一种基础态势控制：你需要在此之上，结合自己场景选择适合的补充方式：比如使用像 AnyTLS 这类支持内嵌反向连接并可以配合cloudflat tunnel使用的科学工具，或者自己搭建一个中转层(如基于 Cloudflare Tunnel 的统一入口），所以，有得必有失，但是，运用之妙，又存乎一心。

注：其实单独购买一台便宜的VPS(比如10.99美金/年那种)来作为SSH跳板机、自建科学工具机等就可以解决绝大部分问题～。

6 后话

后续的VPS初始化、各种应用的搭建都是体力活，没啥技术含量，就不写了。

经过这一周的忙活，Racknerd的芝加哥节点已经正式投入运行，期间我也分别在家庭数据中心以及芝加哥节点进行了几次C类应用的宕机测试，都没发现什么问题，所以也算是通过了初验，而最终能否通过终验，就要稳定运行一段时间之后才能见分晓了。