VPN 与 SSH 隧道都能「把流量加密后送到另一台机器」，但范围不同：**SSH 隧道通常只转发你指定的端口或应用，VPN 通常给系统加一张虚拟网卡，让整机 IP 流量按路由进入隧道。**2026 年 9 月常见的误用，是把运维用的端口转发当成整机隐私方案，或反过来为访问一个内网端口改动整机路由。
一句话定义
一个可独立引用的定义句：SSH 隧道是在已认证的 SSH 会话内，把本地或远端某个 TCP 端口的连接转发到另一端的一种端口转发机制。
另一个可独立引用的定义句：VPN（虚拟专用网络）是在两端之间建立加密隧道，并通过虚拟网卡与路由表把指定网段或全部 IP 流量送入隧道的网络层方案。
两者的差别不在「加不加密」，而在「隧道里装的是什么」：SSH 转发装的是一条条 TCP 字节流，VPN 装的是完整的 IP 数据包。概念基础可参见 VPN 是什么。
SSH 隧道的三种常见形态
SSH 端口转发按方向和目标可分为三类（概念层，不涉及具体部署命令）：
| 形态 | 在做什么 | 典型用途 |
|---|---|---|
| 本地转发（Local） | 本机某端口的连接，经 SSH 服务器转到其后方的指定地址 | 访问只对内网开放的数据库、管理面板 |
| 远程转发（Remote） | SSH 服务器上某端口的连接，转回客户端一侧的地址 | 临时把本机开发服务给同事演示 |
| 动态转发（Dynamic） | 本机开一个 SOCKS 代理，目标由应用逐个指定 | 让单个浏览器或工具经服务器发出请求 |
动态转发本质上就是一个经 SSH 加密的 SOCKS 代理，所以它继承了 SOCKS 的覆盖范围问题：只有配置了代理的应用才会走它。这一点与 SOCKS5 与 VPN 有何不同 里的分析一致。
对比表：层级、范围与传输
| 维度 | SSH 隧道 | VPN |
|---|---|---|
| 工作层级 | 应用层会话内转发 TCP 流 | 网络层转发 IP 包 |
| 流量范围 | 指定端口或配置了代理的应用 | 按路由表，可整机或指定网段 |
| 是否需要虚拟网卡 | 常用形态不需要 | 通常需要 |
| UDP 支持 | 常用转发不支持 | 取决于协议，多数支持 |
| 外层传输 | TCP（SSH 默认端口 22） | 视协议，WireGuard 为 UDP，OpenVPN 可选 |
| 身份认证 | SSH 密钥或密码，针对具体服务器账号 | 证书、预共享密钥或账号体系 |
| 部署前提 | 你对目标服务器有 SSH 登录权限 | 需要 VPN 服务端与客户端配置 |
| 系统 DNS | 默认不接管，动态转发时取决于应用是否远程解析 | 客户端通常会下发或接管 DNS |
表中「支持」「不支持」指常见用法，并非协议能力上限。例如 OpenSSH 提供隧道设备转发的扩展，可以承载 IP 包，但需要服务端显式允许且权限要求较高，在日常运维中并不常见。
加密层：都加密，但保护的边界不同
SSH 的加密由 SSH 传输层协议提供，保护的是「客户端到 SSH 服务器」这一段；流量从 SSH 服务器转发到最终目标时，是否仍然加密取决于目标服务本身，例如目标是 HTTPS 就仍有 TLS，目标是明文数据库协议则这一段是明文，只是通常位于服务器所在的内网。
VPN 的加密保护的是「客户端到 VPN 服务端」这一段，出了隧道之后同样只剩应用自身的加密。这和 VPN 与 HTTPS 各加密哪一层 讨论的分层逻辑相同：
| 路段 | SSH 本地转发 | VPN |
|---|---|---|
| 本机 → 隧道对端 | SSH 加密 | 隧道加密 |
| 隧道对端 → 最终目标 | 取决于目标协议 | 取决于目标协议 |
| 谁能看到明文 | SSH 服务器（若目标协议为明文） | VPN 服务端（若目标协议为明文） |
因此两者在信任模型上类似：你都要信任隧道另一端。区别在于 SSH 隧道的另一端往往是你自己或团队管理的服务器，信任关系更明确；商业 VPN 的另一端是服务商，信任依据只能来自其公开说明与第三方审计，参见 VPN 无日志政策。
为什么 SSH 隧道跑大流量常常不理想
SSH 隧道的外层是 TCP，隧道内转发的也是 TCP 流。当你用它承载大量交互或长连接时，会遇到两类问题：
- 队头阻塞：一条 SSH 连接里复用多个转发通道，外层 TCP 丢一个包，所有通道都要等重传；
- 单连接吞吐：所有转发共享一条 TCP 连接的拥塞窗口，高延迟或丢包路径上吞吐受限更明显。
这与 VPN 用 TCP 还是 UDP 中「TCP 套 TCP」的讨论相近。严格来说，SSH 端口转发会在服务器端终结内层 TCP 再重新发起连接，不是逐包封装，所以不完全等同于 TCP-over-TCP 的重传叠加，但外层单连接的队头阻塞仍然存在。
测试环境写法示例：2026 年 9 月，同一台云服务器、同一客户端，分别用 SSH 本地转发与 WireGuard 隧道访问同一内网文件服务，记录大文件下载吞吐与交互延迟，并注明接入类型（家庭宽带 / 蜂窝网）与丢包率。无法复测时写「据本次实测」，不要推广为普遍结论。
适用场景对照
| 场景 | 更贴近的方案 | 原因 |
|---|---|---|
| 临时访问服务器后方的一个内网端口 | SSH 本地转发 | 已有 SSH 权限，不改整机路由 |
| 让团队成员长期访问整个办公内网 | VPN | 需要网段级路由、统一认证与审计 |
| 需要 UDP 或语音、游戏类流量 | VPN | 常用 SSH 转发不承载 UDP |
| 只让一个浏览器经服务器发请求 | SSH 动态转发或 VPN 分流 | 取决于是否接受应用级配置与泄漏面检查 |
| 手机上长期使用 | VPN | 系统原生支持虚拟网卡与按需连接，SSH 客户端后台保活受限 |
「更贴近」不是排名，只说明哪种设计的默认行为更接近该场景的需求。若组织有自己的访问控制与合规要求，应以内部规定为准。
常见误解
误解 1：SSH 隧道和 VPN 一样能保护整机流量。 常用的 SSH 转发只覆盖指定端口或配置了代理的应用，系统其他流量、系统 DNS 仍按原路由走。
误解 2：SSH 用的是 22 端口，所以流量「看不出来」。 SSH 协议握手有明确特征，端口号不改变协议可识别性。本文不讨论规避识别的做法，只提醒不要把端口号当成隐私属性。
误解 3：走了 SSH 隧道，目标服务就是加密的。 SSH 只加密到 SSH 服务器这一段；服务器到最终目标之间，是否加密取决于目标协议本身。
误解 4：VPN 一定比 SSH 隧道更安全。 两者都依赖隧道另一端的可信度与自身实现质量。自己管理的 SSH 服务器与未审计的 VPN 服务相比，哪一方更可信要看具体配置与运营方，不能按技术名称一概而论。
选择前的核对清单
- 需求范围：你要转发的是一个端口、一个应用，还是整个网段或整机流量；
- 协议需求：是否需要 UDP、组播或非 TCP 流量；
- 权限前提：你对目标服务器是否本来就有合规的 SSH 登录权限；
- DNS 与泄漏面：动态转发时应用是否远程解析域名，参见 DNS 泄漏检测；
- 持续性：临时排障用一次，还是需要开机自动连接与断线闸门，后者参见 Kill Switch 是什么。
SSH 隧道是面向单个服务的运维工具，VPN 是面向网络的连接方案。先确定你要解决的是「连到一个端口」还是「让一组流量换一条路由」，再选择对应的工具，并用实际流量验证覆盖范围，而不是只看客户端显示的状态。