命令行怎么走代理：npm、pip、Git、Docker设置与排错

更新于 2026-10-21 · fs100.cyou

简答：本文介绍的是本站推荐（广告）的服务 云小狐。命令行走代理，先用 curl -x 验证本机端口，再设置当前终端环境变量，最后按 npm、pip、Git 或 Docker 的配置范围排查；Docker 还要单独区分宿主机、daemon、构建阶段和容器内部。

定义：命令行代理，是让终端程序通过指定的 HTTP、HTTPS 或 SOCKS 代理访问目标站点，而不是只依赖桌面客户端的全局网络设置。

先试这一步：用 curl 验证代理端口

假设代理客户端当前显示的 HTTP 代理是 http://127.0.0.1:7890。这个地址只是示例，实际主机、端口和协议必须以本机客户端当前显示为准。目标网址是 HTTPS，并不意味着代理地址也必须写成 https://；目标协议和代理协议是两层概念。

curl 官方文档说明，-x 或 --proxy 可以指定代理，并覆盖环境变量。先做这一条最小测试：

curl -I -L --max-time 15 -x http://127.0.0.1:7890 https://registry.npmjs.org/

• 返回 HTTP 响应，说明请求至少到达了目标站点或中间服务，但不代表 npm、pip、Git 已经读取了正确配置。
• 出现 407，优先检查代理认证信息。
• 连接被拒绝或超时，先确认客户端是否运行、端口是否正确，以及该端口到底是 HTTP 还是 SOCKS5。
• 如果使用 SOCKS5，可按工具文档尝试 socks5:// 或 socks5h://，不要直接把 HTTPS 目标地址改成 HTTPS 代理。

Windows PowerShell 检查端口：

Test-NetConnection 127.0.0.1 -Port 7890

macOS 或 Linux 检查端口：

nc -vz 127.0.0.1 7890

如果客户端开启了 TUN 或全局模式，直连对照也可能经过同一套代理路径，此时两次出口 IP 相同不能证明代理没有生效。更可靠的做法是使用显式 -x、工具配置和请求日志进行对照。

curl 的代理参数和环境变量说明可参考curl 官方教程。

设置、查看、取消：命令行代理速查卡

这张表适合先快速定位入口，但不要把所有工具都当作同一种配置体系。npm、pip、Git 和 Docker 可能分别读取项目配置、用户配置、环境变量或守护进程配置。

通用环境变量：先做临时测试，不急着写入配置文件

环境变量适合临时测试、脚本和 CI。不同工具对代理变量的读取方式并不完全统一，因此建议先清理旧值，再设置当前会话需要的变量。

Windows PowerShell

$proxy = "http://127.0.0.1:7890"

$env:HTTP_PROXY = $proxy
$env:HTTPS_PROXY = $proxy
$env:ALL_PROXY = $proxy
$env:NO_PROXY = "localhost,127.0.0.1,::1"

$env:http_proxy = $proxy
$env:https_proxy = $proxy
$env:all_proxy = $proxy
$env:no_proxy = "localhost,127.0.0.1,::1"

Get-ChildItem Env:HTTP_PROXY,Env:HTTPS_PROXY,Env:ALL_PROXY,Env:NO_PROXY

取消当前 PowerShell 会话：

Remove-Item Env:HTTP_PROXY,Env:HTTPS_PROXY,Env:ALL_PROXY,Env:NO_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:http_proxy,Env:https_proxy,Env:all_proxy,Env:no_proxy -ErrorAction SilentlyContinue

macOS、Linux 或类 Unix shell

proxy='http://127.0.0.1:7890'

export HTTP_PROXY="$proxy"
export HTTPS_PROXY="$proxy"
export ALL_PROXY="$proxy"
export NO_PROXY='localhost,127.0.0.1,::1'

export http_proxy="$proxy"
export https_proxy="$proxy"
export all_proxy="$proxy"
export no_proxy='localhost,127.0.0.1,::1'

env | grep -iE '^(http|https|all|no)_proxy='

取消当前终端会话：

unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY
unset http_proxy https_proxy all_proxy no_proxy

curl 的规则需要特别注意：http_proxy只认小写；其他相关变量可以使用大小写形式，并且小写变量存在优先级差异。其他工具不一定完全遵循 curl 的行为，所以同时设置大小写后仍应以具体工具的实际配置和日志为准。相关规则见curl 官方教程的环境变量说明。

npm 与 pip：配置项不同，优先级也不同

npm：检查项目级、用户级和全局配置

npm 可使用 proxy 与 https-proxy 配置，也可能读取代理环境变量。当前 npm 文档列出的配置来源包括命令行、环境变量和多个 .npmrc 文件；项目目录中的 .npmrc 可能只对当前项目生效。

npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890

npm config get proxy
npm config get https-proxy
npm config list

取消 npm 配置：

npm config delete proxy
npm config delete https-proxy

如果只想测试一次，优先使用当前终端的环境变量，不要立刻把代理写入长期配置。排错时检查项目目录的 .npmrc、用户目录的 .npmrc 和全局配置。npm 配置文件层级可参考npmrc 官方文档，代理配置项可参考npm 当前配置文档。

pip：命令行参数高于环境变量，环境变量高于配置文件

pip 的顺序不要写反：命令行选项覆盖环境变量，环境变量覆盖配置文件。pip 官方配置文档还区分了全局、用户和虚拟环境级配置，因此取消用户配置后仍失败时，不能只检查一个文件。

python -m pip install --proxy http://127.0.0.1:7890 requests

Windows 也可以使用：

py -m pip install --proxy http://127.0.0.1:7890 requests

写入当前用户配置并查看：

python -m pip config --user set global.proxy http://127.0.0.1:7890
python -m pip config --user get global.proxy
python -m pip config --user unset global.proxy

确认 pip 到底读取了哪些文件：

python -m pip config debug

pip 官方用户指南列出了 --proxy、配置文件以及 http_proxy、https_proxy、no_proxy 的用法；如果命令行参数可用，先用它做一次最小验证，再决定是否保存配置。

参考：pip 官方用户指南、pip 官方配置与优先级说明。

Git：HTTPS 远程使用 http.proxy，SSH 要走另一条排查路径

Git 的官方配置项是 http.proxy，它可以覆盖通常由 http_proxy、https_proxy 和 all_proxy 提供的代理。HTTPS 仓库也使用这个配置项，不需要把 https.proxy 当成 Git 的官方键。

git config --global http.proxy http://127.0.0.1:7890
git config --global --get http.proxy
git config --show-origin --get-regexp 'proxy'

取消全局代理：

git config --global --unset http.proxy

只影响当前仓库时，在仓库目录中使用：

git config --local http.proxy http://127.0.0.1:7890
git config --local --unset http.proxy

Git 还支持按远程名称设置 remote.<name>.proxy。使用前先运行 git remote -v，确认远程名称和地址，避免修改错误范围。

如果远程地址是 git@主机:组织/仓库.git 或 ssh://...，它使用 SSH 通道，不能仅靠 http.proxy 解决。此时检查 SSH 端口、密钥、~/.ssh/config 和网络路径。不要为了排查代理而关闭 TLS 校验。Git 配置项说明见Git 官方 git-config 文档。

Docker：先分清 CLI、daemon、构建和容器

Docker 是最容易配置错作用域的对象。Docker CLI 的代理配置主要用于向新建容器和构建过程传递代理环境变量，不等于宿主机的 Docker daemon 代理，也不等于 Docker Desktop 的桌面端代理。

高频坑：容器内的 127.0.0.1 不是宿主机

如果代理客户端运行在宿主机，直接把 127.0.0.1:7890 写进容器环境变量，容器通常会访问容器自身的回环地址，而不是宿主机。这会导致构建或运行容器连接失败。

• Docker Desktop 环境通常可尝试使用 host.docker.internal:7890 访问宿主机服务，Docker 官方文档说明该名称会解析到宿主机的内部 IP。
• Linux Docker Engine 通常需要使用容器可达的宿主机网桥地址或局域网地址；具体地址取决于网络环境。
• 代理服务必须监听容器可以访问的地址，而不是只监听宿主机回环地址。客户端中可能叫“允许局域网连接”或类似名称，具体界面以当前版本为准。
• 如果使用 Docker Desktop，也可以按当前桌面端的代理设置配置宿主机、CLI 或容器代理。

Docker Desktop 的宿主机连接说明见Docker Desktop 网络文档。

Docker CLI、构建和运行容器

Docker 官方支持在 ~/.docker/config.json 中配置代理环境变量。下面的地址以 Docker Desktop 为例；如果是 Linux Engine，请替换为容器能够访问的宿主机地址：

{
  "proxies": {
    "default": {
      "httpProxy": "http://host.docker.internal:7890",
      "httpsProxy": "http://host.docker.internal:7890",
      "noProxy": "localhost,127.0.0.1,::1"
    }
  }
}

也可以只对一次构建或运行传入：

docker build --build-arg HTTP_PROXY=http://host.docker.internal:7890 .
docker run --rm --env HTTP_PROXY=http://host.docker.internal:7890 alpine sh -c 'env | grep -i proxy'

这里的 host.docker.internal 只解决容器访问宿主机地址的问题，不保证代理客户端一定允许来自 Docker 网络的连接。Docker 官方文档还提醒，代理环境变量可能以明文形式出现在容器配置中，不要把含账号密码的代理地址提交到 Dockerfile、镜像层或公开仓库。参考Docker CLI 代理文档。

Docker daemon：宿主机上的 127.0.0.1 可以成立

daemon 运行在宿主机或 Docker Engine 环境中，与容器内进程不是同一个网络命名空间。因此，daemon 配置中的 127.0.0.1:7890 可以指向宿主机上的代理客户端，但这不等于容器内部也能使用该地址。

Linux Docker Engine 可在 daemon.json 中配置：

{
  "proxies": {
    "http-proxy": "http://127.0.0.1:7890",
    "https-proxy": "http://127.0.0.1:7890",
    "no-proxy": "localhost,127.0.0.1,::1"
  }
}

修改后重启 daemon：

sudo systemctl restart docker

Docker 官方当前 daemon 文档推荐使用 daemon.json 或 daemon 启动参数，并明确说明 Docker Desktop 不读取这类 daemon.json 代理配置，应在 Docker Desktop 设置中处理。Docker Engine 23.0.0 的发行说明记录了通过 JSON 配置或启动参数配置 daemon HTTP 代理的支持；更旧版本应以对应版本文档为准，必要时使用 systemd drop-in 设置 daemon 环境变量。参考Docker daemon 官方文档和Docker Engine 23.0 发行说明。

统一排错顺序：端口—请求—配置—作用域

1. 先查端口。用 Test-NetConnection 或 nc -vz 确认本机确实有程序监听。
2. 再查协议。确认端口是 HTTP、HTTPS 还是 SOCKS5，不要只看端口号猜协议。
3. 用 curl 访问真实目标。npm 检查 npm registry，pip 检查 PyPI，Git 检查仓库域名，Docker 则分别检查 daemon、构建过程和容器。
4. 查工具配置来源。npm 使用 npm config list，pip 使用 python -m pip config debug，Git 使用 git config --show-origin --get-regexp 'proxy'。
5. 检查 NO_PROXY。如果把目标域名写入 NO_PROXY，请求可能绕过代理；本地回环地址和内网域名才应按实际需求加入。
6. 区分 401、407 和连接超时。407通常指向代理认证环节；401可能只是目标 API 要求身份验证，不能单凭它判断代理失败。
7. 清理旧值并重启新进程。修改环境变量后，已经打开的 IDE、终端、Docker Desktop 或任务进程可能仍保留旧环境。

如果配置中包含账号、密码或令牌，先改用脱敏值测试，不要把完整代理 URL 粘贴到公开日志、工单、截图或代码仓库。涉及客户端本机端口时，只使用原下单渠道和当前客户端显示的信息；本文不核实任何具体节点、价格或服务状态。

本文是第三方使用指南，不是任何客户端或网络服务的官方页面。页面主要命令和官方文档已于 2026-10-21 核对，但 npm、pip、Git、Docker 和客户端界面仍可能随版本变化，执行前应以当前版本帮助输出和官方文档为准。

常见问题

npm install 还是超时，应该先改哪里？

先用 curl -x 通过同一个代理访问 npm registry，确认端口和协议正常；然后运行 npm config get proxy、npm config get https-proxy 和 npm config list，检查项目目录及用户目录中的 .npmrc。使用 HTTPS registry 时，重点核对 https-proxy 和 HTTPS_PROXY。

pip 取消配置后为什么仍然失败？

pip 的命令行参数高于环境变量，环境变量高于配置文件。请运行 python -m pip config debug 查看实际读取的文件，同时检查 PIP_CONFIG_FILE、HTTP_PROXY、HTTPS_PROXY、NO_PROXY 和当前虚拟环境的 pip.conf 或 pip.ini。

Git 配置了 http.proxy，为什么 SSH 仓库仍然连不上？

SSH 远程地址使用 SSH 通道，不会自动使用 Git 的 HTTP 代理配置。先运行 git remote -v 确认地址类型，再检查 SSH 端口、密钥和 ~/.ssh/config；不要为了排查问题关闭 TLS 校验。

为什么 Docker 容器里写 127.0.0.1 访问不到宿主机代理？

容器内的 127.0.0.1 通常指向容器自身，不是宿主机。Docker Desktop 可尝试使用 host.docker.internal 加代理端口；Linux 则需要使用容器可达的宿主机网桥或局域网地址，并确认代理服务允许来自容器网络的连接。

Docker daemon 和容器代理应该配置在哪里？

daemon 负责镜像拉取等守护进程网络，容器和构建过程则使用 Docker CLI 的 config.json、--build-arg 或 --env。Linux Engine 可按当前版本文档配置 daemon.json；Docker Desktop 不应把 daemon.json 当作桌面端代理设置。

只有 SOCKS5 端口，npm、pip、Git、Docker 都能直接使用吗？

不能一概而论。curl 明确支持 SOCKS5 形式，但其他工具的支持方式会受版本、底层库和作用域影响。先用 curl 验证 SOCKS5 端口，再查看对应工具当前版本文档，不要把未经验证的 SOCKS5 地址直接写入所有配置。

相关阅读

• 飞梭客户端与平台选择指南
• 飞梭连接失败排查步骤
• 飞梭订阅链接复制与导入排错步骤

参考资料

1. curl 官方教程：代理参数与环境变量（curl.se）
2. npm 当前配置文档
3. npmrc 配置文件与项目级配置
4. pip 官方用户指南：使用代理服务器（pip.pypa.io）
5. pip 官方配置、环境变量与优先级说明（pip.pypa.io）
6. pip config 官方命令说明（pip.pypa.io）
7. Git 官方 git-config 文档（git-scm.com）
8. Docker CLI 官方代理文档
9. Docker daemon 官方代理文档
10. Docker Desktop 官方网络与宿主机连接说明
11. Docker Engine 23.0 官方发行说明