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

下载

• axios 1.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中硬编码

实际调试时最容易卡住的点，不是代理地址写错，而是默认以为Node会自动继承环境变量——它只在启动瞬间读一次，且很多库压根不看。动手前先确认process.env.HTTP_PROXY有值，再验证代理连通性，比盲目改配置快得多。