frp 穿透性能实测——家庭服务器 + VPS 架构瓶颈在哪
用真实数据拆解 frp TCP TLS 隧道的性能瓶颈。在 1C/961MB 的低端 VPS + Mac mini M4 的组合下，穿透后 QPS 衰减约 100 倍，但 400+ QPS 对轻量 Web 服务完全够用。瓶颈 100% 在网络 RTT，不在应用层。
frp 穿透性能实测——家庭服务器 + VPS 架构瓶颈在哪
前言
很多自建服务爱好者都有类似的架构：家里一台性能不错的机器跑应用，再买一台便宜 VPS 做内网穿透。这种方案成本低、灵活性高，但一个绕不开的问题是——穿透后性能到底剩多少？
网上关于 frp 的教程很多，但系统的性能实测数据却很少。大部分讨论停留在”能用就行”的层面。本文用真实数据，从多个维度拆解 frp TCP TLS 隧道在实际业务中的表现，找到真正的瓶颈所在。
测试环境
硬件配置
| 角色 | 配置 |
|---|---|
| DMIT VPS（中转） | 1C / 961MB / 20G SSD, 50Mbps 出口带宽, x86_64, Ubuntu 24.04 |
| Mac mini（家庭服务器） | Apple M4, 16GB+, macOS 26.3.1 |
VPS 配置很寒酸——1 核不到 1G 内存，20G 硬盘，出口带宽 50Mbps。这恰恰是很多人的真实选择：便宜够用就行。
软件栈
- frps v0.68.0（VPS 端）+ frpc v0.68.0（家庭服务器端），启用 TLS 加密
- Caddy 作为 VPS 端的反向代理，负责 HTTPS 终止和请求转发
- 应用层：Go (net/http) + PostgreSQL 17.9 + Redis 7.2.13，包含真实的数据库读写操作
- 同时部署了 Python 版本用于语言层面的对比
请求链路
用户 → DMIT HKG VPS (Caddy) → frp TCP TLS 隧道 → Mac mini M4 (应用+数据库) → 原路返回一次请求要经过 VPS 上的 Caddy 反代、frp 隧道加密/解密、跨地域网络传输，再由 Mac mini 处理后原路返回。链路不短。
压测工具
- wrk：部署在 DMIT VPS 上，模拟外部用户通过穿透链路访问
- hey：部署在 Mac mini 上，用于本地基准测试
测试一：Python vs Go 穿透对比
第一个问题是：穿透场景下，语言选型影响有多大？我在 DMIT 上用 wrk 分别压测 Python 版和 Go 版应用。
测试数据
| 场景 | 并发 | Python QPS | Python 延迟 | Go QPS | Go 延迟 |
|---|---|---|---|---|---|
| ping（纯 HTTP 响应） | 50 | 405 | 123ms (23% 失败) | 423 | 118ms (0% 失败) |
| Redis Write | 20 | 193 | 104ms | 229 | 87ms |
| PostgreSQL Write | 20 | 191 | 105ms | 242 | 83ms |
| Mixed（混合读写） | 10 | 101 | 99ms | 121 | 83ms |
分析
Go 确实更快，但优势被网络延迟大幅稀释。
在 ping 场景中，Go 的 QPS 只比 Python 高 4.4%（423 vs 405），延迟仅低了 5ms。而在纯计算场景下，Go 通常比 Python 快 10-50 倍——但穿透链路的 RTT 把这些优势全吃掉了。
不过有一个值得注意的细节：在高并发 ping（50 并发）时，Python 版出现了 23% 的请求失败，Go 版 0% 失败。 这说明 Go 在高并发下的稳定性更好，即使吞吐量差异不大，可靠性也是实打实的优势。
在数据库写入场景中，Go 的优势稍微明显一些（约 20% 的 QPS 提升），这是因为数据库操作本身有一定计算开销，Go 能更快处理完后进入等待网络响应的状态。
结论：穿透场景下选 Go 的主要收益不是速度，而是并发稳定性和资源效率。 语言层面的 10 倍、50 倍性能差距，在 100ms 级别的网络延迟面前几乎可以忽略。
测试二：三种来源对比——找到真正的瓶颈
这是最关键的一组测试。我用 Go 版应用，从三个不同位置发起请求：
- Mac mini 本地（hey，无网络开销）
- DMIT 穿透（wrk，完整链路）
- Mac mini → DMIT → Mac mini（hey 在 Mac mini 上，但请求发给 DMIT 再绕回来）
测试数据
| 场景 | Mac mini 本地 | DMIT 穿透 | Mac mini→DMIT→Mac mini |
|---|---|---|---|
| ping | 41,016 QPS (1.2ms) | 423 (118ms) | 69 (14ms) |
| Redis Write | 34,745 QPS (1.4ms) | 229 (87ms) | 135 (7ms) |
| PostgreSQL Write | 15,942 QPS (3.1ms) | 242 (83ms) | — |
| Mixed | 1,510 QPS (13.2ms) | 121 (83ms) | 132 (8ms) |
逐项拆解
1. ping 场景：97 倍的 QPS 衰减
本地 ping 能跑 4.1 万 QPS，延迟仅 1.2ms。穿透后掉到 423 QPS，衰减了约 97 倍。延迟从 1.2ms 飙升到 118ms。
这不是应用的问题——Mac mini M4 处理一个 HTTP 请求只需要微秒级。这完全是网络链路的锅：frp 隧道的 TCP RTT + TLS 加解密 + Caddy 反代开销叠加在一起，吃掉了所有性能余量。
2. 带数据库操作时，衰减反而更小
Redis Write 场景下，本地 34,745 QPS → 穿透 229 QPS，衰减约 152 倍。看起来衰减更大了？但换个角度看：本地延迟从 1.2ms 涨到 1.4ms（Redis 写入开销），而穿透延迟从 118ms 降到了 87ms。
原因很简单：数据库操作本身需要时间，这部分时间不随网络变化。 穿透链路的固定 RTT 大约是 80ms 左右，Redis 写入本地耗时约 0.2ms，穿透时总延迟约 80ms + 0.2ms × 2（往返）≈ 87ms。这意味着网络 RTT 才是决定性因素。
3. 混合场景最接近真实业务
Mixed 场景包含读、写、计算等多种操作，本地 1,510 QPS，穿透 121 QPS，衰减约 12.5 倍。QPS 衰减比纯 ping 小得多，因为真实业务本身就有计算和 IO 开销，网络延迟的”稀释效应”更明显。
4. 一个反直觉的发现
Mac mini → DMIT → Mac mini 比 DMIT → Mac mini 还快。
看 ping 场景：DMIT 直接穿透到 Mac mini 是 423 QPS，而 Mac mini 发请求到 DMIT 再绕回来只有 69 QPS。
等等，69 比 423 小？这看起来更慢啊。但注意——Mac mini→DMIT→Mac mini 这个路径走的是 hey 在 Mac mini 上发起，经过 DMIT 再回到 Mac mini，整条链路更短（少了一层 Caddy 反代），但 hey 和 wrk 的压测模型不同，直接对比绝对值不太公平。
真正有价值的对比是延迟：Mac mini→DMIT→Mac mini 的 ping 延迟只有 14ms，而 DMIT 穿透是 118ms。少了 Caddy 反代确实省了不少开销。这说明 反向代理层也是有成本的，简化链路能带来可测量的改善。
瓶颈到底在哪？
通过以上数据，可以明确排几个结论：
带宽不是瓶颈 ✗
DMIT 的出口带宽是 50Mbps。按 423 QPS、平均响应体约 1KB 估算，实际带宽消耗约 3.4Mbps，远低于带宽上限。即使在更高并发下，带宽也不会先于延迟成为瓶颈。
CPU 不是瓶颈 ✗
frp 的 TLS 加解密确实消耗 CPU，但 VPS 上 frps 的 CPU 占用率在整个测试过程中始终低于 20%。Mac mini M4 更是不存在 CPU 瓶颈。
瓶颈 100% 在网络 RTT ✓
frp 隧道的 TCP 连接建立、数据在 VPS 和家庭服务器之间的往返传输，构成了约 80-120ms 的固定延迟。这个延迟决定了单并发下的最大 QPS 约为 8-12 QPS（1000ms / 100ms）。在高并发下，由于 TCP 连接复用和 frp 的多路复用机制，实际能达到 400+ QPS，但天花板已经被 RTT 锁死了。
应用层优化空间极小
既然瓶颈在链路延迟，那么在应用层面做优化（换更快的语言、优化数据库查询、加缓存）能带来的提升非常有限。本地 4.1 万 QPS 已经说明应用本身没有问题。你不可能通过优化一个 1.2ms 的请求，去弥补 100ms 的网络延迟。
这个架构能承载多大的业务？
直接上数据：
| 业务类型 | 典型 QPS 需求 | 穿透后可用 QPS | 是否够用 |
|---|---|---|---|
| 个人博客 | < 10 | 423 | ✅ 绰绰有余 |
| 社区/论坛（小型） | 10-50 | 400+ | ✅ 完全够用 |
| API 服务（内部使用） | 10-100 | 200-400 | ✅ 基本够用 |
| 电商/高并发 Web | 500+ | 400+ | ⚠️ 临界或不够 |
对于绝大多数个人和中小团队的 Web 服务，400+ QPS 完全够用。 一个日活 1 万的网站，峰值 QPS 通常不超过 100。frp 穿透后的性能不会成为瓶颈。
真正需要担心的是延迟而非吞吐量。118ms 的延迟对 API 调用来说可以接受，但对实时性要求高的场景（WebSocket 长连接、游戏服务器）则需要额外评估。
优化建议
虽然应用层优化空间有限，但网络层面有几个方向值得尝试：
- 选择 RTT 更低的 VPS：本文使用的是香港 DMIT，RTT 约 80-120ms。如果家庭宽带到 VPS 的物理距离更近，RTT 会显著降低。同城的 VPS 能把 RTT 压缩到 10-30ms，QPS 可以提升 3-5 倍。
- 启用 frp 的多路复用（mux）：frp v0.68.0 默认支持连接多路复用，可以减少 TCP 连接建立的开销。
- 减少反向代理层数：从数据看，少一层 Caddy 反代能降低约 10-20ms 延迟。如果不需要 HTTPS 终止等特性，可以直接用 frp 的端口映射。
- 考虑 UDP/QUIC 方案：TCP 的拥塞控制在高延迟链路上效率较低。如果应用支持，可以探索基于 QUIC 的穿透方案（如 frp 的 QUIC 模式），理论上能进一步降低延迟。
总结
| 结论 | 数据支撑 |
|---|---|
| 瓶颈在 frp 链路 RTT | ping 延迟从 1.2ms → 118ms，QPS 衰减 97 倍 |
| 带宽不是瓶颈 | 实际消耗 3.4Mbps，远低于 50Mbps 上限 |
| 语言优势被网络稀释 | Go 比 Python 在穿透场景只快约 20% |
| 轻量业务完全够用 | 穿透后 400+ QPS，覆盖个人博客到小型社区 |
| 优化方向在网络层 | 选低 RTT VPS、减少代理层数、尝试 QUIC |
一句话总结：家庭服务器 + VPS 穿透架构的瓶颈不在算力、不在带宽、不在代码，而在那条跨地域的网络链路。对于轻量 Web 服务，接受这个现实就好——400 QPS 已经比大多数人的业务需求高了。
测试环境：frp v0.68.0, DMIT HKG VPS (1C/961MB), Mac mini M4, 2026 年 4 月