vscode调试node.js时，http.proxy设置对调试进程无效，必须在launch.json的env字段中显式配置http_proxy和https_proxy环境变量，且需注意代理协议、认证编码及第三方库（如axios、node-fetch）的代理适配问题。
launch.json里配proxy环境变量才生效
VSCode调试Node.js时，http.proxy设置项对调试进程完全无效——它只管VSCode自身请求（如插件市场），不管你的Node进程。想让node发的HTTP请求走代理，必须在launch.json里显式注入环境变量。
-
env字段下加"HTTP_PROXY": "http://127.0.0.1:7890"和"HTTPS_PROXY": "http://127.0.0.1:7890"（注意：不是https://，多数本地代理HTTP端口不支持HTTPS协议） - 若代理需认证，URL编码密码中的
@或:，例如user:p%40ss@127.0.0.1:7890 - Node进程默认不读系统
HTTP_PROXY环境变量，除非你用process.env.HTTP_PROXY手动读取并传给axios或fetch——但直接塞进env更可靠
为什么fetch/axios仍不走代理？检查底层库是否忽略环境变量
Node原生http/https模块会读HTTP_PROXY，但很多第三方库（如旧版axios、node-fetch）默认不遵循，需显式配置代理选项。
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
-
axios1.x必须手动传proxy配置：{ proxy: { host: '127.0.0.1', port: 7890 } } -
fetch（node-fetch或undici）不自动读环境变量，得用agent：new Agent({ host: '127.0.0.1', port: 7890 }) - 验证是否生效：在代码里加
console.log(process.env.HTTP_PROXY)，确保launch.json注入成功；再用curl -x http://127.0.0.1:7890 https://httpbin.org/ip确认代理本身通
证书错误DEPTH_ZERO_SELF_SIGNED_CERT怎么绕过
Charles/Fiddler/mitmproxy等工具用自签名证书，Node默认拒绝，表现为request to https://... failed, reason: certificate has expired或类似报错。
- 临时方案：在
launch.json的env里加"NODE_TLS_REJECT_UNAUTHORIZED": "0"（仅限调试，勿提交到代码库） - 更安全的做法：把代理的根证书导入Node信任链，但操作复杂且跨平台不一致；
NODE_TLS_REJECT_UNAUTHORIZED=0是最快验证代理是否工作的手段 - 注意：这个环境变量对
https模块生效，但对某些封装库（如axios）可能无效，此时仍需在请求层单独关SSL校验
Remote-SSH场景下代理配置失效的真正原因
你在本地launch.json里配了HTTP_PROXY，但远程服务器上跑的Node进程根本收不到——因为VSCode的调试器不会把本地环境变量透传过去。
- 必须在远程机器的
~/.bashrc或~/.zshrc里export HTTP_PROXY=http://192.168.1.100:7890（用局域网IP，别用127.0.0.1） - 确保远程代理服务开启
allow-lan（Clash需设allow-lan: true；Fiddler勾选“Allow remote computers to connect”） - SSH连接后执行
echo $HTTP_PROXY验证环境变量已加载；若没输出，说明shell未source配置文件，可改用env字段在launch.json中硬编码
process.env.HTTP_PROXY有值，再验证代理连通性，比盲目改配置快得多。
