问题 A：我要让互联网用户访问一个 Web 服务#

比如：

1
Home Assistant Dashboard
2
内部 Web 面板
3
开发中的网站
4
自建 API
5
博客源站

你希望用户访问：

1
https://app.example.com

但源站：

• 没有公网 IPv4；
• 在 NAT 后面；
• 不想开放 80/443；
• 甚至不想让别人知道真实源站 IP。

这是一类Public Ingress 问题。

问题 B：我有一台公网 VPS，想自己控制转发#

例如：

1
公网 VPS:6000
2
      ↓
3
家里电脑:22

或者：

1
example.com
2
   ↓
3
公网 frps
4
   ↓
5
内网 Web 服务

你希望自己掌握：

• 公网服务器；
• 端口；
• 转发规则；
• TCP / UDP；
• TLS 和反向代理结构。

这是一类Self-hosted Reverse Proxy / Relay 问题。

问题 C：我只想让自己的设备彼此可达#

例如：

1
笔记本 → 家里 NAS
2
手机   → VPS SSH
3
开发机 → 树莓派
4
服务器 A ↔ 服务器 B

你根本不需要让这些服务暴露给整个 Internet。

你想要的是：

1
“只有我的网络成员能访问”

这是一类Private Mesh / Overlay Network 问题。

而 Cloudflare Tunnel、FRP、Tailscale 恰好分别更接近这三个方向。

公网入口在哪里？#

在 Cloudflare。

用户访问你的域名时，公网连接先到 Cloudflare Edge：

1
Client
2
  ↓
3
Cloudflare
4
  ↓
5
Tunnel
6
  ↓
7
Origin

因此 Cloudflare 可以在前面继续叠加：

• DNS；
• TLS；
• WAF；
• CDN；
• DDoS 防护；
• Access / Zero Trust 身份策略；
• Bot / Rate Limit 等边缘能力。

所以 Tunnel 很适合的一种思路是：

我不是想拥有一个公网转发端口，而是想把这个内部 Web Origin 接到一个现成的公网边缘平台。

最大优点：源站入口可以收得非常小#

传统公网 Web 架构往往是：

1
Internet
2
   ↓ 443
3
Public Origin

源站至少需要存在一个 Internet 可达的入站面。

Tunnel 则可以是：

1
Origin
2
  │
3
  └── outbound → Cloudflare

如果整个服务只通过 Tunnel 提供，那么源站防火墙可以不为 Internet 开放传统 Web 入站端口。

这不是说安全自动解决了，而是攻击面的位置发生了变化：

1
公网入口安全
2
更多交给 Cloudflare Edge
3

4
源站安全
5
更多关注本机、Tunnel credential、内部服务和出站连接

它的代价也来自同一个地方#

入口在 Cloudflare，意味着生产链路会依赖 Cloudflare 的控制面和边缘网络。

如果你的要求是：

1
“公网入口、中继服务器、协议栈必须全部自己控制”

那么 Tunnel 就不是最“自主”的方案。

它的优势正来自托管边缘平台，依赖也同样来自托管边缘平台。

FRP 的本质更像“自建可编程转发站”#

例如一个最直观的 SSH 映射：

1
公网 VPS:6000
2
        ↓
3
       frps
4
        ↓
5
      tunnel
6
        ↓
7
       frpc
8
        ↓
9
内网机器:22

用户访问：

1
ssh -p 6000 user@public-vps

FRP 再把这条连接送回内网 SSH。

FRP 还支持 TCP、UDP、HTTP、HTTPS 等不同代理类型，因此它比“只能反代 Web”的思路更通用。

它和传统 Nginx 反代的关键区别#

普通 Nginx 反代通常假设：

1
Nginx 能主动访问 Backend

比如：

1
Nginx VPS
2
   ↓
3
192.168.1.10:3000

但公网 VPS 往往根本路由不到你家里的 192.168.1.10。

FRP 做的是：

1
先让 frpc 从 LAN 主动连接 frps
2
再在这个已建立的通道中反向承载连接

所以它解决的是“公网中继与内网之间缺少可路由路径”。

FRP 的自由度来自“你自己承担基础设施”#

这也是它和 Cloudflare Tunnel 最明显的工程取舍。

你拥有：

1
公网 VPS
2
frps 配置
3
开放端口
4
域名
5
TLS
6
访问策略
7
日志
8
限速
9
版本升级
10
监控

因此：

1
控制权 ↑
2
运维责任 ↑

如果公网 frps 自己挂了，对应转发链自然也会断。

如果端口直接暴露到 Internet，认证和服务本身的安全也需要你自己认真处理。

FRP 并不是“一装就安全的内网穿透神器”，它更像一块可自己设计的网络积木。

最理想的数据路径是 Peer-to-Peer#

Tailscale 官方当前把连接分成：

• Direct connection；
• Peer Relay；
• DERP relay。

在能完成 NAT traversal 的情况下，两台设备会尝试建立直接 UDP 连接：

1
Laptop
2
   ╲
3
    ╲ WireGuard encrypted P2P
4
     ╲
5
      NAS

也就是说，真实业务数据不一定一直绕某个中央 VPN 服务器。

如果直连失败，才会退回到 Relay 路径。

官方文档也明确指出这些连接都使用 WireGuard 端到端加密；直连与 Relay 的主要差异更多体现在路径、吞吐和延迟，而不是“Relay 就变成明文”。

这和 FRP 的思维完全不一样#

FRP 经典模型：

1
客户端
2
  ↓
3
固定公网 frps
4
  ↓
5
frpc
6
  ↓
7
服务

Tailscale 理想模型：

1
Device A
2
  ↓
3
NAT traversal
4
  ↓
5
Device B

中间的控制面负责身份、密钥协调、节点信息等，但能够直连时，数据面尽可能直接走 P2P。

因此如果我要的是：

1
我自己的电脑 SSH VPS
2
我自己的手机访问 NAS
3
实验室几台机器互相通信

我根本不需要把 SSH / SMB / Database 暴露成公共 Internet Service。

这才是 Tailscale 特别舒服的场景。

Cloudflare Tunnel#

1
Public User
2
    ↓
3
Cloudflare Edge   ← 公网入口
4
    ↓
5
cloudflared
6
    ↓
7
Internal Service

FRP#

1
Public User
2
    ↓
3
Your VPS / frps   ← 公网入口
4
    ↓
5
frpc
6
    ↓
7
Internal Service

Tailscale#

1
Authorized Device A
2
       ↕
3
 Private Overlay / P2P
4
       ↕
5
Authorized Device B

Tailscale 通常根本没有一个“所有 Internet 用户都来这里”的公网入口。

于是一个非常实用的选型问题出现了：

我的用户是整个 Internet，还是一组已授权设备？

如果答案是“整个 Internet”，你大概率在讨论 Public Ingress。

如果答案是“我自己的几台设备”，你大概率应该先考虑 Private Overlay，而不是急着做公网端口映射。

Cloudflare Tunnel：不要求外界连接进来#

1
cloudflared
2
    ↓ outbound
3
Cloudflare

只要内网可以向外建立必要连接，就能维持 Tunnel。

这相当于绕开“如何从 Internet 主动打进 NAT”这个问题。

FRP：内网主动连接一个稳定公网服务器#

1
frpc
2
   ↓ outbound
3
frps(public VPS)

Internet 只需要能访问 frps。

真正的内网机器不需要自己拥有公网地址。

Tailscale：先尝试 NAT Traversal，再决定要不要 Relay#

Tailscale 会尝试让双方找到可直接通信的路径。

成功：

1
Peer A ↔ Peer B

失败：

1
Peer A → Relay → Peer B

所以它关心的是：

1
“两个成员能不能建立最优私网路径”

而不是：

1
“我要在哪个公网服务器暴露 6000 端口”

Control Plane：谁决定“谁能和谁通信”#

它负责：

• 节点发现；
• 配置；
• 身份；
• 策略；
• 路由信息；
• Tunnel / Session 建立。

Data Plane：真实业务字节最后从哪里走#

例如：

1
HTTP body
2
SSH packet
3
SMB data
4
数据库连接

真实数据路径不一定和控制面路径相同。

1
Control Plane / Edge：Cloudflare
2
Data Plane：Client → Cloudflare → Tunnel → Origin

1
Control：frps / frpc
2
Data：Client → frps → frpc → Service

1
Control Plane：协调节点身份与连接信息
2
Data Plane：优先 Direct WireGuard
3
           不行再 Relay

Cloudflare Tunnel 的安全边界#

如果只发布一个 Web App，可以设计成：

1
Internet
2
   ↓
3
Cloudflare Edge / Access Policy
4
   ↓
5
Tunnel
6
   ↓
7
Origin

源站无需传统公网入站端口，但你仍然要保护：

• cloudflared credential；
• Cloudflare 账户；
• Zero Trust 策略；
• Origin 本身；
• 其他旁路入口。

FRP 的安全边界#

如果你把：

1
VPS:6000 → LAN:22

直接发布到 Internet，那么公网 SSH 本身仍然是公网 SSH。

FRP 只是改变了路径，不会把一个本来需要认证和加固的服务自动变成“无风险服务”。

你还需要考虑：

• frpc ↔ frps 认证；
• 公网端口；
• 服务自身认证；
• VPS 防火墙；
• 日志和暴力扫描；
• TLS / Token / ACL 等策略。

Tailscale 的安全边界#

它更容易形成：

1
Internet 上的人
2
       ✕
3
不能直接访问私有服务
4

5
Tailnet Authorized Device
6
       ↓
7
Policy / Identity
8
       ↓
9
Private Service

这里的重点从“公网端口保护”转移到：

1
设备身份
2
账户安全
3
ACL / Grants
4
节点密钥
5
Tailnet Policy

它不是没有安全问题，而是安全边界换了一个位置。

Cloudflare Tunnel#

数据会经过 Cloudflare Edge，再沿 Tunnel 到源站。

对于公网 Web 来说，这并不一定是坏事，因为 CDN / Edge 本来就是架构的一部分。

你优化的目标通常不是：

1
“绝对最短 P2P RTT”

而是：

1
全球公网入口
2
TLS
3
缓存
4
WAF
5
稳定 Origin Connectivity

FRP#

如果是经典中继：

1
User → VPS → LAN

那么 VPS 地理位置、带宽、线路、CPU、内核网络栈都会直接进入性能路径。

所以 FRP 服务器的位置非常重要。

Tailscale#

如果 Direct：

1
A → B

通常拥有最短路径。

如果只能 DERP / Peer Relay：

1
A → Relay → B

吞吐和延迟就会受 Relay 路径影响。

Tailscale 官方文档也明确把“直连通常具有更低延迟和更高吞吐”作为重要区别。

所以排查 Tailscale 性能时，一个关键问题不是：

1
“WireGuard 快不快？”

而是：

1
“当前到底是 Direct 还是 Relayed？”

场景 1：把内部 Web Dashboard 安全地发布给公网用户#

需求：

1
域名访问
2
HTTPS
3
不想给源站开放公网端口
4
希望叠 WAF / Access

更自然：

1
Cloudflare Tunnel

因为它本身就在解决“Web Origin → Cloudflare Public Edge”的问题。

场景 2：我只想从自己的笔记本 SSH 回家里的机器#

需求：

1
不想公网开放 22
2
只有自己的设备访问

更自然：

1
Tailscale

因为这根本没必要变成公网服务。

场景 3：我要转发一个比较特殊的 TCP / UDP 服务，并且必须使用自己的 VPS#

需求：

1
自控公网 IP
2
自控端口
3
非标准 Web 协议
4
愿意运维 VPS

更自然：

1
FRP

场景 4：临时给别人演示本地 Web 项目#

如果对方只是浏览器用户，而且希望快速用域名 / HTTPS 打开：

1
Cloudflare Tunnel

如果演示对象是自己团队里已经加入私网的设备：

1
Tailscale

关键不是工具流行度，而是“访问者是什么身份”。

场景 5：五台 VPS + 家庭 NAS + 笔记本形成管理网络#

这种场景我最不想做的是：

1
每台机器都公网开放 SSH

更清晰的结构是：

1
Tailscale Management Plane
2

3
Laptop ───── VPS-A
4
   ├──────── VPS-B
5
   ├──────── NAS
6
   └──────── Home Server

公网 Web 服务继续走自己的 443 / CDN / Tunnel，而运维面单独走私网。

这叫分离用户流量和管理流量。

Cloudflare Tunnel#

可以分：

1
DNS
2
  ↓
3
Cloudflare Edge
4
  ↓
5
Tunnel status
6
  ↓
7
cloudflared
8
  ↓
9
local origin

如果 localhost:3000 自己就打不开，先别怪 Tunnel。

FRP#

可以分：

1
Public port
2
  ↓
3
frps listening
4
  ↓
5
frpc connected
6
  ↓
7
proxy registered
8
  ↓
9
local service

如果 frpc 都没有在线，外面改 Nginx 没意义。

Tailscale#

可以分：

1
Node authenticated?
2
  ↓
3
Policy allowed?
4
  ↓
5
Route exists?
6
  ↓
7
Direct or Relay?
8
  ↓
9
Target service listening?

把链路分层以后，“内网穿透坏了”这种模糊描述会变成一个具体的状态断点。

结语#

Cloudflare Tunnel、FRP、Tailscale 都能让“原本不好访问的机器”变得可达。

但它们的核心心智模型分别是：

1
Cloudflare Tunnel
2
= 把 Origin 接到托管的 Public Edge
3

4
FRP
5
= 把 LAN Service 反向接到自己的 Public Relay
6

7
Tailscale
8
= 把 Devices 组成一个 Private Overlay Network

所以与其问：

“哪一个内网穿透最好？”

不如先问：

“我要构建的是公网入口、自建中继，还是私有设备网络？”

网络工具最怕用错抽象。

因为一开始只是“能不能连通”的问题，到了生产环境就会逐渐变成：

1
谁拥有入口？
2
谁看到流量？
3
哪里认证？
4
哪里故障？
5
谁来运维？
6
数据实际绕了多远？

而这些问题，恰恰才决定一个方案最后是“能跑”，还是“长期好维护”。