remote-tunnels 最小网络连通性要求：远端机器无需公网ip，但必须同时满足——能解析并访问 vscode.dev 和 tunnel.api.visualstudio.com；dns 可用；出向 https（443）与 websocket（wss://）不被拦截。
Remote-Tunnels 不能在无公网环境下工作——它依赖 Microsoft 的中继服务，远端机器必须能访问 vscode.dev 和相关 Azure 后端域名（如 tunnel.api.visualstudio.com），哪怕只是出向 HTTPS 请求。所谓“无公网”若指完全断网、NAT 封死、防火墙全阻，则 Remote-Tunnels 直接不可用。
Remote-Tunnels 要求的最小网络连通性是什么？
远端机器不需要公网 IP，但必须满足以下三点同时成立：
- 能解析并访问
vscode.dev（用于前端加载）、tunnel.api.visualstudio.com（用于隧道注册与心跳） - DNS 可用（常见失败是内网 DNS 不转发外部域名，或 hosts 写错）
- 出向 HTTPS（443）和 WebSocket（wss://）不被拦截；企业代理、透明防火墙、Clash/Surge 的 TUN 模式常静默丢弃 wss 流量
典型“假离线”场景：机器能 ping 通 8.8.8.8，但 curl -v https://vscode.dev 超时，或 telnet tunnel.api.visualstudio.com 443 拒绝连接——这说明不是“无公网”，而是网络策略限制，需协调运维放行特定域名。
为什么左下角显示 Tunnel Ready 却打不开 URL？
状态栏出现头像 + Tunnel Ready 只代表本地隧道进程已启动，不保证 URL 可达。常见断点：
- 复制的 URL 里混入换行或空格，浏览器实际请求的是
https://vscode.dev/tunnel/xxx-%0Ayyy这类非法地址 - 访问端浏览器未登录同一 Microsoft 账户（GitHub 登录无效），或 Safari 启用了“阻止跨站跟踪”，导致 OAuth 重定向失败
- URL 中的隧道 ID（如
xxx-yyy-zzz）有 15 分钟有效期，过期后页面提示Invalid tunnel ID
验证方式：在远端机器终端执行 code tunnel list，确认输出中 Status 为 active，且 Expires 时间未过期。
Remote-Tunnels 在受限网络下的替代方案
如果确认无法满足上述网络条件，Remote-Tunnels 不是唯一路径。更可行的替代组合：
- 用
Remote-SSH+ 内网 SSH 跳转：只要远端机器开放 SSH 端口（22），且你能在本地通过ssh user@host连通，就能绕过所有 Web 依赖 - 用
Remote-Containers+ 预置镜像：把devcontainer.json和定制 Docker 镜像（含预装的vscode-server二进制）打包进离线介质，直接在目标机运行 - 纯本地容器开发：用
docker run -it -v $(pwd):/workspace -p 3000:3000 node:18启一个带 shell 的容器，在里面手动拉代码、装依赖、跑服务，VS Code 仅作为本地编辑器，不启用任何 Remote 扩展
Remote-Tunnels 的设计初衷是解决“没有固定 IP、没有运维权限、但能联网”的轻量协作场景，不是为物理隔离环境准备的。强行在断网机器上折腾登录、授权、命令面板，只会反复触发 Failed to start tunnel server: permission denied 或静默无响应——问题不在操作步骤，而在前提不成立。
