必须设成localhost:0.0，而非本机IP；SSH X11转发自动设置DISPLAY为localhost:10.0，远程端应保持默认，避免手动覆盖；VcXsrv需禁用Native OpenGL并启用Disable access control；服务端必须配置X11UseLocalhost no且重启sshd。
DISPLAY环境变量设成 localhost:0.0 还是本机IP:0.0？
必须设成 localhost:0.0，不是本机IP。SSH X11转发会在远程端自动创建一个指向本地X Server的代理套接字（通常是 /tmp/.X11-unix/X10），并把 DISPLAY 设为 localhost:10.0 或类似值——这个“localhost”指的不是你本地Windows机器，而是远程Linux上的SSH daemon进程视角下的回环地址。强行改成 192.168.x.x:0.0 会导致连接被拒绝，因为VcXsrv/Xming默认只监听 127.0.0.1 或通配地址，但SSH隧道不走TCP直连，走的是Unix域套接字转发。
验证方法：SSH登录后直接运行 echo $DISPLAY，正常应输出类似 localhost:10.0；如果手动改过，反而要删掉 ~/.bashrc 里那行 export DISPLAY=...，否则会覆盖SSH自动设置。
VcXsrv启动时“Native OpenGL”勾选导致Matplotlib/RViz闪退
这是Windows下最隐蔽也最高频的崩溃原因。VcXsrv默认勾选“Native OpenGL”，但它在多数集成显卡或远程桌面环境下与OpenGL上下文初始化冲突，尤其影响依赖GLFW、Qt5Agg后端的程序。
- 启动XLaunch向导时，务必在“Extra settings”页取消勾选
Native opengl - 勾选
Disable access control——否则远程Linux无法通过TCP连接到你的X Server（即使走SSH隧道，部分库仍会尝试直连） - 选择
Multiple windows，不要选“Single window”，后者会让所有GUI窗口挤在一个容器里，调试和交互极不方便 - Display number 保持默认
0即可，对应DISPLAY=localhost:0.0中的0
sshd_config里 X11UseLocalhost no 是Windows专属救命配置
OpenSSH服务端默认设 X11UseLocalhost yes，意味着它只允许来自 127.0.0.1 的X11连接。但VcXsrv监听的是 0.0.0.0:6000（通配地址），而SSH隧道建立的代理端口实际走的是本地回环，逻辑上没问题——可偏偏Windows防火墙+WSL兼容层有时会干扰这一路径。设为 no 强制让SSH使用通配绑定，绕过所有回环校验。
必须同时确认以下三项未被注释且值正确：
X11Forwarding yesX11UseLocalhost noAllowTcpForwarding yes
改完立刻执行 sudo systemctl restart sshd，否则配置完全不生效——很多人卡在这一步，以为改了就完事。
VSCode Remote-SSH连接后图形仍不显示？检查这三件事
Remote-SSH插件本身不处理X11，它只是建立SSH通道。图形能否出来，取决于底层SSH是否启用X11转发，而不是VSCode界面有没有“X11”按钮。
- Windows客户端SSH配置：编辑
$env:ProgramData\ssh\ssh_config，确保有ForwardX11 yes和ForwardX11Trusted yes - 远程Linux端必须已安装
xauth（sudo apt install xauth），否则SSH无法生成X11认证cookie - 终端里运行
xclock测试最可靠——别用Python脚本先试，因为Matplotlib默认后端可能静默失败；xclock是X11协议最小闭环，成功即说明链路通
真正容易被忽略的是：VcXsrv图标在系统托盘右下角，一旦被误点关闭，所有转发立即中断，且无任何错误提示——你只会看到程序卡住或报 Can't open display。每次重启VcXsrv都要重新验证 xclock。
