1. 从一台吃灰的旧笔记本说起我为什么要在家里搭一套内网穿透家里那台用了五年的旧笔记本卖掉不值几个钱扔了又可惜。某天我盯着它想了半天——8GB内存、256GB固态、i5处理器这配置跑个轻量级服务绰绰有余为什么不让它发挥点余热于是我开始琢磨能不能把家里的这台机器变成一台随时可以访问的服务器问题很快就来了。家里的宽带分配的是内网地址外网根本访问不进来。运营商给的那个地址每隔几天就变一次就算把服务跑起来出门在外也连不上。我试过打电话问运营商要固定地址对方说个人宽带不给办。也考虑过把服务部署到云服务器上但云服务器配置稍微像样点的一年下来少说也要大几百块而且数据放在别人那里心里总归不太踏实。这时候内网穿透就派上用场了。简单说内网穿透就是让外网的请求能够“穿透”层层路由和防火墙到达你家里那台处于内网环境的机器上。实现内网穿透的方案有好几种我前后折腾过不少最后稳定用下来的是一套叫frp的工具组合。它由两部分组成一个跑在具有公网地址的机器上的服务端一个跑在你家里内网机器上的客户端。客户端主动向服务端建立一条长连接外部的访问请求先到服务端服务端再通过这条已经建立好的通道把流量转发到内网机器上。这套方案的好处很明显你不需要动家里的路由器配置不需要向运营商申请任何东西只要有一台具备公网访问能力的机器作为中转就够了。这台中转机器可以是一台最低配的云主机成本压得很低。整条链路是加密的安全性也有基本保障。这篇文章适合几类人看手里有闲置电脑想废物利用的、想在家里搭个人网盘或代码仓库的、做开发需要临时把本地服务暴露出去联调的、以及对网络转发原理感兴趣想动手实践的朋友。我会从整体架构讲起把服务端和客户端的配置一步步拆开再补充我自己踩过的坑和调优经验。整个过程不需要你具备专业的网络工程背景跟着做就能跑通。2. 动手之前先把架构想清楚frp 到底是怎么把请求送进你家的2.1 服务端与客户端的分工frp 的工作模式可以用一个生活场景来类比。假设你住在一个管理严格的小区里外卖员不能直接进小区送到你家门口。这时候小区门口有个快递代收点外卖员把东西放到代收点代收点的工作人员再根据地址送到你手上。这里的“代收点”就是服务端它有一个对外公开的地址任何人都能找到它“你家”就是内网机器外面的人直接找不到而“代收点工作人员”就是那条由客户端主动建立并维持的长连接。具体来说服务端跑在一台有公网地址的机器上它监听一个端口等待客户端来连接。客户端跑在你家里的内网机器上启动后主动去连接服务端连接建立后这条通道就一直保持着。当外部用户想要访问你家里的服务时他访问的是服务端的地址和端口服务端收到请求后通过之前建立的那条通道把请求转发给客户端客户端再把它交给本地的服务进程。响应则沿着相反的路径返回。这个设计最巧妙的地方在于连接的方向始终是内网主动向外发起的。因为内网机器访问外网通常不受限制所以这条通道很容易建立起来而且不需要在路由器上做任何端口映射。这也是 frp 相比其他方案更容易上手的原因。2.2 需要准备哪些东西在正式动手之前先把需要的资源列清楚免得做到一半发现缺东西。资源用途说明一台具有公网访问能力的机器跑 frp 服务端最低配即可1核1G足够家里的内网机器跑 frp 客户端和实际服务旧笔记本、迷你主机、树莓派都行服务端和客户端的 frp 程序核心转发工具从官方仓库获取对应架构的版本一个域名可选方便记忆和访问不买域名直接用地址加端口也能跑关于服务端机器的选择我个人的经验是不需要追求高配置因为 frp 本身非常轻量转发过程几乎不消耗什么计算资源真正吃资源的是你跑在后面的实际服务。带宽方面如果你只是用来做远程开发联调、访问个人文件1Mbps到5Mbps的带宽就够用了如果要传大文件或者做媒体串流那就得看带宽上限了。2.3 网络拓扑与端口规划在配置之前先在纸上画一下端口规划这个习惯能帮你省掉很多排查时间。我一般会这样规划服务端监听端口用于接收客户端连接比如 7000服务端仪表盘端口用于查看连接状态比如 7500对外暴露端口外部用户实际访问的端口比如 6000内网服务端口你家里机器上实际服务监听的端口比如 8080这样规划的好处是每个端口职责清晰出问题的时候能快速定位是哪一段出了岔子。比如外部访问不通先看对外暴露端口有没有被占用再看服务端有没有收到请求最后看内网服务本身是否正常。注意服务端机器上如果有防火墙或安全组规则需要放行上述端口的入站流量。这一步经常被忽略导致配置看起来都对但就是连不上。3. 服务端部署把那台中转机器先跑起来3.1 获取程序与目录规划frp 的程序包在官方发布渠道可以直接下载根据服务端机器的处理器架构选择对应的压缩包。下载完成后解压你会看到两个可执行文件一个是服务端程序一个是客户端程序。服务端机器上只需要用到服务端那个。我习惯把程序放在一个固定的目录下比如/opt/frp配置文件放在同目录的conf子目录里。这样做的原因是后续升级版本时只需要替换可执行文件配置文件不用动。目录结构大概长这样/opt/frp/ ├── frps ├── frpc └── conf/ └── frps.toml配置文件格式方面新版本的 frp 已经全面转向 TOML 格式比早期的 INI 格式更清晰也更好维护。如果你在网上看到的是旧版 INI 格式的教程注意区分不要混用。3.2 服务端配置文件逐项拆解下面是我实际使用的一份服务端配置每一项都加上说明# 服务端监听端口客户端通过这个端口来连接 bindPort 7000 # 仪表盘配置用于查看当前连接状态和流量统计 webServer.addr 0.0.0.0 webServer.port 7500 webServer.user admin webServer.password 换成你自己的强密码 # 认证配置客户端必须提供相同的令牌才能连接 auth.method token auth.token 换成一串足够长的随机字符串 # 日志配置排查问题时非常有用 log.to /opt/frp/frps.log log.level info log.maxDays 7这里有几个点值得展开说。认证令牌一定要改掉默认值而且长度要够。我见过有人图省事用默认配置结果服务端被扫描到之后任何人都能往上面挂服务。令牌相当于服务端和客户端之间的暗号对不上就不让连。仪表盘建议开启它能让你直观地看到当前有哪些客户端连着、每个隧道转发了多少流量排查问题时比翻日志快得多。日志级别平时用 info 就够了遇到疑难杂症再临时调到 debug不然日志文件会涨得很快。3.3 让服务端稳定运行配置写好后直接运行服务端程序并指定配置文件路径即可。但如果你希望它在后台稳定运行、开机自启、意外退出后自动拉起那就需要把它注册成一个系统服务。在大多数 Linux 发行版上用系统自带的服务管理器来托管是最省心的做法。创建一个服务单元文件内容大致如下[Unit] Descriptionfrp server Afternetwork.target [Service] Typesimple ExecStart/opt/frp/frps -c /opt/frp/conf/frps.toml Restartalways RestartSec5 [Install] WantedBymulti-user.targetRestartalways这一行很关键它保证程序意外退出后会自动重启。我遇到过半夜服务端进程因为内存波动被系统回收的情况有了这个配置几秒钟后它就自己恢复了第二天看日志才发现曾经断过。服务启动后用查看服务状态的命令确认它处于运行中然后打开浏览器访问仪表盘地址看看页面能不能正常打开。能打开就说明服务端这一侧基本就绪了。4. 客户端配置把家里的服务“挂”出去4.1 客户端配置的整体思路客户端要做的事情比服务端稍微复杂一点因为它需要描述清楚“把哪个本地服务通过哪条隧道映射到服务端的哪个端口上”。一条完整的隧道配置包含几个要素隧道名称、类型、本地地址和端口、远程端口。隧道名称是你自己起的标识类型决定了转发方式本地地址和端口指向你家里实际跑着的服务远程端口是外部用户访问时用的端口。frp 支持多种隧道类型最常用的是TCP 类型适用于绝大多数场景比如网页服务、远程桌面、数据库连接等。如果你要暴露的是网页服务并且希望通过域名来区分不同的站点那可以用HTTP 类型它能根据请求中的域名信息把流量分发到不同的后端。还有一种UDP 类型用于游戏联机、语音通话这类场景。4.2 一份可直接参考的客户端配置下面这份配置同时包含了 TCP 和 HTTP 两种隧道你可以根据自己的需求删减# 服务端地址和端口 serverAddr 你的服务端地址 serverPort 7000 # 认证令牌必须和服务端一致 auth.method token auth.token 和服务端相同的令牌 # 日志配置 log.to /opt/frp/frpc.log log.level info log.maxDays 7 # 隧道一把本地的网页服务暴露出去 [[proxies]] name web-service type tcp localIP 127.0.0.1 localPort 8080 remotePort 6000 # 隧道二通过域名访问适合有多个站点的情况 [[proxies]] name blog-site type http localIP 127.0.0.1 localPort 8081 customDomains [blog.你的域名.com]第一段隧道把本地的 8080 端口映射到了服务端的 6000 端口。外部用户访问“服务端地址:6000”时请求就会被转发到你家机器的 8080 端口上。第二段隧道用了 HTTP 类型它不需要指定远程端口而是通过域名来区分。当请求的域名匹配到配置中的域名时流量才会被转发过来。4.3 客户端侧同样需要托管运行和服务端一样客户端也需要长期稳定运行。在 Windows 上可以把它注册成计划任务在 Linux 上同样用服务管理器托管。配置方式和服务端几乎一样只是可执行文件和配置文件路径不同。这里有一个我踩过的坑客户端启动顺序。如果你的本地服务启动比较慢而 frp 客户端启动很快可能会出现隧道已经建立但后端服务还没就绪的情况外部访问会报错。解决办法是给客户端服务加上依赖关系让它在本地服务启动之后再启动或者在客户端配置里加上健康检查相关的设置。我后来养成的习惯是本地服务用服务管理器托管并设置好启动顺序frp 客户端排在它后面。5. 实测中遇到的那些坑从连不上到跑得稳5.1 隧道显示在线但访问不通这是最常见的一类问题。仪表盘上明明显示隧道是在线的但外部访问就是没反应。遇到这种情况我一般按下面的顺序排查第一步确认本地服务本身是正常的。在跑客户端的机器上直接用本地地址访问一下比如curl 127.0.0.1:8080看看有没有正常响应。如果本地都不通那问题出在服务本身跟 frp 没关系。第二步检查服务端机器的防火墙和安全组。很多人配置完 frp 就忘了这一步服务端所在机器的防火墙把外部访问端口给拦了。用查看防火墙规则的命令确认一下该放行的端口有没有放行。第三步确认远程端口没有被占用。服务端上如果已经有别的程序占用了你配置的远程端口隧道虽然能建立但流量到不了正确的地方。换一个端口试试就能验证。第四步看服务端日志。日志里会记录每一次连接尝试和转发情况如果请求根本没到服务端那问题在更前面如果到了服务端但转发失败日志里会有相应提示。5.2 连接频繁断开又重连有一段时间我发现隧道每隔十几分钟就断一次然后自动重连虽然能恢复但正在进行的连接会中断体验很差。排查下来发现是网络环境的问题家里的宽带在某些时段会出现短暂的地址变化导致已建立的连接失效。frp 本身有断线重连机制客户端检测到连接断开后会自动尝试重新连接。但如果断开太频繁就需要从根源上找原因。我后来在客户端配置里加了心跳相关的参数让连接保持得更稳定。另外如果服务端和客户端之间的网络质量本身就不太好可以考虑调整传输协议相关的设置在稳定性和速度之间找一个平衡点。5.3 传输大文件时速度不理想用 frp 传大文件时速度往往达不到带宽上限。这里面有几个影响因素一是服务端机器的带宽本身有限这是硬瓶颈二是 frp 的转发过程会带来一定的额外开销三是如果开启了加密加解密也会消耗一些性能。我的优化思路是这样的如果服务端机器配置比较低可以适当调整 frp 的传输相关参数比如调整缓冲区大小如果对安全性要求不是特别高可以在确认链路本身安全的前提下选择开销更小的传输方式。但说实话如果经常需要传大文件更好的做法是直接用对象存储或者文件同步工具而不是让 frp 来扛这个活。frp 的定位是打通连接不是做高速文件传输。5.4 安全性方面不能偷懒把内网服务暴露到公网安全性是必须认真对待的事情。我总结了几条底线认证令牌必须改而且要用足够长的随机字符串不要用有意义的单词。仪表盘不要对公网开放或者至少设置强密码。仪表盘里能看到所有隧道信息泄露出去风险很大。只暴露必要的端口不要图省事把所有端口都映射出去。用不到的隧道及时关掉。定期看日志关注有没有异常的连接尝试。如果发现某个地址在频繁尝试连接可以考虑在服务端加上访问控制规则。保持 frp 版本更新新版本通常会修复已知的安全问题。提示如果你的服务端机器有多个地址建议把仪表盘和客户端连接端口绑定到不同的地址上进一步缩小暴露面。6. 让这套方案真正好用几个提升体验的配置技巧6.1 用域名代替地址加端口直接用地址加端口访问虽然能跑通但记起来麻烦而且很多场景下不方便。如果你有自己的域名可以把域名解析到服务端地址上然后在 frp 里配置 HTTP 类型的隧道用域名来区分不同的服务。这样一来访问blog.你的域名.com就能到你家里的博客服务访问git.你的域名.com就能到代码仓库清清爽爽。配置的时候注意HTTP 类型的隧道需要服务端也做相应配置指定用于接收 HTTP 请求的端口。这个端口和客户端连接端口是分开的不要搞混。6.2 给隧道加上访问控制不是所有隧道都希望被所有人访问。frp 支持在服务端配置访问控制规则可以限制哪些地址能访问哪些端口。比如你可以设置只允许特定范围的地址访问某个隧道其他地址一律拒绝。这个功能在服务端配置文件的访问控制部分添加规则即可语法不复杂但能显著提升安全性。另外如果某个隧道只是临时用一下用完就关那最好的安全措施就是不用的时候把它关掉。我现在的习惯是临时联调用的隧道单独放在一个配置文件里需要的时候启动用完就停不常驻。6.3 监控与告警的简单做法服务跑起来了怎么知道它是不是一直健康我的做法是利用 frp 自带的仪表盘接口写一个简单的脚本定期去拉取状态信息如果发现隧道数量不对或者连接异常就发个通知给自己。这个脚本不需要多复杂几十行代码就能搞定但能让你在问题发生的第一时间知道而不是等自己要用的时候才发现连不上。如果你不想写脚本也可以用一个更土但有效的办法在服务端机器上设置一个定时任务定期用外部地址访问一下自己的服务访问失败就记录一条日志。虽然笨但管用。6.4 多台内网机器怎么管理当你不止一台内网机器需要暴露服务时有两种组织方式。一种是在每台机器上都跑一个 frp 客户端各自连接服务端互不干扰。另一种是在一台机器上跑客户端通过配置多条隧道指向不同的内网地址。两种方式各有优劣前者管理分散但隔离性好一台出问题不影响其他后者管理集中但单点风险高。我目前用的是第一种方式每台需要暴露服务的机器上跑一个客户端用不同的令牌或者不同的隧道名称前缀来区分。这样任何一台机器重启或者出问题都不会影响其他机器的隧道。服务端的仪表盘上也能清楚地看到每个客户端的连接状态。7. 这套方案还能怎么扩展跑通基础的内网穿透之后我陆续在这套架构上叠加了一些别的用法。比如把家里的旧机器变成了一个私人的代码仓库出门在外也能提交和拉取代码比如在上面跑了一个轻量的笔记服务所有设备都能同步再比如把家里的监控摄像头的画面通过 frp 转发出来在外面也能查看。这些扩展用到的核心机制都是一样的本地跑服务frp 负责把连接打通。区别只在于本地跑的是什么服务、需要暴露哪些端口、对带宽和延迟有什么要求。理解了 frp 的工作方式之后剩下的就是根据具体需求去调整配置。有一点需要提醒的是随着暴露的服务越来越多安全管理的复杂度也会上升。我的建议是定期梳理一遍所有隧道把不再使用的及时清理掉保持配置的简洁。配置越简单出问题的概率就越低排查起来也越容易。最后分享一个我在实际使用中体会很深的心得不要追求一步到位。我一开始就想把所有东西都配好结果遇到问题的时候不知道是哪一步出了错。后来改成一次只加一条隧道跑通了再加下一条每一步都确认无误再继续。这样虽然看起来慢但实际上是最快的路径因为每一步都是可控的出了问题也能立刻定位。这套方法不仅适用于 frp折腾任何网络相关的配置都通用。