深夜踩坑记：frp内网穿透报错，我是怎么一步一步爬出来的

凌晨三点，本应该是睡得最香的时候，我却盯着终端里一片红色的报错信息，咖啡都凉了。事情是这样的，我想在家里那台小主机上搭个服务，方便在外面也能访问，于是自然而然地想到了 frp。这东西用起来确实香，配置也不复杂，但架不住偶尔抽风。今天这篇文章，就把我这次遇到的报错和排查思路记录一下，希望能帮到同样在深夜抓耳挠腮的你。

最开始，我按照惯例在云服务器上跑 frps，在家里主机上跑 frpc。结果 frpc 一启动就直接给我甩脸子，报了一个 dial tcp xxx:7000: connect: connection refused。翻译成人话就是：连不上服务器的 7000 端口。遇到这种问题，第一反应肯定是网络不通。我先在本地 telnet 了一下服务器的 7000 端口，果然不通。

于是我开始排查。第一，检查云服务器的安全组。好家伙，之前扩容的时候把安全组规则重置了，7000 端口根本没放行。赶紧加了一条 TCP 放行规则。第二，检查服务器上的 frps 有没有真正在监听。用 ss -tlnp | grep 7000 看了一眼，发现 frps 进程是活的，端口也在监听，心里踏实了一半。

本以为这下总该好了吧，结果 frpc 换了个报错：authorization failed。这个就更好理解了，服务端和客户端的 token 不一致。我翻了下 frps.ini 和 frpc.ini，发现自己在服务器上改了 token，但家里那台的配置文件还是老的。改完重启，终于看到那个让人感动的 start proxy success。

正当我准备收工睡觉的时候，访问服务又给我来了个 502。得，接着查。这次是 frpc 日志里报 connect to local service failed。问题出在内网服务本身的配置上，我本地服务的监听地址是 127.0.0.1，但 frpc 默认走的是容器或者主机网络，有时候对 localhost 的解析会有偏差。改成 127.0.0.1 或者直接写内网 IP，再重启，终于一切正常。

总结一下，frp 报错其实来来去去就那么几类：连不上服务端、认证失败、本地服务连不上。排查顺序建议是：先通网络（安全组、防火墙、端口监听），再对配置（token、端口、协议），最后查本地服务（监听地址、端口）。别一上来就怀疑 frp 有 bug，十有八九是咱们自己环境的问题。

希望这篇深夜踩坑记能让你少走点弯路。如果你也遇到过更奇葩的 frp 报错，欢迎评论区交流，咱们一起把坑填平。晚安，不对，早安。