VS Code+Remote SSH+WSLg实现X11转发失败原因咨询

核心差异在于VSCode Remote-SSH调用的是Windows系统自带的OpenSSH客户端，而非WSL环境内的SSH客户端，两者的网络上下文完全隔离：

1. 你在WSL内执行ssh -X yyy@xxx-ubuntu能成功的原因：
   WSL环境里的SSH客户端会把远程Ubuntu的X11流量转发到WSL内部的localhost:10.0，而WSLg的X11服务器正好在WSL环境中监听这个地址，因此能正常接收并渲染GUI。

2. VSCode Remote-SSH连接时失败的原因：
   VSCode用的是Windows系统的OpenSSH客户端，它会将远程Ubuntu的X11流量转发到Windows系统的localhost（和WSL的localhost不是同一个网络空间）。但WSLg的X11服务器运行在WSL隔离环境内，没有暴露到Windows系统的网络栈中，所以Windows的localhost:10.0无法连接到WSLg的服务，导致报错Can't open display: localhost:10.0。

3. 安装Xming后正常运行的原因：
   Xming是直接运行在Windows系统中的X11服务器，会监听Windows系统的localhost端口，正好能接收Windows OpenSSH客户端转发的X11流量，因此GUI可以正常显示。

如果想让WSLg配合VSCode Remote-SSH实现X11转发，可通过以下步骤配置：

• 临时生效方案：

  1. 在WSL环境中执行echo $DISPLAY，记录下类似localhost:10.0或:0的输出值。
  2. 在VSCode的远程Ubuntu终端中执行：

     export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0
     

     这里的/etc/resolv.conf中的nameserver是WSL网关地址，也就是Windows访问WSL的入口，通过这个地址可让远程Ubuntu的X11流量转发到WSLg的X11服务器。
  3. 再次运行xeyes等GUI程序，即可正常显示。

• 永久生效方案：
  修改远程Ubuntu的~/.bashrc或~/.zshrc，自动配置DISPLAY变量：

  echo 'export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '\''{print $2}'\''):0' >> ~/.bashrc
  source ~/.bashrc
  

  之后每次通过VSCode Remote-SSH连接，都会自动加载正确的DISPLAY配置。

内容的提问来源于stack exchange，提问作者nmatter