Node调试超时主因是launch.json中program路径错误、node命令不可达或--inspect未启用；需验证node -v、用${workspaceFolder}写program、Web服务改用request:"attach"并指定port，TS项目须配准sourceMaps。
Node调试超时，先看launch.json里program路径对不对
VSCode调试Node.js时卡在“正在启动调试器”，大概率不是代理问题，而是program字段指向了一个不存在的文件。VSCode不会报错，只默默失败——断点灰掉、控制台没输出、F5后几秒就停。
-
program必须是绝对路径（用${workspaceFolder}拼接），不能写src/index.js或./src/index.js - 确认该JS文件真实存在，且不是TS源码（TS需先编译，或改用
type: "pwa-node"+runtimeArgs） - 终端里执行
node -v和which node，确保VSCode启动方式能继承PATH（macOS/Linux建议从终端输code .启动）
代理只影响插件市场和AI功能，不影响Node调试本身
很多人把“调试超时”和“插件装不上”混为一谈。VSCode的Node调试器走的是本地进程通信（--inspect端口直连），不经过HTTP代理；而插件市场、Copilot、Live Share这些才真正依赖HTTP_PROXY或http.proxy设置。
- 如果你能正常运行
node --inspect-brk index.js并在浏览器chrome://inspect看到目标，说明Node调试链路完好，代理配置与此无关 - 插件市场打不开、Copilot一直转圈、Live Share提示“handshake failed”，才需要查代理
- 代理填错（比如漏写
http://前缀）、SOCKS5未转HTTP、NTLM认证未处理，都会导致这类网络请求超时
真要配代理，优先用环境变量而非VSCode设置
http.proxy设置在VSCode里容易失效，尤其双击图标启动时根本读不到。系统级环境变量更可靠，但必须注意启动方式是否继承。
- Linux/macOS：在
~/.zprofile（不是.zshrc）里加export HTTPS_PROXY=http://127.0.0.1:7890，然后source ~/.zprofile && code --new-window - Windows：系统环境变量里设
HTTPS_PROXY，重启资源管理器或重装VSCode快捷方式 - 验证代理是否生效：
curl -x http://127.0.0.1:7890 https://marketplace.visualstudio.com应返回HTML - 别信
VSCODE_PROXY_SUPPORT——这变量根本不存在，是网上误传
Node版本不匹配会伪装成“超时”，实际是协议不兼容
VSCode调试器依赖V8 Inspector协议，不同Node版本支持的参数和响应格式不同。用v24.x或v12.x这种非LTS版本，常表现为连接建立后立刻断开，日志里出现ERR_INSPECTOR_NOT_AVAILABLE或connection closed。
- 稳定组合：Node v16.20.2 / v18.20.4 / v20.12.2 + VSCode ≥ 1.85.0
- 检查方式：
node --version+ VSCode菜单 Help → About - nvm用户务必用
nvm use切换后再启动VSCode，否则可能加载旧版本Node - TS项目还要确认
tsconfig.json里"sourceMap": true已开启，否则调试器解析慢到触发超时
program路径少了个/，或者Node版本根本不在支持列表里。调试链路上每个环节都得单独验证，不能靠猜。 
