☰
frp内网穿透实战:用闲置电脑搭建无公网IP的远程服务器
2026/10/16 5:28:09 网站建设 项目流程

1. 从一台吃灰的旧电脑说起:内网穿透到底在解决什么问题

很多人手里都有那么一两台淘汰下来的旧笔记本或者迷你主机,卖二手不值钱,扔了又可惜。与此同时,我们日常又经常遇到一些很具体的需求:在外面想访问家里电脑上的文件、想让家里的设备跑一个定时任务然后远程看结果、想把自己写的小工具部署起来给朋友用一下、想在外面连回自己家里的开发环境继续写代码。这些需求听起来都不复杂,但真正动手的时候,第一个拦路虎就出现了——你家里的电脑根本没有公网 IP。

这就是内网穿透要解决的核心问题。简单说,你家路由器分配给你电脑的地址是类似 192.168.x.x 这种私有地址,这个地址只在你自己家的局域网里有效。外面的网络想主动找到你这台机器,是找不到的,因为中间隔着运营商的网络地址转换。绝大多数家庭宽带现在都是这种共享公网出口的状态,你没法直接让外部流量打进来。

那有没有办法绕过去?有,而且方案不止一种。最直接的是找运营商申请公网 IP,但这件事现在越来越难,很多地区直接不给个人用户办,就算给了,IP 还可能随时变。另一种思路是打洞,也就是让内网机器主动向外建立一条隧道,外部流量通过这条已经建立的隧道回传进来。frp 就是干这个的,它属于反向代理型的内网穿透工具,核心逻辑是:你有一台带公网 IP 的服务器做中转,内网机器主动连上去,把本地的某个端口映射到公网服务器的某个端口上,外部访问公网服务器的那个端口,流量就被转发回你内网的机器。

这套方案的好处非常明显。第一,它不依赖运营商给你公网 IP,只要你能买到一台便宜的公网服务器就行。第二,配置相对直观,一个配置文件加一条命令就能跑起来。第三,它足够稳定,适合长期挂着当服务用。第四,它支持 TCP、UDP、HTTP、HTTPS 等多种协议,不管是远程桌面、SSH、Web 服务还是游戏联机,基本都能覆盖。

这篇文章适合谁看?如果你手里有一台闲置电脑想拿来做点事,如果你写过一些小项目想部署起来自己用或者分享给别人,如果你需要远程访问家里的设备但苦于没有公网 IP,那这套方案就是为你准备的。哪怕你之前没接触过内网穿透,只要会基本的命令行操作,跟着走一遍就能跑通。我会把每一步为什么这么做、参数怎么选、坑在哪里都讲清楚,让你不只是抄配置,而是真正理解这套东西怎么运转。

2. 方案整体设计与核心思路拆解

2.1 为什么选 frp 而不是别的方案

内网穿透这个领域可选的工具其实不少,有商业化的成品服务,也有各种开源方案。我选 frp 主要基于几个实际考量。

首先是自建可控。商业服务虽然省事,但你的流量要经过别人的服务器,数据安全和隐私这块始终是个问号,而且免费版通常有限速和连接数限制,用起来束手束脚。frp 是开源的,服务端跑在你自己买的服务器上,数据链路完全自己掌控。

其次是协议覆盖全。frp 支持 TCP、UDP、HTTP、HTTPS、STCP、XTCP 等多种代理类型。这意味着你既能映射一个简单的 SSH 端口,也能把整个 Web 服务带域名暴露出去,甚至能做点对点的加密隧道。一个工具解决多种场景,不用装一堆东西。

第三是配置简单且文档清晰。frp 的配置文件是 ini 或者 toml 格式,字段命名直观,官方示例也全。相比某些需要自己编译、自己写复杂路由规则的方案,frp 的上手门槛低很多。

第四是社区活跃。遇到问题搜一下基本都能找到答案,版本迭代也稳定,不会出现那种用着用着项目没人维护的情况。

当然它也不是没有缺点。最明显的就是依赖一台公网服务器,这意味着你每年要花一笔服务器费用。不过现在入门级云服务器价格已经很低了,一年几十块到一百多块就能拿下,用来做内网穿透中转完全够用。另一个缺点是流量要绕一圈,延迟会比直连高一些,但对于远程访问、文件传输这类场景,这点延迟基本感知不到。

2.2 整体架构长什么样

这套方案的架构其实很清晰,我用一个生活化的类比来解释。想象你家在一个没有门牌号的小巷子里,快递员根本找不到。于是你在巷子口租了一个临街的铺面,这个铺面有明确的门牌号,所有人都能找到。你告诉快递员,所有寄给你的包裹都送到铺面,然后你每天去铺面把包裹取回家。这里的铺面就是那台公网服务器,快递员就是外部访问的流量,你每天去取包裹的动作就是 frp 建立的那条隧道。

具体到技术层面,整个链路是这样的:

  • frps(服务端):跑在公网服务器上,监听一个固定端口,等待内网机器连过来。它负责接收外部请求,然后通过已建立的隧道转发给对应的内网机器。
  • frpc(客户端):跑在你家里那台电脑上,主动去连接公网服务器的指定端口。连上之后,它会告诉服务端"我本地有个服务在某个端口,你帮我把外部请求转过来"。
  • 隧道:frpc 和 frps 之间维持的一条长连接,所有转发流量都走这条连接。
  • 映射端口:公网服务器上对外开放的端口,外部用户访问这个端口,流量就会被转发到内网机器对应的端口。

整个过程中,内网机器始终是主动发起连接的一方,所以不需要公网 IP,也不需要动路由器做端口映射。这就是反向代理型内网穿透的精髓。

2.3 需要准备什么

动手之前,先把东西备齐,免得做到一半发现缺东少西。

准备项说明备注
公网服务器一台带公网 IP 的云服务器入门配置即可,1核1G够用
内网电脑你想变成服务器的那台机器旧笔记本、迷你主机都行
操作系统服务端和客户端都建议用 LinuxWindows 也能跑客户端
frp 程序从官方仓库下载对应版本注意架构要匹配
基础命令行能力会 ssh、会编辑配置文件不需要编程基础

服务器这块,选最便宜的入门款就行,因为 frp 本身资源占用极低,主要消耗在流量上。带宽方面,如果你只是远程访问、传传文件,1M 到 5M 带宽就够;如果要跑视频流或者大文件频繁传输,那就得往上加。系统建议用常见的 Linux 发行版,兼容性好,遇到问题资料也多。

内网那台电脑,我建议装 Linux,因为长期运行更稳定,资源占用也低。如果你只有 Windows 机器,frpc 也有 Windows 版本,一样能用,只是后台常驻的配置稍微麻烦一点。

3. 核心细节解析与实操要点

3.1 frp 的版本选择与文件结构

frp 的版本迭代比较快,不同大版本之间配置文件格式有差异。早期用的是 ini 格式,新版本推荐用 toml 或者 yaml。我建议直接用较新的稳定版,配置文件用 toml,结构更清晰,也不容易写错。

下载的时候一定要注意架构匹配。服务器一般是 x86_64,内网电脑如果是老设备可能是 arm 架构,树莓派之类的也是 arm。下载错了架构,运行时会直接报格式错误。下载下来是个压缩包,解压后你会看到这么几个关键文件:

  • frps:服务端可执行文件
  • frpc:客户端可执行文件
  • frps.toml:服务端配置示例
  • frpc.toml:客户端配置示例

实际部署时,服务端只需要frps和它的配置文件,客户端只需要frpc和它的配置文件。可执行文件给上执行权限,配置文件按需修改。

注意:下载后先确认文件完整性,有些环境下解压可能不完整。可以用file命令看一下可执行文件的架构信息,确认和你的系统匹配。

3.2 服务端配置的关键参数

服务端配置是整个链路的基础,它决定了隧道怎么建立、谁能连上来。核心参数有这么几个:

bindPort:这是 frps 监听的端口,frpc 要连的就是这个端口。默认是 7000,你可以改成别的,但要注意服务器防火墙和安全组要放行这个端口。我一般会改成一个不常见的端口,减少被扫描的概率。

auth.token:认证令牌。这是安全的第一道防线,frpc 必须提供正确的 token 才能连上 frps。如果不设,任何人都能连你的服务端,那就等于把家门钥匙挂在门上。token 要设得复杂一点,别用简单的单词。

webServer:frps 自带一个 Web 管理界面,可以看当前有哪些客户端连上来、有哪些代理在跑。配置里指定监听端口和访问账号密码,方便你随时查看状态。

subDomainHost:如果你要用 HTTP 类型的代理并且希望通过域名访问,这个参数要设置。它决定了子域名的后缀。

allowPorts:限制客户端能映射的端口范围。这是个安全加固项,防止客户端把任意端口都暴露出去。你可以指定一个范围,比如只允许 20000 到 30000 之间的端口。

服务端配置写好后,启动命令很简单,指定配置文件路径就行。建议用 systemd 做成服务,这样开机自启、崩溃自动重启,不用手动盯着。

3.3 客户端配置的核心逻辑

客户端配置是真正决定"你本地什么服务被暴露出去"的地方。它的结构是:先配置连接服务端的信息,然后一个或多个代理定义。

连接部分需要填服务端的公网 IP、bindPort、以及和服务端一致的 token。这部分配错了,客户端根本连不上,日志里会直接报连接失败或者认证失败。

代理部分,每个代理是一个独立的配置块,需要指定:

  • name:代理名称,唯一标识,服务端管理界面里显示的就是这个名字
  • type:代理类型,tcp、udp、http、https 等
  • localIP:本地服务监听的地址,一般是 127.0.0.1
  • localPort:本地服务监听的端口
  • remotePort:映射到服务端的哪个端口

举个例子,你想把内网的 SSH 服务暴露出去,本地 SSH 跑在 22 端口,你希望外部通过服务端的 6000 端口访问,那就配一个 tcp 类型的代理,localPort 填 22,remotePort 填 6000。配好重启 frpc,外部用服务端 IP 加 6000 端口就能 SSH 到你的内网机器了。

提示:remotePort 必须在服务端 allowPorts 允许的范围内,否则连接会被拒绝。这个坑我第一次配的时候踩过,日志里报端口不允许,排查了半天才发现是服务端限制。

3.4 安全加固不能省

把内网服务暴露到公网,安全是绕不开的话题。frp 本身提供了一些机制,但更重要的是你的使用习惯。

第一,token 必须设且要复杂。这是最基本的门槛,别偷懒。

第二,服务端只开放必要的端口。bindPort 和你要用的 remotePort 开放就行,其他一律关掉。服务器防火墙和安全组都要检查。

第三,敏感服务加一层认证。比如你暴露 SSH,建议用密钥登录而不是密码,并且禁用 root 直接登录。暴露 Web 服务的话,加个基础认证或者用反向代理再加一层防护。

第四,定期看日志。frps 的日志会记录连接情况,如果发现有大量异常连接尝试,说明你的端口被扫描了,该换端口或者加强防护了。

第五,能用加密就用加密。frp 支持 TLS 加密传输,在服务端和客户端都开启 tls 相关配置,隧道里的流量就是加密的,中间人即使截获也看不懂。

4. 实操过程与核心环节实现

4.1 服务端部署全流程

假设你已经买好了一台公网服务器,系统是常见的 Linux 发行版,用 SSH 登录上去。以下步骤按顺序执行。

第一步,下载 frp。去官方发布页面找到对应架构的压缩包,用 wget 或者 curl 下载到服务器上。下载完解压到一个固定目录,比如/opt/frp。

mkdir -p /opt/frp cd /opt/frp # 下载对应版本的压缩包,这里以示例版本号代替 wget https://example.com/frp_x.x.x_linux_amd64.tar.gz tar -zxvf frp_x.x.x_linux_amd64.tar.gz

第二步,编写服务端配置文件frps.toml。内容大致如下:

bindPort = 7000 auth.token = "你的复杂令牌" webServer.addr = "0.0.0.0" webServer.port = 7500 webServer.user = "admin" webServer.password = "管理密码" allowPorts = [ { start = 20000, end = 30000 } ]

这里 bindPort 用 7000,token 自己设一个长的随机字符串,Web 管理界面跑在 7500,允许客户端映射 20000 到 30000 之间的端口。

第三步,给可执行文件加执行权限,然后测试启动。

chmod +x frps ./frps -c frps.toml

如果看到启动成功的日志,说明配置没问题。按 Ctrl+C 停掉,接下来做成系统服务。

第四步,创建 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=always RestartSec=5 [Install] WantedBy=multi-user.target

然后重载 systemd、启动服务、设置开机自启:

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

看到 active (running) 就说明服务端跑起来了。

第五步,检查防火墙和安全组。服务器本机的防火墙要放行 7000 和 7500,以及你后续要用的 remotePort 范围。云服务器控制台的安全组也要对应放行。这两层任何一层没放行,外部都访问不了。

4.2 客户端部署与代理配置

现在转到内网那台电脑上。同样先下载 frp,注意架构要匹配这台机器的 CPU。解压到固定目录,比如/opt/frp。

编写客户端配置文件frpc.toml:

serverAddr = "你的服务器公网IP" serverPort = 7000 auth.token = "和服务端一致的令牌" [[proxies]] name = "ssh" type = "tcp" localIP = "127.0.0.1" localPort = 22 remotePort = 20022 [[proxies]] name = "web" type = "tcp" localIP = "127.0.0.1" localPort = 8080 remotePort = 20080

这个配置定义了两个代理。第一个把本地的 22 端口(SSH)映射到服务端的 20022 端口。第二个把本地 8080 端口(假设你跑了个 Web 服务)映射到服务端的 20080 端口。

启动客户端:

chmod +x frpc ./frpc -c frpc.toml

如果日志显示登录成功、代理启动成功,那就通了。这时候你在外面用服务端 IP 加 20022 端口就能 SSH 到内网机器,用服务端 IP 加 20080 就能访问内网的 Web 服务。

同样建议把客户端也做成 systemd 服务,保证长期稳定运行。配置方式和上面服务端类似,把 ExecStart 换成 frpc 的路径即可。

4.3 验证与调试方法

配好之后怎么确认真的通了?我一般按这个顺序验证。

先看服务端 Web 管理界面。浏览器打开http://服务器IP:7500,用配置的账号密码登录,能看到当前连上来的客户端和活跃的代理列表。如果客户端显示在线,代理状态正常,说明隧道建立成功。

然后从外部测试实际访问。用另一台不在同一网络的机器,尝试连接服务端的映射端口。比如 SSH 测试:

ssh -p 20022 用户名@服务器IP

如果能登录进去,说明整条链路完全打通。

如果连不上,按这个顺序排查:先确认 frpc 进程在跑且日志无报错;再确认服务端 Web 界面里客户端在线;然后检查服务端防火墙和安全组是否放行了 remotePort;最后确认内网本地服务本身是否正常监听。这个顺序能帮你快速定位问题出在哪一段。

4.4 把私人电脑变成服务器的进阶玩法

隧道通了之后,你的内网电脑实际上就已经是一台可以被外部访问的服务器了。接下来可以做的事情很多。

你可以在这台机器上部署各种服务。比如跑一个文件共享服务,随时随地上传下载文件。比如跑一个笔记应用,自己的数据自己掌控。比如跑一个定时任务调度,让机器帮你自动处理一些重复工作。比如跑一个开发环境,在外面也能连回来继续写代码。

如果想让 Web 服务通过域名访问而不是 IP 加端口,可以配置 HTTP 类型的代理,配合域名解析,把子域名指向服务器 IP,frps 会根据域名把请求转发到对应的内网服务。这样访问起来就更优雅了。

还可以配置多个客户端,把家里不同设备上的服务都映射出去,统一由一台服务端管理。frp 支持一个服务端对接多个客户端,每个客户端可以有自己的 token 和端口范围,管理起来很灵活。

5. 常见问题与排查技巧实录

5.1 连接失败类问题速查

这类问题最常见,表现是 frpc 启动后日志报错,或者服务端看不到客户端上线。

现象可能原因排查方法
连接超时服务端防火墙或安全组没放行 bindPort检查两层防火墙规则
认证失败两端 token 不一致逐字符比对配置文件
端口被占用bindPort 已被其他程序使用换端口或停掉占用程序
架构不匹配下载了错误架构的可执行文件用 file 命令确认架构
配置文件格式错误toml 语法写错用在线校验工具检查

我踩过最典型的一个坑是 token 里带了特殊字符,在配置文件里没加引号导致解析出错。后来养成习惯,所有字符串值都加引号,省得纠结。

5.2 代理不通类问题排查

隧道建立了,客户端也在线,但访问映射端口就是不通。这种情况通常是代理配置或者本地服务的问题。

先确认本地服务本身正常。在内网机器上直接访问127.0.0.1:本地端口,如果能通,说明服务没问题,问题在 frp 配置或者网络链路上。如果不通,那就是本地服务没跑起来或者监听地址不对。

然后确认 remotePort 在服务端 allowPorts 范围内。超出范围会被服务端拒绝,日志里会有明确提示。

再确认服务端防火墙放行了 remotePort。很多人只放行了 bindPort,忘了映射端口也要放行,结果隧道通了但外部访问不了。

最后确认代理类型选对了。TCP 服务用 tcp 类型,UDP 服务必须用 udp 类型,选错了协议流量根本转发不过去。

5.3 稳定性与性能优化经验

长期挂着跑,稳定性很重要。我总结了几条经验。

开启自动重连。frpc 默认会在断线后自动重连,但要确认配置里没有禁用这个行为。网络波动导致断线是正常的,能自动恢复就行。

合理设置心跳。frp 有心跳机制用来检测连接是否存活,默认值一般够用。如果网络环境比较差,可以适当调整心跳间隔和超时时间,避免误判断线。

限制日志大小。长期运行日志会不断增长,占满磁盘就麻烦了。配置日志轮转,或者用 systemd 的日志管理,避免日志无限膨胀。

监控资源占用。frp 本身很轻量,但如果转发流量大,带宽和连接数会成为瓶颈。定期看一下服务器的网络和 CPU 情况,该升级配置就升级。

做好备份。配置文件和 token 备份好,万一服务器出问题要迁移,直接拿过来就能用,不用重新配。

5.4 安全事件应对

如果发现服务端日志里有大量异常连接尝试,说明你的端口被扫描了。这时候别慌,按这几步处理。

先把 bindPort 换成一个不常见的端口,减少被扫到的概率。然后检查 token 是否足够复杂,必要时换一个新的。再看有没有不必要的代理暴露在外,能关的关掉。如果某个服务被暴力破解,立刻改密码、加认证、限制访问来源。

平时养成看日志的习惯,异常情况早发现早处理。安全这件事,预防的成本远低于事后补救。

6. 我个人的一些实操体会

这套方案我从几年前开始用,中间换过服务器、换过内网机器、也踩过不少坑。最大的感受是,frp 这类工具的价值不在于技术多高深,而在于它把一件原本很麻烦的事情变得足够简单。你不需要懂网络底层原理,不需要跟运营商扯皮,只要有一台便宜服务器和一点耐心,就能让闲置的电脑重新发挥作用。

配置过程中最容易出问题的地方,往往不是 frp 本身,而是外围的东西:防火墙规则、安全组、本地服务监听地址、配置文件格式。这些细节看起来琐碎,但任何一个没注意到,整条链路就不通。我的建议是每配一步就验证一步,别等全部配完再一起测,那样出问题很难定位。

另外,安全这根弦一定要绷紧。把内网服务暴露到公网,等于开了一扇门,门锁好不好直接关系到你的数据安全。token 要复杂,端口要收敛,敏感服务要加认证,日志要常看。这些习惯养成了,用起来才安心。

最后分享一个小技巧:如果你有多个内网服务要暴露,与其每个都单独配一个 remotePort,不如在内网机器上跑一个反向代理,把所有 Web 服务统一到一个端口,然后只映射这一个端口出去。这样服务端开放的端口更少,管理也更集中。这个思路在服务越来越多的时候特别有用,我自己就是这么干的,省心不少。

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询