xshell端口原理 本地远程动态转发区别

在同一台 Windows 电脑上，Xshell 可以把远程网页接到本机端口，也可以让远程服务器访问本机服务，还能提供一个供应用使用的 SOCKS 入口。区分这三种方式，先看“入口在哪台机器”，再看“谁去连接最终服务”，设置时就不容易把地址和端口填反。

下面以 Windows 版 Xshell 8 为主线：本地电脑记为 P，已获授权的 Linux SSH 服务器记为 R。整个过程沿用这两台机器，不把本地、远程理解成数据只能单向传输。

本地、远程与动态转发的数据流向对比

1. 准备同一会话，分清 SSH 端口和业务端口

先用已经能正常登录 R 的 SSH 会话。打开会话列表，选中该会话，进入【属性】，核对连接协议、主机和服务器实际 SSH 端口。SSH 常用端口是 22，但服务器改过端口时应填写实际值。

连接属性中的 SSH 端口负责建立 P 与 R 之间的连接；后面设置的 18080、19000、1080 是转发入口，8000、9000 是示例业务端口。它们不需要与 SSH 端口一致，也不能靠修改 SSH 连接端口来替代转发规则。

为了分别观察效果，准备两个已经运行、能够辨认内容的测试 HTTP 服务：

• R 的回环地址 127.0.0.1:8000 提供“远端预览”页面。
• P 的回环地址 127.0.0.1:9000 提供“本机预览”页面。

先在各自机器上确认对应服务可访问，再做转发；端口规则不会自动启动网页程序。如果手头服务使用其他端口，把下面对应的业务端口一起替换。18080、19000、1080 也应选择各自监听机器上未被占用的端口。

本例的结果对应如下：

2. 添加本地转发，在本机打开远端页面

在该会话的【属性】中，依次进入【连接】→【SSH】→【隧道】，点击【添加】。英文界面对应 Connection → SSH → Tunneling。类型选择 Local（Outgoing，本地转发），按下面填写：

• 源主机：127.0.0.1。
• 侦听端口：18080。
• 目标主机：127.0.0.1。
• 目标端口：8000。
• 描述：远端预览。

若窗口提供【只接受本地连接】，保持启用。确认并保存会话属性，再重新连接，让这份保存的规则在新连接中生效。

在 Xshell 会话属性中配置本地转发规则

保持 Xshell 会话在线，在 P 的浏览器中访问 http://127.0.0.1:18080/。条件具备时，应看到 R 上“远端预览”的内容。

这条路径是：P 上的浏览器连接 P 的 18080，数据经过现有 SSH 连接到 R，再由 R 连接自己的 8000。本地转发的目标地址从 R 一侧访问，因此目标主机填 127.0.0.1，表示 R 自己，不是 P。

如果业务服务实际在 R 能访问的另一台内网机器上，目标主机才改为那台机器的内网地址，同时核对 R 到它的网络和权限。P 的 18080 只是入口，不能填进目标端口代替真正的业务端口。

3. 添加远程转发，让服务器访问本机页面

回到同一会话的【属性】→【连接】→【SSH】→【隧道】，再添加一条规则。类型改为 Remote（Incoming，远程转发），填写：

• 源主机：127.0.0.1。
• 侦听端口：19000。
• 目标主机：127.0.0.1。
• 目标端口：9000。
• 描述：本机预览。

保存后重新连接。在 R 的终端中，用已安装的 curl 请求：

curl --noproxy '*' http://127.0.0.1:19000/

这里的星号只让这次 curl 请求直接访问回环入口，不使用环境中的代理。配置与服务均正常时，返回内容应来自 P 上的“本机预览”。

配置远程转发并在服务器端使用 curl 验证

远程转发的入口在 R：R 上的程序连接 19000，数据经过 SSH 到达 P，再由 P 连接自己的 9000。远程转发的目标地址从 P 一侧访问；这一次，目标栏的 127.0.0.1 才表示 P。

本例只需要 R 自己访问该入口。OpenSSH 服务端默认把远程转发限制在回环地址，但服务器的 GatewayPorts 策略可能改变最终绑定方式，应以管理员核实的实际监听为准。不要把“已建立远程转发”理解成其他电脑已经能访问 R 的公网地址和 19000 端口。外部共享还涉及监听地址、服务端策略和访问控制，不能只靠在 Xshell 勾一个选项完成。

4. 添加动态转发，让应用选择最终目标

仍在同一隧道设置中添加规则，类型选择 Dynamic（SOCKS4/5，动态转发）。把本地监听地址设为 127.0.0.1，侦听端口设为 1080，保持仅接受本机连接。动态模式不填写固定目标主机和目标端口。

保存并重新连接后，P 上的 1080 是 SOCKS 代理入口。应用必须支持并明确使用 SOCKS，普通浏览器直接打开 1080 端口并不会出现管理网页。

以安装了 curl.exe 的 Windows 环境为例，在 P 的 PowerShell 中执行：

curl.exe --socks5-hostname 127.0.0.1:1080 --noproxy example.invalid http://127.0.0.1:8000/

其中 127.0.0.1:1080 指向 P 上的 SOCKS 入口，最后的 127.0.0.1:8000 则是通过隧道从 R 一侧访问的业务目标。example.invalid 只是这次请求的代理例外列表，不是访问目标；它避免环境中的 NO_PROXY 把回环目标排除在代理之外。

这次请求具备条件时，同样应取得“远端预览”。与本地转发的区别在于：8000 没有写死在 Xshell 规则中，而是由应用这次请求提供；换一个获准访问的目标，应用可以沿用同一个 SOCKS 入口。

如果应用使用域名，--socks5-hostname 会让代理一侧解析域名；使用普通 --socks5 则由本地解析。动态转发也不会自动接管所有程序的流量，不能把 SOCKS 入口填成 HTTP 代理，并期待两者通用。

配置 SOCKS 动态转发并通过命令行测试

5. 对照监听位置，定位填对规则却访问失败的环节

先观察失败发生在哪一步。如果提示本地端口无法绑定，检查 P 的 18080 或 1080 是否已被其他程序占用；远程 19000 申请失败，则核对 R 上的端口占用和服务端限制。更换入口端口后，访问地址或应用代理端口必须同步修改。

若 SSH 已登录、入口也存在，但目标连接失败，回到真正发起业务连接的一侧核对：本地和动态转发检查 R 能否访问目标，远程转发检查 P 能否访问目标。源主机是监听入口绑定地址，不是让你填写客户端来源白名单的位置。

在 Xshell 的【查看】→【隧道窗格】中查看转发规则和连接通道，可以辅助判断业务请求是否进入隧道。规则列在列表里，只能说明规则存在，不能单凭这一点断定网页服务已经可用。

如果日志明确提示转发被管理策略禁止，请管理员核对该账号实际生效的 AllowTcpForwarding、DisableForwarding，以及目标或监听限制 PermitOpen、PermitListen。能够打开 SSH 终端，不代表账号同时获准使用所有转发；不要通过反复改端口掩盖明确的策略拒绝。

6. 保存规则，再用新请求验证方向

确认本地转发时看到“远端预览”，远程转发时看到“本机预览”，动态请求取得的是应用指定的远端内容，而不是只检查页面是否能打开。

再把本地转发的侦听端口从 18080 改为另一个空闲端口，例如 18081，保存并重新连接，随后使用新端口访问。目标端口仍保留 8000，页面内容也应继续来自 R。这个变化能帮助区分“入口端口”和“业务端口”。

长期使用的规则保存在会话属性中。如果是在已连接会话的隧道窗格临时添加规则，还应明确保存到会话文件；未保存的临时规则会随连接关闭而消失。关闭 SSH 连接后，新请求也失去这条隧道，浏览器已显示的缓存页面不能作为仍连通的证据。

最终保留该会话和端口对应记录即可。三种方式都依靠 P 与 R 之间的 SSH 连接承载双向业务数据；SSH 加密覆盖这段连接，服务离开 SSH 端点后是否继续加密，还要看业务协议和目标网络。

6. 保存规则，再用新请求验证方向