FRP内网穿透实战：原理、部署配置与安全调优全攻略

1. 内网穿透到底解决什么问题？为什么我最终选了FRP

1.1 没有公网IP时，你有多难受

先说说我自己的经历。早几年我在家里搭了一台NAS，存电影、备份照片、跑几个小服务，用得挺爽。爽了大概一周，问题就来了：人在外面，想看一眼NAS里的文件，或者远程登录一下家里的电脑，发现根本连不上。原因很简单，家用宽带的IPv4地址是运营商分配的私网地址，路由器拨号拿到的是一个100.64.x.x或者192.168.x.x的内部地址，公网上的设备根本没法主动找到你。这就引出一个老生常谈的词——内网穿透。

那时候我试过不少土办法：路由器开DMZ、端口映射、动态域名解析，但都绕不开一个核心问题：运营商不给你公网IPv4，你映射到天上去也没用。就算你有动态公网IP，又面临另一个坑：很多家庭宽带的80、443等常用端口被封，做网站、跑HTTPS会非常难受。后来接触到FRP，才发现这才是真正值得花时间研究的工具——它能把你家里内网的服务，通过一台有公网IP的服务器中转出去，让外网访问你内网的服务，就像访问公网服务一样简单。

这篇文章我不打算念官方文档，而是从实际踩坑的角度，把FRP的原理、部署、配置、排错完整过一遍。适合谁看？家里有NAS想远程访问的、想把自己电脑上的开发环境暴露给同事测试的、或者单纯想搞明白内网穿透原理的，都可以参考。我默认你有一台云服务器，以及至少一台内网设备，至于具体怎么注册云服务器，这里不展开。

1.2 主流通透方案横向对比：ngrok、cpolar、FRP、花生壳

市面上的内网穿透工具不少，我先列几个大家经常搜到的：ngrok、cpolar、花生壳、FRP。搜索热词里能看到“ngrok内网穿透教程”“cpolar内网穿透”“frp内网穿透”扎堆出现，说明大家的需求是真实的，但选择也确实是眼花缭乱。

ngrok是很多人的入门选择，它最大的优点是有云端服务，注册完就能拿到一个临时域名，本地敲一行命令就能把localhost暴露出去。缺点是免费版域名随机、速度有限、连接数受限，而且在国内的可用性不稳定。cpolar算是ngrok的国产替代，界面友好，带Web管理面板，也提供免费隧道，适合不想折腾的人。花生壳是老牌了，很多人用过它配合路由器或NAS，但它有设备数量限制和流量限制，免费版基本只能算试用。

FRP则是自建方案里的顶流：完全开源、跨平台、支持TCP、UDP、HTTP、HTTPS等多种协议，还能做负载均衡、权限验证。它不提供托管服务，需要你自己有一台公网服务器。从控制力和灵活度来讲，FRP是这几个里面最强的，但代价是你要花半小时到一小时去部署配置。下面这张表是几个方案的直观对比：

1.3 为什么FRP是更适合自建的选择

选FRP不只是因为免费，更重要的是它把“穿透”这件事彻底还给了你自己。你可以完全控制服务器端口、客户端接入的token、日志级别、流量统计，甚至可以给不同客户端的配置做精确到端口级别的权限控制。相比之下，托管服务能给你一个隧道就算不错了，想定制一下转发规则或者看看底层日志，基本没门。

FRP的项目托管在GitHub上，目前最常用的版本是v0.5x系列（比如v0.52.3、v0.53.2等，后续版本也在持续更新）。发布包里直接给了编译好的二进制，覆盖Linux、Windows、macOS、FreeBSD，甚至还有树莓派arm架构版本。下载解压之后，服务端运行frps，客户端运行frpc，配合一个ini/toml格式的配置文件就能工作，依赖极少。这一点在实际部署中很关键，很多生产服务器是精简环境，缺库缺依赖是常事，FRP这种“一个二进制跑起来”的设计省了太多心。

另外，FRP的协议层足够稳定，我在内网环境跑过几百条长期连接，没有出现过内存泄漏导致的崩溃问题。官方文档里也明确说支持多路复用（multiplexing），意味着在一条底层TCP连接上可以同时承载多个代理通道，减少连接数、提高性能。这些特性综合起来，让FRP成为个人自建和中小团队使用内网穿透的首选。

2. FRP工作原理解析：从一条连接说起

2.1 FRP的两端：服务端与客户端

FRP有两个角色：frps跑在有公网IP的服务器上，frpc跑在内网需要暴露的机器上。frps负责监听公网端口并等待外部用户连接，同时维护与frpc之间的控制连接；frpc则主动向frps发起连接，把自己本地的服务端口注册上去。

这里最容易混淆的一点是：到底是谁连谁？很多人以为公网用户请求进来之后，frps直接转发给内网设备。这个理解方向对了，但细节上不是frps主动连内网，而是内网的frpc提前主动连上了frps，并且保持这条控制连接不断开。真正有外部请求时，frps会基于这条控制连接协商出一条数据连接，或者直接复用多路复用通道，把流量转发过去。

这样设计的好处很明显：内网设备不需要公网IP，也不需要路由器端口映射，只要它能出网访问到frps的服务器端口就行。很多公司内网只允许TCP出站，FRP依然能工作。理解了“客户端主动单向出站”这个核心思路，后面的配置就顺理成章了。

2.2 一条完整的访问链路是怎么走通的

我拿一个最常见的场景——通过公网域名访问家里的NAS管理界面——来说明链路。假设你有一台云服务器IP是1.2.3.4，frps监听在7000端口用于接收frpc连接，另外监听在7500端口作为HTTP穿透入口。你家NAS的IP是192.168.1.100，HTTP服务跑在5000端口。

第一步，NAS上的frpc配置里声明了一个名为“nas-web”的代理，类型是tcp或http，本地地址是192.168.1.100:5000，远程端口是7500。然后frpc主动连接1.2.3.4的7000端口，完成身份验证，把“nas-web”这个代理信息注册到frps上。

第二步，外部用户打开浏览器，输入http://1.2.3.4:7500。这个请求最先到frps，frps查一下自己的代理注册表，发现远程端口7500对应的是“nas-web”这个代理，于是把请求数据通过之前建立的控制连接或数据连接转发给NAS上的frpc。

第三步，frpc收到数据后，解析出目标地址192.168.1.100:5000，然后把数据原封不动地发给NAS的HTTP服务。NAS响应后，数据再沿着原路返回。整个过程对用户来说是无感的，他以为自己访问的是一个普通公网服务。

2.3 关键配置项背后的逻辑

FRP的配置项非常多，但真正核心的其实没几个。先说服务端frps.toml里的bindPort，这是frpc连上来用的端口，默认7000，我建议改成不常见的端口以降低被扫描的概率。然后是auth.token，这是服务端和客户端之间的共享密码，必须设置，否则任何知道服务器地址的人都能接入你的内网，风险极大。

再说客户端frpc.toml里的serverAddr和serverPort，指向frps的IP和bindPort；auth.token要与服务端保持一致；然后是每个proxy的配置，比如proxyName（代理名称，同一客户端必须唯一）、type（协议类型）、localIP和localPort（内网服务地址）、remotePort（frps上暴露的公网端口）。

有个细节值得注意：如果你在frps上设置了bindPort=7000，又设置了vhostHTTPPort=7500，那么HTTP类型的代理会统一走7500端口，并通过Host头来区分不同的代理；而TCP类型的代理则占用各自的remotePort。这意味着你可以在一个frps上同时跑多个HTTP穿透，只需要一个端口就够了，这也是FRP比较优雅的设计之一。

3. FRP实战部署：从零到能用的完整过程

3.1 环境准备与版本选择

在动手之前，先把环境准备好。你需要三样东西：一台有公网IP的云服务器（Linux，Ubuntu/Debian/CentOS都行，我以Ubuntu 22.04为例）、一台内网设备（我用一台跑Linux的小主机和一台Windows电脑分别做过测试）、以及一个能上GitHub的终端。

版本选择上，建议优先从GitHub releases页面下载最新的稳定版，不要用某些第三方打包的所谓“绿色版”。因为FRP的配置格式在0.52.0之后从ini切换到了toml，早期版本和新版本配置不兼容。如果你看到网上教程里写的是frps.ini，而你现在下载的版本生成的是frps.toml，别慌，这是正常的，以官方文档为准。这里也顺便提醒一下搜索热词里出现的“frp apk oem unlock file manager”和“怎么清除frp分区”与咱们说的FRP不是同一个东西，别被带偏，那个是安卓手机刷机相关的话题。

下载的时候先去GitHub release页面，找到类似“frp_x.x.x_linux_amd64.tar.gz”的文件。如果你的云服务器是arm架构，比如某些轻量服务器，就下载“linux_arm64”版本。Windows客户端则下载“windows_amd64.zip”。

解压后你会看到一堆文件，包括frps、frpc两个二进制，以及对应的.toml配置文件。我习惯的做法是创建一个单独的目录来管理，比如/opt/frp，把二进制和配置都放进去。

3.2 服务端部署：拿到一台云服务器之后该做什么

我的部署顺序是：先建目录，再放文件，然后改配置，最后用systemd托管。具体命令如下：

mkdir -p /opt/frp cd /opt/frp # 假设已经把frp_0.53.2_linux_amd64.tar.gz上传到了当前目录 tar -zxvf frp_0.53.2_linux_amd64.tar.gz cd frp_0.53.2_linux_amd64 cp frps /opt/frp/ cp frps.toml /opt/frp/ cd /opt/frp

然后编辑frps.toml。这是我自己用的一个基础配置：

bindPort = 7000 auth.method = "token" auth.token = "zhangsan2024!secure" # HTTP穿透统一入口 vhostHTTPPort = 7500 # Web管理面板 webServer.addr = "127.0.0.1" webServer.port = 7501 webServer.user = "admin" webServer.password = "admin@2024"

这里说明一下为什么webServer.addr要绑定127.0.0.1。FRP自带的Web管理面板可以查看代理状态、流量统计，但它本身没有太强的安全防护，如果直接暴露在公网，等于把控制台交了出去。我通常用云服务器的安全组再加一层限制，只允许我从家里的固定IP访问7501端口，所以监听在127.0.0.1配合SSH隧道是更稳妥的做法。如果你图省事想直接访问，至少要改掉默认用户名密码。

改完配置后先手动跑一下验证：

./frps -c frps.toml

看到类似“start frps success”的日志，并且没有报错，就说明服务端起来了。这时候不要急着做别的，先按Ctrl+C停掉，我们把它注册成systemd服务，让它开机自启。

3.3 systemd守护与开机自启

生产环境不可能一直开着一个终端窗口跑frps，所以systemd管理是必须的。我在/etc/systemd/system/下创建一个frps.service文件：

[Unit] Description=FRP Server After=network.target [Service] Type=simple ExecStart=/opt/frp/frps -c /opt/frp/frps.toml Restart=on-failure RestartSec=5s LimitNOFILE=1048576 [Install] WantedBy=multi-user.target

这里重点说下LimitNOFILE。frps作为连接中转站，每一条TCP连接都要占用一个文件描述符。系统的默认ulimit通常是1024，根本不够用，连接一多就报“too many open files”。把它设成1048576是一个比较稳的做法，尤其是你后面要跑大量连接的时候。

配置文件写好后执行：

systemctl daemon-reload systemctl enable frps systemctl start frps systemctl status frps

看到status显示active (running)，服务端这边就算部署完了。注意在云控制台的安全组里放行7000和7500端口，否则外部根本访问不到。

3.4 客户端部署：Windows与Linux两套姿势

客户端的部署逻辑大致相同，就是下载对应平台的frpc，然后配置。先看Linux客户端的做法。假设你内网有一台跑着服务的Linux机器，同样把frpc复制到/opt/frp目录，创建一个frpc.toml：

serverAddr = "1.2.3.4" serverPort = 7000 auth.method = "token" auth.token = "zhangsan2024!secure" [[proxies]] name = "nas-web" type = "tcp" localIP = "192.168.1.100" localPort = 5000 remotePort = 7500

这里把remotePort设置成7500，而不是另外开一个端口。当然也可以开一个不冲突的比如8000，这里取决于你想用什么端口访问。如果复用vhostHTTPPort，建议type直接设成http，这样frps会根据Host头做不同代理的转发。但如果你的NAS管理界面没有绑定域名，直接用IP访问，那么用tcp类型更稳，例如remotePort = 7500，访问时直接http://1.2.3.4:7500。

Windows客户端更简单：下载windows_amd64的zip包，解压到D:\frp，同目录创建一个frpc.toml，内容跟Linux的一样。Windows下没有systemd，我们可以用一个bat脚本或者注册为计划任务，最简单的做法是写一个start.bat并加入开机启动文件夹。bat内容就一行：

D:\frp\frpc.exe -c D:\frp\frpc.toml

把start.bat的快捷方式放到shell:startup目录下，登录系统就会自动启动。如果不想看到黑窗口，可以用PyInstaller或者winsw把frpc封装成Windows服务，这个进阶操作以后有空单独写。

3.5 一个更进阶的配置：STCP模式保护你的服务

很多时候我不想让穿透出的服务被所有人扫到，比如说SSH。用普通的tcp代理把22端口暴露到公网，等于把SSH攻击面暴露给了全世界，密码爆破的日志一天能有几百条。这时候STCP模式就很有用。

STCP模式等于在frps的引导下，让两个frpc之间建立点对点加密连接。假设我有两台内网机器，一台是跳板机A，一台是目标机B，我希望A能通过FRP访问B的SSH，但公网其他设备完全摸不到这个服务。配置思路是：在B上定义一个stcp代理，名字叫ssh-secret，secretKey设一个只有A知道的字符串；在A上定义一个visitor代理，名字叫ssh-visitor，类型是stcp，serverName指向ssh-secret，bindAddr和bindPort是A本地监听的口。

这样做之后，A只能访问“bindAddr:bindPort”这个本地地址，通过FRP连回B的SSH，B的SSH端口实际上并没有暴露在frps上，安全性高很多。

3.6 多服务与权限控制

如果你有多台设备、多个服务需要穿透，最直接的方法是在同一个frpc.toml里加多个[[proxies]]段。这样frpc启动一次就同时注册多个代理，frps上也只看到一条控制连接。我也见过有人为每个服务单独跑一个frpc进程，这样未必更好，既浪费资源又难管理。除非你有不同的认证token需求，或者要按服务隔离故障，才建议拆开。

权限控制上，FRP支持在frps服务端设置allowPorts，限制客户端可以使用的远程端口范围。比如你只想让客户端使用7500到7600之间的端口，就在frps.toml里加：

allowPorts = [{ start = 7500, end = 7600 }]

这个配置在多人共用一台frps的时候非常有用。如果不加限制，任何一个接入的客户端都可以把remotePort设成任意端口，搞不好就冲突了，甚至有人会把你服务器的其他端口占掉。配合token使用，基本能把权限收得比较紧。

4. 常见问题排查与性能优化实录

4.1 连接失败、日志排查的常规套路

我遇到的最多的问题就是“frpc启动后提示连接服务器失败”。这种情况90%是网络层面的问题。先ping一下服务器IP，通了再telnet服务端端口，确认bindPort是否可达。如果ping不通，去看云安全组和系统防火墙；ping得通但端口不通，多半是安全组没放行对应端口，或者frps没监听。

还有一种隐蔽的坑：云服务器控制台里同时有“安全组”和“防火墙”两个概念，如果你改完了安全组但还是不通，检查一下系统自带的ufw或firewalld有没有把端口拒绝掉。常见命令：

ufw status iptables -L -n | grep 7000

如果是frpc日志里出现“login to server failed: EOF”，这通常表示frps根本没收到正确的协议数据，可能原因是版本不匹配（服务端新版、客户端老版），或者auth.token不一致。我建议两边都换成同一个最新版本，token里别带奇怪的字符，用大小写字母加数字最稳。

4.2 安全加固：这件事必须做

FRP部署完之后，第一件事不是庆祝，而是给它上锁。即使你只在家里用，公网扫描器也会在几小时内找到你的服务端口。我有一个很深的教训：第一次部署FRP时嫌麻烦没改token，用了默认的空token，结果第二天服务器CPU飙高，登录一看，有几百个来自不同IP的连接在尝试接入。后来我把token换成随机字符串，同时做了三件事：

第一，修改bindPort为非默认端口，比如27100，降低被扫描到的概率；第二，启用TLS模式，在frps和frpc之间加上TLS加密，避免流量中间人嗅探；第三，用云安全组限制来源IP，如果固定在某几个地方访问，只放行这几个IP。

TLS的配置不复杂，在frps.toml和frpc.toml里都加一行：

transport.tls.enable = true

两端都开启之后，frpc连frps时会自动协商TLS。注意，这里的TLS只是保护frps和frpc之间的链路，不代表你穿透出的HTTP服务本身有了TLS。如果想让访问者用HTTPS访问你的内网服务，那是另一套配置，需要HTTPS证书和vhostHTTPSPort。

4.3 传输速度瓶颈在哪里

很多人感觉用FRP穿透之后速度很慢，这是正常的。因为流量路程变成了：用户->云服务器->家里frpc->内网服务，数据经过了至少两个“跳跃”，损耗不可避免。但如果你觉得慢得离谱，基本是瓶颈在云服务器的带宽，而不是FRP本身。

举个例子，你的云服务器是1Mbps带宽，那无论内网是千兆还是万兆，穿透速度上限就是1Mbps，换算下来也就128KB/s左右。这种情况下，再优化FRP配置也没用，唯一的出路是升带宽，或者改用P2P方式减少中转。FRP的xtcp插件就是为P2P设计的，它通过frps做信令协商，建立两个内网节点之间的直连通道，数据不经过服务器中转。不过xtcp对网络环境要求较高，NAT严格的情况下经常打洞失败，我在自己家测试过，成功率大概六成，不算稳定，适合“能直连就直连，不能就中转”的混合策略。

另外，TCP层面的调优也有一些细节。frps服务端和frpc客户端都建议把transport.poolCount设置成大于1的数，比如5，它会创建多个连接池多路复用，对并发有一定提升。同时操作系统的TCP缓冲区设置也可能影响大文件传输，但作为一个日常穿透工具，我建议不要过度调优，保持默认，优先解决带宽瓶颈。

4.4 一套实用调优与监控方案

当你的frps上挂载了多个客户端之后，你会突然发现“诶，我连的是谁的代理？这个代理还活着吗？”这时候就体现出监控的重要性。FRP自带Web面板能看每个proxy的连接数和traffic，但信息比较粗。我更习惯用Prometheus那套方案，但如果你不想引入额外组件，完全可以用一个简单的脚本定时检查。

我目前的监控思路是这样的：先启用frps的dashboard，也就是webServer配置，然后用crontab每分钟去curl这个dashboard的API接口（比如/api/proxy/traffic），把当前活跃代理数和流量写入一个文本文件，如果某台设备的代理掉线了，脚本就调用短信接口通知我。这个方案看起来原始，但确实有效，帮助我最早发现家里光猫重启之后frpc没自动恢复的问题。

说到自动恢复，这里再补一个经验：frpc进程虽然崩溃的概率不大，但网络抖动会导致连接断开，而frpc有时候不会自动重连。所以客户端这边务必加上systemd的Restart=always，并且设置RestartSec=3，保证进程死了或者被kill后能在几秒内重新拉起。我在树莓派上跑frpc两年多，可以说这个配置救了我至少四五次。

最后再分享一个小技巧。如果你临时需要暴露一个服务又不想改配置文件重启frpc，可以用frpc的“admin”接口。在frpc.toml里配置webServer.addr和webServer.port后，通过HTTP API可以动态添加和移除代理，这样就不用每次改配置了。我有时候在同事电脑上临时演示某个东西，直接调用一次API把8080端口透传出去，用完再删掉，非常方便。这也是FRP作为一个成熟工具少被提及的实用点，真正用到的时候你会感谢它的。