已解决：同一ip下，Mac和Windows同时用vscode连接某个Linux远程服务器后，Mac再次连接时无法正确打开远程文件夹，由于转发设置导致

同一ip下，Mac和Windows同时用vscode连接某个Linux远程服务器后，Mac再次连接时无法正确打开远程文件夹，由于转发设置导致

问题描述：

• 我用 mac 上的 vscode 打开远程服务器，左下角明明已经显示是服务器ip，但点击打开文件夹，发现文件夹是自己的电脑而不是远程的（说明根本没连上远程），而且试图打开 vscode 在远程服务器上的 terminal 按键也失败。
• mac 仍然能通过在命令行 ssh 连接服务器。
• windows 仍然能用 vscode 打开远程服务器、在命令行 ssh 连接服务器。
• 由于没有 terminal ，使用 Cmd + Shift + P 调出 Remote-SSH: Show Log，主要报错如下：

[22:45:29.398] Failed to set up socket for dynamic port forward to remote port 12345: Socket closed. TCP port forwarding may be disabled, or the remote server may have crashed. See the VS Code Server log above for details.
......
"remote.SSH.useLocalServer": false,
"remote.SSH.enableDynamicForwarding": false

最终解决方案

1. 打开 VSCode
2. Cmd + Shift + P，打开 Preferences: Open User Settings (JSON)
3. 加入：

"remote.SSH.useLocalServer": false,
"remote.SSH.enableDynamicForwarding": false

4. 保存，完全退出 VSCode
5. 重新打开再连

原理解释

by GPT：我给你讲清楚 底层机制，而不是表面现象。

---

一、VSCode Remote-SSH 的三层结构

当你连接远程时，实际上有三层组件：

[ VSCode UI ]
        ↓
[ 本地 SSH helper / local server ]
        ↓
[ 远程 vscode-server (node 进程) ]

问题就出在 中间这一层。

---

二、remote.SSH.useLocalServer = true 时发生什么？

默认情况下（你日志里看到的）：

remote.SSH.useLocalServer = true
remote.SSH.enableDynamicForwarding = true

VSCode 不会直接：

ssh 用户名@服务器

它会：

① 在本地启动一个"local server"进程

② 这个进程负责建立一个 SOCKS 动态端口转发：

ssh -D 本地端口 用户名@服务器

③ 然后通过这个 SOCKS 通道去连接远程 vscode-server

也就是说：

VSCode → 本地 node 代理 → 动态端口转发 → 远程 node

---

三、你的错误为什么发生

你日志里关键报错：

Failed to set up socket for dynamic port forward
Socket closed.
TCP port forwarding may be disabled

这说明：

服务器允许 SSH 登录

但拒绝了动态端口转发（-D）

在共享服务器上非常常见。

管理员可能在 sshd_config 里设置了：

AllowTcpForwarding no

或者对部分用户禁用。

于是：

• SSH 登录成功
• 远程 server 进程存在
• 但 SOCKS 通道建立失败
• 本地 helper 进程认为"server 在"
• 但 exec 通道无法建立
• 最终表现为"假连接 + Terminal 打不开"

---

四、你改了这两项后发生了什么？

1️⃣ "remote.SSH.useLocalServer": false

这会让 VSCode：

不再启动那个本地 node 代理层。

结构变成：

VSCode 直接通过 SSH 子进程连接远程

少了一层中间代理。

---

2️⃣ "remote.SSH.enableDynamicForwarding": false

这会让 VSCode：

不再使用：

ssh -D

而改用：

ssh -L 固定端口转发

也就是普通 TCP 本地端口转发，而不是 SOCKS 动态代理。

很多服务器会：

允许 -L

禁止 -D

这就是你能连上的原因。

---

五、核心差异总结

机制	是否用 SOCKS	是否依赖动态转发	共享服务器兼容性
默认模式	是	是	❌ 容易被禁
你现在模式	否	否	✅ 更稳定

---

六、为什么多人服务器更容易出问题？

因为：

• 动态端口转发可以被用作代理
• 可以绕过防火墙
• 可以访问内网
• 安全风险高

所以很多实验室 / 公司服务器默认禁用。

但：

普通本地端口转发（-L）一般不会禁。

---

七、为什么 Windows 可能没问题？

可能原因：

1. Windows 用的是旧版 VSCode，和 Mac 不同；或 Remote-SSH 插件版本不同
2. Windows 没启用 local server
3. Windows 走的是不同 SSH client
4. 服务器针对不同 IP 策略不同
5. useLocalServer 默认是 false

而同一个 ip 下连接 Windows，应该不会导致问题。

SSH 服务器识别的是：用户名 + 认证方式 + 会话，不是"设备"。

只要你没有触发 fail2ban、没有输错密码多次、没有超过 MaxSessions 限制，那么：

👉 同一个公网 IP 同时连 10 台机器都没问题

👉 不会导致 port forwarding 被禁

你在 Windows 上开着一个 VSCode Remote 会话，这个是唯一可能有一点点关联的情况。

因为：

1. 每个 VSCode 客户端都会启动一个远程 vscode-server
2. 会监听一个随机端口
3. 每个客户端都有自己的 execServerToken

如果Windows 那边还连着，Mac 又连，有时会出现：复用已有 server，但 token 不匹配。

不过这种情况下的报错通常是：

• exec server mismatch
• authentication failed

不是你现在的 dynamic forwarding 错误。

---

八、你现在的配置是"更原始、更稳定"的模式

你现在的连接路径：

VSCode
   ↓
ssh -L 本地端口:远程端口
   ↓
远程 vscode-server

少了 SOCKS 层。

结构更简单。

在受限环境更可靠。

---

九、你学到的真正底层知识

当看到：

Socket closed
dynamic port forward

你应该立刻想到：

ssh -D 被禁

而不是：

• vscode-server 坏了
• 本地缓存炸了
• node 进程残留

---

十、专业结论

你不是修好了一个"VSCode bug"。

你是：

把连接模式从 SOCKS 动态转发

切换成了静态端口转发。

这就是根因。