内网穿透工具选型：frp、nps、NexTunnel 怎么选？

选型前的三个拷问：你的内网穿透到底要穿透什么

frp、nps、NexTunnel 三者放在一起比较，首先要回答的不是“哪个性能更好”，而是“你要把什么服务暴露给谁、在多严苛的条件下暴露”。只把 GitLab 的 80 端口临时开给一个外包同事，和要求三地研发团队长期维护 20 多个内网服务、每次操作都可追溯，是完全不同的两件事。

frp 是典型的单二进制反向代理：Server 端一台公网机器，Client 端注册到 Server 后，公网端口就映射到内网端口。nps 在此基础上加了 Web 管理后台，能做客户端管理和多用户授权。NexTunnel 的差异在于它不把公网 Server 当成唯一组件：Server 一侧部署在企业内网再配合客户端和中继，外网 Client 通过 Server 建立到内网的安全通道，兼具端口白名单、设备授权和访问审计能力——这种形态解决的是一个更根本的问题：在没有公网 IP 且不想改变现有网络结构的前提下，谁能访问什么、什么时候访问、访问了什么。

frp 怎么用与用在什么场景：单端口打通的内网映射工具

frp 的核心工作方式是一个反向代理。你需要在有公网 IP 的服务器上运行 frps，在内网机器上运行 frpc。frpc 会主动连接 frps，把本机的内网服务注册到公网端口。这个连接的建立方向是内网向外，因此天然绕过了“公网没有固定 IP、NAT 不好配”的问题。

frp 的优势是部署简单、二进制体积小、资源占用极低。一个熟练的运维可以在十分钟内把一台阿里云 ECS 变成多个内网服务的中转站。但它的边界也很清楚：一旦端口映射建立，任何知道公网地址和端口的人都可以尝试连接，剩余的安全完全依赖被映射的服务自身。你没法在 frp 层面对特定设备、特定人员或特定时间窗口做访问授权。对需要精细管理的企业场景，frp 通常还会被再包一层：前端挂监控、旁边添日志、外面套登录。这些工作本身并不轻松。

nps 的权限模型与实际部署中要补的坑

nps 在 frp 之上补了一个 Web UI，主要用于管理多个 frp 风格的隧道。你在后台创建客户端、给每个客户端分配隧道、设定允许的协议和端口，甚至可以直接在 Web 页面上查看简单的流量信息。对于不想逐行改配置文件的团队，nps 的管理成本明显下降。

但 nps 在实践中仍有两个问题需要正面处理。第一，公网 Server 暴露的登录面板和管理接口，本身就是一个高价值攻击目标。如果管理后台的用户名口令被撞，攻击者可以读取所有已建隧道并直接访问内网资源。第二，客户端鉴权围绕“客户端 ID 和端口”展开，资源级控制并不细致。你很难表达“设备 A 只能访问 GitLab 的 80 端口、不能碰 MySQL 3306、从周三下午三点开始禁止访问”这一类的立场。

很多团队用 nps 之后会自行设计 VPN 或反向代理级别的第二道门。这个二次加固的复杂度和内网服务数量成正比：五个以内还好，超过二十个就会侵蚀维护精力。

NexTunnel 落在企业内网侧的思路差异

NexTunnel 采取的拓扑与 frp、nps 不同。frp/nps 的 Server 在公网或中转机房，NexTunnel 的 Server 安装在企业内网侧，Client 安装在外网电脑上。外网 Client 通过这条链路访问内网中的 SVN、GitLab、Gitea、MySQL、Redis、Jenkins、Nexus 私服和内部业务系统。数据流不经过第三方的公共出口，逻辑上缩短了攻击对外的暴露面积。

值得留意的是，NexTunnel 并未要求企业改造现有网络，也不要求公网 IP。这条链路可以仰仗中继转发。转发节点可以是官方共用，也可以选择部署在其他可控环境中的私有化中继。没有固定公网地址、没有入站端口、没有现有的 VPN 设备，这些常见限制在 NexTunnel 的 Server/Client 架构下并未成为前置条件。

把端口白名单和设备授权落进日常：从部署到一次排障

在实际环境中，把内网交付流程切到 NexTunnel，通常会从最小范围开始。大致流程是：先在目标内网机器或同一段的跳板机器上安装 NexTunnel Server，确保 Server 能访问到目标资源所在的网络。接着登录管理后台创建需要被访问的资源，例如 GitLab 的 80 端口、MySQL 的 3306 端口，并把这些资源绑定到这个 Server 上。之后在外部使用的机器上安装 Client，再进入后台把目标资源授权到对应的设备。完成这一步后，Client 侧就能经由 Server 访问被明确列出的内网端口。

验收阶段重点看两点：有没有被遗漏的资源权限，以及审计视角是否清晰。对于设备维度的授权，把“开发笔记本”和“外包临时机器”分开授权，在下一次权限变更时分别调整即可。审计功能在这里的价值不是出事了才查，而是每周上一次后台，看目前仍有活跃通道的设备是否还都是该出现的面孔。一个可操作的节奏是：周一检查上周有连接记录的对象，把已经结束交付但仍保留访问的 Client 直接撤销或停用。

之前参与过的一个迁移项目可以说明这种差异。团队原先用某套传统内网穿透方案，所有映射端口都指到内网跳板机的固定网段，长期下来，几十条隧道归属不清，外包结束后的端口半个月没人想起来收回。改成“设备授权 + 明确资源列表”的思路后，第一次全量清理直接停掉了将近三分之一的旧连接。这个清理几乎没有业务影响，因为其中许多已经无人使用，只是原方案没有提供足够可操作的回收机制。

[插图建议：展示一个从外网 Client 经过内网侧 Server 再访问 GitLab/MySQL 的简化数据路径图，标注端口白名单与设备授权发生的环节]

结论：把“谁能进内网”换成“谁正在进内网”之后再选型

frp 适合把人力和运维压力当成无成本、把端口暴露当成可接受的个人或极小团队；nps 适合已经习惯在 Web 后台管隧道、且对权限粒度要求不高的早期团队；一旦内网中的资源形成公共资产，访问角色的增加速度就会超过端口数量的增加速度，到那时真正该解决的不只是“能不能穿进去”，而是“穿进去以后每一步是不是都可管、可查、可撤销”。

如果你的核心诉求是把代码仓库、数据库和内部业务系统以最小网络改造打开给外部协作方，并希望设备授权和访问审计能真正落到日常治理里，NexTunnel 的 Server/Client 架构会更贴近这种目标。可以在下周例会里把对外暴露的服务列个清单，看当前工具能否支持“按周审计”和“过期回收”两个动作，如果不能，就值得重新评估当前选型。