远程转发 -R
远程转发把监听端口放在远端 SSH 服务器，再把收到的连接通过已建立的 SSH 会话送回本机。
30 秒结论
Section titled “30 秒结论”远端客户端 → 远端监听端口 → SSH 连接 → 本机目标服务- 监听方：远端 SSH 服务器。
- 目标连接发起方：你的设备。
- 目标是否固定：固定。
- 适合：Webhook、开发预览、本地 API 测试。
ssh -R 8080:127.0.0.1:3000 user@ssh.example.com含义：
| 部分 | 含义 |
|---|---|
8080 | 远端服务器监听端口 |
127.0.0.1 | 目标从本机视角解析 |
3000 | 本机服务端口 |
user@ssh.example.com | 承载转发的 SSH 服务器 |
案例一：把本地开发服务暴露给远端
Section titled “案例一：把本地开发服务暴露给远端”本机运行：
npm run dev -- --host 127.0.0.1 --port 3000建立远程转发：
ssh -N -R 8080:127.0.0.1:3000 user@ssh.example.com在远端服务器上测试：
curl http://127.0.0.1:8080如果远端 SSH 配置允许监听所有地址，其他能被远端访问的客户端可以使用：
http://ssh.example.com:8080这通常需要远端 sshd_config 设置：
GatewayPorts yes也可能是只允许特定绑定：
GatewayPorts clientspecified不要假设远端一定允许公网监听。生产环境中优先保持远端监听在 127.0.0.1，再通过更明确的安全路径访问。
案例二：接收远端 Webhook
Section titled “案例二：接收远端 Webhook”某些测试环境只能回调远端网络中的地址：
- 本机 Webhook 服务监听
127.0.0.1:9000。 - 使用
-R 18080:127.0.0.1:9000。 - 让测试系统回调远端服务器
127.0.0.1:18080。 - 请求通过 SSH 到达你的本机服务。
此方式不要求修改本地路由器，也不要求开放公网入站端口。
NetShuttle 配置
Section titled “NetShuttle 配置”- 选择一台可在远端网络运行的 SSH 服务器。
- 新建隧道或选择已有隧道。
- 添加规则，模式选择
远程转发 -R。 - 本地地址 / 端口填写本机目标，例如
127.0.0.1:3000。 - 远端地址 / 端口填写远端监听位置，例如
127.0.0.1:8080。 - 启用规则，然后在远端服务器上验证监听和访问。
远端监听安全检查
Section titled “远端监听安全检查”- 优先绑定
127.0.0.1。 - 只有确实需要其他机器访问时，才改为
0.0.0.0或指定远端网卡地址。 - 检查远端防火墙和云安全组。
- 不要长期暴露开发服务器。
- 本地服务应至少具备自己的鉴权，不能只依赖“地址不明显”。
常见失败原因
Section titled “常见失败原因”远端端口已被占用
Section titled “远端端口已被占用”在远端服务器检查：
ss -lntp | grep 8080远端拒绝 tcpip-forward
Section titled “远端拒绝 tcpip-forward”部分服务器关闭远程转发：
AllowTcpForwarding no需要服务器管理员明确允许，NetShuttle 无法绕过服务器策略。
远端只能本机访问
Section titled “远端只能本机访问”即使 SSH 连接成功，如果监听地址是 127.0.0.1，只有远端服务器自己可以访问。需要远程访问时，必须同时处理 GatewayPorts、绑定地址和防火墙。
本机服务只监听错误接口
Section titled “本机服务只监听错误接口”本机目标服务必须接受来自 NetShuttle 的连接。测试：
curl http://127.0.0.1:3000与本地转发的核心区别
Section titled “与本地转发的核心区别”本地转发让“本机访问远端”。
远程转发让“远端访问本机”。
两者不能只根据端口号判断，必须确认监听发生在哪一端。