如何在集群内搭建frp服务器，具体操作步骤是什么？

在集群内搭建frp服务器，核心思路是部署一个高可用的frps服务端，再通过负载均衡或DNS轮询将流量分发到集群节点，客户端只需配置一个统一入口地址。这套方案能解决单点故障问题，同时让内网穿透服务具备横向扩容能力，本文基于frp v0.52以上版本，帮你梳理完整的搭建路径。

frp服务器集群搭建前的准备工作

在动手之前,你得先搞清楚集群里每个节点的角色分配，frp的架构本身是C/S模式，服务端frps负责接收客户端连接并转发流量，客户端frpc负责主动建立隧道，集群场景下，frps要跑在多个节点上，frpc则可以部署在任意需要穿透的内网机器中。

加载中

frp内网穿透服务端搭建（包括安全组打开）

星空Nightsky

7647-

原视频地址

网络与端口规划

frps默认监听7000端口作为bindPort,这是客户端连接用的，另外需要预留一个HTTP端口（常见用8080）和HTTPS端口（常见用8443）来转发web流量，如果你有自定义TCP或UDP服务，每个隧道都要单独占用一个公网端口，集群场景下，这些端口需要在所有节点上保持一致，并且通过负载均衡器统一暴露。

端口分配建议用表格整理清楚：

• bindPort（客户端通信）：7000
• vhostHTTPPort（HTTP穿透）：8080
• vhostHTTPSPort（HTTPS穿透）：8443
• 自定义隧道端口：根据业务需求预留段，比如9000-9100

业内专家指出，集群规模较小时，直接用轮询模式分发流量即可；节点超过三台后，建议引入健康检查机制，避免把请求打到宕机节点上。

配置文件基础项

每个frps节点的配置差异只体现在bindAddr和serverAddr上,其他核心参数保持一致，基础配置片段如下：

# frps.toml
bindPort = 7000
vhostHTTPPort = 8080
vhostHTTPSPort = 8443
auth.token = "your-cluster-token"
transport.tls.force = true

这里tls.force必须开启，集群内节点通信默认走TLS加密，能避免token明文传输的风险，transport.tls.trustedCaFile如果内部有CA体系也可以配置上，没有就用默认的自签名证书。

frp高可用集群的两种主流方案对比

集群的核心诉求是“挂了能切换”，目前用得最多的方案是负载均衡前置和VIP漂移两种，你要根据自己的基础设施选。

负载均衡器前置frps集群

这是最直接的frp服务器集群搭建方案,用Nginx或HAProxy在frps节点前面做四层负载转发，客户端连接7000端口时，负载均衡器会把请求分发到后端的多个frps节点。

具体操作路径如下：

1. 在负载均衡器上配置TCP转发规则,监听7000端口，后端指向三台frps节点的7000端口。
2. 设置健康检查,定期探测frps节点的7000端口连通性，失败节点自动摘除。
3. 客户端frpc配置里,serverAddr填写负载均衡器的虚拟IP或域名，serverPort填写7000。

这种方式的好处是frpc不用感知后端节点的变化,坏掉一个节点，负载均衡器自动把流量切到其他节点，缺点是负载均衡器本身成了单点，你还需要给LB做双机热备。

keepalived实现VIP漂移

如果你的集群规模不大,只有两台frps节点，用keepalived更轻量，让两台机器共用一个VIP，正常情况下流量全部打到主节点，主节点宕机后VIP自动漂移到备节点。

需要注意frpc的会话保持问题,frpc建立TCP长连接后，连接断了会自动重连，VIP漂移期间，已有隧道会断开，但frpc的重连机制会很快恢复新连接。

keepalived配置要点

• 主备节点的keepalived配置里,virtual_ipaddress要填同一个IP
• 检测脚本检查frps进程是否存在,不存在就重启，重启失败则降级
• 建议配合dnscheck,确保frps进程僵死时也能触发切换

frp集群的分布式状态同步怎么处理

frp官方版本默认不提供集群状态同步,每个frps节点是独立的，这意味着frpc连接到不同节点时，隧道配置互不可见，行业共识认为，较合理的做法是让客户端配置保持一致，哪个节点接收连接就在哪个节点创建隧道，隧道本身无状态，断开后重连到其他节点也能正常工作。

配置分发策略

你需要把frpc.ini或者frpc.toml下发到所有需要穿透的客户端机器上，保持统一配置，对于TCP隧道，frpc连接哪个frps节点，该节点就会开放对应的端口，要做到这一步，你需要确保所有frps节点预留的端口范围一致，并且没有被本机其他服务占用。

配置模板样例

# frpc.toml
serverAddr = "lb.example.com"
serverPort = 7000
auth.token = "your-cluster-token"
[[proxies]]
name = "web"
type = "http"
localIP = "127.0.0.1"
localPort = 80
customDomains = ["app.example.com"]

每个客户端配置完全一致,通过负载均衡器的统一入口连接到frps集群，这样一个节点挂了，新连接自然被分发到存活节点，隧道自动恢复。

frp集群搭建教程里的TLS证书配置

集群场景下,TLS证书一般配置在负载均衡器或frps节点上，两种做法各有优劣。

证书放在frps节点

当frps的vhostHTTPPort和vhostHTTPSPort收到请求时,会根据customDomains域名匹配TLS证书，你需要把证书文件放到每个frps节点上，或者在frps配置里指定证书目录：

[[domains]]
domain = "app.example.com"
certFile = "/etc/frp/certs/app.crt"
keyFile = "/etc/frp/certs/app.key"

这种做法的好处是frps直接处理HTTPS解密,负载均衡器可以做四层转发不用关心证书，缺点是证书文件需要在多节点间同步，更新证书时所有节点都要改。

证书放在负载均衡器

如果负载均衡器同时兼任七层转发,比如使用Nginx，那TLS终止在LB层，frps只拿到明文HTTP流量，这时候frps里不需要配置证书，但vhostHTTPPort要打开，同时customDomains仍然要配置。

行业共识认为,对多域名穿透场景，证书放在frps节点更省事，因为LB层只维护一条四层转发规则就够了。

frp集群压测与性能调优参数

frp单节点能承载多少并发,很大程度上取决于传输插件和带宽，frp官方文档给出的连接池参数值得参考：

• transport.poolCount控制每个连接复用连接池数量，默认5，并发高可以调到20
• transport.maxPoolCount是连接池上限，设置太大反而增加内存开销
• userConnTimeout控制空闲连接超时时间,默认10秒，长连接业务可以调大到60

建议在集群搭建完成后做一轮真实环境压测,用frpc生成并发连接流量，观察frps节点的CPU和内存占用，如果单节点CPU使用率持续超过70%，就该考虑加节点或拆分隧道。

frp内网穿透集群搭建后怎么验证可用性

搭建完成后,验证步骤别跳过，分三层来检查：

1. 连接层验证：在客户端执行frpc verify命令（frp v0.52以上版本支持），确认能连上负载均衡器的7000端口并完成鉴权。
2. 隧道层验证：从外网访问一个HTTP穿透域名，确认能正常返回内网服务的响应。
3. 故障切换验证：手动杀掉一个frps节点进程，观察客户端是否自动重连到其他节点，服务中断时间是否在可接受范围内。

据统计，多数集群故障排查问题出在token不一致或端口被防火墙拦截，这两项检查优先级最高。

frp服务器集群搭建常见问题排查清单

客户端连接报错EOF

通常是TLS版本或token不匹配,检查frpc和frps版本是否一致，token是否完全相同，frp v0.52后配置格式改为TOML，老版本INI格式不兼容，升级后配置要重写。

HTTP穿透返回502

frps能收到流量但转发失败,可能是vhostHTTPPort没开，或者customDomains配置的域名没解析到frps节点，在集群里还要确认负载均衡器的转发规则同时覆盖了7000和8080端口。

多节点出现端口冲突

自定义TCP隧道经常遇到这个问题,解决思路是给每个frps节点分配不同网段的虚拟IP，端口可以复用；或者统一规划端口段，避免某些节点未预留导致冲突。

Q&A：frp集群相关疑问解答

frp的token只能有一个吗，能否按节点分配不同token

frp官方实现里token是全局认证信息,配置在frps的auth.token字段，所有frpc用同一个token连接，如果集群中每个节点用了不同token，frpc无法自动切换节点，你只能在应用层做隔离，比如不同业务的frpc使用不同frps实例，token才能分开设置。

frp服务端带宽跑满，是单节点瓶颈还是集群能解决

frp本身不限制带宽,性能瓶颈通常在ECS实例的带宽规格，集群方案能缓解CPU和内存压力，但若出口带宽被占满，加节点无济于事，需要升级带宽或改用流量分发的负载均衡策略，云厂商的共享带宽包方案在带宽紧张时更具性价比。

frp集群节点分布在同地域还是跨地域部署

对延迟敏感的业务建议部署在同地域,同可用区最佳，跨地域部署会引入额外的公网延迟，同时在VIP漂移或负载均衡调度时，跨地域的转发链路不可控因素更多，如果容灾要求高，可以采用同地域多可用区形式，效果满足需求且运维成本可控。

最后说回整个frp服务器集群搭建过程：务必将token、TLS、绑定端口统一定义成基础设施标准，所有节点按同一套规范落地；故障切换靠负载均衡或VIP漂移，业务稳定性靠配置一致性，按这套思路下来，frp集群的可用性完全能对标小规模商业内网穿透服务。