如何优雅地解决 frp 内网穿透速度瓶颈？

在使用 frp 进行内网穿透时，很多小伙伴都会遇到一个让人头秃的问题：速度总是上不去，甚至莫名其妙地被限速。明明家里宽带上行有几十兆，穿透出来连个网页都卡半天，这事儿确实搞心态。

frp 内网穿透架构示意图

frp 内网穿透基本架构示意图

今天咱们就来盘一盘 frp 限速的几个常见原因，顺便聊聊怎么排查和优化，希望能帮大家解开这个“枷锁”。

网络带宽瓶颈示意图

带宽限制如同狭窄的管道

首先别急着改配置，先看看你的“基础设施”。

服务器带宽：这是最直观的瓶颈。千万别信那种“1M 带宽能跑几百兆”的鬼话，物理定律是绕不过去的。1Mbps 理论下载速度也就 128KB/s，你哪怕本地是光纤，出口就这一根细管子，神仙也没辙。如果是为了跑大流量，建议至少 5Mbps 起步，或者按量付费的高性价比 VPS。
中间节点质量：很多朋友的架构是“客户端 -> 中转 VPS -> 用户”。中转 VPS 到你的客户端之间的线路质量至关重要。如果这部分线路丢包率高、延迟高，TCP 协议下速度会大打折扣。建议多测试几个不同地区的 VPS，找一条延迟最低、最稳定的线路。

排除了硬件和线路问题，就得在配置文件里找原因了。

bandwidth_limit 参数：这是 frp 自带的限速功能。检查你的 frps.ini 或 frps.toml（视版本而定），看看全局有没有设置 bandwidth_limit。同样，客户端 frpc 的配置中，每一个代理也可以单独设置带宽限制。有些一键脚本为了防止超售被跑死，默认会给个很低的阈值，记得把这个参数注释掉或者调大。
TCP 多路复用：如果你用的是 HTTP、HTTPS 类型的代理，确保服务端和客户端都开启了 tcp_mux（默认通常是开启的）。这个功能能让多个连接在同一条 TCP 连接上传输，减少握手开销，对提升并发时的响应速度很有帮助。
连接数限制：有时候不是带宽堵了，而是连接数满了。检查 max_pool_count 等参数，确保它足够应对你的流量需求。

frp 默认使用 TCP 协议，这虽然稳定，但在高丢包环境下效率极低。如果你穿越的是不稳定的网络环境（比如移动数据网络），强烈建议尝试 KCP 协议。

在 frpc 的配置中，将 protocol 改为 kcp。KCP 协议是为了降低延迟设计的，虽然稍微增加一点 CPU 消耗和冗余流量，但在弱网环境下带来的速度提升是质的飞跃。

对于最新版的 frp，也可以关注 QUIC 协议的支持（基于 UDP），这在现代网络环境下表现通常比 TCP 更好。

还有一种情况，配置没问题，带宽也没满，但就是慢。这时候要考虑：

运营商 QoS：部分运营商会对长时间占满带宽的连接进行 QOS 限速，特别是 UDP 流量。如果是这种情况，尝试加密你的流量（比如 frp 底层走 TLS 或 WSS），伪装成正常的 HTTPS 流量，有时能绕过检测。
磁盘 I/O：如果你是用 frp 穿透文件服务（如 WebDAV、SMB），那还要穿透服务器的读写速度。廉价 VPS 的磁盘 I/O 通常是贫血的，这会成为新的瓶颈。

如果以上方法都试了还是觉得 frp 不给力，不妨看看其他选择：

nps：相比 frp 更强大，功能更多，支持更多高级玩法。
Zerotier / Tailscale：这是基于 SD-WAN 的组网工具，本质上不是端口转发，而是虚拟局域网。如果两端都能安装客户端，这俩工具在 P2P 直连成功的情况下，速度能达到两端物理带宽的上限，体验极佳。

frp 限速大多不是工具本身的问题，而是带宽、线路或配置细节的锅。遇到慢的时候，层层排查：先测速，后看配置，最后尝试换协议。希望这篇分享能让大家家里的 NAS、Web 服务跑得更欢快！