阶段十七：代理网络控制面统一入口与真实客户端验收
阶段状态：进行中
计划状态：修订中
当前工作包：P17-9 360T7 Xray 主备与自动回切
🧾 计划状态
P17 已从需求评审占位进入实施。 本阶段的目标不是重建五节点数据面，而是把现有 2S-UI + 内嵌 sing-box 代理网络补成可清晰入口、可独立管理、可从 Console 一眼看懂并可在真实客户端验收的控制面，同时保留旧 ss-rust、360T7、旧订阅和现有主备顺序。2026-10-12 用户最终确认采用最简方案：五台节点只保留 VLESS + REALITY，删除 dog Hysteria2、DD SS2022 和 RR Trojan+TLS；一个 agentmeshos-main client 关联五条 Inbound，并明确接受五台节点共享同一个 VLESS UUID。360T7 保持当前 C 版固件，不重新编译、不引入 Mihomo/Nikki，改用 PassWall/Xray 主组加后备组实现“MM 优先、其他线路接替、MM 恢复后回到 MM”。依据是 docs/architecture/13_代理网络生产架构.md、五节点 2S-UI 生产回读、RR Master 配置、MM 公网网关、360T7 现场只读进程与配置回读和 Console 现状；影响范围限定在服务器 Inbound、订阅生成、在线客户端刷新、360T7 PassWall、资源清理、客户端验收和文档发布。
📌 结论摘要
最终目标固定为六项。第一，管理员继续通过 https://proxy.yohan.fun/ 使用 2S-UI 自身登录管理 Master、节点、客户端和订阅。第二，四个远程节点分别使用 panel-mm.yohan.fun、panel-d02.yohan.fun、panel-dog.yohan.fun、panel-dd.yohan.fun 的独立面板与独立证书，节点仍只监听 Tailnet。第三，Console 的“系统入口 → 代理控制面”先打开新架构页 #proxyNetwork，再从页内直达 Master 和各节点面板。第四，Windows、Android、iOS 三端用各自的 Mihomo/Clash 兼容客户端导入同一份 Clash 订阅，并验证节点切换和回切。第五，五台节点最终只保留 VLESS + REALITY，删除异构备用协议。第六，360T7 保持当前固件，使用 PassWall/Xray 主组加后备组实现 MM 断线接替和 MM 恢复回切。
不包含的事项同样明确：不重建数据面；不把节点 2095/2096 暴露到公网；不把 2S-UI 嵌入 Console iframe；不实现跨节点原生 SSO；不使用 metacubexd 代替 2S-UI 服务端管理或统一客户端；不为 360T7 重新编译固件、刷入 Mihomo/Nikki 或改变当前 UBI fit 边界；不要求备用节点内部严格顺序；不增加独立身份 client、external links 聚合或额外订阅服务；最终不保留 Hysteria2、SS2022、Trojan 等备用协议。
📚 目录
🧱 技术栈与架构选型
| 候选 | 可维护性 | 部署复杂度 | 安全边界 | 结论 |
|---|---|---|---|---|
| Console 直接打开各节点 Tailnet 面板 | 低，浏览器无法访问 Tailnet 私有地址 | 低 | 浏览器暴露不成立 | 不采用 |
| Console iframe 嵌入 2S-UI | 低，Cookie、Origin 和 WebSocket 容易冲突 | 中 | 增加同源校验风险 | 不采用 |
| MM 公网终止证书并经 RR 私有网关转节点 | 高，复用现有 MM、RR 和 Tailnet | 中 | 节点仍只监听 Tailnet，Host 一致 | 采用 |
| 增加跨节点 SSO 或修改 2S-UI | 低，需要私有 Fork 和额外认证代理 | 高 | 与官方二进制边界冲突 | P17 不采用 |
采用逻辑 edge.yohan.fun 作为公网 TLS 终止身份，RR 的私有回源网关 100.64.0.1:39200 负责按 Host 继续转发到各节点 Tailnet 2095。Master API 通过 RR 的受控 /etc/hosts 把 panel-*.yohan.fun 解析到节点 Tailnet 地址，从而同时满足 2S-UI 的 Host 与 Origin 校验。proxy.yohan.fun 与四个 panel-* 使用 CNAME 跟随 edge.yohan.fun，健康 Edge 必须同时具备控制面网关和面板网关；不再把这五个入口固定到 MM 公网 IP。远程节点保留独立登录，不改变 2S-UI v1.8.3 二进制。
🎯 目标、成果与验收契约
| 工作包 | 目标 | 验收依据 |
|---|---|---|
| P17-0 | 冻结基线、域名、证书、网关、节点兼容和回退契约 | 五节点配置、DNS、MM、Console 只读回读一致 |
| P17-1 | Master 与节点拨号域名兼容 | 节点心跳正常，Master 节点页面和入站副本不变 |
| P17-2 | 控制面和四个面板域名、独立证书和 Edge/RR 网关上线 | 五域名 CNAME、证书、HTTP、WebSocket 和公网 2095 阻断回读通过 |
| P17-3 | Console 代理网络架构页上线 | #proxyNetwork 可见、可导航、桌面和移动端无溢出 |
| P17-4 | 三端真实客户端与资料归档验收 | 三端切换、回切、长连接边界、哈希和 File-Hub 回读通过 |
| P17-5 | 发布、文档、GitHub Actions 与回退收口 | run-local-tests.sh、post_push_verify=pass 和回退材料齐备 |
公共接口冻结如下：Master 面板为 https://proxy.yohan.fun/app/，Master 订阅保持 https://proxy.yohan.fun/sub/...；四个节点面板为 https://panel-<node>.yohan.fun/app/；Console 路由为 #proxyNetwork；节点 2095/2096 保持 Tailnet-only；客户端策略组顺序为 MM,d02,dog,dd,rr；新旧订阅和旧链路并行，回退不删除旧数据。
🧩 统一主协议与 360T7 主备方案
2026-10-12 用户冻结新的实施方向：五台数据面节点最终只保留 VLESS + REALITY；360T7 保持当前 C 版固件，不重新编译、不安装 Mihomo/Nikki，使用 PassWall 自带的 Xray 负载均衡和后备节点完成自动接替与回切。
| 层级 | 冻结方案 | 依据 | 影响 |
|---|---|---|---|
| 单一协议 | 五台节点只保留 VLESS + REALITY，统一端口 24443/tcp |
用户明确接受单一协议，优先降低复杂度和客户端兼容成本 | 所有客户端和 360T7 使用同一协议构建主备 |
| 服务端参数 | REALITY 私钥、Short ID、SNI、伪装目标逐台检查并按差异配置 | 共享 UUID 不代表服务端 TLS/REALITY 参数也必须完全相同 | 避免五台节点使用完全相同的 REALITY 指纹 |
| 客户端身份 | 一个 agentmeshos-main client 关联五条 Inbound，共享一份 VLESS UUID |
用户明确接受共享 UUID，换取现有订阅和客户端不迁移 | 不增加独立 client、external links 聚合或额外服务 |
| 订阅结构 | 保持原订阅和 Proxy / Auto 策略组，只替换节点成员 |
2S-UI subClashExt 是全局模板，现有客户端只选择稳定组名 |
客户端刷新订阅即可，不重新导入订阅地址 |
| 360T7 客户端 | 当前 C 版固件继续使用 PassWall/Xray，不做固件重编译 | 360T7 现场已有 Xray 26.3.27、PassWall 26.9.1，且存在完整 FIT 恢复包 |
不承担重编译、Mihomo 集成和 UBI/FIP 恢复风险 |
| 主备行为 | 主组只放 MM；后备组放 d02、dog、dd、rr 的 REALITY；后备组使用 leastPing |
用户不需要备用节点内部严格顺序，只要求 MM 断线可接替、恢复后回切 | MM 健康时固定优先 MM；MM 故障时任一健康备用接替 |
360T7 的目标路径固定为：
局域网客户端
-> 360T7 PassWall 路由、DNS、FullCone NAT 和分流
-> Xray 主组：MM
-> MM 不健康时进入 Xray 后备组：d02 / dog / dd / rr
-> MM 恢复健康后主组重新生效
该方案不使用 Mihomo fallback，也不要求备用节点按固定顺序选择。PassWall/Xray 的主组只包含 MM，因此 MM 健康时不会在其他节点之间负载均衡；后备组只在主组无健康节点时生效。
迁移采用“加新不删旧”：先在 dog、DD、RR 新增 Reality，保留现有 Hysteria2、SS2022、Trojan；五台 Reality 验证后加入订阅主组；所有在线客户端刷新并 canary 通过后，再移除异构协议并停用旧 Inbound。资源清理采用两阶段门禁：第一阶段在 Xray 主备稳定后停止旧 5 个 sslocal 和 PassWall HAProxy，释放约 27 MiB RSS；第二阶段只保留 LAN/WAN 路由、WiFi、FullCone NAT、dnsmasq、chinadns-ng、PassWall 基础功能和新主备所需的 Xray。nf_conntrack_max 先保持 30720，主备稳定后调整到 65536、nf_conntrack_buckets 调整到 32768；131072 只在真实峰值超过约 5 万且内存持续稳定时评估。
🧩 分布式底座接入声明
- 接入结论：接入 Network、Compute、Credentials、Observability 和 docs-governance。
- Network：使用 MM 公网 TLS、RR 私有回源网关、Tailnet 节点管理链路和 AliDNS 基础记录管理，不新增公网业务端口。
- Compute：RR 运行 2S-UI Master，MM 运行 Nginx 网关，四台 VPS 继续运行各自 2S-UI 系统和内嵌 sing-box；不新增 Nomad Job。
- Adapter 归属：本阶段不新增 Runtime Adapter。
- 数据路径：订阅和面板配置留在各节点
s-ui.db；证书、Nginx 配置和 DNS 证据只保存脱敏后的摘要、状态码和哈希。 - 凭据路径：DNS AccessKey 和 2S-UI 管理凭据仅存在于 root-only 环境文件；GitHub、Console 前端和普通文档均不可见。
- 生命周期：P17 完成后保留面板域名、证书续期任务、RR
/etc/hosts映射和回退快照；旧数据由用户自行决定下线时间。 - 验收证据：包含 DNS 双解析点、证书 SAN、HTTP/WebSocket、Master 节点状态、客户端切换结果、Actions 和回退演练。
📊 当前实施状态
| 工作包 | 当前状态 | 已有证据 | 尚未完成 |
|---|---|---|---|
| P17-0 基线与执行契约冻结 | ✅ 完成 | 五节点 2S-UI 1.8.3、Tailnet-only 2095/2096、Master 快照和回退命令已回读 |
无 |
| P17-1 节点域名与 Master 拨号兼容 | ✅ 完成 | dog canary 后扩展 MM、d02、dd；四节点 base_url 已改为 panel-*，dirty=0，各有 root-only 快照；认证后 api/load 返回四个节点全部 online，dog 延迟约 81 ms |
无 |
| P17-2 DNS、证书与面板网关 | ✅ 完成 | 四条 DNS 已由 1.1.1.1 与 8.8.8.8 复核，四张独立 ECC 证书、四个 307 登录跳转、认证态 /app/ws HTTP 101 和公网 2095/2096 阻断均通过 |
无；最终回退演练纳入 P17-5 |
| P17-3 Console 代理网络架构页 | ✅ 完成 | #proxyNetwork、五个外链、代理页无 2S-UI iframe、无运行时 D2、桌面和 390x844 浏览器契约通过；生产镜像 sha-d7230777c1c9feb3b5b9745231a18f1472e2cdb6 为 running/healthy，app.js 与 styles.css 哈希和仓库一致，四个 panel-* 链接均在生产文件回读 |
无 |
| P17-4 真实客户端与资料归档 | ⚠️ 进行中 | Windows/Android 官方包 SHA-256、iOS 元数据、File-Hub 长期目录和远端回读均通过；Windows Clash Verge Rev 真机 12 步切换/回切 all_pass=true；S20 已完成 Termux/Termius/TermRover 九目标配置，探针修复到 v0.3.7，通过受控重启验证 Tailscale、Termux:Boot 和探针自动恢复，并完成 RR/101/Home 到 100.64.0.8:8022 的 Tailnet-only 入站 SSH；v0.2.0 supervisor 另已通过 VPN 接口重建自动恢复监听。Magic2 已用同一模式纳管，探针 v0.3.8、三来源入站 SSH 和整机重启恢复通过；Termux/Termius/TermRover 九目标完成，TermRover 已实际登录 RR 与 101；Headscale 实时 given_name=andriod-magic2，Registry 稳定 ID 为 honor-magic2。用户设置 Exit Node 后，Google 真机 ping 3/3、约 173–179 ms，Gemini 真实对话返回 Hello! How can I help you today?。TermRover 1.2.2 的 Tailnet 字段经现场确认是官方 API Key 组织名，不是 Headscale 控制面 URL。2026-10-05 晚发现 Termux 进程曾停止，USB ADB 重启 Termux 并执行 boot 脚本后 sshd、supervisor 和探针恢复 |
Android 的 Clash Meta 真机切换/回切仍未执行；Magic2 长时间锁屏和系统内存压力下 Termux 进程驻留仍需观察；iOS 无在线真机 |
| P17-5 发布、验收与回退收口 | ⚠️ 延后到 P17-11 | 本地完整门禁、文档清单、MkDocs strict、脱敏扫描和 P17-0 至 P17-3 生产回读已通过；Windows 真机、S20 与 Magic2 出站管理、自启恢复、入站 SSH、Exit Node 和 Gemini 真实对话证据已形成 | P17-6 至 P17-10 完成后，再统一执行发布、Android/iOS 真机、最终回退和阶段归档 |
| P17-6 统一主协议与 360T7 基线准备 | ✅ 完成 | 五节点 2S-UI、数据库、Inbound、监听、快照、360T7 PassWall 和恢复包已只读核验；用户确认接受五节点共享 VLESS UUID，独立 client 和订阅聚合不进入本轮范围 | 无；共享 UUID 已登记为明确接受的约束 |
| P17-7 五节点统一 REALITY 主入口 | ✅ 完成 | dog、DD、RR 已新增 24443/tcp VLESS Reality；五台节点分别完成真实 Mihomo 10/10、ICMP 0% 丢包和吞吐验证；旧 Hysteria2、SS2022、Trojan Inbound 仍保留 |
无；旧协议保留到离线客户端刷新后再进入 P17-10 |
| P17-8 订阅发布与在线客户端刷新 | ⚠️ 部分完成 | Master agentmeshos-main 已关联五条 Reality；公网订阅只输出五台 Reality，Proxy / Auto 顺序为 MM -> d02 -> dog -> DD -> RR；规则为 agentrouter.org -> Proxy、vidhub2.top -> DIRECT、LAN -> DIRECT、Ads -> REJECT、CN -> DIRECT、MATCH -> Proxy；Home、OfficeSummer 已刷新并回读，Summer、S20、Magic2 当前离线未刷新；Mihomo fallback 的自动回切不是稳定保证 |
等 Summer、S20、Magic2 上线后完成订阅刷新；需要严格回切时以 360T7 Xray 主备或客户端侧控制为准，旧协议在全部客户端迁移前不删除 |
| P17-9 360T7 Xray 主备与自动回切 | ⚠️ 进行中 | 已建立 MM 主 Balancing 和 d02/dog/DD/RR 后备 Balancing，五台实测可用；隔离实例验证 MM 阻断切到 RR、恢复回 MM。A/B 发现新 Xray 全局透明代理对 GitHub 控制面不稳定，已将 Global node 回滚到旧 f9Re2U27 |
需要继续定位 Xray 全局透明代理的稳定性，再重新切换、做整机重启和稳定观察；未完成前不进入 P17-10 |
| P17-10 资源清理与连接数提升 | ⏳ 等待 P17-9 | 旧 5 个 sslocal 和 PassWall HAProxy 合计约 27 MiB RSS；当前 conntrack 为 30720/15360 |
稳定后停用旧路径，逐项审计常驻进程并将 conntrack 提升到 65536/32768 |
| P17-11 P17 最终验收与归档 | ⏳ 等待 P17-6 至 P17-10 | 服务器、订阅、360T7、Android/iOS 和回退证据尚未统一收口 | 执行完整本地门禁、精确 SHA 发布门禁、最终回退演练和阶段归档 |
🛠️ 工作包与依赖
P17-0 基线与执行契约冻结
只读回读 RR、MM、d02、dog、dd 的 2S-UI 版本、监听地址、面板身份、Master 节点 base_url、DNS 当前记录、MM vhost、RR 私有网关和 Console 契约。每台节点在变更前保留 root-only 数据库快照，记录文件权限、SHA-256 和恢复命令。冻结域名清单、证书方式、节点 canary、客户端版本和测试窗口；任一基线与计划不一致时停止生产变更并先修正事实。
P17-1 节点域名与 Master 拨号兼容
先以 dog 做 canary。在 RR 的 /etc/hosts 中登记四个节点面板域名到各自 Tailnet IPv4，先确保 Master API 可用域名 Host 拨号；再设置 canary 的 webDomain=panel-dog.yohan.fun、webURI=https://panel-dog.yohan.fun/app/，保持订阅身份为空。将 Master 对应节点 base_url 改为 http://panel-dog.yohan.fun:2095，验证心跳、节点页面、配置读取和入站副本正常后，再依次处理 MM、d02、dd。RR 继续使用 proxy.yohan.fun，不修改数据面监听。
P17-2 DNS、证书与面板网关
控制面 DNS 不再增加指向 MM 的 panel-* A 记录。proxy 和四个 panel-* 均改为 CNAME edge.yohan.fun，TTL 600；数据面 mm-proxy、dog-proxy、rr-proxy 继续保留独立 A 记录。健康 Edge 通过 DNS-01 签发包含控制面和面板域名的 ECC 证书，并由统一 Nginx 网关承接：proxy 回源 RR 2095/2096，四个面板回源 RR 100.64.0.1:39200。RR 私有网关继续按 Host 路由到对应节点 Tailnet 2095，完整传递 Host、Origin、X-Forwarded-* 和 WebSocket Upgrade。任何一步失败都只回滚该域名或该节点，不扩大修改范围。
P17-3 Console 代理网络架构页
在 Console 新增 #proxyNetwork 工作区，并把左侧“系统入口 → 代理控制面”改为内部打开该页面。页面按客户端、Console、RR Master、四个节点面板、数据面和迁移期旧链路分层展示，节点卡片直达对应面板，Master 卡片直达 https://proxy.yohan.fun/app/。页面使用原生 HTML/CSS/JS，完整支持桌面和 390x844 移动视口，不嵌入 iframe，不运行 D2。D2/SVG 继续作为文档和设计源，生产页面只消费稳定 URL。
P17-4 真实客户端与资料归档
Windows 使用 Clash Verge Rev v2.5.7，Android 使用 Clash Meta for Android v2.11.35，iOS 使用 Stash 3.4.1。三端分别导入同一 Clash 订阅，确认策略组顺序、fallback 语义和协议兼容；在受控窗口逐台阻断节点数据面端口，验证新连接按顺序切换，逐台恢复后验证回切。已有连接不迁移作为记录事实。S20 已建立 Termux、Termius 和 TermRover 对九个在线节点的移动 SSH 管理通道；第二次受控重启后 Tailscale、Termux:Boot 和探针循环均已自动恢复，因此自启门禁已经解除。Magic2 已完成 Termux、Termius、TermRover 九目标、Tailnet-only 入站 SSH、探针 v0.3.8 和整机重启恢复；TermRover 现场为 9 saved，实际登录 101 与 RR 并回读 root shell。TermRover 包 sh.termrover.app 不是 debuggable 应用，run-as 被系统拒绝，因此九主机只能在该应用界面内配置或恢复；其 Tailnet 字段只服务于官方 API Key 所属组织，不是自托管 Headscale 控制面 URL。用户设置 Exit Node 后，Google 真机 ping 3/3、约 173–179 ms，Gemini 真实对话返回 Hello! How can I help you today?，因此 Google/Gemini 门禁已关闭。当天另发现 Termux 进程停止后入站 SSH 拒绝，USB ADB 重新启动 Termux 并执行两个 boot 脚本后恢复；这一事实说明恢复脚本有效，但不能替代长期后台驻留观察。下一步直接在已验收的 Android 设备上执行 Clash Meta 订阅切换和回切验收。同步复核 assets/proxy-network-clients 的来源、哈希、安装说明和 File-Hub 长期目录回读，不在仓库保存安装包二进制和凭据。
P17-5 发布、验收与回退收口
完成本地测试、脱敏检查、GitHub 推送、Actions 监控、RR/Master/MM/Console 生产回读和文档更新。只有精确 SHA 的必需工作流全部成功并返回 post_push_verify=pass，才允许记录提交成功。P17 的最终完成归档只在三端客户端、DNS/证书、Console 页面、节点管理、回退演练和用户验收全部有证据后建立；任一必需项失败则保持“进行中”并明确失败平台或故障域。
P17-6 统一主协议与 360T7 基线准备
前置条件：用户已批准最简方案，并明确 360T7 不重新编译、不改当前固件边界；五台节点最终只保留 VLESS + REALITY，一个 agentmeshos-main client 共享同一 VLESS UUID。当前工作只做只读回读、参数盘点、维护窗口、执行顺序和回退设计，不修改任何 Inbound、订阅或 PassWall 节点。验收要求是五台节点当前 Inbound、客户端身份、端口、监听、2S-UI 数据库快照路径、360T7 PassWall 配置导出路径、恢复镜像和回退命令全部有证据；发现的共享身份已由用户确认接受，不再作为阻塞条件。
P17-6 执行结果
2026-10-12 已执行只读基线核验，证据位于 /root/project/AgentMeshOS/temp/p17-6-evidence/。五台节点均运行 S-UI Panel 1.8.3 和 Sing-Box v1.14.1，s-ui.service 均为 active/enabled，五份 SQLite 数据库 PRAGMA quick_check 均为 ok。
| 节点 | 主机名 | 当前 Inbound | 监听 | 客户端关联 | 数据库 SHA-256 |
|---|---|---|---|---|---|
| RR | rr |
rr-trojan-24446 |
100.64.0.1:2095/2096、0.0.0.0:24446/tcp |
agentmeshos-main 关联 5 条 Inbound |
9ca21b761ffdbcff0cdb5e10a6477fd7855d006f397ce204d9a7b2d7b1b57d8d |
| MM | r1049668 |
mm-reality-24443 |
100.64.0.6:2095/2096、0.0.0.0:24443/tcp |
agentmeshos-main 关联 1 条 Inbound |
551d727b56305b642e28aa6d227af1678753a84cce42f110c93f92355619d6f2 |
| d02 | d02-dedirock |
d02-reality-24443 |
100.64.0.5:2095/2096、0.0.0.0:24443/tcp |
agentmeshos-main 关联 1 条 Inbound |
fb5bb1acca7b7feb72b5aa04f0f5be3e1ada0de295099b095636f51c6a006079 |
| dog | dog |
dog-hysteria2-24444 |
100.64.0.3:2095/2096、0.0.0.0:24444/udp |
agentmeshos-main 关联 1 条 Inbound |
ba78113624edcffb673cf24f754f5b61334755283dc3c3be4499d41124fbc7d3 |
| DD | dedirock-717106053 |
dd-ss2022-24445 |
100.64.0.9:2095/2096、0.0.0.0:24445/tcp+udp |
agentmeshos-main 关联 1 条 Inbound |
c1105a287298226aba7e073ca133193664d514c526dc7182dd1bc6a0c7c9469a |
MM 的 s-ui.service 当前 NRestarts=15。日志显示 2026-10-11 10:25:44 至 10:31:46 多次因 agentmeshos-wait-tailnet-address.sh 未在 30 秒内等到 100.64.0.6 而失败，10:32:24 最终启动成功；这是 Tailnet 地址就绪时序问题，不是 2S-UI Inbound 配置损坏。P17-7 修改前必须保留该事实，避免把重启原因误判为新 Inbound 故障。
身份摘要只在本地计算 SHA-256，未输出 UUID、密码、私钥或 short ID。核验结果发现以下共享项：
| 冲突 | 摘要证据 | 影响 |
|---|---|---|
| MM 与 d02 共享 VLESS UUID | 两节点 client_identity.sha256 均为 9b3b2258f92e25268d1768a75be57cf8bb93eaebf4cfbb5abc7c3c594f835832 |
用户已确认接受；所有 Reality 节点统一使用一份 VLESS UUID |
| dog 与 RR 共享密码 | Hysteria2 与 Trojan 关联客户端协议配置摘要均为 5a056c8495360fed22b2c7bf5d44ff20bd0c4e5037c4ca177289b19ae178717a |
旧异构协议会在迁移完成后删除，不再扩展共享面 |
| MM 与 d02 共享 SNI 和伪装目标 | 两端均为 www.microsoft.com，Inbound 身份摘要分别为 1406b0019f591f73e6eb5688afbe1b7836589204ddb0e816872a91274c51c839 和 d83d2c318c32bf28822c5f85f4126f944871937446689870f1c5532e41fc783d |
P17-7 已确认其余 Reality 参数按节点独立；共享只保留在用户接受的客户端 UUID 层，MM/d02 共享 SNI 作为已知残余项保留 |
2S-UI 当前数据模型以一个 clients 记录承载同一协议的一份 config，该记录已同时关联 MM、d02、dog、DD、RR 五条 Inbound。用户已确认接受五台共享同一 VLESS UUID，以换取现有订阅 URL、现有客户端和 2S-UI 用户管理不发生迁移。P17-7 不再拆分 client，也不再引入 external links 聚合或新订阅服务。
360T7 基线也已采集：/etc/config/passwall SHA-256 为 1b8da1f935010f236bdcedf00b88ddcf12c6979f05d399b3dc7c70f3400ce43e，/etc/config/network 为 25fd979d3a5c4ce75d10e74567f6185b16b56e1f68be2dface38a0ff9775e55b，/etc/config/firewall 为 6dbc78ec104a4f0ac1967f7d19621bf72b5646ea39ccbb047db83bd4ef7a215a。当前全局节点仍是 f9Re2U27，HAProxy balancing_enable=1、balancingStrategy=source，nf_conntrack_max=30720、nf_conntrack_buckets=15360、count=715。现有 /etc/config/passwall.bak-* 和 C 版恢复包均已核对；firmware/recovery/360t7-c-260919/SHA256SUMS 六项全部 OK。
P17-6 状态为 ✅ 完成。当前工作包切换到 P17-7；执行方式固定为“先在 dog、DD、RR 加 Reality，旧 Inbound 不删除，全部验证后再更新订阅并让所有在线客户端刷新”。
P17-7 五节点统一 REALITY 主入口
前置条件：P17-6 通过并冻结。先保留现有 MM、d02 Reality 和 dog、DD、RR 旧 Inbound，为 dog、DD、RR 逐台增加 VLESS + REALITY，统一使用 24443/tcp。五台继续共享 agentmeshos-main 的 VLESS UUID；逐台复核 REALITY 私钥、Short ID、SNI 和伪装目标，避免五台使用完全相同的 TLS/REALITY 身份。每台节点修改前保存 fresh root-only 的 2S-UI 数据库快照，修改后从节点本地和公网订阅两个视角回读版本、监听、协议、端口和客户端身份；任何一台失败只回滚该节点并继续保留旧 Inbound。
P17-7 执行结果
五台节点写入前已生成 fresh 数据库快照，路径为 /root/.codex/backups/proxy-network-2s-ui/p17-7-<node>-20261012T014520Z.db，权限 0600 root:root，大小 114688。dog、DD、RR 分别新增 dog-reality-24443、dd-reality-24443、rr-reality-24443，旧 dog-hysteria2-24444、dd-ss2022-24445、rr-trojan-24446 均未删除。
| 节点 | 真实连接结果 | 吞吐 | ICMP | 结论 |
|---|---|---|---|---|
| MM | 10/10 | 0.5174 MiB/s | 0% | Reality 可用 |
| d02 | 10/10 | 0.5796 MiB/s | 0% | Reality 可用 |
| dog | 10/10 | 0.5287 MiB/s | 0% | 新增 Reality 可用 |
| DD | 10/10 | 0.4446 MiB/s | 0% | 新增 Reality 可用 |
| RR | 10/10 | 0.4382 MiB/s | 0% | 新增 Reality 可用 |
测试使用官方 Mihomo v1.19.32，配置只监听 127.0.0.1，不接管 101 的系统路由。仓库默认 topology 已同步改为五台 Reality、panel-* 拨号和新顺序，契约测试 proxy_master_deploy_contract=pass。P17-7 为 ✅ 完成。
P17-8 订阅发布与在线客户端刷新
前置条件：P17-7 五节点 REALITY 均可独立连接。将五条 Reality Inbound 加入 agentmeshos-main，保留原订阅 URL 和 Proxy / Auto 组名，主备顺序固定为 MM、d02、dog、DD、RR。迁移窗口内可暂时把旧 Inbound 放在 Reality 后备之后，确认所有客户端已刷新并成功后，再从 Auto 移除旧协议。验收要求是 Clash YAML 可解析、五节点 Reality 完整、原订阅 URL 不变、Windows/Android/iOS 刷新后可读取新成员，并保留修改前 subClashExt 或订阅配置的 root-only 快照。
P17-8 执行结果
Master agentmeshos-main 当前关联为 [2,3,8,10,9]，只保留五条 Reality；公网 https://proxy.yohan.fun/sub/agentmeshos-main?format=clash 已回读为五条 Reality，Proxy 和 Auto 顺序均为 MM -> d02 -> dog -> DD -> RR，订阅地址不变。写入前 subClashExt 快照为 /root/.codex/backups/proxy-network-2s-ui/p17-8-subclash-before-20261012T015837Z.yaml，权限 0600，SHA-256 为 41c6c9a6092141127faf4a003e326ba1d7159a139a74ae4863fe8fc2e8977880。
Home 与 OfficeSummer 的 Clash Verge Rev 已刷新 profile，均回读五台 Reality；Home 通过 7897 的 204 探测约 0.568s，OfficeSummer 约 0.646s。Summer、S20、Magic2 当前 Tailnet 离线，不能把未刷新客户端写成完成。Mihomo fallback 的实测行为是当前健康节点在故障时按顺序接替，但当前健康成员恢复后不保证自动回到 MM；因此严格回切只在 360T7 Xray 主备路径成立，标准订阅客户端不能承诺同等回切。旧协议在全部客户端上线刷新前继续保留。
2026-10-12 追加订阅规则修正：Master subClashExt 的规则改为 DOMAIN-SUFFIX,agentrouter.org,Proxy、DOMAIN-SUFFIX,vidhub2.top,DIRECT、GEOIP,LAN,DIRECT、GEOIP,Ads,REJECT、GEOIP,CN,DIRECT、MATCH,Proxy。公网订阅及 Home、OfficeSummer 的 profile 均已回读一致，Home 与 OfficeSummer 对 agentrouter.org 的实测均返回 HTTP 200；本地 Mihomo 日志确认命中 DomainSuffix(agentrouter.org)，连接链使用 Proxy -> AgentMeshOS-mm-reality-24443。自定义域名规则统一放在 GEOIP 前，后续可在 S-UI 原始 YAML 编辑器中继续增加 DOMAIN-SUFFIX,<域名>,Proxy 或 DOMAIN-SUFFIX,<域名>,DIRECT。360T7 不消费该 Clash 订阅，其 PassWall 分流规则不受此变更影响。
P17-9 360T7 Xray 主备与自动回切
前置条件：P17-8 通过。360T7 保持当前 C 版固件，不重新刷机或编译。先在 PassWall 中建立 Xray 主组，只选择 MM 的 REALITY 节点；再建立 Xray 后备组，选择 d02、dog、dd、rr 的 REALITY 节点，后备组允许使用 leastPing，不要求严格顺序。将主组的后备节点指向后备组，并把 PassWall 全局节点切换为主组。切换前备份 /etc/config/passwall、HAProxy 配置和网络配置；旧 Balance HAProxy 组保留为回退。验收要求是 MM 健康时持续走 MM，MM 数据面阻断后自动进入后备组，MM 恢复后自动回到 MM，后备节点单点故障不影响其他节点，路由器重启后 PassWall、Xray、DNS、Wi-Fi 和 FullCone NAT 均自动恢复。
P17-9 执行结果（进行中）
360T7 采用 ImmortalWrt 25.12-SNAPSHOT、PassWall 26.9.1 和 Xray 26.3.27。切换前备份为 /root/passwall-backups/p17-9-20261012T021401Z/，其中 /etc/config/passwall SHA-256 为 1b8da1f935010f236bdcedf00b88ddcf12c6979f05d399b3dc7c70f3400ce43e。
新增 p17_dog_reality、p17_dd_reality、p17_rr_reality 三个 Xray Reality 节点；建立 p17_main_balancer 只包含 MM，p17_backup_balancer 包含 d02、dog、DD、RR，并使用 leastPing。五台节点均通过 PassWall url_test_node，主 Balancing 的真实出口回读为 MM 91.149.239.34；在隔离实例中阻断 MM 后出口切到 RR 96.44.133.235，解除阻断后回切 MM。
切换验证暴露了全局透明代理的稳定性问题：将 Global node 指向 p17_main_balancer 后，101 对 api.github.com 的连续请求出现 Send failure: Broken pipe；对应 GitHub Actions run 38195889742 的 build-and-push 在 Set up job 阶段因 SSL 连接失败退出，未能下载 action。A/B 对照中，旧 f9Re2U27 路径连续 10/10 返回 200，而 Xray 路径在预热阶段出现多次即时失败。为避免把失效路径留在生产，360T7 已回滚 Global node 到 f9Re2U27；Xray 主备节点和后备结构保留但未验收，旧 Balance、5 个 sslocal 和 HAProxy 继续运行。
尚未完成：定位 Xray 全局透明代理的稳定性根因并重新切换，随后完成整机重启恢复和稳定观察。P17-9 因此保持 ⚠️ 进行中。
P17-10 资源清理与连接数提升
前置条件：P17-9 通过并完成至少一个稳定观察周期。先关闭旧 5 个 sslocal 和 PassWall HAProxy，保留配置文件与启动项回退材料；随后按“正常路由、WiFi、FullCone NAT、PassWall 基础功能、Xray 主备、必要 DNS 服务”白名单逐项审计常驻进程，只关闭已证明无依赖的进程。旧系统 HAProxy 的 444/81/60000 不得与 PassWall HAProxy 混为一谈，关闭前必须单独审计。资源稳定后将 nf_conntrack_max 调整为 65536、nf_conntrack_buckets 调整为 32768；验收要求包含峰值连接、内存、CPU、OOM、nf_conntrack table full、DNS 和 UDP 回归。131072 仅在真实峰值超过约 5 万且内存持续稳定时单独评估。
P17-11 P17 最终验收与归档
前置条件：P17-6 至 P17-10 全部通过，且 P17-4 中 Android/iOS 真机与原有未闭环项目有真实证据。统一执行本地完整测试、脱敏扫描、文档构建、GitHub Actions、精确 SHA 的 post_push_verify、服务器和 360T7 生产回读、旧路径回退演练与最终验收。P17 只有在该门禁全部通过后才允许归档；任一平台、节点、订阅、资源或回退项失败则继续标记“进行中”，不得用服务器侧 smoke 代替真实客户端验收。
🧪 验收与发布
| 验收层 | 必验项目 | 成功标准 |
|---|---|---|
| 仓库 | DNS、网关、Console、脱敏、计划状态和文档清单测试 | run-local-tests.sh 全部通过 |
| DNS | proxy 和四个 panel-* 的 CNAME、TTL 和负向保护 |
双解析点一致，CNAME 回读、备份与回滚单测通过 |
| TLS | 四个独立域名证书 | SAN/域名匹配、链完整、有效期正常 |
| 面板 | Master 和四个节点面板 | HTTP 跳转、登录页、WebSocket 101 均通过 |
| 节点 | Master 纳管与数据面 | 心跳在线、副本不变、公网 2095 不可达 |
| Console | 架构页 | 桌面和移动端显示完整、五个链接正确、代理页不嵌 2S-UI、无运行时 D2，生产镜像和文件哈希可回读 |
| 客户端 | Windows、Android、iOS | Windows 已完成；Android/iOS 必须在同一订阅语义下完成顺序切换、回切和旧连接边界记录 |
| 统一主协议 | 五节点 REALITY 主入口 | 每台节点独立身份、24443/tcp 可连接、现有异构备用未删除 |
| 订阅发布 | 原 URL 与原策略组 | 五台 Reality 全部进入 Auto，客户端刷新后成员和顺序可回读；旧协议在刷新完成后移除 |
| 360T7 主备 | PassWall Xray 主组与后备组 | MM 健康优先；MM 阻断后接替；MM 恢复后回切；单备用故障和路由器重启均通过 |
| 资源 | 旧 SS/HAProxy 下线与 conntrack | 旧路径停用后无 OOM、无表满；65536/32768 调整后路由、WiFi、NAT、DNS 和 UDP 回归通过 |
| 发布 | GitHub 与生产 | 精确 SHA 工作流成功、post_push_verify=pass、生产回读通过 |
🔁 回退方案
节点回退恢复 2S-UI 数据库快照、面板域名字段、Master base_url、新增 REALITY Inbound 和 RR /etc/hosts；DNS 层只删除 P17 新增的四个记录；TLS 层保留证书但关闭新 vhost 即可恢复旧入口；网关层恢复应用前备份并执行 nginx -t 后 reload；Console 回退到上一完整镜像 SHA。360T7 回退以 /etc/config/passwall、HAProxy 配置、网络配置和固件恢复包为准，旧 5 个 sslocal、旧 Balance 组和旧订阅在下线观察期内保留。客户端验收失败时继续使用旧订阅；任一服务器 Inbound、订阅或 Xray 主备失败都不得删除旧链路。
⚠️ 未决项 / 需要用户决策
| 事项 | 当前事实 | 下一步 |
|---|---|---|
| 客户端实测窗口 | Home 与 OfficeSummer 已刷新新订阅，但 Windows 新五节点故障切换未执行；Summer、S20、Magic2 当前离线；iOS 无在线真机 | 客户端上线后执行 Clash/Mihomo 新五节点切换与回读；iOS 需提供在线设备；未执行前不得把客户端验收记为完成 |
| 客户端身份粒度 | 用户已确认接受五台共享 VLESS UUID，现有 agentmeshos-main、订阅 URL 和用户管理结构均保持不变 |
不拆分 client；P17-7 仅统一 Inbound 和 Reality 服务端参数 |
| 在线客户端刷新 | Home、OfficeSummer 已完成；Summer、S20、Magic2 当前离线 | 客户端上线后执行一次更新和回读；360T7 已单独更新 PassWall，待重启恢复验证 |
| 当前快照有效性 | P17-7 已为五台节点建立 fresh 快照，路径、权限和 SHA-256 已登记在 P17-7 执行结果 | 后续变更继续按节点单独快照，不覆盖本轮回退点 |
| MM 启动时序 | s-ui.service 的地址等待时序已记录；P17-7 修改后服务与 Reality Inbound 均正常 |
若后续重启再次失败，按 Tailnet 地址就绪问题处理，不误判为 Inbound 配置损坏 |
| 控制面独立节点 | RR 同时承载 Master 和末位数据面 | P17 接受该风险，不新增控制面 VPS |
| 旧链路下线 | P17-9 稳定前不修改旧 ss-rust、HAProxy 和旧订阅；P17-10 只执行经证据确认的清理 |
保留旧配置和启动项回退材料；系统 HAProxy 444/81/60000 与外部服务必须单独审计后再决定 |
| 360T7 固件边界 | 用户已确定保持当前 C 版，不重新编译、不引入 Mihomo/Nikki | 如后续需求再次变化，另立固件选型任务，不并入 P17 本轮实施 |
| conntrack 上限 | 当前 30720/15360，P17-10 计划先提升到 65536/32768 |
131072 只有真实峰值超过约 5 万且内存稳定后才评估 |