家里的树莓派要对外提供服务，内网穿透是绕不开的。这两年我先后用过 frp（以及 ChmlFrp 这类免费面板）和 Cloudflare Tunnel，最近做了一次彻底的梳理，把 frp 全面退役了。聊聊两者的取舍。
frp：灵活，但运维成本在自己身上
frp 的模型是自己（或第三方面板）提供一台有公网 IP 的服务器做中转：
[web]
type = http
local_port = 3000
custom_domains = xxx.example.com优点：
- 协议自由，TCP/UDP 什么都能转发，打游戏开服也行
- 延迟取决于中转服务器位置，选得好可以很低
痛点：
- 免费面板的节点说没就没，配置漂移、隧道失效是常态
- 需要自己写 watchdog 脚本盯着进程，掉了自动拉起
- HTTPS 证书、域名解析都要自己操心
我实际的使用体验：watchdog 脚本写了，定时任务配了，但隧道还是时不时"配置文件与记录不匹配"，排查成本越来越高。
Cloudflare Tunnel：把运维外包给 CF
cloudflared tunnel create my-tunnel
cloudflared tunnel route dns my-tunnel app.example.com- 出站连接，不要公网 IP 不开端口，NAT 后面也能用
- HTTPS 证书自动，DNS 自动，断线自动重连
- 一个 tunnel 挂 N 个子域名，加路由只改一个 yaml
代价：只适合 HTTP(S) 为主的场景（TCP 也支持但要装客户端），而且你的流量全过 Cloudflare——信任模型自己权衡。
我的结论
个人 Web 服务：无脑 Cloudflare Tunnel，省下来的心智成本远超一切。frp 留给真正需要裸 TCP 转发的场景——如果没有这种场景，就干脆删掉，少一个服务就少一个故障点。
退役 frp 那天顺手删掉了 watchdog 脚本、定时任务和三份散落在不同目录的 frpc.ini。基础设施也需要断舍离。