git 设置代理：npm、pip、Docker、SSH 配置及取消方法

git 设置代理，就是为 Git 的 HTTP(S) 请求指定代理服务器；SSH 方式的仓库地址需要另行配置。 大多数命令行工具（git、npm、pip 等）不会自动使用系统代理，所以浏览器能上 GitHub，终端里 git clone 照样超时。

让终端走代理有两条路：一是开启 TUN 模式，在网络层接管整台电脑的流量，终端工具基本不用单独配置；二是逐个工具设置代理地址，比如 git config --global http.proxy、npm config set proxy，适合不想开 TUN、或者在 Linux / CI / 远程服务器上的场景。

下面先讲 TUN，再按工具给出设置和取消代理的命令，最后是一份「配了还是不通」的排查清单。

01 为什么终端不走系统代理

macOS 和 Windows 的「系统代理」设置，本质上是一个约定：告诉愿意遵守它的应用，HTTP/HTTPS 请求应该发给哪个本地代理端口。

浏览器、Electron 应用（VS Code、Figma）默认会读这个设置。但大多数命令行工具不会——它们直接发起 TCP 连接，只认自己的配置项或 http_proxy 这类环境变量。

例外是 Docker Desktop：它的代理设置可以选择跟随系统代理，拉镜像时会自动使用；Linux 上的 Docker Engine 则不会。

结果就是：代理客户端开着，终端工具仍然直连。系统代理和 TUN 的完整区别见 TUN 模式是什么。

02 TUN 模式：系统级接管

TUN 模式在网络层接管流量，包括 UDP 和绕过系统代理的 TCP 连接。开启之后，git、npm、pip、curl、Docker 这些终端工具的网络请求会按分流规则决定走代理还是直连，一般不需要逐个配置，也不用记得事后取消。

它有几个前提，遇到个别地址不通时先查这里：

IPv6：Terraka 的 TUN 默认只接管 IPv4，双栈网站若优先走 IPv6 可能绕开代理，需要在「TUN 设置」里启用 IPv6 hijack（见 TUN 教程的排查一节）。
DNS：「DNS 设置」里的 劫持 DNS 请求 要开启，否则域名解析可能仍走本地 DNS。
分流规则：命中直连规则的地址本来就不走代理，这是规则在起作用，不是 TUN 失效。

如果你经常在终端里做开发，这是最省心的方案：

Apple 芯片 Mac：传统 macOS 桌面客户端已退役，现在 Mac 上运行的是 iOS 版 Terraka（通过 TestFlight 安装）。它用 NetworkExtension 创建系统级 utun 虚拟网卡，在系统层面接管 Mac 的流量——终端里的 git / npm、Docker 等原生进程都包括在内（同样受上面 IPv6、DNS 和规则条件约束）。Intel Mac 不支持。
Windows：桌面客户端开启 TUN 模式，同样在系统层面接管流量。

具体开启步骤参见桌面端 TUN 模式配置指南。

首次开启 TUN 需要系统授权，这是正常行为。Mac 上会弹出「Terraka 想要添加 VPN 配置」，用 Touch ID 或登录密码确认即可；Windows 上需要以管理员身份运行，并在首次启用时安装 WinTun 驱动（安装包已捆绑）。

开了 TUN 之后，公司内网、本地服务这类地址要不要直连，由分流规则决定，而不是逐个工具去配 no_proxy。规则写法见 Clash 规则怎么写。

03 逐个工具配置：先确认端口

如果你不想开 TUN，或者要在 Linux、CI、远程服务器上让命令行走代理，就逐个工具配置。注意：Terraka 没有 Linux 客户端，这类机器上只要有一个能访问到的代理地址，就用下文的环境变量方式。

配置前先确认本地代理端口：以你的代理客户端设置里显示的本地端口为准，下文以 Clash 系常见的 HTTP 127.0.0.1:7890、SOCKS5 127.0.0.1:7891 为例，抄命令时换成你自己的端口。

04 git 设置代理（含 SSH）

下面几种写法是替代方案，选一种即可。不同配置键可以并存：方案三会替换方案一写入的同一个 http.proxy，但 GitHub 专用配置是另一个键，要单独清理；比如先设了全局代理、再加 GitHub 专用代理，其他仓库仍然走全局代理。所以换写法前，先用后文的取消命令把旧配置清掉。另外，git 配置里的 http.proxy 优先于 http_proxy / https_proxy 环境变量。

方案一：git 全局代理（对 HTTPS 地址生效）：

git config --global http.proxy http://127.0.0.1:7890

git 的 HTTPS 请求也读 http.proxy，一条就够。网上常见的 https.proxy 并不是 git 识别的配置项，设了也没用。

方案二：只对 GitHub 生效（推荐，避免影响公司内网仓库）：

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

方案三：全局代理改用 SOCKS5：

git config --global http.proxy socks5h://127.0.0.1:7891

socks5h 表示域名也交给代理解析，比 socks5 少一次本地 DNS 查询。

方案四：临时设置（仅当前终端会话，且没有设置 http.proxy 时才生效）：

export https_proxy=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890

查看与取消 git 代理：

# 查看全局代理配置
git config --global --get-regexp 'http.*proxy'

# 查看所有层级（系统 / 全局 / 仓库）的代理配置及来源文件
git config --show-origin --get-regexp 'http.*proxy'

# 取消全局代理
git config --global --unset http.proxy

# 取消只对 GitHub 的代理
git config --global --unset http.https://github.com.proxy

SSH 协议（git@github.com:...）不走 http.proxy，需要在 ~/.ssh/config 里单独配置：

# macOS / Linux
Host github.com
    ProxyCommand nc -X 5 -x 127.0.0.1:7891 %h %p

# Windows：适用于 Git for Windows 的 Git Bash（自带 connect.exe）
Host github.com
    ProxyCommand connect -S 127.0.0.1:7891 %h %p

nc 需要支持 SOCKS：macOS 自带版本支持，Linux 需要安装 netcat-openbsd。Windows 示例适用于 Git for Windows 环境；如果用的是 Windows 自带的 OpenSSH，它可能找不到 connect，需要把 connect 换成 connect.exe 的完整路径（路径有空格时加引号）。取消时删掉这几行即可。

05 npm / yarn / pnpm

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

# yarn 1.x
yarn config set proxy http://127.0.0.1:7890
yarn config set https-proxy http://127.0.0.1:7890

# pnpm
pnpm config set proxy http://127.0.0.1:7890
pnpm config set https-proxy http://127.0.0.1:7890

Yarn 2 及以上版本（Berry）的配置项不同，要写在 .yarnrc.yml 里的 httpProxy / httpsProxy。

取消：

npm config delete proxy
npm config delete https-proxy

# yarn 1.x
yarn config delete proxy
yarn config delete https-proxy

# Yarn 2+（Berry）
yarn config unset httpProxy
yarn config unset httpsProxy

pnpm config delete proxy
pnpm config delete https-proxy

如果你在用 nrm 之类的工具切换镜像源，切到 npm 官方源时记得同时设置代理，避免直连超时。常见做法是：访问 npm 官方源走代理，访问国内镜像源直连。

06 pip

单次使用：

pip install package-name --proxy http://127.0.0.1:7890

永久配置（推荐用命令写入，不用手动找配置文件）：

pip config --user set global.proxy http://127.0.0.1:7890

加 --user 是为了确保写入用户级配置文件，而不是当前虚拟环境的配置。实际写到哪个文件因系统而异（macOS 可能是 ~/.config/pip/pip.conf 或 ~/Library/Application Support/pip/pip.conf，Windows 一般是 %APPDATA%\pip\pip.ini），用 pip config debug 可以看到 pip 读取的全部配置文件路径。内容等价于：

[global]
proxy = http://127.0.0.1:7890

取消：

pip config --user unset global.proxy

07 Docker

Docker 的代理分三个位置，最容易配错：

拉取镜像（docker pull）——由 Docker daemon 发起，要配在 daemon 上；
构建和运行容器——容器内的进程需要拿到代理环境变量；
Docker Desktop——daemon 跑在虚拟机里，用图形界面配置。

Docker Desktop（Mac / Windows）拉镜像：

Settings → Resources → Proxies，打开手动代理并填入地址，Apply & restart。注意：关掉手动代理后，Docker Desktop 仍可能跟随系统代理；想让它直连，要选 No proxy 再重启。

Linux 上的 Docker Engine 拉镜像： 用 systemd 给 daemon 加环境变量，新建 /etc/systemd/system/docker.service.d/http-proxy.conf：

[Service]
Environment="HTTP_PROXY=http://127.0.0.1:7890"
Environment="HTTPS_PROXY=http://127.0.0.1:7890"
Environment="NO_PROXY=localhost,127.0.0.1"

sudo systemctl daemon-reload
sudo systemctl restart docker

撤销：删除这个文件，再执行同样两条命令。

构建和运行容器： 编辑（或创建）~/.docker/config.json，Docker 会把这里的代理自动注入新建的容器和 docker build：

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

注意：这个文件只影响容器，不影响 docker pull。撤销时删掉 proxies 这一段。

也可以只对单个容器生效：

docker run -e http_proxy=http://host.docker.internal:7890 \
           -e https_proxy=http://host.docker.internal:7890 \
           image-name

容器里的 127.0.0.1 指向容器自己，所以要用 host.docker.internal 访问宿主机（Mac / Windows 的 Docker Desktop 支持）。Linux 上分两种情况：

host 网络（--network=host）：容器和宿主机共用网络，代理地址直接写 http://127.0.0.1:7890，不要用 host.docker.internal。
默认桥接网络：代理地址填容器能访问到的宿主机地址（例如 docker0 网桥地址或宿主机内网 IP），并确保代理服务监听在这个地址上，而不是只监听 127.0.0.1。

08 环境变量：终端统一走代理

很多命令行工具都遵循 http_proxy / https_proxy 环境变量，可以在 shell 配置文件里统一设置。这也是 Linux、CI、远程服务器上最通用的做法：

# 在 ~/.zshrc 或 ~/.bashrc 里添加
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7891
export no_proxy=localhost,127.0.0.1,::1

重新打开终端后生效。curl、wget、go get 等工具基本都支持。部分程序只认大写的 HTTP_PROXY / HTTPS_PROXY，不确定时大小写各设一份。

Windows PowerShell 的临时写法：

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

撤销：

# 当前终端立即撤销
unset http_proxy https_proxy all_proxy no_proxy HTTP_PROXY HTTPS_PROXY

# 永久撤销：删掉 ~/.zshrc 或 ~/.bashrc 里对应的 export 行

PowerShell 里用 Remove-Item Env:HTTP_PROXY、Remove-Item Env:HTTPS_PROXY。

桌面上最省事的是 TUN 模式；到了 CI 和远程服务器，环境变量是最通用的方案。

09 配了代理还是不通？排查清单

按顺序逐条核对，大部分问题在前三条：

端口不对。 命令里的端口必须和代理客户端设置里显示的本地端口一致。可以先用 curl -I -x http://127.0.0.1:7890 https://github.com 单独测这个端口通不通。
协议前缀写错。 端口是 SOCKS5 却写成了 http://，或者反过来，连接会直接失败。SOCKS5 端口要写 socks5:// 或 socks5h://。
git 用的是 SSH 地址。 git@github.com:... 走的是 SSH，http.proxy 对它无效，要按上文配置 ~/.ssh/config。用 git remote -v 看一眼地址是 https:// 还是 git@。
配错了 Docker 的位置。 docker pull 走 daemon，~/.docker/config.json 只管容器；Docker Desktop 的 daemon 在虚拟机里，要在 Settings 里配，而不是改宿主机的环境变量。
容器里用了 127.0.0.1。 桥接网络下容器内的回环地址是容器自己，要换成 host.docker.internal 或宿主机可达地址；只有 --network=host 时才能用 127.0.0.1。
no_proxy 漏了内网地址。 走代理后访问公司内网服务失败，多半是没把内网域名或网段加进 no_proxy，例如 no_proxy=localhost,127.0.0.1,.corp.example.com,10.0.0.0/8（是否支持网段写法因工具而异）。
git 代理残留。 之前设过 git config --global http.proxy，后来关了代理客户端，或者去拉公司内网的 GitLab，就会连接失败。用 git config --show-origin --get-regexp 'http.*proxy' 查出所有层级的配置和来源文件，再用 env | grep -i proxy 检查环境变量，删掉不需要的或改成只对 GitHub 生效。
sudo 丢了环境变量。 sudo 默认不继承当前用户的 http_proxy，需要 sudo -E，或者给对应命令单独配置代理。
开了 TUN 但个别地址不通。 先看是否命中了直连规则，再确认 IPv6 hijack 和 劫持 DNS 请求 是否开启；DNS 的排查思路见 DNS 泄漏怎么彻底防止。

10 常见问题

git 代理设置后怎么取消？ 执行 git config --global --unset http.proxy；如果设的是只对 GitHub 的代理，执行 git config --global --unset http.https://github.com.proxy。不确定设过哪些，先用 git config --show-origin --get-regexp 'http.*proxy' 列出所有层级的配置，再检查 http_proxy / https_proxy 环境变量。

SSH 方式 clone 怎么走代理？ SSH 不读 http.proxy，要在 ~/.ssh/config 里给 github.com 加 ProxyCommand：macOS / Linux 用 nc -X 5 -x 127.0.0.1:7891 %h %p，Windows 在 Git for Windows 环境下用其自带的 connect -S 127.0.0.1:7891 %h %p。另一个办法是直接开 TUN，SSH 连接同样会按规则被接管。

开了 TUN 还需要配 git 代理吗？ 一般不需要。TUN 在网络层接管流量，git 的 HTTPS 和 SSH 都会按分流规则走代理；如果个别地址仍不通，先查 IPv6、DNS 劫持和规则是否命中直连。反而建议把之前手动设的 git、npm 代理取消掉，避免关掉 TUN 后这些残留配置指向一个已经不存在的端口。

Mac 上的 Terraka 能接管终端吗？ 能。Apple 芯片 Mac 上运行的是 iOS 版 Terraka，开启后用 NetworkExtension 创建系统级 utun，终端里的 git、npm、Docker 等原生进程都会按规则被接管。Intel Mac 不支持。

Linux 服务器上怎么让 git、pip 走代理？ Terraka 没有 Linux 客户端。在 Linux、CI 或远程服务器上，用环境变量方式最通用：设置 http_proxy / https_proxy 指向可用的代理地址，git、pip、curl 都会读取；Docker 拉镜像则要按上文给 daemon 单独配置。

命令行工具不走系统代理是开发者的高频痛点。桌面端最简洁的解法是 TUN 模式：Apple 芯片 Mac 上的 iOS 版 Terraka 和 Windows 版 Terraka 都能在系统层面接管流量，git、npm、Docker 基本不用再一个个配。需要精细控制，或者在服务器上，就按上面的命令逐个设置，用完记得取消。

下载 Terraka →

江流

FOUNDING ENGINEER · 内核维护

负责 Terraka 内核与协议层。前 Tower 工程师。喜欢把规则引擎写到极致，也喜欢清晨的咖啡。

所有文章 (10) →

git 设置代理：
npm、pip、Docker、SSH 配置及取消方法

01 为什么终端不走系统代理

02 TUN 模式：系统级接管

03 逐个工具配置：先确认端口

04 git 设置代理（含 SSH）

05 npm / yarn / pnpm

06 pip

07 Docker

08 环境变量：终端统一走代理

09 配了代理还是不通？排查清单

10 常见问题

把 Terraka 装上吧。

01 为什么终端不走系统代理

02 TUN 模式：系统级接管

03 逐个工具配置：先确认端口

04 git 设置代理（含 SSH）

05 npm / yarn / pnpm

06 pip

07 Docker

08 环境变量：终端统一走代理

09 配了代理还是不通？排查清单

10 常见问题

把 Terraka 装上吧。

继续阅读

理解代理协议：SS、VMess、Trojan、VLESS 有什么区别

什么是 TUN 模式，为什么桌面用户应该开启它

Terraka 2.6 发布：节点延迟测速重构