我之前也碰到过几乎一模一样的情况——终端SSH连Azure VM完全正常，可一在VS Code里点“打开文件夹”就直接超时断开，折腾了好一阵才摸清楚几个核心排查方向，给你详细说说：

一、先聚焦VS Code Server启动的特殊需求 #

单纯的SSH终端只需要维持一个交互式会话，但点击“打开文件夹”时，VS Code会在远端VM上启动vscode-server进程，这个过程要同步本地配置、拉取依赖组件，比普通SSH会话对网络和资源的要求高得多，很容易暴露终端会话没触发的问题：

• 手动测试vscode-server启动：
  1. 终端SSH连到VM
  2. 从本地VS Code的「帮助-关于」里记下你的版本号（比如1.89.1）
  3. 手动下载对应版本的vscode-server包，解压后运行里面的server.sh脚本，看看会不会出现超时、拉取失败的报错——如果这里就卡，那就是VM的网络或者权限问题导致server启动失败
• 绕开本地SSH代理：在本地VS Code的settings.json里添加"remote.SSH.useLocalServer": false，有些本地SSH代理会干扰vscode-server的传输

二、Azure网络层面的隐性限制 #

虽然终端SSH能通，但Azure的NSG（网络安全组）、NAT规则经常有容易被忽略的限制：

• 检查NSG出站规则：vscode-server启动时需要从微软服务器拉取依赖，必须确保VM的NSG出站规则允许**443端口（HTTPS）**的出站请求，我当时就是这个坑——终端SSH不需要出站443，可server启动必须要，被限制后直接超时断开
• 检查NAT连接超时：有些Azure NAT规则会把空闲连接的超时时间设得很短（比如300秒），vscode-server拉取依赖时可能有短暂的静默等待阶段，被判定为空闲直接踢掉连接，可以把NAT超时时间调长到1800秒试试
• 临时关闭加速网络：部分Azure VM的加速网络和VS Code Remote-SSH的兼容性有问题，在Azure门户里找到VM的网络接口，临时禁用加速网络测试

三、文件权限的深层细节 #

你已经检查了home目录的权限，但还有几个容易漏的点：

• 测试非home目录：在VM上手动建个测试目录mkdir /home/azureuser/test-vscode，然后在VS Code里打开这个目录，如果能正常打开，说明你的home目录里有特殊权限的文件/目录（比如隐藏的系统配置文件）导致server访问出错
• 检查用户环境变量：虽然你说.bashrc和.profile没异常，但可以试试在终端SSH里运行env -i ssh azureuser@<public_ip>（清空环境变量后SSH），如果这样连VS Code也能打开文件夹，那就是某个环境变量干扰了server启动
• 测试root用户：如果VM允许root SSH，试试用root用户在VS Code里打开目录，如果正常，那就是普通用户的权限或者目录权限的问题（比如home目录的ACL有隐藏限制）

四、VS Code本地配置的冲突排查 #

• 禁用其他扩展：只保留Remote-SSH扩展，有些文件同步、系统监控类的扩展会和Remote-SSH的文件系统访问逻辑冲突
• 重置Remote-SSH配置：删除本地~/.vscode/extensions/ms-vscode-remote.remote-ssh-<你的版本号>目录，然后重新安装Remote-SSH扩展，避免扩展文件损坏
• 检查本地SSH配置：打开~/.ssh/config，如果给这个VM设置了ProxyCommand、ControlMaster这类参数，临时注释掉试试，这些参数有时候会和VS Code的SSH客户端逻辑不兼容

快速定位的小技巧 #

把VS Code的Remote-SSH日志级别拉满：在设置里搜索remote.SSH.logLevel，设为trace，然后再试一次打开文件夹，日志里会显示server启动的每一步——是卡在拉取依赖？还是权限拒绝？还是网络超时的具体阶段，能帮你快速缩小范围

我当时就是NSG出站规则限制了443端口，改完规则后立刻就正常了，你可以先从这个方向入手排查，应该能解决问题！