为什么放弃 FRP 选了 Lucky：一次工具选型心路

为什么放弃 FRP 选了 Lucky：一次工具选型心路

家里这台群晖 NAS 跑了三四年，上面挂的东西越来越多：博客、相册、文件分享、下载器、监控面板，全都要从外网访问。内网穿透这件事，我最早用的是 FRP，后来换成了 Lucky。不是 FRP 不好，而是我的需求变了，工具没跟上。

这篇不讲部署步骤，只讲一次真实的选型心路：当初为什么选 FRP、后来哪里不顺手、换 Lucky 之前我列了哪些需求、又是怎么验证的。如果你也在 FRP 和 Lucky 之间纠结，希望这篇能帮你少走点弯路。

一、先说背景：我用 FRP 的那两年

2024 年刚把博客和几个服务搬上 NAS 时，我用的是 FRP。老牌开源方案，文档全、教程多，群晖上用 Docker 跑一个 frpc 客户端，配好 frpc.ini，指向一台有公网 IP 的 VPS，几分钟就能把服务穿出去。

那两年 FRP 跑得很稳，博客、相册、文件分享都走它，VPS 上一个 frps 服务端带五六个隧道，没出过什么大问题。说实话，如果需求一直停在“穿出去就行”，FRP 完全够用，我也不会换。

转折点出现在服务越挂越多之后。每次加一个新服务，都要改 frpc.ini 加一段配置、重启容器、去 VPS 上确认端口。改一次两分钟，不麻烦，但改十次就烦了。更关键的是，有一次我手滑把配置文件里一个端口写错，重启后博客和相册一起断了，排查了半小时才发现是自己改错了行。

那一刻我意识到：问题不是 FRP 不稳定，而是我的使用方式已经超出了“改配置文件”这种模式的舒适区。我需要一个能看得见、改得快、出错能立刻发现的管理方式，而不是每次靠文本编辑器和重启碰运气。

二、换之前，先把需求写下来

选型最忌讳凭感觉。换之前，我先把自己的真实需求列了一张表：

• 多服务、多域名：NAS 上七八个服务，每个都要独立域名和 HTTPS，不能共用一个端口硬凑。
• 改配置要快：加一个服务、改一个端口，最好在网页上点几下就完成，不用 SSH 进容器改文件、重启。
• 证书要自动：HTTPS 证书到期要自动续，不能靠我每三个月想起来手动续一次。
• 能看到状态：哪个隧道通、哪个断了、流量走了多少，最好一眼看得到，出问题不用先猜。
• 维护成本低：家里这台 NAS 是 7×24 小时跑的，我不想每周都花时间伺候穿透工具，越省心越好。
• 留退路：新工具如果水土不服，要能在一小时内切回 FRP，不能把全家服务押在一个没验证过的方案上。

列完这张表我才发现，FRP 能满足前两条的一半：它能穿多服务、也能配 HTTPS，但“改配置要快”“能看到状态”“证书自动”这三条，它天生就不擅长。FRP 的设计哲学就是“配置文件即全部”，稳定、透明、可脚本化，代价就是一切都要手改文件、重启生效。这不是 FRP 的缺点，是它的定位。只是我的需求变了。

三、为什么是 Lucky，不是别的

当时摆在我面前的选择有三个：继续用 FRP、换 Lucky，或者试试 ECH（Cloudflare 隧道那套）。三者我之前都实测过，结论写在《Lucky / FRP / ECH 三种内网穿透实测对比》里：延迟上 FRP 和 Lucky 差不多，ECH 免费但节点和稳定性要看运气。

这次选型我换了一个判断标准：不再只比延迟和成本，而是按上面那张需求表逐项打分。

• 改配置：Lucky 带 Web 界面，端口转发、反向代理、域名绑定都在网页上点几下完成，改完即时生效，不用重启容器，直接命中我最痛的地方。
• 证书：Lucky 内置 ACME 自动申请和续期，域名解析过去之后，证书自己申请、自己续期。我之前为证书单独写过同步脚本，换了 Lucky 之后那套脚本直接退役了。
• 状态可见：Lucky 的管理界面能看到每条转发规则的状态，断了就是断了，不用先 SSH 再查日志。
• 反代能力：Lucky 本身就是一个反向代理，多域名、多服务、路径分流都能在一个地方配齐，NAS 上的服务统一从它进出，架构反而比“FRP 穿透 + 另外一个反代”更简单。
• 成本：Lucky 和 FRP 一样开源免费，部署同样是 Docker 一个容器，迁移成本就是把规则从配置文件抄到网页上，一个晚上能做完。

ECH 我认真考虑过，但它依赖 Cloudflare 的网络，对我这种要稳定访问家里摄像头和 NAS 管理界面的场景来说，多一层不确定因素。免费是真免费，不可控也是真不可控。我的结论是：ECH 适合做备用通道，不适合当主力。

所以最后的决定是：主力切到 Lucky，FRP 的服务端和客户端配置原样保留一个月，当作回滚预案。

四、切换过程：一个晚上，平滑完成

切换我分了三步走，没敢一次性全切：

第一步：先搭 Lucky，不动 FRP。 在群晖 Container Manager 里新建一个 Lucky 容器，先把一个不重要的服务（下载器的 Web 界面）切过去跑两天，验证反代、HTTPS、证书续期都没问题。

第二步：逐个服务迁移。 按“先边缘、后核心”的顺序迁移：先是文件分享、监控面板这类影响小的，最后才是博客和相册。每个服务切过去后，立刻从外网打开验证一遍，确认没问题再迁下一个。整个过程里 FRP 一直在跑，任何一个服务出问题，改回域名解析就能立刻恢复。

第三步：观察两周，再拆 FRP。 全部服务切完后，我没有马上删 FRP，而是让它空跑了两周。这两周里 Lucky 经历了两次 NAS 重启、一次宽带断线重拨，都自动恢复了，证书也正常续了一次。确认稳定后，才把 FRP 的容器停掉，配置文件备份存档。

整个切换没有一次全家断网，最长的一次单服务中断是博客切域名解析的几分钟，还是我自己手快改错了记录，改回来就好了。

五、用了半年之后，诚实地说说 Lucky 的短板

选了 Lucky 不代表它完美。用了半年，短板也得如实写出来：

• 界面是强大，但也是负担：Lucky 的功能非常多，第一次打开管理界面，菜单密密麻麻，新手容易不知道从哪下手。FRP 的配置文件虽然原始，但至少一眼能看全。
• 出了问题，排查要进界面：FRP 出问题看日志文件就行，Lucky 出问题要先打开管理界面，再找对应的规则和日志。对习惯命令行的老手来说，这一步反而多绕了一圈。
• 版本更新要自己盯：Lucky 更新不算频繁，但也没有 FRP 那种“几年不动也稳”的气质。大版本升级前，最好先看一眼更新说明，别无脑点更新。

这三条没有一条是致命的，但如果你是那种“配好一次、五年不碰”的用户，FRP 反而更合适。工具没有高下，只有适不适合当下的你。

六、我的结论：选型看需求，不看名气

这次选型最大的收获不是“Lucky 比 FRP 好”，而是想明白了一件事：工具的优劣是相对的，锚点是你自己的需求清单。

• 如果你只有一两个服务要穿透，配置改得少，FRP 依然是最稳、最省心的选择。
• 如果你的服务越来越多，改配置越来越频繁，又想要证书自动续、状态一眼可见，那 Lucky 值得换。
• 如果你追求零成本、不在乎多一层不确定性，ECH 可以当备用通道，但别当唯一主力。

顺便提醒一句：站内 2024 年写的 FRP 客户端部署旧文（用 Docker 跑 frpc、接免费 FRP 服务那套）现在看流程还能跑通，但思路已经过时了——免费 FRP 服务的稳定性、端口限制和现在的需求对不上号，如果你是新上手，建议直接按本文的思路先列需求、再选工具，不要照着旧文一步步抄。

选工具和选人一样，没有完美的，只有合适的。FRP 陪我跑了两年，功劳簿上有它一笔；Lucky 接过下一棒，是因为下一程的路变了。下一程路再变的时候，我还会再列一次需求表。

相关旧文

• Lucky / FRP / ECH 三种内网穿透实测对比：延迟、成本、稳定性怎么选：https://www.yeyhome.com/2026/10/14/268.html
• lucky证书更新群晖自动同步：https://www.yeyhome.com/2026/10/25/296.html
• Lucky 反代宝塔面板 — Docker macvlan + bridge 双网络解决方案：https://www.yeyhome.com/2026/02/26/68.html
• 群晖 DSM 7.2 Container Manager 迁移避坑：从旧 Docker 平滑搬家：https://www.yeyhome.com/2026/11/05/304.html