npm代理配置冲突导致网络请求失败，需依次检查并清除全局/用户级npm代理、系统环境变量代理、nvm残留配置及企业证书设置，确保各层级代理一致且适配当前网络环境。

npm config get proxy 返回非空值，但实际网络请求失败

这是多用户环境里最典型的代理冲突信号。系统级或用户级 npm 配置中残留了过期的 proxy 或 https-proxy，而当前网络环境（比如公司内网切换、Wi-Fi 切换到手机热点）已不再适用该代理，导致 npm install 卡在 CONNECTING 或直接报 ETIMEDOUT。

关键判断点：npm config get proxy 和 npm config get https-proxy 都返回非空字符串，但 curl -I https://registry.npmjs.org 能通，npm view lodash version 却超时。

• 先查作用域：运行 npm config list --global 和 npm config list --user，对比两者的 proxy 字段是否一致、是否被重复设置
• 再看优先级：npm 会按 project → user → global → builtin 顺序合并配置，只要任意一级设了 proxy，就可能生效；用 npm config get proxy --global 明确指定范围排查
• 清除方式：执行 npm config delete proxy --global 和 npm config delete https-proxy --global，再检查 --user 级别（路径通常是 %APPDATA%\npm\etc\npmrc 或 ~/.npmrc）

VSCode 终端继承了错误的代理环境变量

即使 npm config 已清空，VSCode 的集成终端仍可能从父进程（如 Windows 登录会话、Shell 启动脚本）继承了 HTTP_PROXY / HTTPS_PROXY 环境变量。这类变量会绕过 npmrc 配置，直接被 Node.js 的 https 模块读取，造成静默代理失败。

验证方法：在 VSCode 终端运行 echo $env:HTTP_PROXY（PowerShell）或 echo %HTTP_PROXY%（CMD），若输出非空，且与当前网络不匹配，就是根源。

Rydberg Agent Node

使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r

下载

• 临时规避：在 VSCode 终端启动时加前缀，例如 $env:HTTP_PROXY=""; $env:HTTPS_PROXY=""; npm install
• 永久修复：不要在系统级环境变量中设代理；若必须设，请确保只在特定 Shell 配置文件（如 ~\Documents\PowerShell\Microsoft.PowerShell_profile.ps1）中按需启用，并加条件判断
• VSCode 特定处理：在 .vscode/settings.json 中添加 "terminal.integrated.env.windows": { "HTTP_PROXY": "", "HTTPS_PROXY": "" }，可隔离终端环境

nvm-windows 切换版本后 proxy 配置残留

使用 nvm-windows 时，每次 nvm use 会切换 Node.js 软链接，但不会自动重载 npm 配置。旧版本 Node 对应的全局 npmrc 文件（如 C:\Users\用户名\AppData\Roaming\nvm\v16.20.2\node_modules\npm\npmrc）可能含硬编码 proxy，新版本启动后仍沿用该文件路径下的配置。

典型现象：nvm use 18.18.2 后 npm config get proxy 仍返回 v16 时代的地址。

• 定位真实配置文件：运行 npm config list -l，查看 prefix 对应路径下的 etc\npmrc 是否被修改过
• 安全清理：手动编辑该路径下的 npmrc，删掉 proxy=... 行；或直接删掉整个 etc 目录（nvm 会重建默认配置）
• 避免复发：禁用 nvm 的 auto-use 功能，在 nvm settings.txt 中设 node_mirror: https://npmmirror.com/mirrors/node/ 和 npm_mirror: https://npmmirror.com/mirrors/npm/，减少对公网 registry 的依赖

企业网络下证书与代理双重叠加失效

当公司强制 HTTPS 代理并注入自签名根证书时，npm 既要用代理转发请求，又要验证证书链。若 cafile 指向的证书文件路径在多用户环境下权限受限（比如只对管理员可读），或 strict-ssl=false 被全局开启但代理本身不支持非加密隧道，就会出现 UNABLE_TO_GET_ISSUER_CERT_LOCALLY 或 SELF_SIGNED_CERT_IN_CHAIN。

这不是单纯关掉 strict-ssl 就能解决的——它掩盖了证书信任链断裂的本质。

• 检查证书路径有效性：运行 npm config get cafile，然后用 Get-Content（PowerShell）确认该文件存在且内容是 PEM 格式证书
• 验证证书是否被系统信任：双击证书文件 → “安装证书” → 选择“本地计算机” → “受信任的根证书颁发机构”
• 更稳妥的做法：不设 cafile，改用 npm config set strict-ssl true + 把企业根证书导入 Windows 证书存储，让 Node.js 自动继承系统信任库

多用户环境的代理问题从来不是“设了就能用”，而是“谁设的、在哪设的、对谁生效”的叠加判断。最容易被忽略的是 PowerShell profile 里的条件代理逻辑和 nvm 切换后未刷新的 etc/npmrc —— 它们不像 settings.json 那样显眼，却在后台持续干扰每一次 npm install。