终端环境Git与Docker代理配置避坑指南 环境变量冲突与镜像拉取排障

为什么命令行程序不会自动跟随代理#

以 Chrome 或 Edge 为代表的桌面图形软件，底层依赖 Windows 系统的 WinINet 或 macOS 的系统网络偏好设置。当你在 Clash 中点击开启系统代理开关时，系统会在注册表中写入本地监听端口，浏览器在发起请求前会主动向该端口进行握手。

而绝大多数诞生于 Unix 哲学的现代命令行开发工具，其设计原则强调环境自治与跨平台一致性。这些工具在初始化网络套接字时，根本不会主动调用操作系统的专有注册表接口去探寻代理设置，而是遵循底层 POSIX 标准，直接向本地物理网卡发送明文网络寻址。

如果开发者没有在当前终端会话中显式注入标准的环境变量，或者未在工具专属的配置文件中写入代理参数，这些命令行的跨国流量就会以直连形态冲入公网，最终在骨干网出口被无情掐断。

关于系统代理在底层注册表中的挂载细节，建议同步参考 Clash 系统代理常见故障排查手册。

HTTPS 协议克隆代理配置#

对于形如 https://github.com/user/repo.git 的克隆链接，Git 内部依赖的是 libcurl 传输库。可以直接通过 Git 全局配置指令注入代理参数。

打开控制台终端，依次执行以下指令。

1
git config --global http.https://github.com.proxy http://127.0.0.1:7890
2
git config --global https.https://github.com.proxy http://127.0.0.1:7890

这里推荐只针对 github.com 域名单独设置代理，而不是无脑对全局所有域名设置代理。这样可以确保后续拉取国内企业自建的 GitLab 或 Gitee 仓库时，流量依然走国内极速直连。

如果后续需要查看当前生效的 Git 代理参数，可以执行带有来源标注的查询指令。

1
git config --global --get-regexp proxy

SSH 协议克隆与密钥连接代理配置#

如果你使用的是形如 git@github.com:user/repo.git 的 SSH 密钥认证克隆方式，上述针对 HTTP 的参数将彻底失效。此时必须在本地用户目录下的 SSH 客户端配置文件中挂载通道。

在用户个人主目录下找到或新建 .ssh\config 文件，在文件中写入针对 GitHub 域名的专属代理跳转规则。

Windows 环境下推荐写入如下配置。

1
Host github.com
2
    User git
3
    Port 22
4
    Hostname github.com
5
    ProxyCommand connect -H 127.0.0.1:7890 %h %p

macOS 与 Linux 环境下通常使用 netcat 工具进行管道跳转，配置如下。

1
Host github.com
2
    User git
3
    Port 22
4
    Hostname github.com
5
    ProxyCommand nc -X 5 -x 127.0.0.1:7890 %h %p

配置保存后，在终端执行 ssh -T git@github.com。如果看到成功通过鉴权的官方欢迎提示语，则证实 SSH 通道代理挂载成功。

为 Docker Daemon 守护进程注入拉取镜像代理#

负责执行 docker pull 下载镜像的是常驻后台以操作系统高权限运行的 Docker 守护进程，前台命令行环境无法直接影响它。守护进程拥有完全隔离的独立网络上下文，必须专门为其赋予代理环境变量。

在 Windows 或 macOS 运行 Docker Desktop 的环境下，点击右上角齿轮图标进入设置。

进入 Resources 资源选项卡下的 Proxies 代理子菜单。

勾选开启 Manual proxy configuration 手动代理配置，将 HTTP 与 HTTPS 代理地址均填入 http://127.0.0.1:7890。

在下方的 Bypass 绕过名单中，务必填入关键的局域网保留网段。

1
localhost,127.0.0.1,docker-desktop,*.local,192.168.0.0/16

如果是运行在 Linux 原生服务器环境下的 Docker 引擎，需要通过 systemd 配置文件注入环境参数。

在 /etc/systemd/system/ 目录下创建名为 docker.service.d 的文件夹，并在内部新建 http-proxy.conf 配置文件。

1
[Service]
2
Environment="HTTP_PROXY=http://127.0.0.1:7890"
3
Environment="HTTPS_PROXY=http://127.0.0.1:7890"
4
Environment="NO_PROXY=localhost,127.0.0.1,docker-registry.somecorporation.com"

保存后执行重载守护进程与重启 Docker 服务的指令。

1
sudo systemctl daemon-reload
2
sudo systemctl restart docker

执行 docker info | grep Proxy，若清晰显示出对应的代理 IP，则表明镜像拉取通道已经全面被打通。

为容器内部业务请求配置默认代理#

如果你希望在执行 docker build 编译镜像时，或者在容器内部执行 apt update 时能够自动走代理，需要在用户目录下的 .docker/config.json 中注入客户端默认网络配置。

1
{
2
 "proxies": {
3
   "default": {
4
     "httpProxy": "http://127.0.0.1:7890",
5
     "httpsProxy": "http://127.0.0.1:7890",
6
     "noProxy": "localhost,127.0.0.1"
7
   }
8
 }
9
}

需要特别注意的是，在 Windows 和 macOS 下，容器内部如果直接访问 127.0.0.1 实际上是指向容器自己内部，无法触达宿主机上的 Clash。此时应将代理地址中的 127.0.0.1 替换为宿主机的特殊虚拟域名 host.docker.internal。

Node.js npm 与 yarn 依赖管理#

1
# 配置 npm 走本地代理
2
npm config set proxy http://127.0.0.1:7890
3
npm config set https-proxy http://127.0.0.1:7890
4

5
# 若需恢复直接清除即可
6
npm config delete proxy
7
npm config delete https-proxy

Python pip 依赖安装#

在使用 pip 安装扩展包时，推荐在单次命令中动态附加参数，避免破坏系统全局 Python 环境。

1
pip install torch --proxy http://127.0.0.1:7890

在终端配置了 proxy 环境变量后本地局域网服务打不开了#

这通常是因为缺少了关键的 NO_PROXY 环境变量配置。当终端设置了全局代理后，甚至连本地发往 127.0.0.1 的内部进程通信也会被强行送往代理节点，导致本地开发服务器握手失败。

务必在终端配置文件中将 NO_PROXY 声明完整，包含 localhost,127.0.0.1,::1,*.local,192.168.* 等常见局域网保留网段。

为什么在 PowerShell 中执行 export 命令无效#

Windows 系统的 PowerShell 并不支持 Linux 传统的 export 语法。在 PowerShell 中注入临时环境变量，应当使用 PowerShell 专有语法。

1
$env:HTTP_PROXY="http://127.0.0.1:7890"
2
$env:HTTPS_PROXY="http://127.0.0.1:7890"

该环境变量仅在当前打开的单个控制台窗口内临时生效，关闭窗口后自动彻底销毁，不会污染系统全局网络环境。

如果配置代理后遇到节点完全无法联通外网的情况，可配合 Clash 有节点但无法上网排查手册 进行系统性排障。