VSCode Tunnel 启动失败主因是网络策略拦截 outbound 连接，需直连 tunnelrelay.io:443；共享链接仅限同 Microsoft 账户访问 7 天，不支持调试协同与自定义域名，所有运行时行为严格绑定本地。
VSCode Tunnel 启动后提示 Failed to start tunnel
根本原因通常是本地网络策略或代理拦截了 code tunnel 的 outbound 连接，尤其是企业内网或启用了防火墙/安全软件的环境。VSCode Tunnel 依赖微软托管的中继服务（tunnelrelay.io），必须能直连该域名和端口（默认 HTTPS 443）。
实操建议：
- 先在终端运行
code tunnel login，观察是否卡在「Opening browser…」——若打不开或跳转失败，说明系统默认浏览器被策略限制，改用code tunnel login --cli手动复制授权码 - 检查是否设置了全局
HTTP_PROXY或HTTPS_PROXY：Tunnel 默认不走系统代理，如需走代理，必须显式加--proxy-server参数启动 - 杀掉残留进程：
pkill -f "code-tunnel"再重试，旧进程占端口会导致启动失败
如何让同事通过链接直接打开你的本地项目文件
Tunnel 本身不共享整个工作区，而是共享「当前打开的文件夹」；链接有效期默认 7 天，且仅对登录了同一 Microsoft 账户的人有效（权限由 VSCode 服务端控制，无法绕过）。
实操建议：
- 确保启动前已用
code .在目标项目根目录下打开了窗口，否则生成的链接只指向空工作区 - 运行
code tunnel share --name "my-api-dev"，名字不能含空格或特殊字符，否则链接解析失败 - 生成的链接形如
https://my-api-dev.tunnels.api.visualstudio.com，打开后自动加载你本地的文件树和已打开的编辑器标签页——但不包括终端历史、调试断点等运行时状态 - 如果同事看到「Loading workspace…」一直转圈，大概率是你本地 VSCode 窗口已关闭或
code tunnel进程意外退出，需重新 share
为什么 code tunnel 不支持自定义域名或反向代理
这是设计使然：Tunnel 的域名、证书、中继路由全部由 VSCode 云服务统一管理，客户端无权配置。你无法把 tunnels.api.visualstudio.com CNAME 到自己的域名，也不能用 Nginx 做前置代理——所有流量必须经微软中继节点加密转发。
这意味着：
- 无法隐藏你正在使用 VSCode Tunnel（URL 明确暴露服务商）
- 无法集成到公司已有 SSO 流程，只能依赖 Microsoft 账户登录
- 国内用户可能遇到连接延迟高、偶尔掉线的问题，这是中继节点物理距离导致的，非配置错误
- 若需要完全可控的隧道，得换方案：比如
ssh -R搭配公网 VPS，或frp自建中继
本地调试时断点不触发，但代码能正常运行
Tunnel 共享的是编辑能力，不是调试会话。远程用户打开的只是「只读镜像」——他们能看到你设的断点标记（蓝色圆点），但实际调试进程仍在你本地运行，且仅响应你本机的 VSCode 实例。
换句话说：
- 同事点击「Start Debugging」会失败，报错
No debug adapter found for type 'node'（或对应语言） - 你本地的调试控制台、变量监视、调用栈，同事完全看不到；反之亦然
- 唯一协同调试方式是：你开启 Tunnel，同事用自己本地环境复现问题，再通过聊天共享日志或截图
- 如果真要共调，得用
Remote - SSH连到同一台机器，或改用 VSCode Live Share（但 Live Share 已于 2023 年 10 月停服）
Tunnel 的边界很清晰：它解决的是「跨网络访问编辑界面」这一个点，不是远程开发平台。容易被忽略的是——所有「运行时行为」（终端执行、调试、任务启动、扩展后台进程）都严格绑定在发起 code tunnel share 的那台机器上，且无法代理、转发或共享。
