我之前也碰到过一模一样的情况——xeyes、xclock这类轻量X程序能正常跑，但一启动Firefox这类浏览器就跳X11授权错误，折腾了好一阵才找到几个可行的办法，你可以挨个试试：

方案1：强制浏览器使用PuTTY的X11代理 #

有些浏览器（比如Firefox）会尝试直接连接X服务器，而非通过PuTTY提供的代理，这就会触发授权问题。你可以通过设置环境变量强制它走代理：

• 在远程Ubuntu的终端里，先执行：

  export NO_AT_BRIDGE=1
  

• 接着再启动Firefox：

  firefox
  

这个变量会让Firefox老老实实通过PuTTY的X11代理通道连接，大部分情况下能直接解决问题。

方案2：手动导入X11授权信息 #

有时候PuTTY自动传递的授权信息对浏览器不生效，你可以手动把本地X服务器的授权条目加到远程：

1. 本地Win11端：打开你用的X服务器软件（比如VcXsrv），如果是临时测试，可以在启动时勾选「Disable access control」（测试完记得改回来，避免安全风险）。然后打开X服务器自带的终端，执行：

   xauth list
   

   你会得到类似这样的条目：localhost:10 MIT-MAGIC-COOKIE-1 abcdef1234567890
2. 远程Ubuntu端：先确认当前的DISPLAY变量：

   echo $DISPLAY
   

   比如你的是server:10.0，对应上面条目中的localhost:10。然后把本地拿到的授权条目加到远程：

   xauth add localhost:10 MIT-MAGIC-COOKIE-1 abcdef1234567890
   

   替换成你自己拿到的Cookie值和显示编号，之后再启动浏览器试试。

方案3：检查PuTTY的X11转发设置 #

可能是PuTTY的X11配置有疏漏，重新检查一下：

• 打开PuTTY的会话设置，导航到「Connection > SSH > X11」：
  • 确保「Enable X11 forwarding」已经勾选。
  • 把「X display location」设置为:0（对应本地X服务器的默认显示端口）。
  • 勾选「MIT-MAGIC-COOKIE-1」，取消「X authority file for local display」的手动指定，让PuTTY自动处理授权文件。
• 保存会话设置，重新连接远程服务器，再尝试启动浏览器。

方案4：换用兼容性更好的工具 #

如果上面的方法都不管用，可以试试换个SSH客户端：

• 如果你本地Win11装了WSL，可以直接用WSL的终端执行ssh -X <远程用户名>@<远程IP>，原生SSH的X11转发对浏览器的兼容性有时候比PuTTY好。
• 或者换用MobaXterm，它自带了X服务器，X11转发的兼容性更强，对浏览器这类程序的支持更稳定，很多时候能直接绕过这类授权问题。

补充说明 #

为什么轻量X程序正常，浏览器却报错？因为xeyes、xclock这类程序严格遵循X11转发的代理规则，而浏览器（尤其是Firefox）有自己的网络连接逻辑，有时候会跳过PuTTY的代理直接请求X服务器，导致授权验证失败。

备注：内容来源于stack exchange，提问作者Isaakfire