a5d980a5e9
实现独立加密设备身份、网关 agent、持久生命周期任务和 Surge/FlClash 专属订阅凭证。 完善 Shadowrocket 规则转换与 Clash AI DNS，增加 Surge FFSB 适配、规则快照、运维工具及验收文档。
50 lines
5.3 KiB
Markdown
50 lines
5.3 KiB
Markdown
# Shadowrocket WireGuard / Apple VNC 对照记录
|
||
|
||
2026-11-02 后续结论：用户已在 macOS/iPadOS/iOS 全面验证 Surge + WireGuard 可工作，停止 Shadowrocket WG 兼容。本文件保留历史复现与排查证据，不再作为继续实现的任务；相关 WG 下发路径已在本地清理，发布状态见 [实现记录](WIREGUARD-DEVICES.md)。
|
||
|
||
状态：2026-11-01，尚未在 Shadowrocket 上解决。本文不含真实密钥、订阅 token 或公网端点；没有向开发者发送反馈。
|
||
|
||
2026-11-02 接续说明：用户已将个人设备统一为 Surge，本文保留为历史对照与未决问题记录，不是当前设备管理实现的阻塞项。最新方案与代码入口见 [实现交接](design/wireguard-devices/HANDOFF.md)；不据此声称 Shadowrocket 问题已经修复或新 Surge 三端功能已验收。
|
||
|
||
## 目标与环境
|
||
|
||
让 OpenScreenSharing 的 Apple VNC 高性能模式通过 iPad Shadowrocket 的 WireGuard 节点工作，并保留既有公网分流。
|
||
|
||
- iPad Pro，Shadowrocket 2.2.93 (3488)，UDP 转发开启、禁用 STUN 关闭。
|
||
- 同设备官方 WireGuard 使用相同身份的标准配置，Apple VNC 已成功，用户确认速度良好。
|
||
- Mac：Surge 6.11.0 (12660)，allow-peer-access/旧 accept-incoming 已生效。官方该 build 说明包含 Apple Screen Sharing 特殊处理。
|
||
- Linux hub：内核 WireGuard，同接口转发两个 peer，仅允许私网，未做公网 NAT。
|
||
- 私网示例为 iPad 10.203.0.2、Mac 10.203.0.3，Apple VNC 连接 TCP 5900、媒体使用 UDP 5900/5901。
|
||
- OpenScreenSharing 与官方 WireGuard 的具体 App 版本尚未单独记录。
|
||
|
||
## 已验证事实
|
||
|
||
1. Shadowrocket 节点已导入、握手正常；普通 VNC 快速可用，账号 RSA-SRP 认证成功。
|
||
2. Apple VNC 在 Shadowrocket 下仍加载/黑屏。服务器抓到双向 UDP，iPad 反馈源端口保留为 5900/5901；不能泛称所有 UDP 被阻断或源端口完全不保留。
|
||
3. 一次受控样本：hub 入站 4,858 个视频 RTP 唯一序号，序号跨度 4,858、缺口 0%；4,288 组 IPv4 分片全部完整；iPad 同期报告约 200 Kbps、90% 丢包。
|
||
4. 同一 iPad 换官方 WireGuard 后 Apple VNC 成功；服务器观察到相同公网出口、同一 peer 身份，Mac 与 hub 保留 MTU 1280。
|
||
5. 后续完整 MTU1420 对照中，两个 token、Mac effective 配置、实际 Shadowrocket YAML 与 hub 运行 MTU均核对到1420，日志确认 iPad 重新拉取节点订阅；iPad UI 字段值尚未单独回报。99.311 秒捕获14,596个IP包、0分片，固定源端口正确；期间三次媒体 SSRC 的 hub 入站 RTP 缺口分别为0%、4.348%、60.437%，不能合并成“链路始终无丢包”。用户最后报告仍无画面、0%丢包和约200Kbps，需区分没有媒体样本与确实无缺口。
|
||
6. 所有远端/生产临时 MTU 改动已自动恢复1280，原生客户端成功配置未覆盖。
|
||
|
||
## 依据与解释范围
|
||
|
||
- [OpenScreenSharing 作者关于固定源端口和反向接收的说明](https://github.com/nekohasekai/open-screen-sharing/issues/2)。该评论有版本/场景范围，不能据此认定当前所有代理客户端永久不兼容。
|
||
- [Shadowrocket 官方网站](https://shadowlaunch.com/) 由 App Store sellerUrl 确认；官网链接指向公告频道。
|
||
- [build3488说明](https://t.me/ShadowrocketNews/1665)、[2.2.93正式版](https://t.me/ShadowrocketNews/1666)，未找到声明修复此 Apple VNC 症状的内容。2.2.94 build3490–3493 的公开说明也未见此修复；这不等于开发者确认存在同一bug。
|
||
- 历史[raw socket MTU修复3215](https://t.me/ShadowrocketNews/1454)、[读取长度调整3216](https://t.me/ShadowrocketNews/1455)、[L3 UDP fast relay3399–3400](https://t.me/ShadowrocketNews/1593)表明相关实现曾变动，不能将其当作当前已确认缺少功能的证据。
|
||
- 源码中 Network 为 TCP SRTT/2；视频丢包率来自成功 SRTP 接收的 RTP 序号跨度，画面重组需要同步帧。没有成功媒体样本时，显示0%不代表完整画面链路已通。
|
||
|
||
## 仍待验证
|
||
|
||
- Shadowrocket 设置→代理→代理类型的实际选项与当前状态。社区手册描述 None 为TUN-only、对应compatibility-mode=3；需以当前版本UI/实测验证。尚未修改此设置或在生产强加该参数。
|
||
- 用同一网络、同一配置、同一画质与匹配时间的抓包验证 TUN-only 是否改变原始UDP/L3路径。
|
||
- 最小规则与标准WG配置直接导入Shadowrocket，排除配置转换、其他规则或本地设置干扰。
|
||
- HTTPS日志曾见一台iPhone下载iPad身份；已询问是否并发启用。一次25秒endpoint监测稳定，尚无并发争用证据，不能将此当作早期故障解释。
|
||
- 未确认具体根因是片段接收/重组、反向包投递、媒体反馈还是其他核心实现问题。
|
||
|
||
## 复现与恢复
|
||
|
||
同一身份只开启一种客户端。先在原生WireGuard确认Apple VNC能工作，再关闭它并开启Shadowrocket，通过同一IP连接；记录节点导入格式、实际MTU、代理类型、Apple VNC画质与同一时段的帧率/码率/丢包。所有实验保留独立成功配置，失败后恢复原值。
|
||
|
||
数据库与节点备份路径、详细时间和既有验证见 [WireGuard组网记录](WIREGUARD-LAN.md)。若后续需要反馈给开发者，先补齐TUN/最小配置结果与App版本；只附脱敏配置及经核对的抓包，不附密钥或完整订阅。
|