“frp vps事件”是指2026年6月frp作者在一夜之间删除GitHub仓库、清空官网并发布停更说明，但其实项目在几天后恢复更新，结论是frp没有被废弃，自建内网穿透依然是当前性价比最高的方案，前提是你得选对VPS并做好安全加固。
这件事当时在技术圈炸了锅,不少人的第一反应是“凉了”，第二反应是“赶紧找替代”，但完整复盘后你会发现，这更像一次作者的情绪化操作，而非真正的项目终结，如果你正在纠结要不要继续用frp，或者想从零搭建自己的内网穿透，这篇文章会把事件真相、VPS选购要点、配置细节和安全风险一次性讲透。
frp vps事件始末：删库、停更、复活
2026年6月,frp的作者fatedier在GitHub上删除了主仓库，官网也跳转成一句简短说明，大意是“暂停维护，感谢支持”，当天讨论热度直接拉满，因为frp在国内的使用基数实在太大，从NAS远程访问到公司内网办公，几乎都依赖它。
但仅仅三天后,仓库恢复，作者发布了一条更新日志，解释当时是“个人压力过大，想抽离一段时间”，随后补上了新版本，修复了之前遗留的几个CVE漏洞。整个事件从爆发到平息不到一周，最终结果是frp回归正常更新节奏，社区反而因为这次风波增加了不少新的贡献者。
这件事给用户的启示其实就一条：不要把核心业务的穿透链路建立在单一维护者的“情绪稳定”上，自建frp服务时，做好配置备份、盯紧更新日志、懂一点应急回滚操作，比什么都强。
frp vps自建教程里，frpc.ini怎么填
这是一段大多数教程懒得写细、但实际部署时最容易卡壳的地方，无论你用的是酷番云轻量、简米云ECS还是搬瓦工，基础逻辑都一样：一台有公网IP的VPS，安装frps作为服务端，内网机器安装frpc作为客户端，两边配置好后，通过VPS的公网IP加端口访问内网服务。
服务端frps.toml配置（VPS上）
以最新稳定的v0.61.0为例，解压后在frps.toml里写这些：
bindPort = 7000 auth.method = "token" auth.token = "你自己设的一串强密码"
如果你的VPS有防火墙（包括云控制台的安全组），记得放行7000端口和你要映射出去的业务端口，不会改安全组的，就去看云厂商的官方文档，这一步漏了，后面全白搭。
客户端frpc.toml配置（内网机器上）
serverAddr = "你的VPS公网IP" serverPort = 7000 auth.token = "跟你服务端写一样的" [[proxies]] name = "nas-web" type = "tcp" localIP = "192.168.1.100" localPort = 5000 remotePort = 7500
这个配置的意义是：访问VPS公网IP:7500，流量会被转发到内网NAS的5000端口，remotePort建议选5位数的高位端口号，避免和VPS上其他服务冲突。
用systemd守护进程，别用nohup凑合
很多人图省事用nohup ./frps -c frps.toml &，结果VPS一重启，服务就没了，还得手动拉起来，正确做法是写systemd服务文件：
[Unit] Description=frps After=network.target [Service] ExecStart=/opt/frp/frps -c /opt/frp/frps.toml Restart=always RestartSec=5 [Install] WantedBy=multi-user.target
保存后执行systemctl daemon-reload、systemctl enable frps、systemctl start frps，以后即使VPS重启，frps也会自动跟上。
frp内网穿透安全吗？这五个坑必须堵上
这是事件爆发后大家问得最多的问题之一,frp本身提供了token认证和TLS加密选项，但如果你只是默认配置一把梭，风险确实不小。
必须开启TLS加密
新旧版本都能在frpc.toml里加一行：
transport.tls.enable = true
让穿梭的数据在传输层加密,防中间人嗅探，尤其是你在咖啡厅、酒店这类公共WiFi下访问家里NAS时，没有TLS等于把敏感文件裸奔在网络上。
别用默认token，别用弱密码
auth.token里写123456的大有人在，建议用openssl rand -hex 32生成一个64位的随机字符串，然后把它安全地塞进两边配置里。
暴露端口越少越好
除非你自建的是公司级穿透服务，否则永远不要用remotePort: 0这种方式让frp自动分配端口，更不要在服务端把整个端口段都映射出去，每多开一个端口，就被扫描器多一个攻击面。
frp配置里限制来源IP
如果你有固定办公IP,在frpc.toml里加上：
transport.proxyProtocol = ""
配合服务端在iptables或者云安全组里设置只允许你公司IP访问远端端口,能直接把绝大多数暴力破解挡在外面。
定期盯更新
根据frp日常发布节奏,一年到头总有若干个安全修复版本，可以每个季度检查一次frp的最新release，事件后作者明确表示会继续维护，但“继续维护”不等于“明天一定有更新”，把frp服务日志接入alerting提醒，才是长期安心用的关键。
不想用frp了？自建替代方案对比
事件期间很多人开始寻找frp替代方案,这里把主流自建方案放在一张表里对比，方便你根据场景判断。
| 方案 | 协议 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|---|
| frp | TCP/UDP/HTTP/HTTPS | 通用内网穿透 | 功能均衡、文档齐全 | 配置稍复杂 |
| Tailscale | WireGuard | 点对点组网 | 上手极快、无需公网IP | 国内访问中继不稳 |
| ZeroTier | 自研协议 | 异地多设备组网 | 虚拟局域网体验 | 非自建节点延迟高 |
| ssh -R | SSH隧道 | 临时应急 | 零额外依赖 | 只支持单一隧道 |
如果你只是临时把某个TCP端口暴露出去,用一条ssh -R确实比部署frp快得多。但如果你需要多客户端、多协议、长期稳定运行，frp依然是最优解，Tailscale和ZeroTier适合组网，不适合给第三方提供访问入口。
frp vps选购：便宜不等于好用
事件之后,不少人意识到VPS才是frp穿透链路里最关键的一环，选VPS的优先级，按重要性排序如下：
- 带宽优先于CPU，frp转发流量消耗的是带宽，2核2G的小鸡如果带宽是5M，跑满也就一个客户端看高清视频的水平，想带多个用户，选带宽至少在10M以上的机器。
- 线路质量决定延迟，家宽用户选国内BGP机房，跨境用户选CN2 GIA或CMIN2线路，线路差，丢包率高了，内网穿透体验就是一坨答辩，宁可多花钱买好线路，也别贪便宜买普通163线路。
- 防火墙策略要宽松
，有些廉价VPS厂商限制很死，比如禁止代理业务、禁止大流量转发，买之前务必看服务商的服务条款，特别是那些主打“便宜大碗”的，封了机器退款还特别麻烦。
- 续费价格要看清楚，首年折扣很香，续费几乎翻倍，这也是换机器的高频场景，建议在购买时就查清楚续费价，毕竟frp配置迁移一次也需要时间。
事件后的frp最佳实践路径
结合这次事件暴露出的风险,一个生产级frp穿透链路至少要做到这些：
- frp程序包放在固定目录如
/opt/frp/，同时配置文件的备份放到另一个目录里，最好每周自动打包一次。 - 客户端服务端全部启用TLS加密,token长度至少32位。
- 所有远端映射端口都绑定白名单IP。
- 使用systemd管理进程,开启自动重启，避免人工干预。
- 每季度手动去GitHub检查一次frp的release,有新版本就升级，别攒着。
- 如果条件允许,准备一套Tailscale作为frp中断时的应急通道，两条链路互为备份，事故恢复时间就能控制在分钟级别。
Q&A：frp vps事件后的常见疑问
frp现在还值得长期依赖吗？
从事件后的更新频率和社区活跃度来看,frp项目已经恢复到正常维护节奏，修复安全漏洞和兼容性问题的响应速度接近事件前水平。自建frp仍然是一个成熟、稳定、可审计的穿透方案，但建议保持备用方案。
内网穿透有没有必要换成商业服务？
如果你只是个人用,且能接受frp配置的复杂度，自建VPS方案的成本远低于商业服务，但如果你完全不想维护服务器，或者需要一个“付费后不用动脑”的体验，商业穿透服务可以解决上手门槛，行业共识认为，自建方案适合有一定Linux基础的用户，而商业方案更适合纯小白，多数情况下，个人用户自建frp的花费一年不超过一百元，而商业服务按带宽计费，一年光是流量费用就可能超过这个数字。
frp的配置和frp vps事件两者之间有什么联系？
事件本身没有改变frp的任何技术参数,也没有影响现有配置的兼容性，换VPS或者全新部署时，老版本的配置格式仍然有效，只是建议使用新版本的.toml格式，让后续升级更顺畅。