X11转发需服务器端启用X11Forwarding yes并重启sshd、客户端运行X Server（如Xming/VcXsrv/MobaXterm）、SSH连接时使用-X或-Y参数三者同时满足；DISPLAY值须与本地X Server实际监听地址一致，缺一不可。
能跑图形界面，但必须两端都配对成功，缺一不可。X11转发不是“开个开关就能用”，而是服务器端允许转发 + 客户端提供X Server + SSH连接时启用通道，三者同时成立才生效。
服务器端必须确认 X11Forwarding yes 且重启 sshd
很多问题卡在这一步：配置改了但没重启服务，或者改的是客户端的 /etc/ssh/ssh_config（完全无关）。只看服务器上的 /etc/ssh/sshd_config：
- 用
sudo vim /etc/ssh/sshd_config打开，确保这两行存在且为yes：X11Forwarding yesX11UseLocalhost no（后者避免 localhost 绑定导致本地 X Server 连不上） - 改完必须执行
sudo systemctl restart sshd，仅 reload 不生效 - 最小化系统常缺字体，顺手装上：
sudo apt install -y fonts-dejavu fonts-wqy-zenhei，否则中文乱码或窗口空白
Windows本地必须运行 X Server（如 Xming、VcXsrv 或 MobaXterm 内置）
SSH本身不带图形显示能力，Windows默认也没有X Server。你连上服务器后执行 xclock 报 Can't open display，90% 是因为本地根本没开X Server。
- Xming（v7.7）或 VcXsrv 都可，安装后务必勾选“Disable access control”或运行时加
-ac参数，否则会因权限拒绝连接 - MobaXterm 更省事：自带X Server，启动后默认开启，无需额外配置；但需在 SSH 新建会话时勾选
Enable X11 forwarding - 不要依赖 WSL2 的 GUI 支持来替代——那是另一套机制，和传统 X11 转发不兼容
ssh -X 和 ssh -Y 的区别直接影响 Qt/PyQt 程序能否启动
很多崩溃源于用了错误的标志。普通 GUI 程序（如 gedit、xclock）用 ssh -X 就够；但 Qt5/6、PyQt、Matplotlib（backend=Qt5Agg）等需要可信转发，否则报 qt.qpa.xcb: could not connect to display 或直接段错误。
-
ssh -X user@host：受限转发，适合简单工具，安全性高 -
ssh -Y user@host：可信转发，绕过部分 X11 认证检查，Qt 类程序基本依赖它 - 如果仍失败，登录后手动运行：
xhost +si:localuser:$USER（临时放行），但仅限可信内网
Docker 容器里跑 GUI 程序要额外挂载和授权
容器默认隔离了 X11 socket 和认证文件，直接 docker run -it ubuntu bash 后执行 xclock 必然失败。
- 必须挂载 X11 socket：
-v /tmp/.X11-unix:/tmp/.X11-unix - 必须传入 DISPLAY：
-e DISPLAY=host.docker.internal:0（macOS/WSL2）或-e DISPLAY=:0（Linux宿主机直连） - 必须处理 xauth：先在宿主机运行
xauth nlist $DISPLAY | sed -e 's/^..../ffff/' | xauth -f /tmp/.docker.xauth nmerge -，再挂载该文件并设-e XAUTHORITY=/tmp/.docker.xauth - 安全起见，容器启动前先运行：
xhost +local:docker，用完记得xhost -local:docker关闭
最常被忽略的一点：DISPLAY 值不是固定写死的。MobaXterm 默认是 localhost:10.0，VcXsrv 是 :0，Xming 可能是 :10.0——你得先在本地运行 echo $DISPLAY（Linux/macOS）或看 X Server 日志，再确保远程端的 DISPLAY 环境变量与之一致，否则所有图形请求都会发到错误地址。
