Webman不能替代frpc或nps_client，因其仅为HTTP框架，缺乏TCP/UDP隧道转发、心跳保活、客户端注册中心等穿透必需能力；所谓“Webman内网穿透”实为调用frpc/nps进程的可视化配置界面，不参与实际数据转发。

Webman 本身不提供内网穿透能力，但可以作为高性能管理平台承载穿透服务（如 FRP/NPS 的 Web 管理端），或通过自研隧道代理模块实现轻量级穿透逻辑。直接拿 Webman 当“穿透工具”用会踩坑——它没有内置的 TCP/UDP 隧道转发、心跳保活、客户端注册中心等核心能力。

为什么不能直接用 Webman 替代 frpc 或 nps_client

Webman 是一个常驻内存的 HTTP 服务框架，底层基于 Workerman，擅长处理高并发 HTTP 请求，但它不是网络层代理程序：

• Webman 默认只监听 HTTP/HTTPS 流量，无法原生处理原始 TCP 或 UDP 数据包（比如 SSH、RDP、DNS 查询）
• 它没有内置的客户端连接注册、隧道生命周期管理、多路复用封装（如 frp 的 mux 协议）等穿透必需机制
• 若强行用 Webman 接收外网请求再 file_get_contents 转发到内网服务，属于同步阻塞调用，会卡死事件循环，失去高并发优势
• 真实穿透场景要求低延迟、长连接维持、断线自动重连——这些需在 Swoole/Workerman 底层用 onConnect/onClose/onMessage 手动实现，Webman 不暴露这些钩子

webman-admin 内网穿透插件的真实定位

市面上所谓“Webman 内网穿透平台”，实际是 webman-admin 提供的可视化配置界面，背后仍依赖独立运行的 frps/frpc 或 nps 进程：

Webman 2.2.0

Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。

下载

• 插件只负责生成和下发 frpc.ini 配置，调用 system('frpc -c /path/to/frpc.ini') 启动客户端，不参与数据转发
• Web 界面看到的“在线状态”来自定时轮询 frps 的 dashboard_port（如 7500）API，不是 Webman 自己探测的
• HTTP 类型穿透（如域名路由）可由 Webman 做一层反向代理（proxy_pass），但 TCP/UDP 必须交由专用穿透进程处理
• 若你在插件里配了 type = tcp，却没在服务器上装 frpc，点击“启动”只会报错：sh: frpc: not found

真正在 Webman 里做穿透要绕过哪些坑

如果你坚持用 Webman 实现简易穿透（例如仅限 HTTP 内网服务暴露），必须绕开默认 HTTP 模式限制：

• 不能用 app/controller 处理隧道流量——控制器是为业务逻辑设计的，不适合做字节流透传
• 需在 app/process 下新建自定义进程，用 Swoole\Server 或 Workerman\Connection\TcpConnection 手动监听端口，实现 onReceive 直接转发原始数据
• 内网目标地址不能写死在代码里，要从数据库或配置中心动态加载，否则每次改 IP 都得重启进程
• 必须自己实现连接池、超时控制（set_timeout）、错误重试，否则一个异常连接会拖垮整个进程
• HTTPS 流量需在 Webman 前加 Nginx 终止 SSL，或用 Swoole\Server 启用 ssl 选项，但 Webman 官方不封装该能力

真正稳定的内网穿透，永远是“Webman 管配置 + 独立穿透进程跑隧道”。混淆这两层职责，最容易在流量突增时发现：Webman 进程 CPU 100%、隧道连接大量 TIME_WAIT、客户端频繁掉线却查不到日志——因为问题根本不在 Webman 里。