很多自托管服务悄悄长在"家里的群晖"或"公司的内网"这类没有公网 IP 的地方。想把它们对公网开放、或在别处访问它们，传统换公网 IP 太重，端口映射在运营商 NAT 下又常失效。Frp 用"一台有公网 IP 的 VPS 当中转 + 内网机器主动出连建隧道"的思路解决了这个问题：内网机器主动连出去的连接不会因 NAT 而断，公网的访问经由 VPS 转发进内网。这篇讲清架构、配置、场景与安全边界。
一、原理：主动出连，绕开 NAT 的方向性限制
从根上说，问题在于"内网机器没有对外可达的地址，公网怎么找它"。Frp 的答案是把建链方向反过来：内网里跑一个 frpc（客户端），先主动连到公网 VPS 上的 frps（服务端），建立一条长连接；当公网有人访问 VPS 的某个端口时，frps 把流量从这条已建立的隧道转给 frpc，frpc 再送往内网目标。因为隧道是内网主动建立的，运营商 NAT 也就无从"断开进向连接"——这正是 Frp 比端口映射稳的原因。
本质上 frps 是一个"入站流量接驳点"，frpc 是"出站隧道 + 内网转发"。你只需要一台公网 VPS 做这两层，内网各台机器各自起 frpc 即可。理解这个单向建链模型，后面配置里的 role 概念就不会乱。
二、服务端（frps）最小配置
# /opt/frp/frps.toml
bindPort = 7000
token = "一个较强的共享密钥"
dashboardAddr = "127.0.0.1"
dashboardPort = 7500用 Docker 或在 VPS 上直接跑 frps，bindPort 是隧道端口（7000），token 是 frpc 连接时对身份的共享密钥，务必用一个强随机串，dashboard 只绑 127.0.0.1 方便现场看但别暴露到公网。frps 的配置通常很短，因为它只负责"接隧道、转流量"，真正把哪个内网服务暴露在哪个端口，是在每个 frpc 端声明。
三、客户端（frpc）：把内网某个服务"搬"到公网端口
# /etc/frp/frpc.toml
serverAddr = "vps.example.com"
serverPort = 7000
token = "同一个共享密钥"
[[proxies]]
name = "nas-web"
type = "http"
localIP = "192.168.1.100"
localPort = 5000
customDomains = ["nas.example.com"]这段是说：把内网群晖的 5000 端口，通过 nas.example.com 这个域名向外提供（frps 会把该域名的 HTTP 流量转发进隧道）。type 有三种常用：http / https（按域名分发流量的 L7 转发）、tcp / udp（端口直通的 L4 转发，适合 SSH、非 HTTP 服务）。要能解析 nas.example.com，把它的 CNAME 或 A 记录指到 VPS 公网 IP 即可。多个内网服务用不同域名或不同端口，就能在一个 frps 基础上把各个服务清晰分隔、互不干扰地开放。
四、经典场景：把家里 NAS / 公司内网开出来
三个最常碰到的用法：一是访问家里 NAS 的 Web 端与同步端口（用 http/tcp 混合）；二是把"仅在 LAN 能用的开发机"给远程同事访问（tcp 暴露某个端口）；三是做内网穿透的"串联"——如果家里还有另一台没公网段的机器，可以让它通过frps 中转后二次穿到内网。这几个场景里，transport.proxyProtocol 或"真实客户端 IP 传递"是容易踩的点：frps 记录到的访客 IP 默认是 VPS 自己的，若不透传真实 IP，下游的访问日志/限流/防火墙都会"以为是同一台机器"。
五、安全边界：穿透是把"刀"，要配"鞘"
Frp 暴露的其实是"内网服务的入口"，所以要奉行安全第一原则：不要用默认 token，不要把高权限服务（SSH 22、数据库 3306）裸穿透到公网；优先用 http 类型的域名 + 前置认证（如果走 Traefik，可在 frps 前面再叠一层 BasicAuth/TLS），而不是直接把数据库端口 tcp 裸开。穿透后对外入口的安全性 = 内网服务自身安全性 + 这层转发那侧的保护，少一层就少一层纵深，别只图"打通了"。
六、排障与性能：隧道通了不代表"访问顺畅"
Frp 的故障分两层要分开看：隧道是否建立（frps 与 frpc 握手成功、frps -c 日志无报错），查看 frps dashboard 或客户端日志；公网到隧道是否可达（VPS 防火墙放行对应端口、DNS 解析正确、frps 的 bindPort 和业务端口都没被安全组挡住）。性能上，Frp 是"中转"，数据会多绕一跳，所以带宽损耗无可避免；对于大流量（视频、备份），优先判断是否该走直连/多级别的带宽，别指望穿透能凭空加速。实测一条法则是：先 curl 本机 localPort 确认内网服务本身是好的，再测经过隧道那端，直接把"内网坏"和"隧道坏"分开。
结语
Frp 的真正价值，是把"没有公网 IP 的内网服务"重新拉进"可以被公网按需访问"的阵容，同时因为主动出连的模型，避开了运营商 NAT 对进向连接的阻断。它的门槛极低：一台公网 VPS 起 frps，内网机器起 frpc，声明一条代理规则，就能在几十分钟里把家里的 NAS 或开发机接出来。但穿透是把双刃剑——它让"内网"这个概念部分失效，所以永远要把认证、最小暴露、以及"这层转发旁边有没有再做一次保护"想圆，才不至于为了便利把整个内网的边界打开了。
