家庭网络架构演进 (v3.0)：All-in-One Docker 化与中心化配置

发表于 阅读次数：

今天的重构不仅仅是修修补补，而是底层运行架构的彻底革新。我将原本零散的脚本、二进制文件全部容器化，实现了真正意义上的 “Infrastructure as Code” (IaC)。

核心变革：全面的 Docker 化 (The Big Switch)

在此之前，我的客户端（Mac/Windows）是一堆 loose scripts：手动跑 frpc 进程，再配合一个 Docker 里的 X-UI。
问题：依赖环境复杂（Python版本、FRP版本）、进程管理混乱、日志分散。

v3.0 方案：
我将所有组件封装进了一个 docker-compose.yml 堆栈中。现在，Mac 和 Windows 客户端不再需要安装 Python 环境，不再需要手动下载 FRP。
只需一个命令：

1
docker compose up -d

它会自动拉起：

  • X-UI (代理面板)
  • FRPC (内网穿透)
  • Sync Sidecar (配置同步)
    这三者在同一个 Docker 网络中互联，彻底解耦了宿主机环境。

架构红利：中心化控制 (Centralized Control)

基于 Docker 化带来的标准化环境，我终于能实现一直想做的Master-Slave 架构：

  • 配置中心化：
    以前配置分散在各个设备上。现在引入了 global.env 和 master_config.json。
    VPS 是唯一真理。Mac/Android 启动时会自动从 VPS 拉取最新的 UUID 和用户名单。
  • 自动同步：
    利用 Docker 容器间的互通性，Sync Sidecar 容器会定期检查配置更新。
    Result: 在 VPS 改一次配置，全家所有设备重启即生效，无需逐台设备 SSH 进去修改。

稳定性提升：静态 IP 网络 (Static IPs)

为了解决 Nginx 反代 Docker 容器时常见的 502/Connection Refused 问题（容器重启 IP 变动导致 DNS 缓存失效或配置指向错误），我在 VPS 上实施了 Docker Internal Static IP 策略。

通过在 docker-compose.yml 中显式指定 IP，确保服务组件之间的通信链路绝对稳定：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
networks:
  vps_net:
    ipam:
      config:
        - subnet: 10.88.0.0/16

services:
  nginx:
    networks:
      vps_net:
        ipv4_address: 10.88.0.4
  
  frps:
    networks:
      vps_net:
        ipv4_address: 10.88.0.2

这让 VPS 的内部网络拓扑固若金汤，无论怎么热更新容器，Nginx 永远知道去 10.88.0.2 找 FRP，去 10.88.0.x 找其他服务。

总结

v3.0 的改动量巨大（看 git log 满屏的 refactor 就知道了），但收益是长远的：

  • 部署：从 “照着文档操作10步” 变成了 “Copy 文件夹 -> Docker Compose Up”。
  • 维护：从 “SSH 到处修” 变成了 “改 Master Config -> 重启”。
  • 体验：配置的一致性得到了极大的保证，再也不用担心某个节点配置漏改导致连接失败。

This is how modern home proxy should be built.