摘要：SSH 隧道、SOCKS 代理、正向代理和反向代理都在“替别人转发连接”，但方向和暴露面完全不同。本文用远程数据库、本地接口和跳板机三个场景，讲清谁发起连接、谁真正访问目标，以及该怎么选。

上次写 Tailscale、ZeroTier、VPN 和内网穿透时，留下了一个更容易混淆的问题：

SSH 隧道、SOCKS 代理、正向代理、反向代理，到底有什么区别？

开发者通常是这样遇到它们的：

• • 数据库在内网，应用在云服务器，本地想临时连上去排查；

• • 本地跑了一个回调接口，远端服务需要访问它；

• • 浏览器想通过某台服务器访问一部分地址；

• • 公司有统一代理，浏览器可以上网，但某个命令行工具不会配置。

于是有人说“开个 SSH 代理”，有人说“走反向代理”，还有人把所有不能直连的情况都叫“隧道”。

这些说法不一定错，但经常没有说清楚最关键的三件事：

谁发起连接？谁替谁访问？哪一端暴露了入口？

只想知道临时连数据库用什么，可以直接看“SSH 本地端口转发”一节；想把这一家子概念彻底分开，再从头看。

先给坐标：不要先背“正向”和“反向”

这张表有一个容易被忽略的地方：

“本地 / 远程”通常描述端口开在哪里；“正向 / 反向”通常描述代理站在谁的一侧。它们不是同一组词。

SSH 本地端口转发，可以被理解为“本地开了一个入口，连接借 SSH 去远端”；SSH 远程端口转发，则是“远端开了一个入口，连接借 SSH 回到本地”。

先把入口位置和访问方向拆开，后面的名字就不会互相打架。

问题一：正向代理到底替谁访问？

正向代理站在客户端这一边，替客户端访问外部目标。

浏览器、命令行工具或应用程序先把请求交给代理服务器，再由代理服务器去访问目标站点。目标站点看到的直接连接者，是代理服务器。

可以把它想成写字楼里的统一快递窗口：员工不直接和外面的快递员联系，而是把包裹交给窗口，窗口负责对外联系。

正向代理关心的是：

• • 客户端是否被允许使用代理；

• • 代理能访问哪些目标；

• • 目标站点看到的出口是谁；

• • 代理是否记录了请求信息。

它并不等于 VPN。VPN 可以把一段网络流量送进另一张网络，正向代理通常只接收配置了代理的应用请求。浏览器走代理，不代表电脑上所有程序都走代理。

这也是为什么有时网页能打开，某个 Git、包管理器或桌面应用却完全不通：它们没有使用同一个代理配置。

但如果外部用户访问的是你部署的服务，情况就反过来了。

问题二：反向代理为什么叫“反向”？

反向代理站在服务端这一边，替后端服务接待外部用户。

用户访问的是域名和公网入口，真正的应用服务器藏在后面。反向代理收到请求后，再根据域名、路径或其他规则转给后端。

生活中的类比是医院前台：病人先到前台，前台根据科室把人分流。病人不需要知道每位医生在哪个房间，后端也不必直接暴露在公网。

反向代理不是“把内网服务偷偷放出来”的同义词。它可以部署在公网服务器前面，也可以和内网穿透结合：公网入口收到请求，再通过一条受控连接把请求送到内网后端。

还要区分一个经常被混用的词：代理处理的是请求，隧道承载的是连接。

反向代理通常理解 HTTP 请求，能根据域名、路径、请求头把流量分给不同后端；SSH 隧道往往只负责把一段 TCP 字节从一端搬到另一端，并不知道里面是数据库协议、网页还是其他应用协议。正因为如此，SSH 隧道很通用，但它也不会自动替你完成鉴权、限流、审计和故障切换。

这也是“能转发”与“适合做生产入口”的分界线：前者是连通性问题，后者还包括身份、策略和运维问题。

这里的安全边界也很明确：

藏在反向代理后面，不等于后端没有风险；入口有登录页，也不等于权限设计完成。

下一步的问题是：SSH 隧道和反向代理看起来都能“把请求送到后面”，它们又差在哪？

问题三：SSH 本地端口转发，究竟转发了什么？

假设有三台机器：

• • 本地电脑 L：你正在操作的电脑；

• • 跳板机 J：你可以 SSH 登录的服务器；

• • 内网数据库 D：只有 J 能访问，L 不能直连。

你想在本地使用数据库客户端，但不想把数据库端口开放到公网。

SSH 本地端口转发的思路是：在 L 上开一个本地端口，L 连接这个端口时，SSH 把字节带到 J，再由 J 连接 D。

本地数据库客户端以为自己连的是 localhost。它不知道后面还有跳板机，也不需要理解内网路由。

这类转发适合：

• • 临时排查内网数据库；

• • 访问只对跳板机开放的管理端口；

• • 给本地开发工具接一个远端测试服务。

它不适合直接当成多人共享的长期网络。因为入口通常只开在你的本机，连接依赖你的 SSH 会话和账号；一旦会话关闭，本地端口也就失效。

这里最容易产生的误解是“本地端口映射到远端端口”。更准确的说法是：

本地应用把连接交给 SSH；SSH 让跳板机代替本地去连接目标。

所以数据库看到的来源通常是跳板机，而不是你的家庭宽带地址。

问题四：SSH 远程端口转发，为什么方向反过来了？

现在换一个场景：

• • 本地电脑 L 上跑着一个开发接口；

• • 远端服务器 J 可以被外部服务访问；

• • 你希望 J 上的程序访问 L 的接口。

这次要做的是 SSH 远程端口转发：入口开在 J，连接从 J 的入口进入，再沿着 SSH 会话回到 L。

它解决的不是“我从本地访问远端”，而是“让远端能够访问本地”。     

远程端口转发常见于：

• • 让远程测试环境临时访问本地 Web 服务；

• • 让外部回调经过受控的远端入口到达本地；

• • 在不直接开放本地防火墙端口的情况下，做一次短期联调。

但它的风险也跟着入口位置变化：入口开在 J，就要检查 J 的监听地址和访问控制。绑定在回环地址，和绑定到所有网卡，暴露面完全不同。

“SSH 连接是加密的”只说明隧道里的内容受到保护，不说明远端入口就自动安全。谁能访问入口、转发到哪个本地服务，仍然要单独限制。

问题五：SOCKS 代理为什么比端口转发更灵活？

前面的本地端口转发通常针对一个固定目标：本地某端口，去远端某个主机和端口。

SOCKS 代理则像一个“代收地址”：客户端先连接 SOCKS 入口，然后在协议里告诉它这一次想访问哪个目标。目标可以随着请求变化，不必为每个服务单独开一个本地端口。

SOCKS 代理适合需要动态访问多个目标的情况，比如浏览器、调试工具或某些支持代理的命令行客户端。它的重点不是“把整个电脑接入另一张网”，而是让支持 SOCKS 的连接把目标交给代理代连。

因此它有三个限制：

1. 1. 应用必须支持 SOCKS，或者通过额外适配把流量交给 SOCKS；

2. 2. 代理服务器必须能访问目标；

3. 3. 代理入口本身必须受到认证和访问控制保护。

SOCKS 也不是天然的匿名工具。代理端可能看见你的连接目标和时间，远端网站看到的是代理出口；链路上每一段能看见什么，取决于协议是否加密和各方日志策略。

“谁先发起连接”，比“正向还是反向”更可靠

把几个场景放在一起，就能看出“方向”的本质：

连接方向和业务访问方向可以相反。

远程端口转发里，SSH 会话可能是本地主动连 J，但业务请求却是 J 上的程序主动访问本地服务。不要只看 TCP 连接最初由谁建立，要看“谁在请求什么服务”。

用一张流程图选机制

选择时再加三个过滤条件：

• • 临时还是长期：临时排查优先短连接；长期服务要有正式的身份、日志和配置管理。

• • 一个目标还是一组目标：一个固定端口用本地转发；多个目标再考虑 SOCKS 或组网。

• • 谁能成为访问者：自己的设备可以加入私有网络，第三方平台通常只能访问一个受控公网入口。

四个场景，直接对号入座

最后记住：代理的对象，决定了边界

SSH 隧道代理的是一条连接，通常服务于一个临时目标。

SOCKS 代理代理的是一类动态连接，目标由客户端逐次指定。

正向代理替客户端访问外部资源，反向代理替后端接待外部用户。

所以遇到“我该开哪个代理”时，先别从命令名开始，按下面顺序问：

1. 1. 谁是访问者？ 是我自己的设备、员工，还是第三方平台？

2. 2. 谁是真正的目标？ 一个端口、多个网段，还是一个要公开的服务？

3. 3. 入口开在哪里？ 本地、跳板机，还是公网服务器？

4. 4. 这条路要存在多久？ 排查十分钟，还是承载长期业务？

答案清楚以后，工具通常不会再显得神秘：

固定目标，优先固定转发；目标很多，考虑 SOCKS；外部用户访问服务，考虑反向代理；临时联调，优先短期隧道。

下一篇可以继续追问另一个基础问题：公网 IP、私网 IP、IPv6 到底差在哪，为什么有了地址，服务还是访问不到？

涉及 SSH 隧道、代理和内网穿透时，只在获得授权的设备、账号和网络范围内使用；入口要最小化开放，调试结束及时关闭，并遵守所在组织制度和适用法律法规。