又又又迁移回美西了（

上一篇记录的是将美西两台 Web 节点合并至香港单机。本文是续篇：香港节点完成过渡后，入口、业务、计算与存储重新拆分，回落到当前的美西多节点架构。

DMIT 新机到位是本次回迁的条件之一，但不是唯一原因。香港节点虽然国内访问延迟更低，却长期存在稳定性隐患：持续遭受 DDoS 干扰是其中一个背景因素；迁移当晚又出现了间歇性断流。低延迟无法抵消单机入口不稳定带来的风险，因此决定趁美西资源重新可用时，将入口、应用与文件管理从香港单机拆回多节点。

DMIT 的线路与配置更适合重新承担业务面，也让这次拆分具备了可执行条件。新机评测另文说明，本文只记录架构取舍与迁移过程。

迁移仍主要通过 AI Agent 调用 ops-mcp 完成，几乎不依赖手工 SSH。

新机评测见：DMIT 美西Premium优质线路 测试数据存档

注：文中公网地址、域名、端口与本地路径等均已脱敏，并非生产真实信息。

为何再次拆分

香港单机降低了国内访问延迟，但延迟并不是唯一指标。该线路稳定性始终不够理想，长期遭受 DDoS 干扰；迁移当晚还出现了间歇性断流。在入口、应用、数据库与文件管理均集中于同一台主机的前提下，这类波动会被放大为整站可用性风险。面板与端口策略偏“先跑通再收敛”，后续计算任务也缺少独立承载位置。

DMIT 新机上线后，美西侧资源重新具备分层条件：

• Zgo-us：公网七层入口
• US-DMIT：新业务节点，承载 Docker、Compose 与主控面板
• us-dedi：后续补充的轻量计算节点
• us-nfs：备份与共享存储，继续独立部署

架构规划如下：

当前拓扑

香港迁移已经说明：数据体量通常不是瓶颈，服务范围才是。

• 不整机迁移 1Panel
• 不在 Zgo-us 上运行业务容器
• 数据库热数据不放 NFS
• 不开放 Docker 2375
• 不启用 Swarm 充当多节点调度

目标是可回滚、可审计的轻量拆分，而不是引入 Kubernetes。

面板栈同步调整：入口侧由 nginx-ui 管理 Nginx，业务侧由 DPanel 管理 Docker/Compose。新机从初始阶段即不再沿用旧 1Panel 全家桶方案。

US-DMIT 是本轮迁移的业务主服务器。新机上线后优先完成验收：

• 接入 WireGuard 集群内网
• 部署主控 DPanel、Docker、Compose
• 业务 Compose 目录收敛到 /data/compose/
• 修复 DPanel 无法识别站点 Compose 配置的问题

若面板无法读取真实 Compose 文件，后续可视化运维会出现“面板视图与磁盘状态不一致”的问题。

ops-mcp 侧主要使用：

docker_ps US-DMIT
compose_projects US-DMIT
compose_config US-DMIT
dpanel_home_usage US-DMIT
dpanel_compose_list US-DMIT

通过结构化回读，反复核对容器、Compose 与面板视图是否一致。

入口侧改为 nginx-ui 管理 Nginx：

• 公网站点域名统一由 Zgo-us 接入
• 修复站点列表为空
• 修复证书列表为空
• 证书元数据可见，私钥不写入文档

后续新站点上线流程固定为：

1. 后端绑定业务/计算节点的 WireGuard 地址
2. 防火墙仅放行入口节点
3. 在 Zgo-us 配置反代与证书
4. DNS 指向 Zgo-us

访问策略明确如下：

nginx-ui 管理端口
DPanel 管理端口

仅允许 WireGuard 内网访问

两端均部署持久化面板防火墙服务。

需要注意：存在 Docker 的主机不能只限制 INPUT 链。容器发布端口会经过 NAT/转发，必须同步约束 DOCKER-USER。US-DMIT 与后续的 us-dedi 均按此处理。

管理电脑使用分流 WireGuard 配置，大致结构如下：

Zgo-us peer:
  入口侧若干历史节点 /32

US-DMIT peer:
  业务节点 /32

us-dedi peer:
  计算节点 /32

配置中不包含 0.0.0.0/0，默认路由仍走本机网络。

迁移中曾出现一次客户端问题：Windows WireGuard 服务残留旧配置，访问业务节点 DPanel 时先绕经入口节点。服务端状态正常，故障点在客户端路由。以管理员权限重新导入新配置后恢复。

因此，面板访问异常时优先检查客户端隧道与路由，再排查服务端防火墙。

US-DMIT 承接主业务后，再引入轻量计算节点，比继续向业务机堆叠任务更合理。

us-dedi 概况（示例）：

已完成 Docker CE、Compose、firewalld、WireGuard 部署；DPanel Lite 仅监听 WireGuard 地址上的管理端口；与 US-DMIT、Zgo-us、us-nfs 完成 peer 握手；MCP 注册 docker、compose、systemd、dpanel 角色。

防火墙分区示意：

public / eth0:
  SSH（高位端口）
  WireGuard

internal / wg0:
  SSH（高位端口）
  DPanel 管理端口

验证结果：

计算节点内网 DPanel     HTTP 200
计算节点公网 DPanel     blocked

为何不使用 Swarm

采用的是“单一主控面板 + 远程 Docker 环境”：

• 主控：US-DMIT DPanel
• 远程环境：us-dedi
• 连接方式：WireGuard 上的 SSH，不暴露 Docker API
• 专用用户：仅接受主控公钥的受限账号，密码锁定

该方案避免开放 2375，也不引入 Swarm 复杂度。操作入口统一，状态边界仍清晰；us-dedi 本地 DPanel Lite 保留为应急入口。

代价同样明确：不具备自动调度与跨节点负载均衡。每个任务需单独评估资源、数据路径与回滚方式。以 us-dedi 当前约 1 核 2G 的规格，这种约束反而有助于控制迁移范围。

这是计算节点接入的首个生产任务。

不只是容器迁移，还包括：

• 继续作为 NFS 总管理入口
• 完整展示 NFS 根下全部顶层目录
• 保留原账号、密码哈希与权限配置
• 后端不直接暴露公网
• 保留可执行回滚点

主要步骤：

1. 在 us-nfs 上仅为计算节点增加根导出权限，不扩大其他来源
2. 在 us-dedi 上通过 NFSv4.2 与 systemd automount 挂载至本机汇总目录
3. 配置与 BoltDB 保留在本机盘，不放入 NFS 热路径
4. 容器仅绑定计算节点 WireGuard 地址上的后端端口
5. DOCKER-USER 仅允许入口节点访问该后端端口
6. Nginx 上游由业务节点切换至计算节点
7. 停止源实例，并放入 rollback profile，避免双活

迁移后容器内可见完整节点目录树（备份、历史节点、共享与当前节点等），具体目录名从略。

验收项不限于页面可访问：

• HTTPS 入口正常
• 账号与权限配置与迁移前一致
• 计算节点公网后端端口不可达

回滚顺序固定为：先停止新实例并同步最新 BoltDB，再将 Nginx 上游改回旧地址，最后启动源实例。禁止两端同时写入同一账号数据库。

上一篇中，ops-mcp 主要覆盖主机探针、Docker、1Panel 与 mihomo。本轮实际新增使用较多的能力包括：

• DPanel：环境列表、容器、Compose、资源用量
• nginx-ui：站点、证书、Nginx 状态、配置测试
• 计算节点纳管：host 角色热更新、远程 Docker 环境校验
• 暴露面审计：确认公网访问是否被有效阻断

常用检查组合：

server_health
server_network
server_firewall
server_exposure_audit
docker_ps
compose_projects
dpanel_env_list
nginxui_sites_list
nginxui_certs_list

最大效果仍是“改完即可结构化回读”。迁移最怕半成功状态：容器已启动但面板不可见，面板可见但公网仍暴露，HTTPS 正常但上游仍指向旧节点。结构化工具可显著缩小这类状态偏差。

底层文本编辑、一次性初始化与特殊防火墙规则，多数仍通过 ops_ssh_exec 兜底。它不是万能方案，但把多台异构主机的状态读取与常规操作收成了统一接口。

两轮迁移可以概括为：

第一轮：将分散且暴露面偏大的旧服务，合并为香港单机。
第二轮：香港线路虽低延迟但稳定性不足，且迁移当晚出现间歇性断流；DMIT 新机到位提供了回迁条件，因此重新拆分为入口、业务、计算、存储四层，并使计算节点进入生产链路。