a5d980a5e9
实现独立加密设备身份、网关 agent、持久生命周期任务和 Surge/FlClash 专属订阅凭证。 完善 Shadowrocket 规则转换与 Clash AI DNS，增加 Surge FFSB 适配、规则快照、运维工具及验收文档。
7.2 KiB
FlClash Android：WireGuard 与本机入站能力核对
核对日期：2026-11-02。范围：官方稳定版 FlClash v0.9.2（2026-10-24 发布）、该 tag 固定的内核子模块，以及官方配置文档。初次研究未安装 APK、未做 Android 真机测试、未改订阅/设备/peer 或生产部署；后续本地实现见 配置兼容性。
结论
| 能力 | 本次结论 |
|---|---|
| WireGuard 出站节点 | 支持，FlClash 的节点模型与内核都有相应类型/字段 |
| Android 主动经 WG 访问 njcq 私网、Mac 服务 | 可作为候选；需要配置正确的节点/私网规则并用实际设备验证 |
| 已发起连接的响应数据 | 属于正常 TCP/UDP 出站能力，不是任意本机服务入站的证明 |
| 像 Surge allow-peer-access 一样，由对端主动访问 Android 本机应用 | 当前标准 Android 使用方式未提供等价配置/桥接实现；不能作为已支持的双向设备方案 |
| Apple VNC 高性能媒体 | 未验收；WG、普通 TCP/UDP 或握手成功都不足以证明该业务可用 |
| 本项目 FlClash 订阅附加设备 WG | 已部署独立用途的设备凭证及出站配置；尚未真机验收 |
以上入站判断来自已核对版本的实现，不能扩写为所有 Mihomo 版本、root 环境或自定义补丁都永远不可实现。
版本与来源
- 官方站点
- 官方 v0.9.2 发布
- v0.9.2 模块声明：实际使用作者的 Clash.Meta fork，而不是任意版本的上游 Mihomo。
- v0.9.2 core/go.mod：Mihomo 依赖替换到本地
./Clash.Meta。 - 该 tag 的 Git tree 将
core/Clash.Meta固定在 c5062921054902b25215a6a933e72ccd714c9bfa。本文内核判断使用该提交。
WireGuard 出站的依据
FlClash 的 节点模型 包含 wireguard 类型与私钥、公钥、PSK、allowed-ips 等字段；Mihomo 官方 WG 配置 也将其放在 proxies 出站节点中。
固定内核的 wireguard.go 实现：
- WG 参数、peer 与 TCP/UDP 能力；
newIPStack创建内部 MIPS/gVisor 网络栈；DialContext从内部栈发起 TCP；ListenPacketContext为 UDP 代理流创建内部 socket。
因此可研究 Android 主动经 njcq 连接 Mac 的私网服务。这个源码结论不替代认证、握手、业务连接及 Android VPN 路由实测；也不说明可以直接导入 Surge .conf，FlClash 使用的是 Mihomo YAML。
Incoming 指的是什么
本项目需要的是：另一设备经 njcq，向 Android 的 WG 固定 IP 发起 TCP/UDP 连接，并到达 Android 本机实际运行的服务。它不同于“支持 WG 加密”“接收已发起连接的回包”“提供 HTTP/SOCKS 代理端口”或“作为 WireGuard 服务端监听 UDP”。
Surge 官方 allow-peer-access 文档 明确说明这种本机服务入站；旧名 accept-incoming 仍受支持。该文档还单列 Apple Screen Sharing 的系统栈处理、固定源地址/端口及反向 UDP 媒体行为。
核对 FlClash v0.9.2 固定内核后：
- WG 选项没有
accept-incoming/allow-peer-access对应字段； - WG 地址属于内部用户态 WG 栈，出站适配器没有建立将这些地址的任意本机服务流量转交 Android OS 应用的桥接；内部栈有 Listen 方法不代表 Android App 已在该内部栈监听；
- Android 的 VpnService 单独建立系统 VPN 接口，使用其固定 VPN 地址/路由，不会因为 YAML 里填了一个 WG
ip就自动把它变为 Android 本机服务地址； - UDP 出站 socket 使用空的本地 AddrPort，不能由“支持 UDP”推出它具有 Surge 对 Apple Screen Sharing 的源端口透传和反向流投递行为。
由此判断：不能只加一项 YAML 参数，就把 FlClash 当成已具备 Surge 同等本机入站能力的客户端。 这仍是源码判断，未通过 Android 本机服务的反向连接实验。
Mihomo WireGuard inbound issue #2864 在核对时仍 open，但它讨论的是 WireGuard 协议入站/服务端功能，与本项目所需 peer-access 并不完全相同，只作补充，不能单凭该 issue 得出全部结论。
容易混淆的开关和业务
allow-lan 官方说明 是让其他设备访问 Clash 的代理端口；它不会把 Android 的全部本机服务接到 WG 地址上。TUN 开启同样不是这个桥接能力的证明。
若安卓仅需主动访问 Mac，WG 出站可继续做独立验证；若需要 Mac/其他设备反过来访问 Android 的服务，则当前 FlClash 方案不能按已确认支持接入。还需区分普通 VNC 与 Apple VNC 高性能媒体，不将此前 Shadowrocket 的特定失败原因移植成对 FlClash 的已证实故障结论。
若改用独立的 Android WG VPN 处理系统层地址，需要另行设计与 FlClash 的共存方式。Android 官方 VPN 文档 明确每个用户/工作资料只有一个活动 VpnService，启动另一个会停止原来的服务。因此不能默认“同时打开 FlClash VPN 与官方 WireGuard”即可解决。
对 Proxy Station 的影响
初次研究时尚无 Clash 设备 WG 序列化。后续已在本地补充独立分发用途、WG 出站和私网规则，排除动态公网组；默认订阅不附身份。配置仍需在 Android 真机上验证，不复用正在运行的 Mac/iPad 身份，也不恢复 Shadowrocket WG。
追加隔离对照（同日）
adb devices -l 未发现已连接的 Android 设备，因此没有对 FlClash APK 或 Android 真机做网络验收。为验证“栈内监听”和“系统监听”是否自动等价，在本机使用该固定内核 go.mod 所锁定的 mipstack 提交 9a80a07eaeb9，构造两个直接交换 IP 包的隔离内存栈：
- 系统
127.0.0.1打开 TCP 服务，虚拟对端连接另一栈的虚拟 IP、同一端口：连接失败，系统监听不会自动成为栈内监听。 - 维持上述系统服务，在虚拟栈上显式创建同一端口的 TCP listener：虚拟对端连接成功。
该对照没有运行 FlClash、Android 或真实 WireGuard 加密，也没有检查 UDP/Apple VNC；只能验证默认 MIPS 栈的隔离现象，并与前述固定版本源码的桥接缺口相互印证。测试没有修改本机活动 Surge、生产配置或节点。临时实验代码在 /private/tmp/flclash-wg-research.8KkNAl/lab.go，源码依赖为上游对应提交的本机临时副本。