一、内网穿透到底在解决什么问题，先把模型建立起来
内网穿透被误解最多的地方，是很多人以为它「让内网机能被外网访问」就完事了。实际上它解决的是一个更具体的网络学问题：你的设备在私有网络后面，没有一个公网可路由的地址，外部的连接请求送不进来。
要理解这件事，先看三种网络位置的差别：
| 你的设备所在 | 外部能不能主动连进来 | 解决方式 |
|---|---|---|
| 有公网 IP 的云服务器 | 能，直接开放端口 | 不需要穿透 |
| 家里/公司宽带后的电脑 | 不能，运营商做了 NAT | 需要穿透 |
| 路由器后的手机、软路由、NAS | 不能，多层 NAT | 需要穿透 |
关键的认知是：NAT 不是「不安全」，它是「不可寻址」。你的设备发出去的连接能正常出去并收到回应（这叫状态型 NAT 或 cone NAT），但外部主动发起的连接找不到你，因为路由器没有把入站流量转发到内网某台设备。
穿透要做的事情只有一件：在中转机上开一个监听端口，把这个端口收到的连接转发到内网设备的对应端口，再把回程数据原路送回。所以任何穿透方案的成败，都取决于两件事——中转机是否稳定可达，以及转发规则是否正确。
三类主流做法的原理完全不同：
frp 这类工具走的是「反向隧道 + 中转机」。你在内网跑一个客户端，它主动连到中转机建立长连接，然后告诉中转机「我要把公网的这个端口映射到我本地的这个端口」。中转机负责对外监听和转发。这是目前最主流的做法。
WireGuard 走的是「组建虚拟局域网」。它不是端口映射，而是把两台机器放进同一个虚拟网络里，内网设备拿到一个虚拟网段的地址，外部直接访问这个地址。两端之间是加密的点对点隧道。
SSH 隧道走的是「本机端口转发」。它不需要中转机，完全基于 SSH 协议。适合临时使用或者只需要访问几个端口的场景。
选错的代价很大：用 frp 去做本来该用 SSH 隧道的事，会平白多一个中转机和它的流量账单；用 SSH 隧道去做需要长期运行的服务，连接一断服务就停。
二、成本账：穿透方案的钱花在流量还是端口上
选方案之前先算钱。穿透的成本有三个部分：中转机的月费、中转机的流量费、你的内网设备的带宽费。
先看在售产品线里的真实价格与单位成本：
| 机型 | 月费 | 内存 | 系统盘 | 月流量 | 内存单价 | 磁盘单价 | 流量单价 |
|---|---|---|---|---|---|---|---|
| RosCloud-01 | 19.99美元 | 1 GB | 20 GB | 1024 GB | 19.99美元/GB | 1.00美元/GB | 19.99美元/TB |
| RosCloud-02 | 29.99美元 | 2 GB | 40 GB | 2048 GB | 14.99美元/GB | 0.75美元/GB | 15.00美元/TB |
| RosCloud-03 | 39.99美元 | 4 GB | 80 GB | 3072 GB | 10.00美元/GB | 0.50美元/GB | 13.33美元/TB |
| RosCloud-04 | 49.99美元 | 8 GB | 160 GB | 4096 GB | 6.25美元/GB | 0.31美元/GB | 12.50美元/TB |
| RosCloud-05 | 59.99美元 | 16 GB | 240 GB | 5120 GB | 3.75美元/GB | 0.25美元/GB | 12.00美元/TB |
| RosCloud-06 | 69.99美元 | 24 GB | 320 GB | 6144 GB | 2.92美元/GB | 0.22美元/GB | 11.67美元/TB |
流量单价从 19.99美元/TB 降到 11.67美元/TB，降幅 41%。对穿透场景来说，这个数字比内存单价重要得多，因为穿透的中转机流量是实打实往外跑的。
具体算一遍。假设你要穿透的是家里 NAS 上的一个 Web 服务，月访问 1 万次，每次平均传输 2 MB：
月流量 = 10000 × 2 MB = 20 GB按 RosCloud-01 的 1024 GB 月流量算，占用比例是 20/1024 约 2%。看起来毫无压力。但如果你穿透的是一个视频流、一个大文件下载服务，或者被爬虫抓取呢？同样是 1 万次访问，每次传输 200 MB：
月流量 = 10000 × 200 MB = 2000 GB这已经超过 RosCloud-01 的 1024 GB 配额，而且流量单价 19.99美元/TB 意味着多出来的部分要按超额计费。
再看年付线的对比。年付起步档 200 美元，折合月费 16.67 美元，给 2 核 2 GB、40 GB 磁盘、5000 GB 月流量、2000 Mbps 带宽，流量单价 3.413美元/TB。
同样是穿透中转机，年付线的流量单价只有月付最低档的 1/6，流量总量是 4.9 倍。这是穿透场景下最值得算的一笔账，因为穿透机本身几乎不需要内存——它只是个转发器，1 GB 内存跑 frp 服务绰绰有余。
结论很清楚：穿透中转机选大流量、低内存的档位，不要被「内存大」带偏。年付线的 5000 GB 流量、3.413美元/TB 单价，正是为这种用途设计的。
三、frp 方案：完整配置与三个关键参数
frp 是最主流的选择。这一节给出完整可用的配置，以及三个决定成败的参数。
架构上是两个角色：
- frps 跑在中转机（公网服务器）上，负责对外监听端口；
- frpc 跑在内网设备上，主动连接 frps，注册端口映射。
第一步，在中转机上装 frps。下载官方二进制，解压到 /usr/local/bin/，给权限：
chmod +x frps第二步，写 frps 的配置文件。最小可用配置：
[common]
bind_port = 7000bind_port 是 frpc 主动连过来的控制端口。它必须在中转机防火墙里放行，否则内网客户端连不上，注册映射也就无从谈起。
第三步，跑起来并设为开机自启。
./frps -c frps.toml第四步，在内网设备上写 frpc 配置。这是整套方案里最容易写错的地方：
[common]
server_addr = 中转机公网IP
server_port = 7000
auth.token = 一段足够长的随机字符串
[tcp-web]
type = tcp
local_ip = 127.0.0.1
local_port = 5000
remote_port = 8080三个关键参数必须理解：
server_addr 是中转机的公网 IP。填错的最典型症状是内网客户端日志里一直报 dial tcp ...: i/o timeout，而不是连接被拒——超时通常意味着 IP 填错或者 bind_port 被防火墙挡了。
local_port 是内网服务真实监听的端口，remote_port 是外部访问的端口。这两个千万别搞反。搞反之后的症状是：你访问 中转机:8080 打开了内网的一个完全不相干的服务，而且不会有任何报错提示你搞错了。
auth.token 是双方约定的密钥。它不是加密，是身份校验——防止别人用你的 frps。设一个长随机串，两端必须完全一致。
第五步，注册多个服务。每加一个要穿透的服务，加一段配置，端口号不重复即可：
[tcp-ssh]
type = tcp
local_ip = 127.0.0.1
local_port = 22
remote_port = 2222
[udp-game]
type = udp
local_ip = 127.0.0.1
local_port = 25565
remote_port = 25565第六步，设成 systemd 服务。因为内网设备（软路由、NAS）随时可能重启，frpc 不开机自启就等于穿透时断时续。
[Unit]
Description=frp client
After=network-online.target
[Service]
ExecStart=/usr/local/bin/frpc -c /etc/frp/frpc.toml
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.targetRestart=always 是关键——frpc 断了会自动重连，配合 frps 的 heartbeat_interval 配置，可以做到几秒内恢复。
第七步：确认映射真的建立了。frpc 跑起来不代表映射成功，要从外部验证而不是从内部看日志：
curl -I http://中转机公网IP:8080从你本机（不是中转机上）执行这个命令。能返回 HTTP 状态码就说明整条链路通了。在中转机本地 curl 是不算数的——那测的是中转机自己，绕过了整个穿透链路，这一步如果做错，你会以为成功了但外部根本访问不了。
第八步：中转机侧的 frps 也要配 systemd 自启。中转机是会重启的（商家维护、系统更新、你自己的误操作）。frps 不自启的话，中转机一重启所有映射全部失效，而内网侧的 frpc 还在傻等重连。frps 的服务定义和 frpc 基本一样：
[Unit]
Description=frp server
After=network-online.target
[Service]
ExecStart=/usr/local/bin/frps -c /etc/frp/frps.toml
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.target两边都自启，才是真正稳定的方案。
一个容易被忽略的细节：frps 的日志和 frpc 的日志要能看到。配好 log.to = /var/log/frps.log 和 log.level = info 之后，用 tail -f /var/log/frpc.log 实时观察连接状态。绝大多数「时好时坏」的穿透问题，看日志三分钟就能定位——比如看到 reconnect to server failed 就说明是中转机的问题，看到 login to server success 但访问不通就说明是本地服务的问题。
四、常见报错：四个症状对应四个根因
内网穿透的报错有很强的规律性，认准症状就能定位。
症状一：frpc 日志报 login to server failed: i/o timeout。这是最常见的一个。根因有三个可能：按顺序排查——第一，server_addr 填错或者中转机的 bind_port 没在防火墙放行；第二，中转机的 frps 服务根本没起来（用 systemctl status frps 确认）；第三，中间有运营商级 NAT 或者云安全组拦截了非标准端口。
中转机放行控制端口的命令：
ufw allow 7000/tcp
systemctl reload ufw云服务器还要检查安全组规则，很多人的 frps 跑得好好的但安全组没放行 7000 端口，症状完全一样。
症状二：连接建立了但访问时提示 connection refused。这说明 frpc 注册成功了，但转发过去的本地端口上根本没有服务在监听。用 ss -lntp | grep 5000 在内网机器上确认服务是否真的起来了，以及监听的地址是不是 127.0.0.1——如果服务只监听了 127.0.0.1 且 frpc 配置里的 local_ip 写的是别的地址，也会连不上。
症状三：访问时提示 502 Bad Gateway 或者 no route to host。这通常是本地服务是 HTTP 服务，但你把 frp 配成了 type = tcp 之外的模式，或者前置了 Nginx 但没配 proxy_pass。验证方式是在内网机器本地直接 curl 一下：
curl -I http://127.0.0.1:5000本地通、远程不通，是穿透配置问题；本地也不通，是应用本身的问题。
症状四：穿透能用，但速度很慢。这一条最容易被误判成「服务器配置不行」。实际上瓶颈通常在三处：中转机的带宽上限、你本地宽带的上行、frp 的传输模式。本地宽带上行只有 20 Mbps 的情况下，中转机给 2000 Mbps 也没用，因为数据必须先从你家里传出去。
解法之一是用 frp 的 STCP 模式做安全访问，之二是换用 UDP 透传来改善高延迟链路的表现。
| 症状 | 日志关键字 | 根因 | 修复动作 |
|---|---|---|---|
| 连不上中转机 | i/o timeout |
端口没放行 / IP 填错 | ufw allow 7000/tcp + 查安全组 |
| 端口通但拒绝连接 | connection refused |
本地服务没监听 | ss -lntp 查本地端口 |
| 转发后 502 | Bad Gateway |
前置代理没配 proxy_pass |
本地 curl 自查 |
| 速度慢 | 无报错 | 本地上行或中转机带宽瓶颈 | 测 iperf3，换线路 |
五、WireGuard 方案：什么时候该用它而不是端口映射
WireGuard 不是端口映射，它做的是把两台机器放进同一个虚拟局域网。它的价值在于内网设备可以直接用一个虚拟 IP 被访问，而不只是几个被映射的端口。
架构：中转机（或家里的另一台设备）跑 WireGuard 服务端，内网设备跑客户端。配好之后两边互通了虚拟网段，比如 10.10.0.0/24。
服务端配置：
[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = 服务端私钥
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
[Peer]
PublicKey = 客户端公钥
AllowedIPs = 10.10.0.2/32客户端配置：
[Interface]
Address = 10.10.0.2/24
PrivateKey = 客户端私钥
DNS = 1.1.1.1
[Peer]
PublicKey = 服务端公钥
Endpoint = 中转机公网IP:51820
AllowedIPs = 10.10.0.0/24
PersistentKeepalive = 25AllowedIPs 是 WireGuard 的路由控制，是最需要理解的一个参数。它声明「哪些目标地址的流量要走这条隧道」。服务端对客户端的 AllowedIPs 通常写客户端自己的虚拟 IP（10.10.0.2/32）；客户端这一侧如果只想访问内网机器，写 10.10.0.0/24。如果你在客户端写 0.0.0.0/0，意味着全部流量都走隧道，这是最常见的「上网变慢」原因。
PersistentKeepalive = 25 不能省。NAT 映射通常有超时时间（常见 60 秒到 5 分钟），没有保活包，映射被回收后隧道就断了。25 秒的间隔能保证在超时之前刷新映射。
WireGuard 相对 frp 的三个优势和两个限制：
优势一是性能：WireGuard 走内核态，实测吞吐通常明显高于用户态的 frp，尤其是大流量场景。
优势二是安全模型更清晰：wg-quick 生成的配置是 peer-to-peer 的密钥配对，没有「端口映射到公网」这一步，所以不需要为穿透出来的端口单独做访问控制——默认所有东西都在隧道内。
优势三是可组网：多点互联（比如三地组网）配置量远小于端口映射方案。
限制一是客户端需要配置（手机、Pad 上要装 App 并导入配置），而 frp 只需要服务端和中转机配置。
限制二是UDP 可用性：WireGuard 依赖 UDP，如果你的网络环境封 UDP 就用不了。检查方法是从内网 ping 中转机的 UDP 端口，或者直接用 wg show 看握手有没有建立。
什么时候选它：当你要访问的是「内网机器上的多个服务」而不是「几个端口」，或者需要内网设备之间互通，或者流量较大且延迟较高时。
什么时候不该选它：当你的使用者是非技术人群（他们没法配置客户端），或者你只是临时访问一个 Web 服务。
六、SSH 隧道：不花钱但有边界的方案
SSH 隧道是最容易被忽略的免费方案，而且在很多场景下它就是最好的方案。
它的原理是在 SSH 连接上开一个本地监听端口，把连接内容通过 SSH 加密通道送到远端。它不需要中转机，不需要任何额外软件（系统自带 ssh 客户端），也不消耗中转机流量。
本地端口转发（把远端服务映射到本地）：
ssh -L 8888:127.0.0.1:5000 -p 端口号 用户@中转机执行后本机访问 127.0.0.1:8888 就是访问中转机上的 5000 端口。如果中转机本身在内网机器上可达，等于直接穿透了。
远程端口转发（把中转机的端口转到内网）：这才是真正的穿透用法：
ssh -R 8080:127.0.0.1:5000 -p 端口号 用户@中转机含义是：在中转机上监听 8080，所有连到中转机 8080 的流量通过这条 SSH 连接回到你本机，再转发到本机 5000 端口。
要让远程转发真正工作，中转机的 sshd 必须允许转发。检查并修改 /etc/ssh/sshd_config：
GatewayPorts clientspecified改完 systemctl restart sshd。不改这一行的话，-R 参数不会报错，但中转机上根本不监听那个端口，你会困惑于「命令执行成功但连不上」。
加 -N 参数让它只做转发不执行命令，-f 让它转到后台：
ssh -fN -R 8080:127.0.0.1:5000 -p 端口号 用户@中转机SSH 隧道的四个边界：
边界一：连接断，服务就停。SSH 隧道是进程级的，进程退出隧道就没了。要长期运行必须配 autossh，它会自动重连：
autossh -M 20000 -fN -R 8080:127.0.0.1:5000 -p 端口号 用户@中转机-M 20000 是监控端口，autossh 用它检测连接状态。
边界二：性能受 SSH 加密开销影响。默认的加密算法在低带宽高延迟链路上开销明显。加上 -c chacha20-poly1305 在这类链路上表现更好。
边界三：需要中转机上有账号。你要用一个真实用户登录中转机，这也是它的安全性来源——只有拿到账号的人才能建隧道。
边界四：不能穿透 UDP。SSH 隧道只走 TCP。需要 UDP 的话还是得用 frp 的 UDP 模式或者 WireGuard。
七、安全：穿透出来的东西必须加三道锁
穿透的本质是把内网服务暴露到公网——这意味着任何知道端口和 IP 的人都能访问你的服务。加三道锁是底线。
第一道锁：不要直接暴露原始端口，改用 frp 的 STCP 模式。STCP 让 frpc 之间先建立加密隧道，访问者必须也是 frpc 客户端才能连进来，公网上根本不监听那个端口。配置方式：
服务端不需要额外配置，客户端加一段：
[stcp-web]
type = stcp
local_ip = 127.0.0.1
local_port = 5000
secret_key = 双方约定的一串密码访问者那边：
[stcp-visitor]
type = stcp
role = visitor
server_addr = 中转机公网IP
server_port = 7000
secret_key = 同一串密码
bind_addr = 127.0.0.1
bind_port = 8888这样外部要用 ssh -L 8888:127.0.0.1:8080 用户@中转机 才能访问，公网上没有可扫到的端口。
第二道锁：应用层必须有强认证。穿透解决的是可达性，不是身份验证。你的 Web 服务如果本身没有登录或者强 token，任何人都能用。至少加一层：反向代理层做 Basic Auth 或加访问白名单。
第三道锁：限速。中转机带宽是共享资源，一个爬虫抓你的服务就能把带宽吃满。frp 的代理配置支持限速：
[web]
type = tcp
local_port = 5000
remote_port = 8080
transport.proxyBufferLimit = 8192第四道锁（隐含但重要）：定期轮换 auth.token。token 泄露后别人就能用你的 frps 建隧道。定期更换是最简单的防护。
还有一个必须做的动作：检查中转机上开放的端口。穿透配置多了之后，中转机上会有一堆 remote_port 对应的监听端口，它们是公网可见的。用这条命令列出所有监听：
ss -lntp对照你的 frp 配置逐条核对，把不再用的映射对应的 frpc 配置删掉，然后重启 frps 释放端口。残留的开放端口是攻击面，而多数人从不去清理它们。
顺便说一句：auth.token 一定要用长随机串而不是一句好记的短语。frp 官方文档也建议使用足够长的 token。
八、什么情况下你根本不需要内网穿透
这一节按公开事实推演，不涉及对任何商家的评价。很多人在这里绕了大弯，答案其实是不需要。
场景一：你的服务只需要你自己访问，或者团队内部几个人访问。判断依据是使用者数量和身份。这种情况下 SSH 隧道（第六节）完全够用，不需要中转机、不需要 frp、不需要公网 IP。成本是零。
场景二：你的服务本来就可以部署到公网服务器上。判断依据是数据是否必须在内网。如果你要穿透的是一个 Web 服务、一个小程序后端、一个 API 服务——它们的代码完全可以放到 VPS 上直接跑。从 VPS 到 VPS 的访问比从公网绕回内网更快、更稳、更省。穿透只在你确实无法把服务移出去时才必要。
场景三：你需要一个固定的公网入口，但服务在内网。判断依据是流量特征。这种场景 frp 的 STCP 或 WireGuard 都合适，但要注意中转机的流量成本——回到第二节的算账，1 万次访问每次 2 MB 是 20 GB，1 万次每次 200 MB 就是 2000 GB，后者已经超过最低档的配额。如果流量特征是后者，你应该直接考虑把服务放公网，而不是花高额流量费穿透。
场景四：你要穿透的是需要 UDP 的游戏或实时语音。判断依据是协议类型。SSH 隧道和 WireGuard 在部分网络环境下受 UDP 限制，frp 的 UDP 透传是更稳的选择。但要清楚 UDP 透传的可靠性不如 TCP，因为 UDP 本身不保证送达。
| 场景 | 判断依据 | 结论 | 替代方向 |
|---|---|---|---|
| 只有自己或小团队访问 | 使用者数量与身份 | 不需要穿透 | SSH 隧道，零成本 |
| 服务可以移到公网 | 数据是否必须在内网 | 不需要穿透 | 直接部署到 VPS |
| 固定公网入口 + 服务在内网 | 流量特征 | 需要，但先算流量费 | STCP 或 WireGuard |
| 需要 UDP 的服务 | 协议类型 | 需要 | frp UDP 模式 |
九、给四类人的具体方案
第一类：想临时访问家里/公司的某个服务，用完就关。用 SSH 隧道，成本为零。命令：
ssh -L 8888:127.0.0.1:目标端口 -p 端口号 用户@中转机本地浏览器访问 127.0.0.1:8888。不需要买任何机器，不需要装任何软件。
第二类：要长期运行的服务，访问者是自己或固定几个人。用 frp 的 STCP 模式。配置见第七节，安全性最好——公网上不存在可扫描的端口。中转机选型按第二节的算账：优先选大流量低内存的档位，年付线的 5000 GB 流量、3.413美元/TB 单价是穿透场景最合适的选择，因为穿透机本身不需要大内存。
第三类：需要访问内网多台机器上的多个服务，或者要让家里几台设备互通。用 WireGuard。理由是它一次配置就能覆盖整段虚拟网段，后续加机器只需要加一段 peer 配置，不用一条服务改一次穿透配置。注意客户端的 AllowedIPs 别写成 0.0.0.0/0，除非你确实想让全部流量走隧道。
第四类：要穿透的是 Web 服务，且访问者不固定、可能来自公网任意位置。这是风险最高的一类。方案是：优先考虑把服务直接部署到公网 VPS——如果数据允许，这是最省事也最安全的做法。确实必须留在内网时，用 frp 的 STCP 加上应用层的强认证和限速，并且定期轮换 auth.token。
四类人的共同点：都需要在动手前先确认「中转机的流量费会不会比我预想的多」。第二节那笔账值得在每次方案设计时重算一遍。
按你的情况，下一步该看哪家
上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：
- 主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 cloudcone 当前机型与价格
- 跑游戏服或实时业务：看上行抖动与防御能力，普通套餐往往不达标。看 digitalocean 当前机型与价格
- 只是开发测试、临时用：按小时或月付，用完就删，别买年付。看 hostwinds 当前机型与价格
价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。
十、常见问题
Q：内网穿透会不会被查封或者限制？
穿透本身是合法的技术手段，但在国内要遵守相关规定，商业用途需要 ICP 备案（用国内节点做中转时）。技术层面的风险是你的服务可能被用于不符合规定的行为从而导致服务商收到通知，这种情况通常的处理是服务商暂停该 IP 的服务。所以关键是：确认你穿透出去的服务内容合规，别在共享的中转机上跑敏感业务。
Q：frp 的 tcp 模式和 stcp 模式怎么选？
看暴露范围。tcp 模式会在中转机上真的开一个公网端口，任何人扫到这个端口就能尝试连接你的服务；stcp 模式需要访问者也是 frpc 客户端且持有正确 secret，公网上没有可扫的端口。除非你明确需要让「任何人通过 IP 加端口就能访问」，否则默认用 stcp。
Q：中转机选哪个地区？
判断依据是你的内网出口位置和访问者位置。中转机的作用是转发，所以它的位置决定了「内网 → 中转机」和「中转机 → 访问者」两段路径的延迟。内网在國內、访问者也在国内时，中转机选国内或香港这类近距离节点，能显著降低延迟；访问者在海外时，中转机选离访问者近的位置。注意这段延迟是叠加的：内网到中转机加中转机到访问者。
Q：穿透之后速度上不去，是配置问题还是线路问题？
用 iperf3 一测就分清。在中转机和内网设备各跑一个：
iperf3 -s
iperf3 -c 中转机公网IP如果测出来的速度接近你本地宽带的上行（比如宽带标称 100 Mbps，上行 20 Mbps，那测出 18 到 20 Mbps 就是正常的），说明是本地宽带上限，加配置没用，只能加钱换宽带。如果测出来远低于上行，那才是穿透配置或链路的问题。
Q：内网设备重启后穿透断了，怎么让它自动恢复？
两个层面。第一层是 frpc 本身设为 systemd 服务并配 Restart=always，这一步能覆盖大多数情况。第二层是中转机侧的 frps 也要设为开机自启——很多人在内网侧做了自动重连，但中转机重启后 frps 没起来，内网连过去照样失败。中转机侧的服务定义：
[Unit]
Description=frp server
After=network-online.target
[Service]
ExecStart=/usr/local/bin/frps -c /etc/frp/frps.toml
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.targetQ：能不能同时穿透多个内网设备？
可以。每一台内网设备跑一个 frpc 实例，各自在 frps 上注册不同的 remote_port 即可。多个 frpc 用不同的配置文件（frpc -c /etc/frp/frpc-nas.toml）区分。中转机的资源消耗很低——每个 frpc 连接占用的内存通常在 10 MB 到 30 MB 量级，所以 1 GB 内存的机器跑十几个 frpc 客户端的连接是没有问题的，中转机的瓶颈在带宽而不是内存。
喜欢 
高兴
鬼脸
呵呵
无聊
伤心
