[scode type="green"] 家里的 NAS、博客、影音服务和一些实验环境，最开始都是“能访问就行”。后来跑的服务越来越多，异地备份、远程访问、跨站点访问也慢慢加了进来，单纯依赖 **DDNS + 端口转发** 就开始不太够用了。 动态公网 IP 会变，运营商会调整线路，路由器也可能重启。更麻烦的是，家里的业务一旦直接暴露在公网，SSH、RDP、SMB 这些端口很快就会被扫描到。只要再碰上弱密码，NAS 和家用服务器就可能变成攻击入口，放大攻击平面。 所以我现在使用的是一套基于 **SD-WAN 思路** 搭建的家庭私有云网络：用 WireGuard / IPsec 负责加密组网，用 FRR + OSPF 负责动态路由，用公网 VPS 作为所有公网业务访问的统一入口，再配合 WAF 反向代理，把公网访问、内网管理和站点之间的业务流量分开 ::aru:thumb:: 。 [/scode] 这套架构的目标很简单： - HOME 1、HOME 2 使用 DDNS 维持动态地址可达，VPS 作为所有公网业务访问的统一入口。 - HOME 1 提供 OpenVPN，HOME 2 使用 WireGuard，HOME 1 和 HOME 2 之间通过 WireGuard 直连。 - 所有 VPS 同时接入 WireGuard 和 OpenVPN 两套隧道网络。 - HOME 1 和 HOME 2 之间的内部业务优先走 WireGuard 直连，直连故障时再切换到 VPS 中继。 - 主站点不可用时，公网业务可以切到异地灾备站点。 - 公网只暴露 Web 入口，管理面和存储面尽量不直接暴露。 - 所有DDNS 使用阿里云 专业版DNS，减小TTL，缩短故障恢复时间。 ## 一、先看整体拓扑 下面是我目前这套网络的逻辑拓扑。为了方便理解，可以把它看成“云端入口 + 两个家庭站点 + 一个共享站点”。  这里有一个比较重要的设计：**VPS 负责所有公网业务访问的入口，但不负责承载所有站点之间的内部流量。** 普通用户访问博客、Web 服务或影音服务时，都会先到 VPS 的 WAF 和反向代理，再由 VPS 通过 WireGuard 或 OpenVPN 隧道访问 HOME 1 或 HOME 2 的后端业务。正常情况下，HOME 1 和 HOME 2 之间的 NAS 同步、文件访问等内部流量通过 WireGuard 直接通信；只有直连链路出现问题，OSPF 才会把跨站业务切到 VPS 中继。这样既能保证公网业务入口统一，也能减少内部大流量对 VPS 带宽的依赖。 ## 二、为什么不用DDNS + 端口转发就到此为止了呢 DDNS 本身没有问题，它解决的是“域名跟着动态 IP 变化”的问题。在这套架构里，HOME 1 和 HOME 2 都使用 DDNS，分别作为 OpenVPN 和 WireGuard 的稳定访问地址。但 DDNS 本身解决不了下面这些事情： - 家庭公网 IP 变化之后，所有访问都要重新依赖这条线路。 - 家庭宽带断线时，公网服务直接不可用。 - 多个服务需要开放多个端口，攻击面会越来越大。 - HOME 1 和 HOME 2 之间没有统一的路由控制。 - HOME 1 和 HOME 2 之间的 NAS 同步、跨站影音这类大流量业务会绕到公网入口，体验和成本都不理想。 所以我把“访问入口”和“业务所在位置”拆开了。公网用户只需要访问 VPS 的域名，VPS 再通过 OpenVPN / WireGuard 隧道访问后面的业务节点；站点之间则优先通过 HOME 1 和 HOME 2 的 WireGuard 直连。家庭宽带只作为站点出口和隧道承载线路，不再直接对公网提供业务入口。 ## 三、站点和网段怎么规划 异地组网最容易踩的坑就是网段冲突。两边都用 `192.168.1.0/24`，一开始看不出问题，等到需要跨站访问 NAS 或配置动态路由时就会发现：路由器根本不知道这个地址到底应该往哪边发。 因此我的网段尽量做到每个站点唯一。 | 站点 | 作用 | 网段 | | -------------- | ---------------------------------------------- | ------------------ | | VPS 1 | 统一公网业务入口、WAF、反向代理、备用中继 | `66.66.66.254/24` | | VPS 2 | 备用公网入口和灾备入口 | `66.66.66.253/24` | | HOME 1 | 主数据中心、博客、NAS等 | `10.254.95.0/24` | | HOME 1 | Manage Network | `10.0.0.0/24` | | HOME 1 | 无线网络 | `10.254.254.0/24` | | HOME 2 | 异地私有网络 | `192.168.123.0/24` | | HOME 2 | 灾备业务和备份 NAS | `192.168.122.0/24` | | HOME 1 DDNS | HOME 1 的 OpenVPN 服务访问地址 | 动态公网地址 | | HOME 2 DDNS | HOME 2 的 WireGuard 访问地址 | 动态公网地址 | | OpenVPN | 远程访问，以及 VPS 的 OpenVPN 接入 | `10.7.7.0/24` | | WireGuard 骨干 | HOME 1、HOME 2、VPS 之间的路由互联和 OSPF 邻居 | `66.66.66.0/24` | 这里的重点不是把所有设备都强行归到同一种 VPN，而是根据使用场景分工：HOME 1 的 OpenVPN 更适合移动运维接入，HOME 2 的 WireGuard 更适合站点互联和高吞吐传输；HOME 1 与 HOME 2 之间则使用独立的 WireGuard 直连。 ## 四、控制平面：FRR + OSPF 负责自动找路 OpenVPN 和 WireGuard 负责把隧道打通，但它们不会自动替我决定某个网段应该走哪条路径。真正负责路径选择的是运行在各个网关上的 **FRR**，以及其中的 OSPF 进程。 在这套架构里，两套 VPN 的角色不一样：HOME 1 的 OpenVPN 主要提供运维接入，同时也给 VPS 保留一条 OpenVPN 接入路径；HOME 2 和 HOME 1 之间的 WireGuard，以及各个 VPS 的 WireGuard 接入，组成站点互联和动态路由的骨干。 ### 直连路径优先 HOME 1 和 HOME 2 之间的 WireGuard 隧道设置较低的 OSPF Cost，例如 `10`。这条路径是平时的主路径： - NAS 双机同步直接走两地宽带。 - 跨站访问 HOME 2 的服务直接走站点间隧道。 - Emby 或其他影音业务不经过 VPS，减少中继延迟和云端带宽消耗。 ### VPS 路径作为站点间备用 HOME 1、HOME 2 分别通过 WireGuard 与 VPS 建立隧道，并把这类链路的 OSPF Cost 设置为 `30`。所有 VPS 同时接入 WireGuard 和 OpenVPN：WireGuard 主要承载站点互联和 OSPF 路由，OpenVPN 作为 HOME 1 的运维及兼容接入路径。平时 VPS 的 WireGuard 链路主要交换邻居状态和路由信息，不承载 HOME 1 与 HOME 2 之间的主要业务流量。 当 HOME 1 和 HOME 2 的直连 WireGuard 隧道断开时，FRR 会发现 OSPF 邻居超时，重新计算最短路径。原来的直连路由被撤销，去往对端网段的流量就会改走 VPS 中继。 这就是我这里的“自动切换”：不是脚本定时探测后修改一堆静态路由，而是把链路状态交给动态路由协议处理。 需要说明的是，OSPF 收敛后，**新的连接通常可以自动走新路径**；已经建立的 TCP 连接是否能够无感恢复，还取决于应用本身的重连机制、连接超时和隧道切换时间。因此我会给需要高可用的服务配置客户端重连或反向代理重试，不能简单地把“路由收敛”理解为所有连接都不会中断。 ## 五、数据平面：不同流量走不同的路 这套网络里我把流量分成三类。 #### 1. 公网访问流量 普通用户访问博客、Web 服务或影音服务时，先到 VPS 的 WAF 和反向代理。VPS 完成 HTTPS 证书卸载、域名分流和基础攻击过滤，再通过 OSPF 可达的隧道网段访问 HOME 1 的业务网。 HOME 1 整站不可用时，反向代理把上游切换到 HOME 2 的同构灾备服务。这样公网域名不需要跟着家庭 IP 变化，入口也不需要暴露家庭宽带地址。 VPS 上的 WAF 和反向代理尽量保持无状态：证书、域名和转发规则可以在主备节点保持一致，业务数据和需要持久化的会话则留在后端。这样入口节点切换时，只是换了一条访问路径，不会把用户数据也带走。 #### 2. 跨站点业务流量 HOME 1 和 HOME 2 之间的 NAS 同步、文件访问以及影音流量，优先走 WireGuard 直连。如果直连断开，才使用 VPS 中继。 #### 3. 管理流量 管理流量不通过公网 Web 入口。人在外面时，先连接 HOME 1 的 OpenVPN，拿到 `10.7.7.x` 地址，再访问 HOME 1 的管理网 `10.0.0.0/24`，或者通过已经同时接入 OpenVPN / WireGuard 的 VPS 进入其他站点。 这种分层之后，Web 访问、站点互联和管理员操作分别有自己的入口，出现问题时也比较容易定位。 ## 六、Friend Home 为什么用 IPsec Friend Home 不属于我的核心数据中心，使用场景主要是跨家庭的数据共享，所以没有把它直接放进主 WireGuard 骨干里，而是通过 IPsec IKEv2 和 HOME 1 的 WAN 2 建立点对点隧道。 IPsec 的好处是兼容性比较好，很多家用路由器和软路由都可以直接配置。对于第三方节点，我只发布需要互访的网段和服务，不把 HOME 1 的管理网、无线网全部暴露过去。 异地互联一定要先做访问边界，再做路由发布，能通不代表应该全通，最好使用防火墙策略限制方向。 ## 七、公网入口和安全策略 我的公网业务入口尽量收敛到 VPS，HOME 1 和 HOME 2 的 DDNS 主要用于 VPN 隧道建立，仅有部分不太重要的但是需要外网访问的通过HOME1 的 NGINX WAF 代理网关 8443端口放出，还有云服务器VPS只对外开放80 443端口，ssh，数据库等只能通过内网堡垒机进行访问。 ## 八、故障切换场景 ### 1、HOME 1 和 HOME 2 之间的直连断开 WireGuard 隧道不可用，OSPF 邻居超时，FRR 会撤销 Cost 10 的直连路由，流量切到 Cost 30 的 VPS 中继路径。直连恢复后，OSPF 再次选择 Cost 10 的路径。 ### 2、HOME 1 的 OpenVPN 接入异常 HOME 1 的 OpenVPN 运维入口暂时不可用时，管理员无法直接通过 OpenVPN 回家，但 HOME 1 与 HOME 2 之间的 WireGuard 直连并不一定受影响。公网业务仍然先进入 VPS，再通过 VPS 的 WireGuard 接入访问后端；如果 HOME 1 的外部线路整体不可用，则由 OSPF 将相关路径切换到 VPS 中继。 ### 3、HOME 1 断电 我这两个小机柜都没有做UPS ，觉得也没什么必要，公网入口仍然在 VPS，反向代理探测到 HOME 1 上游不可用后，将请求切换到 HOME 2 的灾备业务。HOME 2 提供的是已经同步好的业务副本，恢复范围取决于最后一次同步时间，也就是实际的 RPO。 ### 4、VPS 主入口故障 公网访问切换到备用 VPS。这里的入口切换用的阿里云的GTM全局流量管理，通过 DNS健康检查以及流量调度实现，具体收敛时间取决于 DNS TTL 和健康检查周期。站点内部的 OSPF 备用路径仍然可以继续工作的 ## 九、这套架构的优缺点 优： - 家庭宽带以及VPS不需要直接对外暴露大量服务端口。 - 大流量跨站业务优先走直连，速度和成本都更可控。 - 站点之间使用动态路由，线路变化时不需要手工修改全部静态路由，。 - HOME 1、HOME 2 和 VPS 都有各自的角色，故障范围更容易隔离。 - 权限隔离，管理平台、业务平面做了细粒度的防火墙策略。 缺： - 配置复杂度太高，有些地方可能有点小题大做。 - OSPF、策略路由、WireGuard AllowedIPs 和防火墙规则需要一起设计。 - VPS 中继还是会受到带宽和延迟影响。 - 灾备站点要真正可用，除了同步数据，还要同步应用配置、证书和恢复流程。 - 这里的自动切换只能保证路径切换，不能代替应用层高可用和数据一致性设计，这里我做的是定时同步。 仅供分享参考，可能99%的人都用不到我这个网络，过于复杂了 ::aru:crying:: Loading... <div class="tip inlineBlock success"> 家里的 NAS、博客、影音服务和一些实验环境，最开始都是“能访问就行”。后来跑的服务越来越多，异地备份、远程访问、跨站点访问也慢慢加了进来，单纯依赖 **DDNS + 端口转发** 就开始不太够用了。 动态公网 IP 会变，运营商会调整线路，路由器也可能重启。更麻烦的是，家里的业务一旦直接暴露在公网，SSH、RDP、SMB 这些端口很快就会被扫描到。只要再碰上弱密码，NAS 和家用服务器就可能变成攻击入口，放大攻击平面。 所以我现在使用的是一套基于 **SD-WAN 思路** 搭建的家庭私有云网络：用 WireGuard / IPsec 负责加密组网，用 FRR + OSPF 负责动态路由，用公网 VPS 作为所有公网业务访问的统一入口，再配合 WAF 反向代理，把公网访问、内网管理和站点之间的业务流量分开 <img src="https://wanghaoyu.com.cn/usr/themes/handsome/assets/img/emotion/aru/thumb.png" class="emotion-aru"> 。 </div> 这套架构的目标很简单： - HOME 1、HOME 2 使用 DDNS 维持动态地址可达，VPS 作为所有公网业务访问的统一入口。 - HOME 1 提供 OpenVPN，HOME 2 使用 WireGuard，HOME 1 和 HOME 2 之间通过 WireGuard 直连。 - 所有 VPS 同时接入 WireGuard 和 OpenVPN 两套隧道网络。 - HOME 1 和 HOME 2 之间的内部业务优先走 WireGuard 直连，直连故障时再切换到 VPS 中继。 - 主站点不可用时，公网业务可以切到异地灾备站点。 - 公网只暴露 Web 入口，管理面和存储面尽量不直接暴露。 - 所有DDNS 使用阿里云 专业版DNS，减小TTL，缩短故障恢复时间。 ## 一、先看整体拓扑 下面是我目前这套网络的逻辑拓扑。为了方便理解，可以把它看成“云端入口 + 两个家庭站点 + 一个共享站点”。  这里有一个比较重要的设计：**VPS 负责所有公网业务访问的入口，但不负责承载所有站点之间的内部流量。** 普通用户访问博客、Web 服务或影音服务时，都会先到 VPS 的 WAF 和反向代理，再由 VPS 通过 WireGuard 或 OpenVPN 隧道访问 HOME 1 或 HOME 2 的后端业务。正常情况下，HOME 1 和 HOME 2 之间的 NAS 同步、文件访问等内部流量通过 WireGuard 直接通信；只有直连链路出现问题，OSPF 才会把跨站业务切到 VPS 中继。这样既能保证公网业务入口统一，也能减少内部大流量对 VPS 带宽的依赖。 ## 二、为什么不用DDNS + 端口转发就到此为止了呢 DDNS 本身没有问题，它解决的是“域名跟着动态 IP 变化”的问题。在这套架构里，HOME 1 和 HOME 2 都使用 DDNS，分别作为 OpenVPN 和 WireGuard 的稳定访问地址。但 DDNS 本身解决不了下面这些事情： - 家庭公网 IP 变化之后，所有访问都要重新依赖这条线路。 - 家庭宽带断线时，公网服务直接不可用。 - 多个服务需要开放多个端口，攻击面会越来越大。 - HOME 1 和 HOME 2 之间没有统一的路由控制。 - HOME 1 和 HOME 2 之间的 NAS 同步、跨站影音这类大流量业务会绕到公网入口，体验和成本都不理想。 所以我把“访问入口”和“业务所在位置”拆开了。公网用户只需要访问 VPS 的域名，VPS 再通过 OpenVPN / WireGuard 隧道访问后面的业务节点；站点之间则优先通过 HOME 1 和 HOME 2 的 WireGuard 直连。家庭宽带只作为站点出口和隧道承载线路，不再直接对公网提供业务入口。 ## 三、站点和网段怎么规划 异地组网最容易踩的坑就是网段冲突。两边都用 `192.168.1.0/24`，一开始看不出问题，等到需要跨站访问 NAS 或配置动态路由时就会发现：路由器根本不知道这个地址到底应该往哪边发。 因此我的网段尽量做到每个站点唯一。 | 站点 | 作用 | 网段 | | -------------- | ---------------------------------------------- | ------------------ | | VPS 1 | 统一公网业务入口、WAF、反向代理、备用中继 | `66.66.66.254/24` | | VPS 2 | 备用公网入口和灾备入口 | `66.66.66.253/24` | | HOME 1 | 主数据中心、博客、NAS等 | `10.254.95.0/24` | | HOME 1 | Manage Network | `10.0.0.0/24` | | HOME 1 | 无线网络 | `10.254.254.0/24` | | HOME 2 | 异地私有网络 | `192.168.123.0/24` | | HOME 2 | 灾备业务和备份 NAS | `192.168.122.0/24` | | HOME 1 DDNS | HOME 1 的 OpenVPN 服务访问地址 | 动态公网地址 | | HOME 2 DDNS | HOME 2 的 WireGuard 访问地址 | 动态公网地址 | | OpenVPN | 远程访问，以及 VPS 的 OpenVPN 接入 | `10.7.7.0/24` | | WireGuard 骨干 | HOME 1、HOME 2、VPS 之间的路由互联和 OSPF 邻居 | `66.66.66.0/24` | 这里的重点不是把所有设备都强行归到同一种 VPN，而是根据使用场景分工：HOME 1 的 OpenVPN 更适合移动运维接入，HOME 2 的 WireGuard 更适合站点互联和高吞吐传输；HOME 1 与 HOME 2 之间则使用独立的 WireGuard 直连。 ## 四、控制平面：FRR + OSPF 负责自动找路 OpenVPN 和 WireGuard 负责把隧道打通，但它们不会自动替我决定某个网段应该走哪条路径。真正负责路径选择的是运行在各个网关上的 **FRR**，以及其中的 OSPF 进程。 在这套架构里，两套 VPN 的角色不一样：HOME 1 的 OpenVPN 主要提供运维接入，同时也给 VPS 保留一条 OpenVPN 接入路径；HOME 2 和 HOME 1 之间的 WireGuard，以及各个 VPS 的 WireGuard 接入，组成站点互联和动态路由的骨干。 ### 直连路径优先 HOME 1 和 HOME 2 之间的 WireGuard 隧道设置较低的 OSPF Cost，例如 `10`。这条路径是平时的主路径： - NAS 双机同步直接走两地宽带。 - 跨站访问 HOME 2 的服务直接走站点间隧道。 - Emby 或其他影音业务不经过 VPS，减少中继延迟和云端带宽消耗。 ### VPS 路径作为站点间备用 HOME 1、HOME 2 分别通过 WireGuard 与 VPS 建立隧道，并把这类链路的 OSPF Cost 设置为 `30`。所有 VPS 同时接入 WireGuard 和 OpenVPN：WireGuard 主要承载站点互联和 OSPF 路由，OpenVPN 作为 HOME 1 的运维及兼容接入路径。平时 VPS 的 WireGuard 链路主要交换邻居状态和路由信息，不承载 HOME 1 与 HOME 2 之间的主要业务流量。 当 HOME 1 和 HOME 2 的直连 WireGuard 隧道断开时，FRR 会发现 OSPF 邻居超时，重新计算最短路径。原来的直连路由被撤销，去往对端网段的流量就会改走 VPS 中继。 这就是我这里的“自动切换”：不是脚本定时探测后修改一堆静态路由，而是把链路状态交给动态路由协议处理。 需要说明的是，OSPF 收敛后，**新的连接通常可以自动走新路径**；已经建立的 TCP 连接是否能够无感恢复，还取决于应用本身的重连机制、连接超时和隧道切换时间。因此我会给需要高可用的服务配置客户端重连或反向代理重试，不能简单地把“路由收敛”理解为所有连接都不会中断。 ## 五、数据平面：不同流量走不同的路 这套网络里我把流量分成三类。 #### 1. 公网访问流量 普通用户访问博客、Web 服务或影音服务时，先到 VPS 的 WAF 和反向代理。VPS 完成 HTTPS 证书卸载、域名分流和基础攻击过滤，再通过 OSPF 可达的隧道网段访问 HOME 1 的业务网。 HOME 1 整站不可用时，反向代理把上游切换到 HOME 2 的同构灾备服务。这样公网域名不需要跟着家庭 IP 变化，入口也不需要暴露家庭宽带地址。 VPS 上的 WAF 和反向代理尽量保持无状态：证书、域名和转发规则可以在主备节点保持一致，业务数据和需要持久化的会话则留在后端。这样入口节点切换时，只是换了一条访问路径，不会把用户数据也带走。 #### 2. 跨站点业务流量 HOME 1 和 HOME 2 之间的 NAS 同步、文件访问以及影音流量，优先走 WireGuard 直连。如果直连断开，才使用 VPS 中继。 #### 3. 管理流量 管理流量不通过公网 Web 入口。人在外面时，先连接 HOME 1 的 OpenVPN，拿到 `10.7.7.x` 地址，再访问 HOME 1 的管理网 `10.0.0.0/24`，或者通过已经同时接入 OpenVPN / WireGuard 的 VPS 进入其他站点。 这种分层之后，Web 访问、站点互联和管理员操作分别有自己的入口，出现问题时也比较容易定位。 ## 六、Friend Home 为什么用 IPsec Friend Home 不属于我的核心数据中心，使用场景主要是跨家庭的数据共享，所以没有把它直接放进主 WireGuard 骨干里，而是通过 IPsec IKEv2 和 HOME 1 的 WAN 2 建立点对点隧道。 IPsec 的好处是兼容性比较好，很多家用路由器和软路由都可以直接配置。对于第三方节点，我只发布需要互访的网段和服务，不把 HOME 1 的管理网、无线网全部暴露过去。 异地互联一定要先做访问边界，再做路由发布，能通不代表应该全通，最好使用防火墙策略限制方向。 ## 七、公网入口和安全策略 我的公网业务入口尽量收敛到 VPS，HOME 1 和 HOME 2 的 DDNS 主要用于 VPN 隧道建立，仅有部分不太重要的但是需要外网访问的通过HOME1 的 NGINX WAF 代理网关 8443端口放出，还有云服务器VPS只对外开放80 443端口，ssh，数据库等只能通过内网堡垒机进行访问。 ## 八、故障切换场景 ### 1、HOME 1 和 HOME 2 之间的直连断开 WireGuard 隧道不可用，OSPF 邻居超时，FRR 会撤销 Cost 10 的直连路由，流量切到 Cost 30 的 VPS 中继路径。直连恢复后，OSPF 再次选择 Cost 10 的路径。 ### 2、HOME 1 的 OpenVPN 接入异常 HOME 1 的 OpenVPN 运维入口暂时不可用时，管理员无法直接通过 OpenVPN 回家，但 HOME 1 与 HOME 2 之间的 WireGuard 直连并不一定受影响。公网业务仍然先进入 VPS，再通过 VPS 的 WireGuard 接入访问后端；如果 HOME 1 的外部线路整体不可用，则由 OSPF 将相关路径切换到 VPS 中继。 ### 3、HOME 1 断电 我这两个小机柜都没有做UPS ，觉得也没什么必要，公网入口仍然在 VPS，反向代理探测到 HOME 1 上游不可用后，将请求切换到 HOME 2 的灾备业务。HOME 2 提供的是已经同步好的业务副本，恢复范围取决于最后一次同步时间，也就是实际的 RPO。 ### 4、VPS 主入口故障 公网访问切换到备用 VPS。这里的入口切换用的阿里云的GTM全局流量管理，通过 DNS健康检查以及流量调度实现，具体收敛时间取决于 DNS TTL 和健康检查周期。站点内部的 OSPF 备用路径仍然可以继续工作的 ## 九、这套架构的优缺点 优： - 家庭宽带以及VPS不需要直接对外暴露大量服务端口。 - 大流量跨站业务优先走直连，速度和成本都更可控。 - 站点之间使用动态路由，线路变化时不需要手工修改全部静态路由，。 - HOME 1、HOME 2 和 VPS 都有各自的角色，故障范围更容易隔离。 - 权限隔离，管理平台、业务平面做了细粒度的防火墙策略。 缺： - 配置复杂度太高，有些地方可能有点小题大做。 - OSPF、策略路由、WireGuard AllowedIPs 和防火墙规则需要一起设计。 - VPS 中继还是会受到带宽和延迟影响。 - 灾备站点要真正可用，除了同步数据，还要同步应用配置、证书和恢复流程。 - 这里的自动切换只能保证路径切换，不能代替应用层高可用和数据一致性设计，这里我做的是定时同步。 仅供分享参考，可能99%的人都用不到我这个网络，过于复杂了 <img src="https://wanghaoyu.com.cn/usr/themes/handsome/assets/img/emotion/aru/crying.png" class="emotion-aru"> Last modification：July 21, 2026 © Allow specification reprint Support Appreciate the author Like 如果觉得我的文章对你有用，请随意赞赏