frp：没有公网 IP 也能远程连上工程机

frp 是一款开源的反向代理工具，官方的一句话定位是：把一台放在内网、没有公网 IP 的机器，"暴露"到公网上让别人能连进来。这句话拆开看，正好对上展厅项目里最常见的一个死结——甲方机房那台播控主机，除了机柜里那根网线，跟外面的世界没有任何直接联系；你人在公司，想远程处理一次半夜死机，中间隔着一堵网络上的墙。

先把两个绕不开的术语说清楚。"公网 IP"是一台机器在整个互联网上独一无二的门牌号，别人拿着这个号码就能直接找到你；大多数企业内网、家用宽带分给你的其实是"内网 IP"，只在自己家里能认，出了这个网就谁也找不到你。"端口映射"是另一条路：在甲方的路由器或防火墙上开一个口子，把外面某个端口的流量转发进内网这台机器——听着简单，但这步操作权限在甲方网管手里，很多单位出于安全考虑压根不批。frp 解决的正是"两条路都走不通"的场景：不需要甲方开任何映射，只需要内网这台机器主动往外连一次。这跟"连出去"和"被连进来"的方向刚好相反，也是为什么防火墙管得再严也拦不住它——大多数防火墙只防外面往里打，很少防里面往外连。

展厅哪道工序会用到它

第一道，也是最典型的一道：验收交付后甲方不给公网 IP。 项目做完，合同里写着一年甚至三年的运维期，可甲方 IT 明确说"我们不开公网映射"。播控机半夜死机，人跑不过去，前面聊过的远控软件如果甲方装不了或者要求自建服务器，frp 就是另一条能落地的路——它本身只管"打通这条通道"，通道打通之后跑什么（远程桌面、脚本、文件同步）是另一件事。

第二道：暴露的不是画面，是一个网页后台或接口。 有些播控系统、中控系统自带一个网页管理界面，或者留了一个接口给上位机调用。这种场景纯远控软件不好使，因为你要暴露的是"一个服务"而不是"一整台电脑的桌面"，frp 天生就是干这个的——把内网那台机器上跑着的某个服务，原样映射到公网的一个地址上。

第三道：批量展项设备的集中管理。 有些项目铺了几十台触摸一体机或者互动终端，都在同一个内网里。与其给每台单独开一条远控通道，不如在内网里放一台跳板机，用 frp 把它对外露出来，再从这台跳板机跳进内网的其它设备——集中一个出口，比每台机器各自折腾要好管。

怎么获取，该拿哪个包

官方入口只有 GitHub 一个地方：https://github.com/fatedier/frp，代码和发布包都在这里，没有官网、没有下载站。这一点跟前面聊过的一些工具不一样——它没有图形界面，也没有安装向导，本质上是两个命令行程序压缩包，下载后解压直接跑。这意味着装它这件事，得交给会用命令行、能看懂几行配置文件的实施或运维同事，前台售前人员自己动手的门槛比装一个图形化远控软件要高不少。

包分两半，一个叫服务端程序，装在那台有公网 IP 的机器上；一个叫客户端程序，装在甲方机房那台内网工程机上。GitHub 的发布页会按操作系统和芯片架构分好包，Windows、macOS、Linux 各有对应版本——展厅项目里常见的组合是：服务端跑在云主机（多半是 Linux），客户端装在甲方那台 Windows 播控机上。选包只看清楚系统和位数即可，选错重下一个就是。

还有一条官方专门提示过的坑：因为这类反向代理工具天生能绕开防火墙的端口限制，有些杀毒软件会误把客户端程序当成木马直接删掉。装机前记得把它加进甲方机器杀毒软件的白名单，不然装完过一阵子发现进程没了，排错会绕不少弯路。

最短可用路径

frp 的角色关系比配置本身重要得多，先把这层关系讲明白，比记住任何一条参数都管用。

整件事只涉及两个角色。一个是中转站：一台你自己掌控、有公网 IP 的服务器，上面跑着服务端程序，相当于一个约定好的碰头地点。另一个是内网机器：甲方机房那台工程机，上面跑着客户端程序，它做的唯一一件事，是主动往外拨号连到中转站，并且这条连接会一直保持着。

有了这条常驻连接，中转站就能顺着它，把外面发来的请求转手交给内网机器——不需要甲方那边开任何端口映射，因为从始至终都是内网机器在"打出去"，不是外面在"打进来"。你要在外面连内网机器，实际连的是那台中转站的某个地址；中转站再把这次连接接力转给内网机器。角色理清楚了，剩下的就是"服务端配一份地址和端口、客户端配一份连过去的地址"这两份配置文件，具体怎么填，官方文档给了完整的示例，交给做部署的同事对着填就行，不需要在这里逐行解释。

展厅工程里真正要弄明白的那几件事

第一条，也是最重要的一条：这件事很多甲方是明令禁止的，动手之前必须先报备。 内网穿透的本质是在甲方的网络边界上开一个由你控制的"后门"，哪怕出发点是为了方便运维，站在甲方网络安全的角度看，这跟未经授权私自打洞没有本质区别。政企、国企、金融、涉密性质的展厅项目，很多单位的网络安全制度里明确写着"禁止任何形式的内网穿透与反向代理"，一旦被查出来，轻则要求立即拆除、写检讨，重则牵扯违约责任。正确的顺序永远是：先书面告知甲方 IT 你打算用什么方案、通道怎么工作，拿到明确书面同意，再动手部署；绝不能想着"先装上再说，反正甲方也不懂"。 这不是免责套话，是真实会出事的红线，投标和签合同阶段就该把这层沟通做完，不要留到交付后才想起来。

第二条：那台中转站服务器，是一笔持续要花的钱，谈合同的时候必须算进去。 frp 本身完全免费开源，不存在授权费；但它要跑起来，必须有一台常年在线、有公网 IP 的服务器，这笔钱要么甲方出、要么自己出，一年一年续下去。很多售前报价时只算了实施那几天的工时，把这笔持续性支出漏掉了，等运维期过半服务器到期没续费，通道说断就断，甲方那头突然连不上人，很难看。报价阶段就该讲清楚：这是一项长期运维成本，不是一次性买断。

第三条：默认状态下，管理后台是关着的，别图省事把它对外打开。 服务端自带一个能看运行状态的网页管理后台，默认只允许本机访问，要从外面看必须自己主动把它改成对外开放，而且用户名密码这两项官方特意标注是可选项——意味着不设的话谁都能进去看。展厅项目上，这个后台不建议对公网开放；确需要看，务必设一个不是"admin/admin"这种默认值的密码，能只对公司网段开放就别对全网开放。

第四条：内网机器和中转站之间这条常驻连接，默认是加密的，但认人这件事得靠一个共享的密令。 两边通信默认走加密通道，不用额外操心"数据会不会被人在半路截走"；但要让中转站认出"这是我自家的机器在连"，靠的是双方配置文件里填的同一段密令（token），这段密令一旦泄露，等于把中转站的大门钥匙给了别人。批量装机时这段密令容易图省事写成弱口令或者到处复制粘贴，交付前务必核对：密令是不是够随机、有没有跟其它项目共用同一个。

第五条：暴露到公网的每一个端口，都要有人管着，别放任自流。 中转站的服务端程序支持限定"只允许对外开放哪几个端口区间"，用来防止端口被滥用成别的用途；这项官方文档里有现成的配置方式，交给运维同事按项目实际需要的端口数量填，别图省事直接放开全部端口范围。

第六条：它和远控软件不是二选一，是可以叠着用的两层。 远控软件解决"我要看画面、点鼠标"，frp 解决"我要把任意一个服务捅到公网上"，两者面对的问题有重叠但不完全一样。如果只是要远程运维一台播控机的桌面，直接上远控软件更省事、门槛更低；如果甲方那边的远控软件因为合规原因用不了，或者你要暴露的是一个网页后台而不是整台电脑的桌面，frp 才是更合适的那一层。有的项目甚至会两层都用——frp 负责打通网络，远控软件在这条通道之上跑桌面画面。

踩坑与排错清单

什么时候别用它

甲方内网明令禁止内网穿透、或要求先过安全审批时。 前面已经反复强调：这条红线不是可以绕过去的技术问题，是流程问题，没拿到书面同意就不要动手。

只是想临时看一眼画面，连都懒得部署服务器时。 frp 要求你自己找一台服务器、自己维护配置，门槛比装一个现成远控软件高得多，纯粹为了"偶尔看一眼"这种需求，不值得为此专门搭一整套。

团队里没人能长期盯着那台中转服务器时。 服务器过期没续费、系统没打补丁被人攻破、密令用了很久没换——这些都是需要有人持续管的事，frp 本身不负责帮你兜底运维那台服务器，扔在那儿没人管迟早出问题。

要暴露的服务本身就不该暴露到公网时。 有些内部系统设计的时候压根没考虑过会被公网访问，权限校验、访问控制都很薄弱，贸然用 frp 捅出去，等于把一个没锁门的房间搬到了大街上。这种情况该做的是先加固那个服务本身的安全性，而不是急着把它连到公网。

与本站的衔接

frp 解决的是"内网机器怎么被外面连到"这一层网络问题，它不管连上去之后具体做什么。想看整条远程运维链路怎么规划，可以从远程运维专题进，那里按"内网／外网""有人值守／无人值守"分了几条不同的路子，frp 属于其中"甲方不给公网 IP"这一条分支的解法。

如果你的场景是甲方机房能开端口映射、或者干脆有现成的公网 IP，那更简单的路子是直接上RustDesk这类现成远控，不需要额外折腾这层网络通道；frp 更适合前面那条路走不通、又必须解决远程运维的场景，两者可以按项目实际情况二选一，也可以叠着用。

把远程运维这件事写进投标方案或者交付文档时，公网服务器谁出钱、密令谁保管、合规报备走没走完这三件事，最好都提前跟甲方谈定、白纸黑字写清楚，可以参考行业方案里各类展厅项目运维章节的写法，比交付后再扯皮省事得多。

从「能连进去」到「先于甲方知道」

远程接入解决的是「我要看到那台机器」，它的价值上限取决于你多快知道该看。展厅出故障到集成商知晓之间，往往隔着甲方发现、内部反馈、打电话这几个环节，延迟以天计。

企服君的运维体系是主动上报模式：设备状态、异常事件由系统推给你，远程接入只是最后的处置手段。集成商如果想把运维从售后成本变成可以向甲方收费的服务，见集成商年费方案。

出处

本文所述的功能定位、部署角色关系、安全默认值与排错方法，均来自 frp 的官方渠道：GitHub 官方仓库的 README 说明（包括反向代理原理、常见误报为恶意软件的说明、管理后台默认行为、认证与加密机制、端口限制配置）、发布页的平台安装包，以及仓库内的开源许可证文件。具体地址见本页出处栏。功能细节与默认值可能随版本调整，以官方仓库文档为准。