# FlClash Android:WireGuard 与本机入站能力核对 核对日期:2026-11-02。范围:官方稳定版 FlClash **v0.9.2**(2026-10-24 发布)、该 tag 固定的内核子模块,以及官方配置文档。初次研究未安装 APK、未做 Android 真机测试、未改订阅/设备/peer 或生产部署;后续本地实现见 [配置兼容性](FLCLASH-COMPATIBILITY-2026-11-02.md)。 ## 结论 | 能力 | 本次结论 | |---|---| | WireGuard 出站节点 | 支持,FlClash 的节点模型与内核都有相应类型/字段 | | Android 主动经 WG 访问 njcq 私网、Mac 服务 | 可作为候选;需要配置正确的节点/私网规则并用实际设备验证 | | 已发起连接的响应数据 | 属于正常 TCP/UDP 出站能力,不是任意本机服务入站的证明 | | 像 Surge allow-peer-access 一样,由对端主动访问 Android 本机应用 | 当前标准 Android 使用方式未提供等价配置/桥接实现;不能作为已支持的双向设备方案 | | Apple VNC 高性能媒体 | 未验收;WG、普通 TCP/UDP 或握手成功都不足以证明该业务可用 | | 本项目 FlClash 订阅附加设备 WG | 已部署独立用途的设备凭证及出站配置;尚未真机验收 | 以上入站判断来自已核对版本的实现,不能扩写为所有 Mihomo 版本、root 环境或自定义补丁都永远不可实现。 ## 版本与来源 - [官方站点](https://chen08209.github.io/FlClash/?lang=en) - [官方 v0.9.2 发布](https://github.com/chen08209/FlClash/releases/tag/v0.9.2) - [v0.9.2 模块声明](https://github.com/chen08209/FlClash/blob/v0.9.2/.gitmodules):实际使用作者的 Clash.Meta fork,而不是任意版本的上游 Mihomo。 - [v0.9.2 core/go.mod](https://github.com/chen08209/FlClash/blob/v0.9.2/core/go.mod):Mihomo 依赖替换到本地 `./Clash.Meta`。 - [该 tag 的 Git tree](https://api.github.com/repos/chen08209/FlClash/git/trees/v0.9.2?recursive=1) 将 `core/Clash.Meta` 固定在 **c5062921054902b25215a6a933e72ccd714c9bfa**。本文内核判断使用该提交。 ## WireGuard 出站的依据 FlClash 的 [节点模型](https://github.com/chen08209/FlClash/blob/v0.9.2/lib/models/clash_config.dart) 包含 wireguard 类型与私钥、公钥、PSK、allowed-ips 等字段;[Mihomo 官方 WG 配置](https://wiki.metacubex.one/en/config/proxies/wg/) 也将其放在 `proxies` 出站节点中。 固定内核的 [wireguard.go](https://github.com/chen08209/Clash.Meta/blob/c5062921054902b25215a6a933e72ccd714c9bfa/adapter/outbound/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 文档](https://manual.nssurge.com/policies/wireguard.html#allow-peer-access-ios-600-mac-6110) 明确说明这种本机服务入站;旧名 `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](https://github.com/chen08209/FlClash/blob/v0.9.2/android/service/src/main/java/com/follow/clash/service/VpnService.kt) 单独建立系统 VPN 接口,使用其固定 VPN 地址/路由,不会因为 YAML 里填了一个 WG `ip` 就自动把它变为 Android 本机服务地址; - UDP 出站 socket 使用空的本地 AddrPort,不能由“支持 UDP”推出它具有 Surge 对 Apple Screen Sharing 的源端口透传和反向流投递行为。 由此判断:**不能只加一项 YAML 参数,就把 FlClash 当成已具备 Surge 同等本机入站能力的客户端。** 这仍是源码判断,未通过 Android 本机服务的反向连接实验。 [Mihomo WireGuard inbound issue #2864](https://github.com/MetaCubeX/mihomo/issues/2864) 在核对时仍 open,但它讨论的是 WireGuard 协议入站/服务端功能,与本项目所需 peer-access 并不完全相同,只作补充,不能单凭该 issue 得出全部结论。 ## 容易混淆的开关和业务 [allow-lan 官方说明](https://wiki.metacubex.one/en/config/general/#allow-lan) 是让其他设备访问 Clash 的代理端口;它不会把 Android 的全部本机服务接到 WG 地址上。TUN 开启同样不是这个桥接能力的证明。 若安卓仅需主动访问 Mac,WG 出站可继续做独立验证;若需要 Mac/其他设备反过来访问 Android 的服务,则当前 FlClash 方案不能按已确认支持接入。还需区分普通 VNC 与 Apple VNC 高性能媒体,不将此前 Shadowrocket 的特定失败原因移植成对 FlClash 的已证实故障结论。 若改用独立的 Android WG VPN 处理系统层地址,需要另行设计与 FlClash 的共存方式。[Android 官方 VPN 文档](https://developer.android.com/develop/connectivity/vpn#vpn_service) 明确每个用户/工作资料只有一个活动 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 包的隔离内存栈: 1. 系统 `127.0.0.1` 打开 TCP 服务,虚拟对端连接另一栈的虚拟 IP、同一端口:连接失败,系统监听不会自动成为栈内监听。 2. 维持上述系统服务,在虚拟栈上显式创建同一端口的 TCP listener:虚拟对端连接成功。 该对照没有运行 FlClash、Android 或真实 WireGuard 加密,也没有检查 UDP/Apple VNC;只能验证默认 MIPS 栈的隔离现象,并与前述固定版本源码的桥接缺口相互印证。测试没有修改本机活动 Surge、生产配置或节点。临时实验代码在 `/private/tmp/flclash-wg-research.8KkNAl/lab.go`,源码依赖为上游对应提交的本机临时副本。