Clash 开着，npm install 为什么仍然会超时
npm 安装超时不一定意味着 npm registry 或镜像源出了问题。浏览器能正常访问网页，只能说明浏览器当前的代理路径可用；在终端里执行的 npm install 则由 Node.js 和 npm 发起，它们不一定会自动继承 Clash 的系统代理设置。于是常见情况是浏览器可以打开目标网站，终端却在下载依赖时反复出现 ETIMEDOUT、ECONNRESET 或长时间停留在 idealTree、reify 阶段。
npm 安装也不是只连接一个地址。客户端先向 registry 请求包元数据，再根据响应中的下载地址获取 tarball；安装过程还可能访问多个依赖的包地址。只让 registry 主机名经过代理，而下载链接命中其他域名或 CDN 后仍然直连，就会出现「能查到包，下载却失败」的半代理状态。反过来，如果你使用的国内镜像本来就能直连，却把所有 npm 流量都强制发往不可用的节点，也可能让安装变慢或失败。
排查时先把问题拆成三件事：Clash 核心和节点是否正常、当前终端是否能连接到 Clash 的本地代理端口、npm 请求最终命中了什么规则。不要一上来就清缓存、换十个节点或重装 Node.js；这些操作会改变多个变量，却不一定能告诉你故障发生在哪一段。下面按从简单到具体的顺序检查，通常可以在几分钟内定位是代理未设置、规则走错，还是 registry 配置不一致。
先检查 Clash 模式、节点和本地监听端口
打开 Clash Verge、Clash Verge Rev、Mihomo Party 或其他当前使用的客户端，先确认核心处于运行状态，而不是只有界面打开。检查配置是否已激活、代理策略组是否选中了可用节点，并在客户端的连接或日志页面观察是否有新的请求记录。若策略组当前选择的是「DIRECT」或某个已失效节点，终端即使设置了代理，也不会得到预期的网络出口。
日常使用规则模式时，npm 请求由配置中的规则决定走代理、直连还是拒绝。临时切到全局模式可以作为诊断手段：如果全局模式下安装恢复，而规则模式下仍超时，问题更可能在规则匹配或规则集，而不一定是节点本身。测试完成后应切回日常模式，避免把所有流量长期送入同一代理路径。也不要仅凭测速延迟判断节点可用；节点对测速地址响应正常，不代表它对 npm 的 registry 和下载主机也能稳定建立连接。
接下来查看客户端设置中实际启用的 HTTP、SOCKS 或 mixed-port 端口。常见默认端口可能是 7890、7891 或其他值，但订阅配置、客户端版本及用户自定义设置都可能不同，不能只照抄网络文章中的数字。以客户端显示的监听端口为准，并确认它监听在本机可访问的地址上。若你在 Docker、WSL、远程 SSH 会话或容器内安装依赖，容器里的 127.0.0.1 指向容器自身，不一定是运行 Clash 的宿主机；此时需要单独处理容器网络和宿主机代理地址。
如果系统代理开关已经打开，但终端请求仍未出现在 Clash 的连接记录里，说明 npm 可能没有使用系统代理，或当前命令在另一个环境中运行。反之，如果记录中出现了 npm 相关目标，但连接失败或走向错误策略组，就可以继续从节点、规则和目标域名着手，而不必反复调整 npm 缓存。
给当前终端设置代理，并核对 npm 实际配置
对最常见的本机命令行场景，可以先在当前终端临时设置 HTTP_PROXY 和 HTTPS_PROXY，让 npm 使用 Clash 的 HTTP 兼容监听端口。以下例子中的 7890 仅为示意，请替换成客户端实际显示的端口。设置只对当前终端会话及其启动的子进程生效，关闭终端后通常会失效，适合用来做一次干净的对照测试。
macOS / Linux：临时设置并测试
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
npm ping
npm view lodash version
npm installWindows PowerShell：临时设置并测试
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
npm ping
npm view lodash version
npm install
先运行 npm ping 或 npm view，不要一开始就安装大型项目。前者可快速确认当前 registry 是否有响应，后者可以检查一个包的元数据查询是否成功。如果元数据查询成功但安装包时失败，重点看 tarball 下载阶段和 Clash 日志中实际出现的目标主机；如果连最简单的查询也超时，则先检查代理变量、端口和 registry 地址。需要 SOCKS 代理时，不要假定 npm 一定能直接识别任意 SOCKS URL；优先使用 Clash 提供的 HTTP 或 mixed-port，并以本地客户端和 npm 版本实际支持的方式配置。
如果你曾经在 npm 中设置过持久代理，环境变量可能与 npm 配置互相覆盖或造成判断混乱。使用 npm config get proxy、npm config get https-proxy 和 npm config get registry 查看当前值。临时测试时尽量只采用一种代理来源；如果发现旧配置指向已经不存在的地址，可先记录原值，再清除错误设置后重新测试。确认有效后，再决定是保留当前终端变量、写入项目脚本，还是使用客户端的 TUN 模式，而不是同时堆叠多个来源不明的代理参数。
动手排查：核对 registry、规则命中与下载目标
这一节按可复现的顺序操作。每次只改一个变量，并记录测试结果；这样即使问题没有立刻解决，也能知道是哪一步让现象发生变化。npm 的全局设置、项目级 .npmrc 和环境变量可能同时影响 registry 与代理行为，因此要以当前项目实际读取的配置为准。
-
确认 registry 地址。运行
npm config get registry，记下输出是 npm 官方 registry、组织内部 registry，还是你主动设置的镜像。不要根据浏览器收藏夹推测 npm 当前使用的地址；项目目录中的.npmrc也可能覆盖全局配置。 -
单独测试元数据请求。执行
npm ping，再用npm view lodash version查询一个常见包。若两者都失败，先处理终端代理和 registry 连通性；如果查询成功而具体项目失败，继续检查安装日志中第一个超时的请求和包名。 - 观察 Clash 连接记录。在连接页面按时间找到刚才测试产生的请求，确认目标域名、命中的规则和最终策略组。可能看到 registry 主机，也可能看到返回的 tarball 下载地址。不要只检查一条请求：安装多个依赖时，后续下载主机可能与最初查询元数据的主机不同。
- 用规则模式和全局模式对照。在相同终端、相同 registry 和相同命令下测试。全局模式成功而规则模式失败，优先检查相关域名是否被更靠前的直连规则匹配、规则集是否更新，以及规则最终指向的策略组是否选中可用节点。若两种模式都失败，则回头确认本地端口、代理变量和节点链路。
- 确认后再固定配置。如果使用的镜像适合直连，就让 registry 与对应下载请求保持同一条明确路径；如果必须通过代理访问，就确保请求涉及的目标域名都能匹配到可用代理策略。修改配置后重载规则或重新载入配置，再用同一条查询命令复测。
规则排查的关键不是盲目添加一条宽泛的域名关键词，而是以连接日志中的实际主机为依据。对于 npm 官方源，常见请求会涉及 registry.npmjs.org，但响应中提供的下载地址、企业代理和镜像服务都可能改变实际目标。若日志明确显示请求被一条泛化的直连规则截获，应调整规则顺序或针对日志中确认的域名补充合适规则，并确保目标策略组名称在当前配置中真实存在。修改前备份配置，避免因拼写或策略组引用错误导致整个配置无法载入。
如果你使用国内镜像，先确认镜像地址确实可用，再让 registry 与 tarball 下载尽量保持一致的访问路线。临时更换 registry 适合判断问题是否与当前源有关，但不建议把「换源」当作唯一修复：镜像可能有同步延迟、包版本不齐或企业网络策略限制。若镜像查询成功，安装仍卡在下载阶段，就应继续核对下载请求的域名，而不是反复切换镜像。公司或学校提供的内部 registry 还可能需要认证、证书或专用网络；未经管理员确认，不要为了绕过超时而关闭 TLS 校验。
根据错误类型处理超时、重置和缓存问题
不同错误信息提供的线索并不相同。ETIMEDOUT 通常表示连接或响应等待超过期限，可能与代理未接通、节点不可用、目标被直连阻断或链路丢包有关；ECONNRESET 表示连接被中途重置，既可能是代理或网络设备主动关闭，也可能是节点链路不稳定；证书相关错误则更应检查系统时间、企业 HTTPS 检查、证书链和代理设置。单凭错误名称无法断定具体原因，应把 npm 输出与 Clash 日志中的同一时间段对起来看。
如果报错里指出具体包或下载 URL，可以先对该包做单独查询，再在 Clash 连接记录中寻找对应主机。若只有某个项目失败，检查项目级 .npmrc、锁文件中记录的 registry 地址、工作区设置和依赖来源；其他项目都能安装，则不必先改系统级配置。若所有项目都失败而浏览器正常，优先回到命令行代理变量和本地监听端口。
清理缓存不应作为第一步。npm 缓存用于复用已下载内容，通常不会修复一个无法建立连接的代理路径；频繁执行强制清缓存反而会让后续安装重新下载更多文件，增加排障变量。只有日志指向缓存数据损坏、校验失败，或你已经确认网络可用但同一内容始终读取异常时，才考虑先运行缓存校验，再按 npm 给出的诊断结果处理。完成修复后保留一份成功命令、当前 registry、代理端口和对应 Clash 策略组记录，下一次遇到类似问题就能快速比较。
还有一种常见误区是把 strict-ssl 关闭后当作网络问题已解决。关闭证书校验会降低连接安全性，也可能掩盖代理证书或系统证书链配置错误；它并不能让一个不可达的端口变得可用。应优先确保使用可信的代理入口、正确的证书链和一致的网络路径。若处于企业网络，依照管理员提供的证书与 registry 配置操作；个人设备则检查系统日期是否正确，并确认代理客户端没有把 HTTPS 请求错误地转发到不匹配的端口。
让 npm 命令行代理保持稳定且便于复查
确认安装恢复后，不必永久保留所有临时变量。选择一种符合日常工作方式的方案即可：偶尔使用 npm 时，在当前终端会话设置代理；经常使用多个命令行工具时，可采用受控的 Shell 配置并在不需要时取消；希望终端程序不逐个设置代理时，可评估 Clash 的 TUN 模式，但要先确认它与系统 VPN、公司网络和本地开发端口兼容。任何长期设置都应明确记录端口与启用条件，避免几个月后端口变更，终端仍悄悄连向旧地址。
代理变量通常可以在当前会话中清除，避免离开代理环境后 npm 继续尝试连接一个已经关闭的本机端口。macOS 和 Linux 可在当前 Shell 中取消相关变量；PowerShell 则可移除对应的进程级环境变量。若代理设置写入了用户级 npm 配置或项目 .npmrc，还应分别检查并按需恢复。清理后再执行一次 npm ping，确认当前网络环境下的行为符合预期。
对团队项目，建议把 registry 的选择、代理是否由开发者本地设置、证书要求以及 CI 环境的代理注入方式写进项目文档；不要提交含个人地址、令牌或机器专属路径的配置。CI、Docker 和远程开发环境也需要分别验证代理从构建进程到宿主机的可达性，不能因为本机终端已经成功就假设构建容器也会继承同一设置。排查时记录关键错误、失败目标主机和规则命中结果，比长期提高 npm 超时时间更有价值：增加等待时间最多让请求等得更久，并不能修复错误路由或无法访问的节点。
相比只靠浏览器系统代理的轻量工具，Clash 的规则模式、连接日志和策略组能帮助你判断 npm 的每个请求究竟直连还是经过节点；但它不会自动替所有终端进程设置代理，也不能弥补错误的 registry 或无效的节点。把终端代理、实际下载域名与 Clash 规则逐项对齐，通常比反复清缓存更可靠。如果你希望在图形界面中统一管理节点、规则和运行状态，可以前往 下载 Clash V.CORE，再按本文步骤验证 npm 命令行是否真正走上预期的代理路径。