上周出差住酒店深夜想看一眼家里NAS上的下载进度打开手机App发现连不上路由器后台、群晖管理页全都失联。这种情况遇到不止一次了家里宽带没有公网IPv4运营商给的地址本质上是NAT内网外部根本没法直接访问。后来我把家里的NAS管理界面、路由器后台、开发机SSH全部通过frp内网穿透统一暴露到自己域名下配合子域名方式访问出差时手机浏览器输个地址就能进去运行大半年稳定可靠。这篇就把我的完整部署过程写出来。frp是一个开源的内网穿透工具服务端frps部署在有公网IP的云主机上客户端frpc放在内网机器上由frpc主动连出到frps建立隧道外部请求通过frps转发到内网服务。整个过程不需要在路由器上做端口映射也不用申请公网IPv4非常适合家里有NAS或服务器想外网访问、开发环境需要临时对外展示、微信公众号/小程序调试本地接口这类场景。下面从选型开始讲重点覆盖服务端配置、客户端配置、子域名访问方式的完整链路最后是几百个小时跑下来踩过的坑。1. 为什么选frp而不是其他内网穿透方案1.1 主流的几种内网穿透方案对比在决定用frp之前我把市面上能想到的方案都过了一遍。这里说的“内网穿透”本质都是解决同一个问题让公网上的请求能够到达位于内网里的某个服务。常见的路径有这几类方案类型部署方式优劣势frp自托管隧道工具需一台公网服务器协议全、自可控、支持TCP/UDP/HTTP/HTTPS/stcp社区活跃ngrok开源SaaS自托管或官方云配置简洁SaaS有免费额度但域名受限自托管版本功能相对固定Tailscale / ZeroTier组网方案端上装客户端适合设备间互联、访问内网网段不适合对外提供Web服务需要访问方也加入组网花生壳 / 樱花内网穿透SaaS服务客户端一键式上手快但免费版限速、域名和并发受限个性化能力弱nps自托管隧道工具需一台公网服务器功能上和frp很接近也带Web面板但维护活跃度不如frp从我实际使用的体验来说Tailscale这类组网方案确实省心装上之后像在同一个局域网里访问NAS共享目录、远程桌面都很舒服。但它有一个局限它解决的是“设备互联”问题而不是“对外发布服务”问题。别人访问你内网里的网站不可能也装一个Tailscale客户端。如果你是想让外部用户或客户的浏览器能打开你内网里的服务还是得靠frp这种基于公网服务器的转发方案。1.2 frp的适用场景和选型理由frp的发布页和维护状态一直不错项目由Go语言编写交叉编译出来的单文件直接丢到目标机器就能跑不依赖运行环境。对我这种经常折腾的人最看重的是两个点。第一frpc一个进程可以同时维护多条隧道。比如我家里那台用旧笔记本改的服务器一个frpc进程里同时跑了SSH隧道、NAS管理页隧道、路由器后台隧道、还有一个临时给客户演示的项目隧道每条隧道互不干扰。如果用某个一键内网穿透工具大概率是一个服务一个进程管理起来非常散。第二frp对HTTP层有专门支持。服务端配置一个vhostHTTPPort客户端配置subdomain或customDomains就能实现基于域名的路由同一个公网端口上通过不同的子域名转发到内网不同的服务。这也是“子域名配置方式”最舒服的用法用一个泛解析域名加一个HTTP端口几十个内网服务都有了独立的公网入口不需要为每个服务单独开端口。这个能力在很多SaaS穿透工具里是要收费的。如果你本身有一台云主机比如学生机、轻量服务器哪怕配置很低把frps放上去毫无压力。frps本身内存占用才几十MB空闲的时候几MB都不到和一台机器上跑各种全家桶完全不同。2. 服务端部署frps关键配置逐项拆解2.1 下载与服务端目录规划先说服务端。frp的每个版本都会同时提供frps服务端和frpc客户端两个二进制下载release包之后解压目录里会有frps、frpc、frps.toml、frpc.toml几个文件还有对应的ini格式示例。这里有个容易踩坑的点值得提前说从v0.52.0开始frp官方把默认配置文件格式从INI换成了TOML新版release里给的是frps.toml和frpc.toml示例。网上大量教程和博客还是老版本的INI写法直接照抄可能会解析失败或者字段名对不上。不过frp对老格式还是兼容的如果你用的版本比较老或者习惯INI也依旧能用只是新版本新增的字段只会在TOML配置里生效。我的建议是直接用当前最新稳定版配置文件用TOML格式写。我的服务端目录规划是/usr/local/frp/ ├── frps # 服务端二进制 ├── frpc # 客户端二进制服务端机器上一般用不到 ├── frps.toml # 服务端配置 ├── frpc.toml # 客户端配置会拷贝到内网机器 └── logs/下载之后先把二进制拷到/usr/local/frp/加执行权限然后开始写配置。2.2 frps.toml核心参数说明下面这段是我线上实际在用的frps.toml我删掉了密钥等敏感信息你把它当作骨架参考bindAddr 0.0.0.0 bindPort 7000 auth.method token auth.token 你自己生成的一长串随机字符串 vhostHTTPPort 8080 vhostHTTPSPort 8443 subdomainHost frp.example.com webServer.addr 127.0.0.1 webServer.port 7500 webServer.user admin webServer.password 复杂密码 log.to console log.level info log.maxDays 3 allowPorts [ { start 6000, end 7000 } ]逐项解释一下bindAddr和bindPortfrps自己监听什么端口。7000是frpc连上来用的这个端口必须在公网防火墙、云安全组里放行。auth.token服务端和客户端之间的认证凭证。frpc连接frps时必须带上相同的token。生成方法很简单openssl rand -hex 16随便来一个。vhostHTTPPortHTTP虚拟主机端口。所有通过HTTP类型隧道暴露的内网服务最终都是从这个端口进来的。可以填80但通常我会先用8080跑通确定没问题再根据实际情况调整。subdomainHost子域名访问方式的关键指定一个域名作为基准后缀。客户端配了subdomain nas最终访问地址就是nas.frp.example.com。webServer新版frp把Dashboard配置统一放在webServer下面。可以查看在线隧道状态、流量、连接数。我习惯绑127.0.0.1只在本机访问管理面板不在公网暴露。allowPortsTCP隧道模式下remotePort只能使用这个范围内的端口。这是安全手段防止客户端随意占用服务器上的任意端口。2.3 用systemd守护服务端进程服务端不能只在前台跑要交给systemd管。写一个/etc/systemd/system/frps.service[Unit] Descriptionfrp server Afternetwork.target [Service] Typesimple ExecStart/usr/local/frp/frps -c /usr/local/frp/frps.toml Restartalways RestartSec5 LimitNOFILE1048576 [Install] WantedBymulti-user.target然后执行systemctl daemon-reload systemctl enable --now frps systemctl status frpsRestartalways这个参数很重要。frps这种常驻进程万一因为网络波动或服务器重启挂了systemd会自动把它拉起来。RestartSec5是挂了之后等5秒再拉起避免频繁重启把日志刷爆。LimitNOFILE顺手调大文件描述符上限frp隧道多的时候不容易报too many open files。2.4 防火墙、安全组与端口开放顺序这一步最容易忽略也最容易导致“配置全对但就是连不上”。在云服务器上Linux防火墙firewalld/ufw和云平台安全组是两层都要放行TCP7000frpc连接frps的通道必须放行TCP8080HTTP虚拟主机对外端口必须放行给公网TCP8443HTTPS虚拟主机对外端口用HTTPS隧道时才需要TCP7500Dashboard端口建议只放行本机不要公网开放如果是Ubuntu的ufw大概是这样的命令ufw allow 7000/tcp ufw allow 8080/tcp ufw allow from 127.0.0.1 to any port 7500 proto tcp ufw reload云平台安全组里面同样在入方向规则里加对应端口。有一个小经验安全组和ufw两头都放行之后用nc -vz 服务器IP 7000从本机测一下端口连通性能通再继续配客户端。3. 客户端配置从frpc到第一条隧道3.1 客户端下载与frpc.toml基础结构客户端放在内网那台机器上。下载同一版本的frp包版本最好和服务端保持一致我遇到过跨大版本连接时认证协议不兼容的情况把frpc和frpc.toml放到内网机器的一个固定目录里。一个最小化的frpc.toml长这样serverAddr 你的服务器公网IP serverPort 7000 auth.method token auth.token 和服务端一致的token log.to console log.level info先只写连接信息不配置任何隧道直接跑./frpc -c frpc.toml看能不能和服务端握手成功。这一步能快速定位是网络问题还是认证问题。3.2 隧道类型选择的依据frp里每条隧道叫一个proxy类型决定了这个隧道怎么工作。我在实际项目中用到的就四种类型适用场景特点tcpSSH、MySQL、Redis、远程桌面不可识别域名直接转发端口需要在服务端占用一个remotePortudp部分游戏、自定义UDP协议服务和tcp类似适合UDP流量httpWeb管理界面、网页服务、API接口基于域名路由多个服务共用一个端口服务端不需要额外开端口https需要加密传输的Web服务同样基于域名路由证书处理见后面章节stcp对安全要求高的服务不在frps上暴露任何端口由访问端也装frpc来访问新手容易犯的错是把所有服务都配成tcp。比如本地有个网站跑在8080端口如果用tcp隧道暴露到服务器的6000端口访问时要输IP加端口看起来能用但SSL证书、域名绑定全都做不了也不方便过CDN。HTTP/HTTPS类型的隧道才是Web服务的最佳选择。3.3 实例把SSH和一个本地Web服务暴露出去还是看实例最直观。假设我内网服务器上有两个服务一个是SSH服务22端口一个是跑在127.0.0.1:9000的Web管理界面比如路由器后台、NAS面板之类。frpc.toml这样写serverAddr 1.2.3.4 serverPort 7000 auth.method token auth.token 你的token [[proxies]] name ssh-tunnel type tcp localIP 127.0.0.1 localPort 22 remotePort 6000 [[proxies]] name web-dashboard type http localIP 127.0.0.1 localPort 9000 customDomains [dashboard.frp.example.com]SSH隧道这条公网访问方式就是ssh -p 6000 用户服务器IP它把服务器上的6000端口流量原样转发到内网机器的22端口。Web这条走的是HTTP虚拟主机服务器上8080端口收到带Host: dashboard.frp.example.com的请求时frps会根据Host头找到名字是web-dashboard的隧道把流量转给内网127.0.0.1:9000。这里customDomains可以直接写完整的子域名前提是这个子域名要解析到frps所在的服务器IP。3.4 客户端开机自启与断线重连内网机器通常是7x24小时开着的而且可能没接显示器所以frpc必须做成开机自启。Linux上用systemd写/etc/systemd/system/frpc.service[Unit] Descriptionfrp client Afternetwork.target [Service] Typesimple ExecStart/usr/local/frp/frpc -c /usr/local/frp/frpc.toml Restartalways RestartSec5 [Install] WantedBymulti-user.target注意Afternetwork.target对大部分场景够用但如果机器是DHCP拿IP偶尔会出现网络还没就绪frpc就启动、连接失败的情况。其实不用担心Restartalways会自动重拉等网络起来后第二次启动就连上了。macOS上也有不少人用frpc特别是M系列芯片的MacBook当家庭服务器用的情况。可以写一个launchdplist放到~/Library/LaunchAgents/下KeepAlive设为true效果和Linux下的systemd类似。具体plist写法网上很多核心就是ProgramArguments里指向frpc和配置文件路径。4. 子域名配置方式的完整链路4.1 subdomainHost和DNS泛解析的原理这是这篇的核心我把子域名方式的完整链路讲透。服务端配置了subdomainHost frp.example.com客户端配置中如果写了subdomain nasfrp会把两者拼成完整的访问域名nas.frp.example.com。当公网用户访问这个域名时请求先到达DNS解析到frps所在服务器IP再访问服务器的vhostHTTPPort这里就是8080frps根据请求中的Host头匹配到客户端名为对应name的隧道然后转发到内网指定的端口。用一句话概括就是DNS负责把域名指向frps服务器frps负责按域名把请求分发到不同内网服务。要在公网真正生效DNS侧最省事的做法是配置泛解析wildcard。在域名解析服务商控制台加一条记录类型: A 主机记录: *.frp 记录值: 服务器公网IP这样nas.frp.example.com、web.frp.example.com、jenkins.frp.example.com……所有以frp.example.com结尾的子域名都会解析到同一台服务器不需要每次加新服务都去加一条DNS记录。4.2 subdomain 与 customDomains 的差异客户端配置HTTP/HTTPS类型隧道时有两种指定域名的写法。我在最初配置时也迷糊过这里单独拎出来对比配置字段作用使用条件subdomain填写子域名前缀frps自动拼接成前缀.subdomainHost需要服务端配置了subdomainHost且DNS做了泛解析customDomains填写完整域名frps把这个域名和隧道绑定需要该域名手动解析到frps服务器适合不统一用subdomainHost后缀的场景两者可以同时存在。比如客户端既写subdomain nas又写customDomains [nas.other-domain.com]那么两个域名都能访问到同一个服务。我实际使用中会用到这个能力内部测试用一个统一的frp.example.com泛解析域名给特定客户演示时用客户自己的域名两条入口指向同一个内网服务切换无缝。如果配置了subdomain但不生效先检查frps配置里有没有subdomainHost。这个字段是服务端白名单不在这个后缀下的子域名即使客户端写了也会被frps拒绝日志里会看到类似“subdomain is not allowed”的报错。4.3 本地hosts测试方法改DNS泛解析之后不是立刻生效的尤其某些小运营商DNS缓存能拖很久。在跑通的第一天我建议直接用本地hosts文件绕过DNS验证配置是否正确。编辑本机hostsLinux/macOS是/etc/hostsWindows是C:\Windows\System32\drivers\etc\hosts1.2.3.4 nas.frp.example.com 1.2.3.4 dashboard.frp.example.com把1.2.3.4换成frps服务器IP。然后浏览器访问http://nas.frp.example.com:8080如果页面出来了说明frps路由、frpc隧道、内网服务全部正常问题只剩DNS生效时间。如果页面出不来也能确定问题不在DNS解析方便直接跳到frp配置排查。这里提个细节用http://测试时一定要带端口因为配置的vhostHTTPPort是8080。等以后通过Caddy或Nginx做80/443转发之后才可以省略端口。4.4 多服务多子域名的实战规划子域名最有价值的地方在于管理多个服务。我目前的frpc.toml里类似这样子域名内网地址用途nas.frp.example.com127.0.0.1:5000NAS管理界面router.frp.example.com192.168.1.1:80路由器后台jenkins.frp.example.com127.0.0.1:8080构建服务demo.frp.example.com127.0.0.1:3000临时客户演示所有type http的代理都共用一个公网端口8080。在frps的Dashboard里可以清楚看到每个域名对应几条连接、多少流量哪个子域名的隧道掉了一目了然。我建议从一开始就规范命名最好和服务名对应。我见过有人用test1、test2这种命名过一个月自己都想不起来哪个是哪个。代理的name字段在frps日志和Dashboard里都会显示命名清晰能少很多排查时间。5. HTTPS证书怎么配三种可行路径5.1 最简单Caddy反代frps并自动签发证书HTTP裸奔在公网上路由器密码、NAS登录凭证容易被抓包。给frp套HTTPS的路径里我测试下来最省事的是在frps服务器上再跑一个Caddy由Caddy监听80/443并自动申请证书然后把HTTPS请求反向代理到frps的vhostHTTPPort8080。Caddy配置极短nas.example.com, router.example.com, demo.example.com { reverse_proxy 127.0.0.1:8080 }Caddy启动后会自动为这三个域名向CA申请证书并续期完全不需要手动管理证书文件。用户访问https://nas.example.comCaddy解密HTTPS后把带原Host头的HTTP请求转发给frps的8080frps再根据Host头路由到内网对应服务。这也是为什么我说subdomainHost用独立域名更方便。如果所有子域名都在同一台Caddy上配置里列出域名列表即可如果子域名很多还可以用通配符证书方案让Caddy监听*.frp.example.com。5.2 frp内置的https2http插件如果不想额外装Caddy可以走frp自带的https2http插件。这个方案的核心思路是frpc对外表现为HTTPS隧道TLS握手碰巧由frpc本地的插件处理插件把HTTPS解密成HTTP后转发给内网本地服务。旧版INI配置大概是[web] type https customDomains [nas.frp.example.com] plugin https2http pluginLocalAddr 127.0.0.1:5000 pluginCrtPath /usr/local/frp/server.crt pluginKeyPath /usr/local/frp/server.key新版TOML写法不太一样plugin变成了[proxies.plugin]子表。这个方案需要自己解决证书问题和续期问题比较适合已经熟悉acme.sh、certbot这类工具的人。如果只是个人使用我还是推荐Caddy方案证书自动续期这一点能节省大量过期的烦恼。5.3 本地就是HTTPS服务的情况如果你的内网服务本身就是HTTPS比如自建的某些面板只监听443frp也有https2https插件。流程是外网访问frps的HTTPS虚拟主机端口frps把流量转发给frpc的插件插件再以HTTPS方式请求内网服务整个链路保持加密。这个方案适合对“末端加密”有硬性要求的内网服务但配置复杂度也更高前置条件是内网服务的证书需要被客户端信任。如果内网用的是自签名证书插件那边还需要额外配置跳过校验新手不建议上来就搞这个。5.4 证书选型建议一个容易被忽略的细节是证书必须覆盖实际访问的域名。如果通过https://nas.frp.example.com访问证书就得是nas.frp.example.com的否则浏览器会报证书错误。泛解析域名配合泛域名证书是最省心的但泛域名证书申请和续期对ACME协议要求高一些需要DNS API验证Caddy在这方面支持得很好。我目前个人环境是Caddy方案Caddy负责80/443、TLS证书申请与续期frps只监听7000和8080端口暴露面最小证书维护成本最低。如果你不想引入Caddy最简单能跑的方式就是先用http://访问等全部调通后再上HTTPS。6. 踩坑实录排查链路与典型问题6.1 第一次配置最容易遇到的三个“连不上”结合我自己和帮朋友解决的经历新手第一次配置frp最容易卡在三个地方。第一个是frpc连不上frps。frpc启动后一直报连接失败日志反复出现dial tcp 服务器IP:7000 connect: connection refused。原因八成不在frp本身而是服务器安全组或防火墙没放行7000端口。用nc -vz 服务器IP 7000从本机测一下通不通一下就知道了。注意很多云平台的安全组入方向规则默认只放行22和常见端口7000这种自定义端口必须手动添加。第二个是子域名打不开。frpc日志显示隧道已启动浏览器访问却超时或拒绝连接。先确认vhostHTTPPort对应的8080端口是否放行再确认DNS是否解析到frps服务器最后看frps日志里有没有请求进来。还有一个比较隐蔽的问题有些云厂商安全组默认限制了HTTP/HTTPS端口8080不在允许范围内需要在安全组里显式放行。第三个是访问到服务了但502/404。这种情况frps工作正常问题出在隧道配置上。最常见的原因是localIP写错了比如把127.0.0.1写成了局域网IP或者反过来还有一种情况是本地服务只监听了IPv6的::1而frp默认连接IPv4的127.0.0.1自然连不上。6.2 日志和常用排查命令frp的日志是排查问题的第一手资料。服务端启用log.to file并指定路径客户端也一样把日志落盘而不是只输出到控制台。开启文件日志之后出问题可以直接看最后几十行tail -n 100 /usr/local/frp/logs/frps.log journalctl -u frps -f如果客户端是systemd托管使用journalctl -u frpc -f可以实时跟踪客户端日志。排查HTTP隧道问题时最有用的是在frps机器上手动发一个带Host头的请求看frps是否成功匹配隧道curl -H Host: nas.frp.example.com http://127.0.0.1:8080/这个命令绕过了外部DNS和防火墙直接请求frps本地8080端口。如果这条命令能返回内网服务的内容链路已经通了一多半问题就只在DNS或公网防火墙如果返回502那就是frps路由或内网服务本身的问题。6.3 常见问题对照表我把实际遇到比较多的问题整理成一张表方便直接对照现象可能原因定位方法解决方法frpc启动失败提示connection refusedfrps未启动、防火墙未放行7000nc -vz 服务器IP 7000放行安全组/ufw确认frps运行frpc启动失败提示auth失败token不一致比对frps.toml和frpc.toml的auth.token两边改成完全一致的token子域名访问超时DNS未生效、vhostHTTPPort未放行本机dig域名查看解析结果等DNS生效或改hosts测试子域名访问返回404Host头没匹配到任何客户端隧道看frps日志中的访问记录确认客户端subdomain/customDomains配置正确访问服务502 Bad Gateway内网服务未启动、localPort错误、localIP不通curl本地内网地址确认修正localIP/localPort确保服务监听正常隧道正常但访问很慢跨地域网络延迟、frp框架转发开销ping/traceroute观察延迟选用就近的frps服务器或用P2P型隧道减少中转Dashboard打不开webServer只绑了127.0.0.1服务器本机curl 7500用SSH隧道访问不建议改0.0.0.0服务器重启后frp服务不在没设置开机自启systemctl is-enabled frpssystemctl enable --now frps7. 安全加固与其他经验7.1 token强度、allowPorts白名单与dashboard保护frp隧道本质上是把内网服务暴露到公网安全上不能马虎。我的底线是三条。第一auth.token必须用足够长的随机字符串。别用123456这类弱口令一旦泄露任何人都能往你内网里建立隧道。生成命令很简单openssl rand -hex 32或者用head -c 16 /dev/urandom | base64。第二用allowPorts限制TCP隧道可以占用的端口范围。frpc配置里如果没有特别需求remotePort就限制在一个小范围里严格限制了对服务器端口的占用。同时只为需要的端口类型开放安全组HTTP隧道只需要vhostHTTPPort一个端口暴露给公网就够了。第三Dashboard管理面板永远绑定127.0.0.1不要暴露到公网。想看面板时用SSH隧道访问ssh -L 7500:127.0.0.1:7500 用户服务器IP然后本地浏览器访问http://127.0.0.1:7500。这样面板完全不经过公网账号密码泄露的风险小了一大截。7.2 用stcp隐藏服务端口如果你对某个服务的暴露程度有更高要求frp还提供stcp类型。它和普通tcp隧道最大的区别是frps上不对外开放任何端口公网上的扫描器根本无法探测到这个服务的存在。访问端也需要装一个frpc通过frps的信令协调建立一条点对点或经过frps中转的加密通道。stcp典型的使用场景是远程桌面。公网不开放端口只有自己的访问端装了frpc、使用正确的secretKey才能连接安全性比直接暴露TCP端口高一个量级。代价是访问方也要部署客户端配置稍繁琐不太适合对外提供服务只适合自己用。7.3 版本升级与配置文件迁移frp的版本更新很快升级本身不难下载新版本的二进制停掉服务替换再启动。但配置文件的写法可能需要适配。特别是从老版本升级到v0.52.0以后主要变化就是INI到TOML的迁移。字段名有一些对不上比如老配置里的privilege_token变成了auth.tokendashboard_addr、dashboard_port变成了webServer.addr、webServer.port。升级后如果服务起不来第一件事就是把新版本release目录下自带的frps.toml和frpc.toml示例全部打开看一遍对照字段逐个检查。至少我迁移的时候光靠看官方示例就已经够用了。暂时不想折腾TOML的话旧INI配置文件在多数场景下也还能用但别指望新特性会在INI里生效。7.4 一个提升稳定性的小经验最后分享一个小经验。frpc长时间运行的场景下内网机器的网络环境其实没那么可靠比如家里PPPoE拨号会在凌晨重新拨号、WiFi中继偶尔断流。以前我遇到过内网IP变了frpc日志开始刷连接失败但systemd不会重启它的情况。后来我在frpc.service里加上了Restartalways和RestartSec10并且用watchdog级别的监控脚本定时探测本地SSH端口隧道是否正常。实际用下来即使家里断网重拨frpc也会在几分钟内自动恢复连接几乎感知不到中断。如果你的内网网络经常变动建议也加一层这样的兜底重试机制。