NetProxy-Magisk：用 eBPF 接管 Android 流量的透明代理模块

它解决什么问题

Android 上的代理工具大多依赖 VPN 接口，比如 V2RayNG 或 Clash for Android。VPN 模式有它的代价：应用可以检测到 VPN 图标，部分游戏或金融应用会拒绝在 VPN 环境下运行，而且 VPN 本身会接管所有应用，分应用控制往往要通过额外路由规则实现。NetProxy-Magisk 走的是另一条路。它以内置 sing-box 为代理核心，通过 cgroup 与 TC eBPF 接管本机及共享网络流量，不改 iptables、nftables 或策略路由。这意味着流量在系统层面被透明转发，应用看不到 VPN 的存在。这个模块面向已经 Root 的 Android 设备，支持 Magisk、KernelSU 与 APatch。它解决的问题很具体：让代理成为系统的一部分，而不是一个用户态应用。

数据路径与内核要求

eBPF 不是随便就能用的。README 明确写了，eBPF 入站需要内核启用 BPF、cgroup v2 与 cgroup socket attach 能力，热点共享还需要可用的 TC eBPF 支持。不满足要求的内核无法启动这个版本。数据路径有三种模式：local、shared 与 hybrid，由 config/ebpf/ebpf.conf 中的 EBPF_MODE 控制。local 只管本机流量，shared 管热点和 USB 共享，hybrid 两者都管。DNS 处理也有独立配置，EBPF_LOCAL_DNS_MODE 和 EBPF_SHARED_DNS_MODE 默认都是 hijack，也就是劫持 DNS 查询。这种设计把流量接管放在内核层，而不是用户态的 tun 设备，所以它声称不修改 iptables 或 nftables。代价是内核兼容性成了硬门槛，旧设备基本无缘。

安装与初始配置

安装本身不复杂。从 Release 页面下载 ZIP，在 Magisk、KernelSU 或 APatch 中刷入。标准包不含管理器 APK，含管理器包会在刷入时提供可选的 APK 安装步骤。更新已有模块时，安装提示会让你选择保留现有数据还是全新安装，超时默认保留。刷入后默认 AUTO_START=0，也就是不会开机启动。首次使用需要导入节点。CLI 是最直接的入口，所有命令都要 Root 权限。导入单个 vless 链接用 su -c '/data/adb/modules/netproxy/netproxyctl node add "vless://..."'，导入 Clash YAML 用 node import /sdcard/clash.yaml。然后 node list 查看节点，node use <分组 ID>/<节点标签> 选择节点，最后 service start 启动。整个流程不需要图形界面，但 CLI 的路径很长，记起来有点费劲。

手写节点文件的坑

如果你不想用管理器或 CLI 导入，可以手写节点文件。但这里有一个容易踩的坑：文件必须是一个完整的 sing-box 配置片段，顶层用 outbounds 数组，不能把单个 outbound 对象直接作为文件根节点。README 给了 SOCKS5 示例，type 字段是 socks，server 和 server_port 分别填地址和端口。还要注意 sing-box 的出站协议字段是 type，不是 Xray 配置里的 protocol。导入后节点会追加到 default 本地配置组，tag 要保证唯一。另外，不要用 direct、block、Proxy 或 Auto-Fastest 作为节点标签，这些是保留名。data/catalog/ 下的 provider.json 由 Catalog 管理，不建议手动编辑，格式错误会导致对应分组无法加载。这些细节说明这个模块对配置格式有严格要求，不是拿来就能乱改的。

管理入口与默认安全边界

NetProxy 提供了四个管理入口：Android 管理器、模块 WebUI、CLI 和 Clash API 加 zashboard。Android 管理器在 Google Play 上，源码在 src/android/，与模块共用 netproxyctl 的 schema=1 JSON 契约，但构建流程独立，CI 不编译管理器。Clash API 默认 Controller 是 http://127.0.0.1:9999，zashboard 在 /ui/，sing-box Service API Dashboard 在 http://127.0.0.1:9090/dashboard/，Secret 默认是 singbox。这里有个明显的安全提醒：Clash API 与 Service API 默认只监听本机，README 明确说不要直接暴露默认端口。如果你需要从其他设备访问，必须显式配置监听地址，同时调整访问控制、密钥和 TLS。这个默认配置对单机用户够用，但如果你想把代理状态面板开放到局域网，就得自己改配置，否则等于把控制权交给同一网络里的任何人。

配置结构与升级成本

配置分散在几个目录里。config/module.conf 管开机启动、出站模式和订阅调度，config/ebpf/ebpf.conf 管 eBPF 入站和 Map 容量，config/singbox/confdir/ 放通用 sing-box 配置，包括 DNS、路由和 Clash API。runtime/ 是启动时生成的 Provider 和 eBPF 配置，README 说不要手动编辑。日志在 logs/service.log 和 logs/sing-box.log，前者管模块服务与订阅更新，后者管 sing-box 核心。升级时可以选择保留数据，这意味着你的节点和订阅配置不会丢。但要注意，nightly 版本是预发布，v8.1.1 才是稳定版。如果你追求稳定，应该避开 nightly。维护成本主要来自内核兼容性：每次系统更新都可能改变 cgroup 或 eBPF 行为，模块的自动清理机制会清理 eBPF 程序和 TC 挂载，但你不能指望它覆盖所有内核变化。

替代方案与差异

最常见的替代方案是 V2RayNG 或 Clash Meta for Android，它们都基于 VPN 模式。区别在于流量接管层：VPN 模式在用户态创建 tun 设备，系统把流量路由到虚拟接口，应用能看到 VPN 状态；NetProxy 用 eBPF 在内核态挂钩，不产生 tun 接口，应用层面无感知。另一个替代是 iptables 透明代理，比如一些老式 Magisk 模块，但 NetProxy 明确不修改 iptables 或 nftables，而是用 cgroup 和 TC eBPF。这意味着它的依赖是内核 BPF 子系统，而不是 iptables 规则链。如果你设备内核太老，没有 BPF 支持，那 iptables 方案反而更现实。但如果你内核满足要求，eBPF 方案在性能和隐蔽性上更优。

许可证与适用边界

项目采用 GPL-3.0 许可证，这意味着如果你修改并分发这个模块，你的衍生作品也必须以 GPL-3.0 发布。这不是法律建议，但 GPL 的传染性对商业用途是个现实约束。模块本身是 Shell 写的，但核心是 sing-box，sing-box 是 GPL-3.0 的，所以整个项目的许可证选择是一致的。适用边界很明确：只适合已 Root 设备，且内核必须支持 eBPF 和 cgroup v2。如果你用的是 KernelSU 或 APatch，模块也支持，但 eBPF 要求不变。如果你不想折腾 CLI，Android 管理器是日常操作的首选，但管理器需要从 Google Play 安装，国内用户可能需要额外手段。这个模块不是给普通用户准备的，它要求你理解代理配置、内核限制和命令行操作。

编辑结论

NetProxy-Magisk 适合已经 Root 且内核满足 eBPF 与 cgroup v2 要求的用户，尤其是需要系统级透明代理、不想依赖 VPN 模式、又希望保留分应用控制和热点共享能力的人。不适合内核较旧或缺少 BPF 支持的设备，也不适合不想接触 CLI 或配置文件、只想点开即用的用户。采用前应确认内核支持 cgroup socket attach 与 TC eBPF，并检查默认的 Clash API 监听地址和 Secret 是否需要修改。模块默认关闭开机启动，确认节点可用后再将 config/module.conf 中的 AUTO_START 改为 1，这是最稳妥的启用顺序。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes