没有公网 IP 做远程访问：WebRTC、libp2p、frp、webrpc 怎么选？

没有公网 IP 做远程访问：WebRTC、libp2p、frp、webrpc 怎么选？

做个人项目时，我经常卡住同一件事：家里有一台 NAS 或树莓派，人在外面，运营商不给公网 IP，路由器也不想乱开端口。这时候搜索结果里最常跳出的名字，几乎总是 WebRTC、libp2p 和 frp。它们都很常见，但并不自动等于「适合你的产品」。

最近把 webrpc 也放进同一张对照表里看了一圈。结论其实很朴素：

• 音视频会议，优先 WebRTC
• 要自建一整套 P2P 协议栈，看 libp2p
• 只想把已有 HTTP/SSH 服务透出去，用 frp
• 要做无公网 IP 下的多端应用通信、文件传输、设备 RPC，更该认真看 webrpc

下面按这个逻辑拆开讲。

先分清：你要的是「隧道」，还是「业务调用」

很多需求被笼统说成「内网穿透」，真正落地时其实有四种完全不同的目标：

1. 把家里的某个端口暴露到公网，像多开了一扇门——这是隧道问题，frp 很擅长。
2. 两端拉起音视频或实时媒体流——这是 WebRTC 的主场。
3. 自己定义发现、路由、协议模块，搭一条可进化的 P2P 网络——这是 libp2p 的主场。
4. 在 App 里像调用远程方法一样发请求、收回复，大文件尽量走直连——这才是 webrpc 想承接的那一类。

选型翻车，多半是拿错了锤子：用 WebRTC 硬做网盘协议，用 frp 硬扛端到端业务通道，或用 libp2p 只为了发几条 RPC。

WebRTC：媒体很强，网盘和 RPC 要自己补

WebRTC 之所以成为默认联想，是因为它在浏览器实时音视频上几乎无可替代。ICE、STUN、TURN 生态成熟，DataChannel 也能塞自定义数据。

但一旦主需求变成个人网盘、跨网文件、长期在线的 NAS 守护进程、多语言原生端，你会发现 WebRTC 并没有替你做完应用层：

• 信令服务仍要自己设计与运维
• 目录、分片、断点、业务 RPC 语义都要自建
• 「能传数据」和「能做出一个稳定的私有云产品」之间，还隔着很长一段工程

所以我会这样用它：产品核心是通话、会议、直播连麦，就上 WebRTC；产品核心是文件与设备调用，就不要默认从 WebRTC 起步。

libp2p：上限很高，交付很 DIY

libp2p 更像模块化网络工具箱。对等发现、多路复用、可插拔传输，社区里能拼出非常强的基础设施。如果你的目标本来就是自定义 P2P 协议栈，它值得投入。

反过来，独立开发者若只是想在 Android、Windows 和家里 NAS 之间尽快跑通业务调用，libp2p 往往过重。你要选组件、处理弱网和产品化细节，学习曲线和维护面都不小。对「先把私有云做出来」的人来说，这通常不是最短路径。

frp：穿透最快，模型却是中继隧道

frp 解决痛点的方式非常直接：公网机器跑 frps，内网跑 frpc，HTTP、SSH、TCP 都能很快映射出去。想 SSH 回家、临时打开 NAS 管理页，它几乎是最快方案之一。

也正因为模型清晰，边界同样清晰：

• 流量常常经过你自己的 VPS，带宽和费用在中继侧
• 它提供的是入口，不是应用内的会话 SDK
• 多端加密业务通道、RPC 语义、文件传输协议，仍要另做
• 端口暴露后的鉴权与攻击面，需要自己收紧

如果你要的是运维向的「把服务变可达」，frp 很好。如果你要的是产品向的「在客户端里稳定完成一次远程调用」，它只完成了前半程。

webrpc：把 P2P 收成接近 RPC 的 SDK

webrpc 的定位和前三者都不太一样。它把自己描述成面向 NAT 与复杂网络的点对点通信基础设施：能直连时尽量直连，传输加密，API 有意做成 RPC 风格，让应用开发少碰打洞循环和各平台套接字细节。

从官网能力看，关键点大致是：

1. 用 Token 标识端点，常见是一设备一 Token
2. 登录后建立加密 P2P 会话，双方都可以没有公网 IP
3. 进程通过本地回调拿到带 sessionId 的数据，再用 SendData 回复，观感接近一次 RPC 返回
4. 提供多平台 Native SDK，以及 Go、C/C++、Java、Rust、Python、PHP 等示例
5. 公开材料里常见的卖点包括约 200ms 量级握手、QUIC 传输、弱网重试放在 SDK 内处理

它更适合这类目标同时成立的时候：个人 NAS 或私有云、设备互联、私有 IM、远程监控与遥测、跨网 RPC；没有公网 IP；希望业务代码保持 登录 → OpenSession → SendData/SendFile 这种节奏；需要原生多端，而不是只在浏览器里跑；大流量希望尽量吃两端本地带宽，而不是全程烧中继。

当然也不该神话。浏览器音视频还是 WebRTC；要深度定制网络协议还是 libp2p；只是临时透 SSH 或后台页，frp 仍然更快。官网也写明握手无法保证百分百成功，高延迟和跨境策略可能带来失败或波动，产品层仍要做超时与重试。

对照表

一个够用的决策顺序

可以按下面顺序问自己：

1. 主需求是音视频会议或直播连麦吗？是，就 WebRTC。
2. 只是想把现成的 HTTP/SSH 服务透出去吗？是，就 frp。
3. 要自研完整 P2P 协议与发现机制吗？是，就 libp2p。
4. 需求落在无公网 IP、多端 SDK、文件或 RPC 调用？优先评估 webrpc。

小结

「穿透」只是手段，真正要交付的是稳定业务调用。WebRTC、libp2p、frp、webrpc 都有自己的主场，把它们当成同一类「内网穿透工具」互相替换，很容易选错。

我自己的用法是：临时运维走 frp，实时画面走 WebRTC，网络实验走 libp2p；一旦目标变成家里那台没有公网 IP 的设备，要被手机和电脑像 RPC 一样调用，就把 webrpc 放进候选，用两个 Token 在真实网络里把登录、会话和收发跑通，再决定是否替换现有方案。

个人档试用成本不高，官网 Personal 套餐常见报价大约每年 5 美元、2 个 Token；SDK、文档和套餐都以 webrpc 控制台 为准。合法业务再用，违法用途平台不容忍，责任仍在开发者和运营者自己。