WangshuXC
01开发工具
2026 · 02 · 21
10 分钟
← 返回列表

通过 frp 内网穿透 + SSH ProxyJump 访问校园网服务器并进行远程开发

本文提供了一种通过公网服务器与跳板机远程进行内网开发的方式。

远程访问内网服务器有几种常见方案：

我的目标服务器完全无法访问公网，排除了 ZeroTier/Tailscale 等 P2P 方案。最终选择 frp 内网穿透 + SSH ProxyJump（跳板连接）：只要校园网内有一台能同时访问内网和公网的机器作为跳板，就能打通整条链路。

架构设计

网络拓扑

加载中…

各节点角色

核心原理

frp（Fast Reverse Proxy） 是一款反向代理工具。跳板机上的 frpc 主动连接公网服务器上的 frps，建立一条 TCP 隧道。外部访问公网服务器的 7001 端口时，流量通过隧道转发到跳板机的 22 端口——这就是"内网穿透"。

SSH ProxyJump 是 OpenSSH 7.3+ 提供的跳板连接功能。通过 ProxyJump 指令，SSH 客户端会先连接跳板机，再通过跳板机连接目标服务器，整个过程对用户透明，就像直接连接目标服务器一样。

两者组合的数据流向：

text
1本地 → SSH → 公网服务器:7001 → frp隧道 → 跳板机:22 → SSH → 目标服务器:22 2

实施步骤

Step 1: 准备工作

公网服务器要求：

  • 任意云服务器（推荐 1 核 1G，约 ¥20/月）

  • 操作系统：Linux（CentOS/Ubuntu 均可）

  • 开放端口：7000（frp 通信）、7001（SSH 穿透）

跳板机要求：

  • 可以同时访问校园网内网和公网

  • 能保持长时间开机（Mac Mini、树莓派等均可）

目标服务器：

  • 已安装 SSH 服务

  • 确认与跳板机在同一内网且可互相访问

Step 2: 部署 frp 服务

从 frp Releases 下载对应平台的二进制包。

公网服务器 — 配置 frps（服务端）：

创建 frps.toml：

toml
1bindPort = 7000 2

启动服务：

bash
1# 前台运行（测试用） 2./frps -c frps.toml 3 4# 后台运行（生产用） 5nohup ./frps -c frps.toml > frps.log 2>&1 & 6

跳板机 — 配置 frpc（客户端）：

创建 frpc.toml：

toml
1serverAddr = "82.156.32.5" 2serverPort = 7000 3 4[[proxies]] 5name = "ssh-mac-mini" 6type = "tcp" 7localIP = "127.0.0.1" 8localPort = 22 9remotePort = 7001 10

启动客户端：

bash
1nohup ./frpc -c frpc.toml > frpc.log 2>&1 & 2

验证穿透是否成功：

bash
1# 在任意外网机器上执行 2ssh username@82.156.32.5 -p 7001 3

如果成功登录到跳板机，说明 frp 隧道已经打通。

Step 3: 配置 SSH 密钥认证

密钥认证比密码更安全且更方便，免去每次输入密码的麻烦。

bash
1# 1. 生成密钥对（如果还没有的话） 2ssh-keygen -t ed25519 -C "your_email@example.com" 3 4# 2. 将公钥分发到跳板机 5ssh-copy-id -p 7001 username@82.156.32.5 6 7# 3. 将公钥分发到目标服务器（通过跳板机中转） 8ssh-copy-id -o "ProxyJump username@82.156.32.5:7001" admin12club@222.30.60.30 9

分发完成后，后续连接将自动使用密钥认证，不再需要密码。

Step 4: 编写 SSH Config

编辑 ~/.ssh/config：

text
1# 跳板机：通过 frp 穿透后的公网入口 2Host mac-mini 3 HostName 82.156.32.5 # 公网服务器 IP 4 Port 7001 # frp 映射的远程端口 5 User username # 跳板机用户名 6 7# 目标服务器：通过跳板机连接 8Host 12club 9 HostName 222.30.60.30 # 目标服务器内网 IP 10 Port 22 # SSH 默认端口 11 User admin12club # 目标服务器用户名 12 ProxyJump mac-mini # 关键：指定经由跳板机连接 13

配置完成后，一条命令即可直达目标服务器：

bash
1ssh 12club 2

SSH 会自动先连 mac-mini（跳板机），再从跳板机连 12club（目标服务器），整个过程无感。

Step 5: 创建端口转发脚本

为了在本地访问目标服务器上的 PostgreSQL、Redis 等服务，我编写了一个自动化端口转发脚本，支持一键转发、守护模式、智能重连。

**完整脚本 ssh-tunnel.sh： **https://github.com/WangshuXC/12Club/blob/main/scripts/ssh-tunnel.sh

脚本核心设计解析：

  1. cleanup_existing_tunnels — 启动前通过 lsof 查找占用目标端口的旧 SSH 进程并自动清理，避免 Address already in use 错误。

  2. check_redis — 普通端口用 nc -z 检测即可，但 Redis 存在"僵尸连接"问题：端口虽然开放，但隧道实际已断。因此脚本发送 PING 命令，只有收到 PONG 回复才认为连接正常。

  3. start_tunnels — 使用 ssh -f -N 后台建立多端口转发。-o ExitOnForwardFailure=yes 确保端口绑定失败时立即退出，而非静默忽略。

  4. daemon_loop — 守护进程每隔 N 秒检查一次所有端口。单次失败立即重连；连续 3 次失败则延长等待至 60 秒，避免在网络中断期间疯狂重试。

使用示例：

bash
1# 添加执行权限 2chmod +x ssh-forward.sh 3 4# 一次性启动 5./ssh-forward.sh 6 7# 守护模式（推荐日常使用） 8./ssh-forward.sh -d 9 10# 检查当前状态 11./ssh-forward.sh -c 12 13# 停止所有转发 14./ssh-forward.sh -s 15

运行 ./ssh-forward.sh -c 的输出效果：

text
1端口转发状态检查: 2 ✓ PostgreSQL (localhost:5432) - 连接正常 3 ✓ Redis (localhost:6379) - 连接正常 4 ✓ Openlist (localhost:5244) - 连接正常 5

实际开发体验

IDE 远程开发配置

在 CodeBuddy（或 VS Code）中配置 SSH Remote Development：

  1. 安装 Remote - SSH 扩展

  2. 打开命令面板 → Remote-SSH: Connect to Host

  3. 选择 12club（自动读取 ~/.ssh/config）

  4. 等待远程环境初始化完成

连接成功后，IDE 就像在本地一样操作远程服务器上的文件，终端、调试器、Git 全部可用。

数据库连接

端口转发启动后，本地连接远程数据库就像连接本地服务一样：

bash
1# PostgreSQL 2psql -h localhost -p 5432 -U postgres -d mydb 3 4# 连接字符串（用于 .env 配置） 5DATABASE_URL="postgresql://postgres:password@localhost:5432/mydb" 6 7# Redis 8redis-cli -h localhost -p 6379 9

日常工作流

bash
1# 1. 启动端口转发（守护模式） 2./ssh-forward.sh -d 3 4# 2. 在 CodeBuddy 中连接 12club 进行开发 5 6# 3. 本地浏览器访问远程 Next.js dev server 7# （需额外转发 3000 端口，或在 ssh-forward.sh 的 PORTS 中添加） 8

性能表现

  • SSH 连接延迟：约 30-50ms（公网服务器在华南区域）

  • 文件操作：IDE 远程编辑几乎无感知延迟

  • 数据库查询：通过端口转发的 PostgreSQL 查询，延迟增加约 20ms，完全不影响开发

  • 稳定性：守护模式下偶尔断线（约每 2-3 天一次），自动重连后无感恢复

故障排查

调试技巧： 在 SSH 命令中添加 -v（verbose）参数查看详细连接过程：

bash
1ssh -v 12club 2

总结

方案优劣

优势：

  • 成本低：仅需一台低配云服务器（约 ¥20/月）

  • 配置灵活：可随时添加新端口映射，修改 PORTS 变量即可

  • 性能优秀：延迟低（30-50ms），200Mbps 带宽满足开发需求

  • 兼容性好：支持所有 SSH 工具（IDE、SCP、rsync 等）

劣势：

  • 需要公网服务器（有一定成本）

  • 初始配置相对复杂（但一次配置，长期受益）

  • 安全性依赖配置（需要额外加固）

适用场景

  • 学生远程访问实验室/宿舍服务器

  • 远程办公访问公司内网开发机

  • 多地点切换开发（家、公司、咖啡厅）

  • 临时对外展示内网 Web 项目

这套方案已经稳定服务了我半年多的远程开发工作。从宿舍到咖啡厅，从图书馆到家里，只要有网络，ssh 12club 一条命令就能回到我的开发环境。

希望这篇文章能帮助有类似需求的开发者搭建自己的远程开发通道。

参考资源：

推荐工具：

  • tmux：终端复用，保持 SSH 会话在断线后不丢失

  • mosh：Mobile Shell，比 SSH 更适合不稳定网络，支持断线自动重连

  • autossh：SSH 隧道自动重连工具，可替代脚本中的守护模式

下一篇
基于 html-react-parser 的 Markdown 渲染管线改造→