本文试图探讨的核心问题：没有公网 IP / 处于 NAT 或 CGNAT 后方时，如何用开源的方式让外部访问内网服务？

一、问题空间

内网穿透解决的问题很简单：你的服务跑在家里/办公室的局域网里，外面访问不了。传统的端口映射需要路由器的控制权和公网 IP，但 CGNAT（运营商级 NAT）、DS-Lite、防火墙策略让这条路越来越窄。

隧道工具的核心思路一致：内网主动往外连（NAT 放行出站），通过这条长连接复用回来。但不同工具在"怎么连、能穿什么、怎么管"上出现了显著分化，最终形成了三条完全不同的赛道。

二、全景纵览

活跃维护的项目的社区规模（GitHub Stars）：

FRP 的 Stars 数是第二名到第七名之和的两倍——在这个领域是绝对的统治级。

三、各项目深度分析

3.1 FRP（fatedier/frp）— 行业标准

Stars: 106k | 语言: Go | 协议: Apache-2.0

历史与现状

FRP 是中文开发者 fatedier 于 2016 年创立的项目，至今已走过近 10 年。在两年没有新 release 的沉寂期（2020-2022）之后，2024 年起重回了非常活跃的开发节奏——v0.70.0 于 2026 年 7 月刚刚发布。仓库有约 15k forks、超过 400 位贡献者，是 Go 语言生态中最知名的网络工具之一。

FRP 的架构是经典的两组件模型：frps（公网服务器端）+ frpc（内网客户端）。控制连接和数据连接分离的设计自 v0.10.0 起就已成熟。

核心能力

• 多协议穿透： TCP / UDP / HTTP / HTTPS / STCP（秘密端口）/ XTCP（P2P 打洞）/ SUDP（安全 UDP）
• 多传输层： 默认 TCP，支持 KCP（高延迟优化）、QUIC、WebSocket
• HTTP 高级路由： 域名虚拟主机、URL 路径分发、Host 头重写、HTTP Basic Auth
• 生产特性： 连接池、健康检查（TCP/HTTP）、负载均衡（多 frpc 后端组队）、Prometheus 指标
• 管理面： Web Dashboard、Admin UI 热加载配置
• 认证： Token / OIDC，传输层可选 TLS 加密（默认已启用）
• v0.62+ VirtualNet（alpha）： TUN 虚拟网络，IP 级路由而非端口转发，轻量级 mesh VPN
• SSH Tunnel Gateway： 无需 frpc，纯 ssh -R 建立隧道

典型配置

# frps.toml（公网 VPS）
bindPort = 7000
auth.token = "your-token"

# frpc.toml（内网）
serverAddr = "your-vps.com"
serverPort = 7000
auth.token = "your-token"

[[proxies]]
name = "ssh"
type = "tcp"
localIP = "127.0.0.1"
localPort = 22
remotePort = 6000

[[proxies]]
name = "web"
type = "http"
localPort = 80
customDomains = ["app.example.com"]

ssh your-vps.com:6000 直穿内网，无需路由器配置。

优势

• 社区最大，文档/教程最丰富，遇到问题几乎都能搜到
• 功能最完整，单一工具覆盖了绝大部分穿透场景
• 双协议栈（Layer 4 + Layer 7）在一套配置体系内统一

劣势

• 学习曲线中等——配置选项多，TOML/YAML/JSON/INI 四种格式并存（INI 已 deprecated）
• 默认配置的安全性需要留意——allowPorts 白名单要显式配置，默认绑定所有端口
• 功能膨胀——v2 的开发方向也反映了作者对当前架构复杂度的反思

v2 方向

FRP v2 将是一个不兼容 v1 的重写，受 Envoy 和 K8s Service Mesh 启发，核心是一个通用可扩展的四/七层代理，不局限于内网穿透。目前仍在概念开发阶段。

3.2 Pangolin（fosrl/pangolin）— 零信任接入平台

Stars: 21.8k | 语言: TypeScript (98.6%) + Go (0.7%) | 协议: AGPL-3.0 / 商业双许可

背景

Pangolin 是 2024 年 9 月才启动的项目，不到两年暴涨到 21.8k Stars——增速是这个领域最快的。它有 110 位贡献者、85 个 release（最新 v1.21.0，2026-07-20），开发极其活跃。

Pangolin 和 FRP 做的事有重叠，但定位完全不同。FRP 解决的是"把内网端口暴露到公网"，Pangolin 解决的是"安全地让授权用户访问内网资源"。

核心架构

┌─ 用户浏览器 ──────────────────────┐
│  HTTPS → pangolin.example.com      │
└───────────────────────────────────┘
         ↓ TLS + 身份认证
┌─ Pangolin Hub（公网 VPS） ────────┐
│  - 认证（OIDC/内置用户/RBAC）     │
│  - 路由 / 负载均衡 / 健康检查      │
│  - 自动 ACME 证书 / WAF           │
│  - 审计日志                        │
└──────────┬───────────────────────┘
         ↓ WireGuard 隧道（出站）
┌─ Pangolin Site Connector（内网） ──┐
│  - 用户空间 WireGuard              │
│  - NAT 穿透                        │
│  - 子网路由（CIDR）                 │
└───────────────────────────────────┘

关键区别： 内网机器不暴露任何端口到公网。Site Connector 主动出站建立 WireGuard 隧道，外部用户经过 Hub 的身份验证后，才通过隧道访问内网服务。

功能特性

• 浏览器直接接入： VNC、RDP、SSH 都可在浏览器内完成，无需客户端
• 零信任网络接入（ZTNA）： 每条路由可配独立的身份策略（OIDC SSO / PIN码 / 邮件OTP / 地理位置限制 / IP白名单）
• P2P 智能 NAT 打洞： 当两端可直接连接时，流量不经过 Hub
• 子网路由： Site Connector 可以暴露整个内网网段（CIDR），不只是单个端口
• 客户端应用： macOS / Windows / Linux / iOS / Android 全平台
• 审计日志： 全流量记录 + 告警
• 双模式： 提供 SaaS 云服务（app.pangolin.net）和自托管版

优势

• 一站解决：WireGuard 隧道 + 反向代理 + 身份认证 + 证书管理，代替 Traefik+Authelia+WireGuard 三件套
• 用户体验最好——Web UI 完善，资源和用户管理直观
• 身份认证深度集成，适合团队/企业场景

劣势

• 体量远大于传统隧道工具——需要 PostgreSQL、Redis，不是单二进制
• 偏重 HTTP/HTTPS 应用，纯 TCP/UDP 穿透不如 FRP/chisel 灵活
• 社区版 AGPL-3.0，企业商用需购买许可
• 生态不如 FRP 成熟，第三方集成和文档相对较少

适合谁

Pangolin 的典型用户是：有多个内网服务（NAS、Home Assistant、Jellyfin、开发环境）需要安全暴露给特定团队/家人，最好有 Web 管理界面、OIDC 登录、细粒度权限控制。

3.3 Chisel（jpillora/chisel）— HTTP 隧道之王

Stars: 16.3k | 语言: Go | 协议: MIT

背景

Chisel 是 2015 年启动的元老级项目，和 FRP 同期。和 FRP 不同的是，它保持了非常克制的功能集——本质就是 TCP/UDP over HTTP。经过 11 年发展，代码库只有 252 次 commit、Go 代码 99.1%，非常精简。

最新 release v1.11.8（2026-07-10），v1.12 开发中（可靠性/安全增强）。

核心理念

Chisel 的核心洞察是：HTTP 是所有防火墙都放行的协议。企业防火墙、CDN、反向代理——它们都会放行 80/443 端口的 HTTP(S) 流量。Chisel 把隧道封装在 HTTP 的 WebSocket 升级请求中，天然兼容所有 Web 基础设施。

隧道本身用 SSH 协议加密（Go 标准库 crypto/ssh），不是简单的 HTTP。

关键能力

• 单二进制： chisel 同时是 server 和 client，无外部依赖
• 自动 HTTPS： --tls-domain 一键 Let's Encrypt
• SOCKS5 支持： server 端可做 SOCKS5 代理，client 端也可反向 SOCKS
• 反向隧道： R:2222:localhost:22 语法，从外网 SSH 到内网
• stdio 模式： ssh -o ProxyCommand='chisel client server stdio:%h:%p'——把 chisel 当 SSH 跳板
• 认证： 基于 authfile（JSON 用户配置），SSH Key fingerprint 验证
• CDN 兼容： 只要 CDN 支持 WebSocket（Cloudflare 等），chisel 能正常工作
• 接入认证： SSH ECDSA 密钥对 + --fingerprint 防止 MITM

典型用法

# 服务端（公网 VPS）
chisel server --port 443 --tls-domain tunnel.example.com --auth user:pass

# 客户端（内网）
chisel client --auth user:pass https://tunnel.example.com 3000
# 把内网 3000 暴露为服务器的 localhost:3000

# 反向 SSH
chisel client --auth user:pass https://tunnel.example.com R:2222:localhost:22
# 外网 ssh user@tunnel.example.com -p 2222 → 内网 SSH

优势

• HTTP 穿墙能力最强——企业防火墙通常是 HTTP(S) 白名单，WebSocket 通常放行
• 单二进制极度轻量（scratch 镜像 6MB）
• 配置语法最简洁，5 分钟上手
• 可以和 CDN/反向代理组合使用

劣势

• 没有 Dashboard / Web UI
• 没有自带负载均衡和健康检查
• 功能深度不如 FRP（没有 STCP/XTCP、没有多路服用级别的高级控制）

3.4 bore（ekzhang/bore）— 极简主义的 TCP 隧道

Stars: 11.3k | 语言: Rust | 协议: MIT

背景

bore 是极简主义的代表。它的 README 第一句就是："That's all it does: no more, and no less。" 没有认证、没有加密（自带的）、没有 HTTP 路由、没有 Dashboard——只做一件事：TCP 端口转发。

从搜索反馈来看 v0.6.0 发布于 2025-06，30 位贡献者，社区小而精。

核心用法

# 服务端（公网 VPS）
bore server

# 客户端（内网）
bore local 8000 --to your-vps.com
# 输出：bore is available at your-vps.com:12345
# 外部连接 your-vps.com:12345 → 内网 8000

只有这两个命令。

适合谁

当你手上有公网 VPS，只需要快速暴露一个端口（SSH、HTTP 开发服务器、临时 demo），不想写任何配置文件的时候——bore 是最快的选择。11k Stars 证明了这种"单一职责"的吸引力。

劣势

• 没有任何认证机制（你自己在 VPS 上用防火墙限制）
• 只支持 TCP，不支持 UDP
• 没有重连机制，断连后需手动重启
• 不适合生产环境或长期部署

3.5 zrok（openziti/zrok）— 零信任文件与网络共享

Stars: 4.6k | 语言: Go | 协议: Apache-2.0

背景

zrok 由 NetFoundry（背后的公司也维护 OpenZiti 项目）开发。它的定位不是"内网穿透"，而是安全共享——共享 Web 服务、文件目录、TCP/UDP 资源，目标用户是需要快速分享本地内容给指定的人，而不只是暴露端口。

zrok 构建在 OpenZiti 零信任网络层之上，默认端到端加密、P2P 直连。

独特能力

• 文件共享： zrok share public --backend-mode drive ~/Documents ——把本地文件夹暴露为网盘
• 私有共享： zrok share private localhost:3000 ——只对特定 zrok 用户可见
• SDK： 可以在自己应用中嵌入共享能力

适合谁

比 FRP 更强调"临时分享"场景——给同事看本地开发环境、分享文件给客户、临时暴露一个 TCP 服务。zrok.io 提供免费公共服务。

3.6 Piko（andydunstall/piko）— K8s 原生生产隧道

Stars: 2.1k | 语言: Go | 协议: MIT

背景

Piko 是面向 K8s 生产环境设计的隧道。2024 年 3 月启动，作者是前 AWS 工程师。

核心设计目标是：集群部署、水平扩展、零宕机升级。多个 Piko 节点组成集群，upstream 连接到任意节点后，集群内部自动同步 endpoint 路由信息。如果有节点宕机，upstream 自动重新连接到其他节点。

# Docker Compose 示例
piko-cluster:
  image: andydunstall/piko:v0.10.0
  ports:
    - "8000"  # proxy
    - "8001"  # upstream
    - "8002"  # admin/metrics

适合谁

如果你的上游服务跑在 K8s 里，需要可靠的生产隧道（比如 BYOC 场景、SaaS 连接到客户内网），Piko 的集群 HA 设计是这些工具里最成熟的。

3.7 connet（connet-dev/connet）— P2P 优先的 QUIC 隧道

Stars: 525 | 语言: Go | 协议: Apache-2.0 | 状态: Alpha

背景

connet 提供一个独特的 twist：两端都运行 connet client，server 只做配置交换（不转发数据），P2P 直连。当 NAT 打洞失败时回退到 relay。

基于 QUIC（UDP），性能好于 TCP 隧道，没有队头阻塞问题。v0.15.3（2026-05），活跃开发中。

适合谁

对隐私要求极高（数据不经过任何中继服务器）、带宽敏感的场景。但 alpha 阶段、Stars 偏少，不适合生产。

四、赛道划分

三个截然不同的赛道：

赛道 A：端口穿透（FRP / Chisel / bore）

解决的问题： "把我的内网端口映射到公网"

三者关系： bore 能做的时候它最快最轻。需要认证和 HTTP 路由时上 Chisel。需要负载均衡、健康检查、Dashboard、多协议全面能力时上 FRP。FRP 覆盖了另外两家的所有功能，代价是配置复杂度。

赛道 B：零信任接入平台（Pangolin / zrok）

解决的问题： "让特定用户安全地访问我的内网"

Pangolin 和 zrok 不是 FRP 的替代品——它们是面向授权用户的安全接入，而不是端口映射。

Pangolin 目前在这个赛道上表现最突出：21.8k Stars、最活跃的开发节奏、最完善的产品体验。它在解决的问题远比"端口穿透"复杂：身份认证、RBAC、审计、会话记录、浏览器内 VNC/RDP/SSH、子网路由。

赛道 C：生产级集群隧道（Piko）

解决的问题： "在 K8s 生产环境中可靠地建立隧道"

Piko 的集群节点设计在传统隧道工具中是独有的。没有节点的反向代理就不可用，Piko 把"单个节点挂了"从故障模式降级为正常运维事件。

五、选择决策树

你想解决什么问题？
│
├─ 只是快速暴露一个 TCP 端口给别人
│  └─ bore（最轻量）
│
├─ 需要暴露多个服务，但能接受简单配置
│  ├─ 主要走 HTTP(s) → Chisel（HTTP 穿墙最强）
│  └─ 也有 TCP/UDP → FRP（最全面）
│
├─ 需要身份认证 + 细粒度权限控制
│  ├─ 浏览器访问为主 → Pangolin（最佳体验）
│  ├─ 临时分享给他人 → zrok（共享场景）
│  └─ 纯命令行隧道 + SSH 加密 → Chisel（authfile）
│
├─ 运行在 K8s 上的生产服务
│  └─ Piko（集群 HA）
│
└─ 隐私优先，不想让流量经过中继服务器
    └─ connet（P2P 直连）

六、密码朋克视角审视

密码朋克的角度看隧道工具，评判标准不是功能多少或性能高低，而是：谁控制协议，谁拥有数据，哪个节点可以作恶，哪个环节需要信任。

6.1 信任模型频谱

完全依赖第三方                    完全自控
  │────────────────────────────────│
  ngrok        FRP      Chisel    Pangolin    bore
  (闭源SaaS  (自托管,  (自托管,   (自托管,    (无认证,
   必须信任   信任自己的 信任自己   信任自己    防火墙自控
   第三方)    VPS)     的VPS)    的VPS+PG)   无加密)

越靠右，你拥有的控制权越大。但控制权是有代价的——运维责任全在你身上。

6.2 密码朋克七大原则 × 各工具表现

6.3 密码朋克视角的关键判断

FRP 的加密模型： v0.50.0 起默认启用 transport.tls——线上 frpc↔frps 之间 TLS 加密，frps 终止 TLS 后在内存中可见明文。对于信任自己 VPS 的用户，这不是问题。如果需要连 frps 也无法解密的端到端加密，可以用 [[proxies]] transport.useEncryption = true + transport.useCompression = true——此时 frpc 加密、frps 仅转发密文、对端 frpc 解密。这时 frps 只是一个密文管道，能看到的是"有人在传数据"但完全不知道内容（元数据仍然有：连接时间、流量大小、频率）。STCP 提供类似的能力，用预共享密钥控制访问，密钥需带外传递。XTCP（P2P 打洞）数据平面完全绕过 frps，密码朋克上最干净——但成功率受 NAT 类型限制。

如果在 FRP 之外另有加密层（如 VPN 或 WireGuard）： frps 看到的是已被外层加密的流量，FRP 的 TLS 是第二层加密。这不会改变 frps 终止 FRP TLS 后可见明文的事实，但中间链路的多层加密对防流量分析有好处。

Pangolin 的矛盾：它基于 WireGuard，加密是内核级的，但 Hub 仍然终止 TLS。 这意味着 Hub 运营者（即使是你自己的 VPS）在内存中能看到解密后的请求。Pangolin 的零信任模型解决的是"用户到资源的授权"，不是"数据对中继节点的保密"。你信任自己的 VPS，这个模型就成立；你如果连自己的 VPS 都不信任，那需要的是 connet 的 P2P 方案。

Chisel 的 SSH 加密被低估了。 Chisel 是这些工具里唯一在隧道层使用 SSH 公钥加密的（不是 TLS 终止再转发，而是真正的 crypto/ssh 会话加密）。--fingerprint 验证提供了 SSH 级别的 MITM 防护。它的痛点是 sshd（Go 实现）本身不成熟——Go 的 crypto/ssh 缺少很多 OpenSSH 的安全加固。

bore 在密码朋克意义上是最诚实的：它不做任何安全性承诺。 你的安全完全依赖 VPS 防火墙和网络隔离。这是 "don't pretend to be what you're not" 的设计哲学——但密码朋克会告诉你没有加密的隧道就是明文传输。

6.4 主权个人视角的推荐

你是怎样的用户？
│
├─ "我需要暴露的只是一个端口，不介意 VPS 上有明文"
│  └─ FRP / Chisel（功能选 FRP，简洁选 Chisel）
│
├─ "我的信任半径到我自己的 VPS 为止"
│  ├─ 多服务 + HTTP → Pangolin（平台体验）
│  ├─ 纯 TCP 穿透 → FRP（功能最全）
│  └─ 需要 SSH 级加密 → Chisel（fingerprint 验证）
│
├─ "我连自己的 VPS 都不完全信任"
│  ├─ 数据必须端到端加密 → connet（P2P + QUIC）
│  └─ 需要生产级稳定性 → FRP + STCP
│
└─ "我不需要自己管服务器"
    └─ 付费方案 → 见下文

6.5 密码朋克最大的盲区

所有自托管方案都假设你拥有并控制一台公网 VPS。VPS 运营商能看到你的流量到达其网卡的时间、大小、频率。 即使你用了 TLS，运营商也能做流量分析——知道你什么时候在访问哪个内网服务、峰值流量多大。这不是"看内容"的问题，是"元数据泄露"的问题。

真正密码朋克级别的方案应该：

1. 流量混淆（像 obfs4 一样让隧道流量看起来像随机噪声）
2. 洋葱路由（多跳中继，任何单点不知道通信双方）
3. 去中心化控制面（没有固定的 frps/Pangolin Hub）

目前这些工具里没有哪个做到了。这是一个空白。

七、付费产品对标

7.1 全景对比

7.2 付费产品深度分析

ngrok — 行业标准 SaaS

创始： 2011 年，Alan Shreve。模式： 纯 SaaS，无开源核心（开源了 ngrok-agent 但 server 端闭源）。

ngrok 的价值不在技术——隧道协议本身是标准技术。它的价值在边缘网络：全球分布的接入节点、自动 TLS 终止、请求重放、流量检查、Webhook 验证、OAuth/SAML/OIDC 门控。

2026 年的免费层：1GB/月、1 个活跃端点、随机子域名。付费从 \(8/月（Personal）到\)39/月（Enterprise）。

密码朋克视角： ngrok 是你完全无法审查选择、数据经过第三方网络、没有离线能力的反面教材。它适合开发调试，不适合任何需要主权的基础设施。

vs FRP/Pangolin： FRP 在功能上覆盖了 ngrok 的 80%（TCP/UDP/HTTP/HTTPS + Dashboard + 认证），但少了全球边缘网络和 ngrok 的企业极开发者体验。如果你有自己的 VPS，FRP 替代 ngrok 的核心穿透场景绰绰有余。

Tailscale — 零信任 VPN 体验之王

创始： 2019 年，Avery Pennarun（前 Google 员工，WireGuard 协议合作者）。模式： 免费增值 SaaS + 开源客户端。

Tailscale 的独特之处：它不是一个隧道工具，而是一个基于 WireGuard 的零配置 VPN。每台设备安装客户端后，自动组建一个安全网格网络。NAT 穿透使用 DERP（Detour Encrypted Routing Protocol）中继。

个人版免费：3 用户、100 设备。团队版 $6/用户/月。

密码朋克视角： Tailscale 的加密到端（真正的端到端 WireGuard），控制面托管在 Tailscale 的协调服务器上。你的设备私钥永远不离开设备，所以协调服务器不能解密流量——这是密码朋克级别正确的设计。但协调服务器是你的信任依赖：Tailscale 可以在不通知你的情况下切断你的网络。

vs Pangolin： Tailscale 解决的是"让所有设备在一个安全网格内互通"，Pangolin 解决的是"让浏览器安全访问特定内网服务"。两者可以组合使用，不是零和。

Cloudflare Tunnel — 最慷慨的免费方案

模式： SaaS + 开源客户端 cloudflared。定价： 免费层非常慷慨（10GB/月带宽），付费从 $10/月起。

Cloudflare Tunnel 的架构：内网运行 cloudflared，出站连接到 Cloudflare 边缘网络，通过 Cloudflare 的 DNS/代理层暴露服务。没有公网端口暴露。

密码朋克视角： 这是对你数据主权威胁最大的方案。你的所有流量经过 Cloudflare 的网络，Cloudflare 终止 TLS、可能检查内容、受美国法律管辖。免费的价值在于"你的数据就是产品"。

vs FRP： Cloudflare Tunnel 的用户体验更好（无需 VPS、自动 DNS/TLS），但你放弃了所有控制权。FRP 可以用更小的代价（一台 $5 VPS）获得完全的数据主权。

Twingate / OpenZiti — 企业零信任

Twingate 是面向企业的零信任远程接入，定价 $5/用户/月。OpenZiti（zrok 的底层）是开源替代。

它们的共同设计：不暴露 IP/端口、应用级授权、基于身份的访问。在企业场景，Twingate 的合规报告和 AD/LDAP 集成是自托管方案无法替代的。

7.3 付费 vs 自托管：总拥有成本

场景 A：个人开发者，暴露 3-5 个服务
  自托管：一台 $5/月 VPS + 30 分钟配置
          = $60/年
  ngrok：$8/月 = $96/年（Personal，1GB 限流）
  Tailscale：免费（3用户以内）
  
场景 B：小团队，10 个成员 + 20 个内网服务
  自托管：$10/月 VPS + 1 小时维护/月
          + 人工成本 ≈ $120/年 + 维护时间
  Pangolin Cloud：$15/用户/月 = $1,800/年
  Twingate：$5/用户/月 = $600/年
  Tailscale：$6/用户/月 = $720/年
  
场景 C：K8s 生产，SaaS 连接到客户内网
  Piko 自托管：$10/月 VPS + 0.5h 初始配置
  ngrok Enterprise：$39/月 + 按量计费

结论（经济层面）： 只要你有能力维护一台 VPS，自托管始终比 SaaS 便宜。这是密码朋克工具箱的经济学——不只是因为省钱，而是因为你的替代成本从"每个月付钱"变成了"我的数据我做主"。

7.4 产品对标矩阵

你的场景                 付费最优解             自托管最优解
─────────────────────────────────────────────────────────
开发调试（临时暴露端口）   ngrok（一键体验）        bore / Chisel
个人服务长期暴露           Tailscale（免费）        FRP / Chisel
团队远程办公               Twingate / Tailscale    Pangolin
SaaS 连接客户内网          Cloudflare Tunnel       Piko / FRP
多站点 VPN / 全网格        Tailscale               Headscale + WireGuard
零信任企业合规             Twingate                Pangolin Enterprise
最大隐私/最高安全          Tailscale（E2E）         connet（P2P） / FRP + STCP

7.5 终极判断

付费方案卖的不是技术——隧道协议本身趋同，开源方案的加密能力不输付费产品，甚至在某些维度更强（Chisel 的 SSH 层加密超过 ngrok 的标准 TLS）。

付费方案卖的是：

1. 运维外包 —— 不用管 VPS、证书、升级、监控
2. 全球边缘网络 —— ngrok/Cloudflare 的多节点低延迟接入
3. 企业合规 —— SOC2、审计报告、AD 集成
4. 开发者体验 —— 一条命令上线 vs 写 TOML 配置文件

密码朋克的角度，只有当"我的数据不能离开我的控制"这个约束比运维成本更贵时，才值得用自托管。 在你自己的 homelab 场景里，这已经是既成事实——你的整套栈（Trilium、Gitea、Nextcloud、Hermes）都掌握在手里，穿透层加一个 FRP 或 Pangolin 只是扩展这条边界。

八、最终总结

三条赛道的最终判断：

密码朋克的核心问题："如果我信任的 VPS 运营商明天翻脸，我的服务还能跑吗？"

FRP 的回答：换个 VPS，重新部署 frps，更新 DNS，10 分钟恢复。

Pangolin 的回答：同上，但需要先恢复 PostgreSQL。

ngrok 的回答：你不能——你的隧道 URL 属于 ngrok。

Tailscale 的回答：你的设备网格还在——Tailscale 控制面不可用时，已有连接不中断，但新设备不能加网。

真正的筹码不是加密强度，是迁移成本。 自托管方案在这点上有碾压性的优势——你的配置是文件，不是 SaaS 的数据库。