Android VPN 服务器：root 并不能让手机变得可达

root 改变的是进程被允许尝试哪些网络操作。它不会给手机一个公网可达的地址，不会在上游预留入站映射，也不会让守护进程在重启后继续存活。如果你正在判断一台 Android 手机能否充当 VPN 服务器，请把三件事拆开：目标客户端到底能不能到达监听端口、服务器实现需要怎样的权限模型，以及隧道建立之后需要转发什么。

谁必须、从哪里到达这台手机

同一允许网段内的客户端与使用移动数据的客户端，测试的是两个完全不同的网络。先确定你要应对的是哪一种，因为答案并不通用。在 Wi-Fi 下，未经请求的入站流量通常需要上游路由器上的一条映射，以及映射之外一条可用的公网路径。在蜂窝网络下，运营商级 NAT 意味着入站 IPv4 往往根本不可用，手机允许什么并不改变这一点。

而 root 恰恰碰不到最后这一项。手机本地防火墙与运营商 NAT 是两套不同的系统，改动前者对后者毫无影响。私有接口地址、移动数据图标、正在监听的套接字，都不是可达性的证据。即使运营商路径确实提供全球可路由的 IPv6，你仍然需要为它单独制订监听与防火墙策略；有地址并不等于愿意接受连接。

提供服务与转发是两种不同的成功

一次完成的 VPN 握手只能证明隧道存在。它不能证明客户端可以到达手机后方的局域网，也不能证明手机可以充当互联网出口。这些是彼此独立的配置，建立在内部地址规划、路由、回程行为，以及针对你真正想要的任务所划定的狭小转发策略之上。

失败的样子很好预测：握手成功，客户端显示已连接，但什么都加载不出来。在调试客户端之前，先确定你究竟在建哪一种角色。对手机所在网络中某台设备的远程访问，与整条隧道的互联网出口，需要不同的转发规则；只想要一种却把两种都放开，只会扩大暴露面，并不会增加你要的能力。

权限模型是一种选择，而不是 root 或者什么都做不了

使用内核 TUN 设备的传统 OpenVPN 守护进程，需要相应能力、对设备节点的访问，以及 Android 安全策略的配合。root 并不是对 SELinux 的一揽子豁免；特权进程仍然受平台策略约束。这正是为什么一个在 Linux 服务器上运行良好的二进制程序，到了手机上会失败，而且没有任何关于权限的明显报错。

用户空间的网关实现可以拥有完全不同的权限模型，所以「Android 上每个 VPN 服务器都需要 root」这个常见说法过宽了。root 买到的是尝试更多操作的能力，而不是这些操作一定被允许、结果一定可达的保证。

Android 自身的 VPN 服务注册又是另一套机制。它给应用一个受管理、具有明确生命周期的客户端接口；它不是通用的服务器安装器，从终端启动一个守护进程，也换不来常驻管理、按应用策略或自有的恢复路径。

想要一个出口，就改架构

当目标只是通过手机远程出网，而不是兼容已有的 OpenVPN 配置时，覆盖网络中受支持的出口节点是更匹配的设计。Tailscale 记录了Android 出口节点角色，并给出了它自己的注册、授权与客户端选择步骤。

这个取舍是真实的，也值得说清楚：你接受另一种协议、另一种信任模型，并依赖那个账号与协调服务。它不会让未经修改的 OpenVPN 客户端加入覆盖网络，也不会给你一个位于公网地址上的 OpenVPN 监听。

部署仍然需要什么

无论走哪条路，决定它能否撑过一周的是运维基本功。保守服务器凭据，为每个客户端签发不同的身份，并在需要之前就规划好吊销。确定更新如何到达、什么让服务在后台保持运行，以及它在重启或网络切换之后如何自己恢复。

避开那些看起来很方便的捷径：过时的静态二进制、写死的接口名，以及会清空现有防火墙策略的启动脚本。然后用一个具体测试来验收：被授权的远程客户端能到达预期资源，被禁止的目标依然不可用，设备在受支持的生命周期事件之后能自行恢复。root 权限只是这个结果中可能的一味材料，而且很少是决定性的那一味。