proxy-station/docs/FLCLASH-WIREGUARD-AUDIT-2026-11-02.md

# 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`，源码依赖为上游对应提交的本机临时副本。