用 frp 做内网穿透：3 份配置，和 4 个必然踩到的坑-未来星球

家里那台 NAS 想从外面打开，最省事的做法不是去运营商要公网 IP，也不是在路由器上做端口映射，而是在外面租一台最便宜的小机器，让内网主动连出去。省事和省心，在这里是两件事。

内网穿透最容易出的事故，不是打不通，是打通之后你自己忘了它还开着。这篇文章用 frp 搭一条只走一个域名的通道，三份配置，四个一定会踩到的坑。

环境固定如下：公网侧是一台 1 核 1G 的 Debian 12 云主机，公网地址 203.0.113.10，域名 example.com 已解析；内网侧是一台群晖，Web 管理端口 5001；frp 版本 v0.61.1，服务端和客户端必须是同一大版本，跨版本会因为配置项改名而启动失败。版本不统一，是这类故障里最常见的原因。

1. 先确认你为什么需要它

如果运营商给了公网 IPv4，直接在路由器上把 5001 映射出去就行，多一层跳板只是多一个故障点。需要 frp 的场合只有两类：拿不到公网 IPv4，或者不想在防火墙上开口。

IPv6 是一个容易被忽略的选项。多数地区的家宽已经下发 IPv6 地址，手机流量也支持，如果两端都有 IPv6，直连比任何穿透方案都快。先花十分钟确认 IPv6 通不通，能省掉后面全部工作。

确认不通，再往下走。整条链路是这样的：外网访问 nas.example.com，DNS 指向 VPS，VPS 上的 Caddy 接到 80/443 并终结 TLS，反代到本机 8080，frps 在 8080 上按域名把请求转给内网的 frpc，frpc 再转给 NAS 的 5001。链路清楚了，出问题时才知道该看哪一段。

2. 服务端：frps.toml

从 GitHub Releases 下载 linux_amd64 包，解压后只有一个二进制和一份示例配置。frp 从 v0.52 起只认 TOML，网上大量 INI 格式的教程已经不能直接用。

bindPort = 7000
vhostHTTPPort = 8080
auth.method = "token"
auth.token = "换成一串32位随机字符"
transport.tls.force = true
log.to = "/var/log/frps.log"
log.level = "info"
log.maxDays = 7

四行是关键的。bindPort 是 frpc 连进来的端口，只走 TCP；vhostHTTPPort 是给 HTTP 代理用的入口，按域名分流；transport.tls.force 强制客户端走 TLS，避免 token 在公网上裸奔。其余项都有默认值，只有这四行决定能不能通。

不需要在这里配置证书。证书交给 Caddy，frps 只处理已经解密过的 HTTP 请求，这样证书续期只有一处，不会出现两边都过期的情况。

写一个 systemd 单元，让它开机自启。ExecStart 指向二进制加 -c /etc/frp/frps.toml，Restart 设为 always，RestartSec 设 5 秒。一个没有守护进程的穿透服务，会在某次重启后安静地消失。

3. 客户端：frpc.toml

客户端配置比服务端长，因为要声明每一条隧道。这里只开一条：一条隧道一段配置，新增服务只加一段，不动其他。

serverAddr = "203.0.113.10"
serverPort = 7000
auth.method = "token"
auth.token = "与服务端完全一致"
transport.tls.enable = true
loginFailExit = false

[[proxies]]
name = "nas-web"
type = "http"
customDomains = ["nas.example.com"]
localIP = "192.168.1.20"
localPort = 5001

loginFailExit = false 是这份配置里最容易被删掉的一行。它的作用是首次登录失败时不退出进程，而是继续重试。默认值 true 碰上网络抖动，会让进程直接死掉，而 systemd 反复拉起又反复死，日志里全是同一个错误。

服务端那一侧建议把 log.level 保持 info，不要图清静改成 warn。frp 的连接失败多数只打一行 info，改到 warn 之后，你会看到一条空日志和一个不通的端口。

群晖上不建议用 Docker 版 frpc，套一层网络之后 localIP 的语义会变。直接下二进制，用计划任务或者套件的方式跑，路径写绝对路径。少一层网络抽象，少一类排查不到的问题。

4. 第三份配置：Caddyfile

VPS 上装 Caddy，一行域名一句反代，证书自动申请自动续。这一步的作用不是加密，是把 443 端口和证书从 frp 手里接过来，让穿透只负责转发。证书只有一处，续期就只有一处会出问题。

nas.example.com {
    reverse_proxy 127.0.0.1:8080 {
        header_up Host {host}
        header_up X-Real-IP {remote_host}
    }
}

header_up Host 这一行决定 frps 能不能认出你要访问哪个隧道。frp 的 HTTP 代理靠 Host 头做域名匹配，Host 被改写成 127.0.0.1 之后，请求会落到 404 页面。这一行写错，症状是 404，不是 502。

Caddy 需要 80 和 443 都能从公网进来。云厂商的安全组和机器上的 ufw 是两道独立的门，只改一处，另一处仍然会把 ACME 的验证请求挡在外面。

5. 验收：三步确认真的通了

  1. 在 VPS 上看 frps 日志，出现 client login info 且带 nas-web 的隧道名，说明 frpc 已连上。
  2. 在任意一台外网机器上访问 https://nas.example.com，看到群晖登录页，说明域名分流和反代都对。
  3. 把内网 frpc 停掉，再访问一次，应该得到 502 而不是超时。502 说明链路存在、只是后端掉了；超时说明 7000 端口根本没通。

第三步是最有价值的排查手段。能区分「隧道断了」和「后端挂了」，比看十页日志都快。

6. 四个必然踩到的坑

坑一：customDomains 和 subdomainHost 不能同时用。服务端一旦配置了 subdomainHost，客户端再用 customDomains 就会报 domain is not supported。二选一，选完就别改，否则所有隧道都要跟着调。

坑二：token 首尾的空格不算空格。从密码管理器复制过来时常带一个不可见字符，frpc 报 authorization failed，两边的字符串肉眼看完全一样。用一个纯字母数字的 32 位串，能省掉半小时。

坑三：localIP 写 127.0.0.1，服务却在另一台机器上。frpc 所在的主机和 NAS 不是同一台时，127.0.0.1 指向的是运行 frpc 的那台机器。这个错误不会报错，只会一直 502。

坑四：VPS 的带宽是按 bit 算的。1 Mbps 的入门机型，实际下载速度约 128 KB/s，传一个 200 MB 的文件要半小时以上。穿透适合看页面、传小文件，不适合当网盘用。按 128 KB/s 算，一张 5 MB 的照片要四十秒，这是它的物理上限。

7. 安全边界：哪些东西不该透出去

frp 转的是端口，不是权限。你把 5001 透出去，等于把一个只做了密码验证的管理页面挂到了公网上，全世界都会来试。

  • 不要透 SSH 的 22 端口，需要远程运维就上 Tailscale 之类的点对点方案。
  • 不要透数据库端口，MySQL 和 Redis 在公网上被扫到只是时间问题。
  • 群晖务必开两步验证，并把自动封锁打开。
  • 隧道名带业务含义，别用 test、tmp，三个月后你自己也认不出。
  • 给 frps 加 allowPorts，只放行你真正用的端口段。

如果内网要透的不止一台机器，不要另起一个 frpc 进程，直接在同一个文件里加第二段 [[proxies]]，换个 name 和域名，localIP 指向另一台。一个进程能带几十条隧道，进程越多，出问题时越难定位。

写在最后

很多人把内网穿透理解成「把家里的机器暴露到公网」。实际发生的事正好相反：是把一台公网机器变成了内网的延长线。风险不在那条加密隧道上，而在隧道尽头那台机器的管理页面上。

这也是为什么这套东西装好之后，最该做的一件事不是继续加隧道，是回头看一眼你刚打开的那扇门后面，放的是什么。装好只是开始，收敛暴露面才是收尾。

你现在用的穿透方案是哪种？有没有遇到过连上了但一直 502 的情况？