# 交付物 · 端口决策 ＋ 设备当中继可行性（2026-09-25/26）

> **工作区**：`E:/ProgramData/AIProject/aliyun-dsh-server`｜**基线**：`D:/github/dsh_shenxian`（只读）
> **用户两条口径**：① **先不开端口，后续有需要再开** ② 可让**性能与网速高的设备当中继**，如桌面客户端版本

---

## §1 拍板 ①：先不开端口（已定）

| | 状态 |
|---|---|
| **D8 云安全组**（47/106 入站 UDP `21100–21115` 放对端 `/32`） | 🔴 **用户拍板：暂不开**（后续有需要再开） |
| **影响** | 真机 P2P 打洞率仍为 **0** ⇒ 内容面跨节点分发的带宽节省（实测潜力 **75–93.75%**）**暂时拿不到** |
| **⛔ 不影响** | 群聊 / 房间 / 消息 / 历史 / 在线态 / 插件 —— **全走 443 中继，功能完整可用** |
| **重开条件** | 要做**跨节点内容分发**（插件内容 / 大文件 / 镜像同步），或消息面直连被证明确有收益时 |

## §2 拍板 ②：设备当中继 —— 🔴 **路径已存在，但要分清两个角色**

### §2-1 现成基础（实证，⛔ 不是设想）

| 件 | 状态 |
|---|---|
| **覆盖网节点接入**（`overlay-node-join.cjs` / `overlay-node-admit.cjs`） | ✅ 已落地：控制面签**一次性**邀请凭据 → 节点侧一条命令四步全自动（私钥**不出机**）→ 批准 → 投影成白名单 |
| **中继白名单机制** | ✅ `dialers: Map<network, Set<hostId>>`、**默认拒绝**（没列到的一个都拨不动）⇒ **加节点 = 配置动作**，任何设备都能登记 |
| **分组 / 独立组网** | ✅ **零代码**：新增一个 `networkId` 即是一张独立网 |
| **桌面端节点接入** | ✅ **已实测**（`dsh-ai1net-desktop/docs/S2_覆盖网络节点接入编排与守护实测报告_20260920.md`）—— 客户端接线 / 身份准入 / **守护**（退避自愈、永不放弃、开机自启）/ 验收脚本全就位 |
| **一条命令既起服务端也起客户端** | ✅ `lib/net/relay/main.js`：`--client`（拨出）／`--port --keys-file --base --span`（**起服务端 = 中继**）|

🔴 **⇒ 结论：桌面端"能当节点"已实测；"能起中继服务端"是同一个入口的另一种模式** —— 技术路径通，⛔ 不需要新造协议。

### §2-2 🔴 但必须分清两个角色（这是关键）

| 角色 | 做什么 | 需要"可达"吗 | 现状 |
|---|---|---|---|
| **拨出方**（`--client`） | 连到中继，**把自己的实例口注册出去** | ⛔ 不需要（NAT 允许出站） | ✅ **已实测** |
| **中继 / 被拨入方**（`--server`） | 监听并**替别人转发** | ✅ **需要**：别人得能连到它 | ⚠️ 未实测 |

⇒ 你说"设备当中继"＝要的是**第二个角色**。它比第一个多一道门槛：**其他节点得能连上这台设备**。

### §2-3 🔴 一个容易混淆的点：设备当中继**也有它自己的"端口问题"**

⛔ 这**不是**服务器云安全组那件事，而是**用户自己那侧的网络**：

- 设备在家庭/公司 NAT 后面 ⇒ 外网连不进来 ⇒ **不能被当中继**（除非：公网 IP、路由器端口映射/UPnP、或打洞成功）。
- ⚠️ 所以"**先不开端口**"这个决定与"设备当中继"**不冲突**（一个是服务器的，一个是用户设备侧的），但**设备当中继自己也有可达性门槛** —— ⛔ 别以为"换设备当"就绕开了全部网络前提。

✅ **但有一类场景几乎零门槛**：**同一局域网 / 同一组织内网**（公司内几台高性能机器互为中继）——
内网直连不需要任何公网端口，立即可用。

### §2-4 ✅ 一条**完全不需要任何端口**的替代路径（推荐先试）

不用"设备当中继"，改成"**设备主动拉**"（业界叫 **fan-out on read**）：

```
服务器收到消息 → 只落库 + 广播一条**小信令**（"某房有新消息"）
              → 各设备**主动拨出**去拉消息（拨出不需要可达、不需要端口）
```

| | 设备当中继 | 设备主动拉 |
|---|---|---|
| 端口/可达性 | ✅ 需要（用户侧 NAT 要能进） | ❌ **不需要**（只出站） |
| 卸载服务器扇出 | ✅ 真正卸载（服务器少写 N 次） | ✅ **同样卸载**（服务器不再逐连接写） |
| 消息延迟 | 低 | 略增（一次拉取往返） |
| 现成度 | 中继服务端已有，接入机制已有 | ⚠️ 需接线（我上一棒的插件 `subscribe` 轮询**已是雏形**） |

🔴 **我的判断**：若目标是"给服务器减负"，**"设备主动拉"性价比明显更高**——省的是同一块成本，却不需要用户侧任何网络前提。⚠️ 但**要先把轮询做对**（现在是固定间隔轮询，随设备数线性增长 ⇒ 得改成"信令触发 + 增量拉"）。

## §3 与既有技术路线的关系

已拍板的技术路线是「**引入 Centrifugo 类外部连接层**」，而连接层**支持多实例**。

⇒ **你的设想在架构上 = 把连接层的节点来源，从"只由平台提供"扩展为"平台 ＋ 用户自备高性能设备"**。
这与既有方向**一致**，⛔ 不改架构；且已有现成机制（白名单 ＋ 一键加入 ＋ 桌面端守护）。

## §4 建议的推进顺序（技术项，可自决）

1. **先做「设备主动拉」的改造**（无网络前提、收益同向）—— 把轮询改成信令触发 + 增量拉。
2. **同时**在**局域网**场景小范围试"设备当中继"（零公网前提，验证中继服务端角色）。
3. **跨公网设备当中继**留到**确实需要**时 —— 届时与"是否重开端口"一起定（两者同源）。

## §5 边界

⛔ 本件**零代码改动**、未部署、未 commit/push、未动 47/106、未动云安全组、未改桌面线一个字节（**只读**）。
⛔ **未登记下一棒**。