你在解决什么问题
很多开发者的日常画面是：Clash（或基于 Mihomo 的桌面客户端）已经在菜单栏里亮着绿灯，Chrome 打开 GitHub、查文档都顺畅，可是一回到终端执行 npm install、pip install、cargo fetch，进度条就卡在「resolving」或反复重试，最后抛出一串 ETIMEDOUT、Connection timed out。第一反应往往是换订阅节点，但换完依旧，于是开始怀疑「是不是 npm 源坏了」——却忽略了更底层的一点：命令行工具默认不会自动使用系统代理或浏览器扩展那条路径。
本文聚焦本机原生终端里的包管理器如何把出站请求送进 Clash 混合端口或单独的 HTTP / SOCKS 入口。它与仓库中《Docker Desktop 走 Clash 代理》所讲的三层（系统、守护进程、构建环境）是并列场景：Docker 引擎读的是 Desktop 与 daemon.json，而你在 macOS Terminal 或 Windows PowerShell 里直接跑的 npm / pip / cargo，读的是当前进程继承的环境变量与各自配置。两件事都「要配代理」，但配置入口完全不同，因此不会与 Docker 教程构成同题重复。
为什么「Clash 已开」不等于「终端已走代理」
桌面客户端开启后，常见有两类流量路径：一类是TUN 模式或系统级透明转发，理论上可以覆盖更多进程；另一类是仅对遵循系统代理栈的应用生效，而许多 CLI 工具既不读 macOS「系统网络代理」面板，也不读 Windows「Internet 选项」里的自动配置，除非你显式设置了标准代理变量或工具专属配置。
更隐蔽的是端口不一致：订阅教程里习惯写 7890，但你当前配置里可能是 7897、9090，或 HTTP 与 SOCKS 分开了两个端口。只要 HTTP_PROXY 里写错一个数字，CLI 就会对着空端口连接，表现与「墙外网站全挂」几乎一样。还有一类情况是 NO_PROXY 写得太宽或太窄：该直连的内网被送去代理会失败，该走代理的 registry 却被排除，同样会表现为随机超时。
因此排错的第一步永远是：在 Clash 界面或配置里确认「当前实际监听的 HTTP / Mixed / SOCKS 端口」，再把这个数字原样写进终端环境，而不是凭记忆套用别人的截图。
Clash 侧：混合端口、HTTP 端口与协议前缀
混合端口（Mixed）通常同时接受 HTTP CONNECT 与 SOCKS 连接，很多教程会让你把 http://127.0.0.1:混合端口 填进代理地址。若你单独开启了 HTTP 代理端口与 SOCKS 端口，则需要与变量前缀一致：http:// 对应 HTTP 代理；socks5h:// 或 socks5:// 对应 SOCKS（是否使用远程 DNS 解析以 socks5h 为准，视工具而定）。
若工具链对 SOCKS 支持更好，可以把 ALL_PROXY 设为 socks5h://127.0.0.1:你的端口，同时仍保留 HTTP_PROXY 与 HTTPS_PROXY 指向 HTTP 或混合端口——不少网络库会按协议选择读取哪一个。切忌把 HTTP 端口填成 socks5:// 前缀，反之亦然，否则会表现为握手阶段一直卡住。
仅在 127.0.0.1 监听时，一般不需要开 allow-lan；若你从虚拟机、远程 SSH、或另一子系统访问宿主机 Clash，才需要把监听地址与防火墙一并考虑。Windows 与 Linux 子系统协同可参考《WSL2 走 Windows Clash》，避免在 WSL 里把 127.0.0.1 误当成 Windows 上的 Clash。
终端通用写法：HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXY
下列变量在类 Unix Shell 与 Windows 终端中都被广泛支持（具体大小写敏感度因程序而异，顽固场景可同时导出大写与小写两套）：
HTTP_PROXY/HTTPS_PROXY：指向http://127.0.0.1:端口（或你的实际 Mixed 端口）。ALL_PROXY：可选，用于「所有协议」回退，常见为 SOCKS 形式。NO_PROXY：逗号分隔的直连列表，至少包含localhost、127.0.0.1、::1；若有内网 PyPI、npm 私服或公司 Git，应把对应主机名或后缀写进去，避免误走代理。
在 zsh / bash 中可临时测试（端口请替换）：
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5h://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1若临时导出后装包立刻恢复正常，说明问题就在环境未注入；接下来再把同样内容写入 ~/.zshrc、~/.bashrc 或 Windows 用户环境变量，避免每次手动输入。
npm、pip、cargo 各自还读什么
npm / yarn / pnpm：除环境变量外，npm config set proxy 与 npm config set https-proxy 也会生效；若曾为公司网络设过代理而后端口变更，旧值会一直留在 ~/.npmrc 里，导致与当前 Clash 不一致。可用 npm config list 查看。registry 指向国内镜像时，若镜像本身可达，也可能掩盖「未走 Clash」的问题；一旦需要访问默认 registry 或私有外网仓库，代理变量仍必须正确。
pip / uv：标准库与常见发行版会尊重 HTTP_PROXY 等变量；部分环境还会读取 PIP_INDEX_URL。企业证书或 SSL 中间人场景与代理无关，需单独信任存储，本文不展开。若仅在内网镜像安装成功、访问 pypi.org 失败，应先确认是网络策略还是变量未设置。
cargo / rustup：拉取 crate 与 git 依赖时常走 libgit2 或 curl 栈，一般同样遵循上述代理变量；若依赖 git:// 协议被拦，需改用 https 协议或配置 git 代理。rustup 自身更新频道若超时，也可在同一终端会话导出变量后再执行。
关键分叉：系统 Shell 与 IDE 集成终端
这是高频踩坑点：你在 iTerm2 或 Windows Terminal 里配好的 ~/.zshrc，不一定会被 VS Code、Cursor、JetBrains 内置终端继承。原因包括：IDE 启动时未经过「登录 Shell」，因而跳过了加载 ~/.zprofile / ~/.zshrc 的时机；或 IDE 从图形界面启动时继承了另一套最小环境，仅含系统级变量。
可行做法包括：在「登录级」配置文件里导出代理变量，使非交互子进程也能继承；或在 IDE 的终端环境设置里显式写入键值；或在项目级 .env 配合工具插件（视编辑器而定）。若你在 IDE 里装依赖失败、在外部终端却成功，应优先对比两处执行 env | grep -i proxy（PowerShell 可用 Get-ChildItem Env:HTTP*）的输出差异。
涉及 Cursor、GitHub 与 AI 相关域名分流时，可与《Clash 下 Cursor 与 GitHub 开发分流》对照：规则解决「该域名走哪条链路」，而本文解决「终端进程是否拿到了代理地址」——两层都通，装包才稳。
自检顺序（建议按步执行）
① Clash 中确认 Mixed / HTTP 端口与是否允许本机回环连接。② 在同一终端执行 curl -I https://www.google.com 或任意可验证外网连通性的 HTTPS 目标（请遵守本地法规与网络政策）。③ 导出代理变量后重试 curl，确认延迟与证书链正常。④ 再执行最小 npm / pip / cargo 操作（例如只装一个小包）。若 ③ 失败而 Clash 日志无对应连接，重点检查端口与协议前缀；若 ③ 成功而 ④ 失败，检查工具专属配置（如 .npmrc）是否覆盖或清空了代理。
Clash 日志里若完全看不到来自终端进程的连接，说明流量仍绕开了客户端；若能看到连接但耗时极长，再回头考虑节点质量、DNS 与规则命中，这与「变量未设置」是不同层面的问题。
合规与边界
本文仅讨论在合法授权的网络环境中，通过本机代理客户端改善开源包下载可达性的技术步骤，不构成对任何地区法律法规、服务条款或雇主安全政策的规避建议。请在你所在地法律允许的范围内使用，并优先遵守公司与校园网络管理规定。
小结
npm 代理、pip 代理、cargo 代理在工程上最常落地的做法，是把 Clash 当前真实监听端口写进 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY，并配好 NO_PROXY。与此同时，务必分清系统 Shell与 IDE 集成终端各自的环境来源，避免「一个窗口能装、另一个窗口全挂」的假随机现象。与容器场景相比，本机终端不读 Docker Desktop；与 WSL2 相比，回环地址可能指向不同命名空间——需要时分文阅读对应教程即可。
若你希望桌面端客户端版本统一、端口与内核行为更可预期，从而减少和文档示例不一致带来的折腾，可以从本站下载页获取当前平台推荐的发行版。固定使用可信渠道的安装包，比在搜索引擎里拼凑过时命令要省心得多。→ 立即免费下载 Clash，开启流畅上网新体验