Git Clone 提示 SSL certificate problem 该怎么处理？

通常是本地代理开启了中间人证书解密所致，可检查客户端设置或临时配置 http.sslVerify false。

Windows CMD、PowerShell 与 Git Bash 设置终端代理解决 Git Clone 超时卡死

Q: 为什么设置了代理后，终端克隆反而报 Connection refused？

说明请求成功发送到了指定的代理端口，但目标端口上并没有任何程序在监听。通常是因为代理客户端未启动或实际端口不匹配。

Q: 为什么在终端使用了 export 或者 set，关闭窗口后就失效了？

终端中的命令属于进程级变量，关闭窗口后生命周期结束即被销毁，需持久化写入配置文件。

Q: 局域网有另外一台电脑开启了代理，本地终端如何借用该代理？

在宿主机开启允许局域网连接后，将本地终端的代理地址指向该宿主机的局域网 IP 与端口即可。

⚡ Answer-First 核心速览

终端工具天然绕过 Windows 注册表系统代理。在 PowerShell 中运行 `$env:all_proxy="http://127.0.0.1:7890"` 或在 CMD 中执行 `set http_proxy=http://127.0.0.1:7890` 即可让当前会话即刻走代理。针对 Git 克隆超时，执行 `git config --global http.https://github.com.proxy http://127.0.0.1:7890` 即可专门为 GitHub 流量挂接本地代理通道，既避免了全局污染又解决了克隆卡死。

返回从零到精通使用大系

在日常开发与运维工作中，很多工程师都会遇到一个极其困扰的现象。桌面上开启了代理客户端，浏览器看国外技术文档和视频流畅稳定，但只要打开 Windows 终端运行 git clone，光标就在屏幕上闪烁无休，数十秒后抛出 Connection timed out 或者 Failed to connect to github.com port 443。使用 npm install 拉取前端依赖、使用 pip install 下载 Python 算法包，甚至在拉取 Docker 镜像时，终端同样频频发生连接超时重试与网络握手中断。

很多人误以为本地代理软件没有生效，反反复复开关系统代理，却始终不见好转。要彻底解决终端环境的网络卡顿，必须理解操作系统中应用层网络协商机制与 Unix 命令行生态的技术断层。

为什么终端环境天然不走 Windows 系统代理

Windows 系统中常见的“系统代理”开关，本质上是在修改当前用户注册表的一个键值。对应路径是 HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings 下的 ProxyEnable 与 ProxyServer。

这套体系叫做 WinINET 与 WinHTTP 架构，属于 Windows 视窗图形应用程序的协议规范。Edge、Chrome、Firefox 等主流浏览器在启动时会主动查询这套注册表项，依照系统指定的端口转发 HTTP 报文。

text

+-------------------------------------------------------------------------+
|                        操作系统的网络请求派发体系                         |
+-------------------------------------------------------------------------+
                                     |
         +---------------------------+---------------------------+
         |                                                       |
         v                                                       v
+-----------------------------+             +-----------------------------+
|    图形界面应用 (浏览器等)    |             |   终端命令行与开发包管理器   |
| (Edge / Chrome / Teams)     |             | (CMD / PowerShell / Git)    |
+-----------------------------+             +-----------------------------+
         |                                                       |
         | 遵循 WinINET 规范                                     | 遵循 POSIX / Unix 习惯
         v                                                       v
+-----------------------------+             +-----------------------------+
|   读取 Windows 注册表代理项   |             |  仅读取当前进程的环境变量   |
| (ProxyEnable / ProxyServer) |             | (http_proxy / all_proxy)    |
+-----------------------------+             +-----------------------------+
         |                                                       |
         v                                                       v
+-------------------------------------------------------------------------+
|                  本地代理客户端核心 (127.0.0.1:7890)                     |
+-------------------------------------------------------------------------+

命令行生态完全由类 Unix 环境移植而来。Git 诞生自 Linux 内核开发流程，PowerShell 遵循跨平台设计，cURL、npm、pip 以及 Docker 守护进程都基于标准 POSIX 规范运作。这些程序在发起套接字通信时，压根不会去读取 Windows 注册表。

它们唯一承认的标准是当前操作系统进程树中的环境变量（如 http_proxy、https_proxy 与 all_proxy），或者自身独立的配置文件。如果在终端环境变量中没有明确声明代理服务器地址，这些命令行工具就会直接绑定物理网卡向目标公网 IP 发送原始 TCP SYN 握手包。在跨境网络受到严重阻断的环境下，握手数据包被网关丢弃，最终导致连接超时卡死。

典型终端网络超时报错大表

当终端工具因缺少代理配置而直连受阻时，不同工具在协议栈不同阶段会抛出截然不同的错误日志。下表整理了开发与运维场景中十种最高频的报错现象、对应触发阶段与针对性解决思路。

工具类别	典型终端报错代码与输出文本	发生阶段	根本故障成因	推荐工程处置手段
Git HTTPS	`Failed to connect to github.com port 443: Timed out`	TCP 握手阶段	Git 未配置代理，直连 GitHub 边缘节点遭遇丢包	为 github.com 域名单独配置 HTTP 局部代理
Git HTTPS	`OpenSSL SSL_read: Connection was reset, errno 10054`	TLS 协商阶段	数据传输中途被重置，TCP 连接被物理防火墙切断	检查本地客户端分流节点并开启代理
Git SSH	`ssh: connect to host github.com port 22: Connection timed out`	SSH 握手阶段	22 端口出境流量被封锁或阻断	在 SSH 配置文件中配置 ProxyCommand 走 Socks5 转发
NPM	`npm ERR! code ETIMEDOUT syscall connect`	依赖元数据拉取	npm 官方镜像源访问延迟过高且未注入代理参数	配置 npm proxy 或临时设置环境变量
Pip	`pip._vendor.urllib3.exceptions.ConnectTimeoutError`	索引解析阶段	官方 PyPI 仓库握手超时，TLS 证书交换停滞	在 pip 指令中追加 `--proxy` 参数或换源
Docker	`error pulling image: net/http: request canceled while waiting`	镜像分块下载	Docker 守护进程为后台服务，未读取用户终端变量	在 Docker 配置文件中写入 systemd 代理环境变量
cURL	`curl: (28) Failed to connect to ... Connection timed out`	HTTP 建立连接	cURL 默认忽略注册表设置，直连远端超时	执行命令时追加 `-x http://127.0.0.1:7890` 选项
Go 编译	`go: ...: dial tcp ...: i/o timeout`	远程模块依赖下载	Go 编译工具拉取境外模块超时	设置 GOPROXY 代理变量或导出终端代理
Rust Cargo	`cargo: error: failed to download from crates.io: timed out`	索引与源码拉取	Cargo 客户端直连 crates.io CDN 节点丢包	在 Cargo 配置文件中配置 HTTP 代理项
Maven/Gradle	`Could not resolve dependencies ... Connect to repo.maven.apache.org timed out`	Java 构建拉包	构建工具进程未继承终端环境变量	在全局属性文件中注入代理主机与端口参数

终端网络通信拓扑与转发路径

终端网络请求在挂接代理后，数据流在本地计算机与远端服务器之间的传递拓扑如下。

text

+---------------------+     +----------------------+     +---------------------+
|   Windows 命令行    |     |   开发包管理工具     |     |    Git 源代码管理   |
| (CMD / PowerShell)  |     | (npm / pip / cargo)  |     | (git.exe / ssh.exe) |
+---------------------+     +----------------------+     +---------------------+
           \                           |                           /
            \                          |                          /
             \                         |                         /
       读取环境变量: all_proxy / http_proxy / git config 代理设置
                                       |
                                       v
                     +-----------------------------------+
                     |      本地回环接口 (Loopback)       |
                     |       127.0.0.1:7890 端口         |
                     +-----------------------------------+
                                       |
                                       v
                     +-----------------------------------+
                     |       本地代理客户端核心          |
                     |  (Mihomo / Xray / Sing-box)       |
                     +-----------------------------------+
                                       |
                         分流规则判断 (Rule Engine)
                                       |
                     +-----------------------------------+
                     |   物理网卡与出口网关 (NIC)        |
                     +-----------------------------------+
                                       |
                            加密通道 (TLS / UDP)
                                       |
                                       v
                     +-----------------------------------+
                     |        境外落地服务器节点         |
                     +-----------------------------------+
                                       |
                         目标请求发起 (TCP/443, 22)
                                       |
                                       v
                     +-----------------------------------+
                     |  目标服务 (GitHub / npm / PyPI)   |
                     +-----------------------------------+

从拓扑可以看出，终端工具只要在发起套接字前，将目标目的地指向本机的 127.0.0.1:7890，所有的出境请求就会由本地代理客户端核心接管。代理核心依据规则路由完成分流与加密，再通过物理网卡将流量封装输出。

Windows CMD 环境变量临时与持久化设置

传统 Windows 命令行（CMD）广泛用于历史项目、批处理脚本或 Jenkins 自动化构建节点。在 CMD 中设置代理相对简单，但需要分清作用域。

1. 当前 CMD 会话临时代理

打开 CMD 窗口后，运行以下指令即可为当前会话注入代理环境变量。这里的 7890 需要替换为您本地代理客户端实际监听的端口。

cmd

set http_proxy=http://127.0.0.1:7890
set https_proxy=http://127.0.0.1:7890
set all_proxy=socks5://127.0.0.1:7890

如果需要排除本地局域网地址，避免局域网设备或者本地 Docker 容器请求也被送入代理，务必补上一条 no_proxy 规则。

cmd

set no_proxy=localhost,127.0.0.1,192.168.*,10.*,local.home

验证当前 CMD 是否已经走通代理，可以使用 Windows 自带的 curl 工具向公网 IP 诊断接口发起查询。

cmd

curl https://api.ipify.org

如果返回的 IP 地址是代理节点的境外公网 IP，说明当前终端会话已经处于代理通道接管之下。如果关闭此 CMD 窗口重新打开一个新窗口，上述设置就会自动消失。这是环境变量的特性，不会污染全局系统环境。

2. 清除 CMD 当前会话代理

如果在调试内网服务时需要恢复直连，可以在同一个 CMD 窗口中运行清空命令。

cmd

set http_proxy=
set https_proxy=
set all_proxy=

3. Windows 全局用户环境变量持久化

如果希望每次打开 CMD 或任何进程时都默认带上代理参数，可以使用 setx 命令将环境变量写入当前 Windows 用户的持久化注册表。

cmd

setx http_proxy "http://127.0.0.1:7890"
setx https_proxy "http://127.0.0.1:7890"
setx all_proxy "socks5://127.0.0.1:7890"
setx no_proxy "localhost,127.0.0.1,192.168.*,10.*"

使用 setx 修改后，需要重新打开终端才会生效。

这种做法存在副作用。一旦某天代理客户端未启动或者更改了端口，某些对网络依赖较深的程序在启动时会一直尝试连接已经关闭的 127.0.0.1:7890，引发不可预期的网络错误。对于开发工作，推荐按需开启或使用下一节介绍的 PowerShell 别名函数方案。

PowerShell 核心函数编写与配置文件持久化

PowerShell 是现代 Windows 系统的默认外壳环境。在 PowerShell 中，语法与 CMD 有所不同。环境变量通过 $env: 前缀进行访问和赋值。

1. 基础临时设置语法

在 PowerShell 会话中临时开启代理，直接执行以下语句。

powershell

$env:http_proxy="http://127.0.0.1:7890"
$env:https_proxy="http://127.0.0.1:7890"
$env:all_proxy="socks5://127.0.0.1:7890"
$env:no_proxy="localhost,127.0.0.1,192.168.0.0/16,10.0.0.0/8"

清空当前环境代理变量的语法为。

powershell

$env:http_proxy=""
$env:https_proxy=""
$env:all_proxy=""

2. 编写高复用性 PowerShell 控制函数

每次手动敲打冗长的变量赋值不仅效率低下，而且容易输错端口。优雅的工程方案是将控制逻辑封装成函数，写入 PowerShell 的配置文件中。

打开 PowerShell 窗口，执行以下命令检查配置文件路径。

powershell

$PROFILE

通常该路径位于 C:\Users\用户名\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1（Windows PowerShell 5.1）或者 C:\Users\用户名\Documents\PowerShell\Microsoft.PowerShell_profile.ps1（PowerShell 7）。

如果该文件不存在，可以使用一条命令自动创建并打开它。

powershell

if (!(Test-Path -Path $PROFILE)) {
    New-Item -ItemType File -Path $PROFILE -Force
}
notepad $PROFILE

在打开的记事本中，粘贴以下专门针对代理管理的完整函数代码块。代码中包含了开关控制、当前状态回显、自定义端口支持以及网络可用性探测功能。

powershell

function Set-Proxy {
    param(
        [int]$Port = 7890,
        [string]$HostIP = "127.0.0.1"
    )
    $proxyUrl = "http://${HostIP}:${Port}"
    $socksUrl = "socks5://${HostIP}:${Port}"

    $env:http_proxy  = $proxyUrl
    $env:https_proxy = $proxyUrl
    $env:all_proxy   = $socksUrl
    $env:HTTP_PROXY  = $proxyUrl
    $env:HTTPS_PROXY = $proxyUrl
    $env:ALL_PROXY   = $socksUrl
    $env:no_proxy    = "localhost,127.0.0.1,192.168.0.0/16,10.0.0.0/8,*.local"

    Write-Host "[+] 终端网络代理已成功挂接 -> ${proxyUrl}" -ForegroundColor Green
    Write-Host "[+] SOCKS5 通道已注入 -> ${socksUrl}" -ForegroundColor Green
}

function Clear-Proxy {
    $env:http_proxy  = ""
    $env:https_proxy = ""
    $env:all_proxy   = ""
    $env:HTTP_PROXY  = ""
    $env:HTTPS_PROXY = ""
    $env:ALL_PROXY   = ""
    $env:no_proxy    = ""

    Write-Host "[-] 终端网络代理已解除，恢复直连模式" -ForegroundColor Yellow
}

function Test-ProxyConnection {
    Write-Host "[*] 正在测试当前终端网络出境连通性..." -ForegroundColor Cyan
    try {
        $response = Invoke-RestMethod -Uri "https://api.ipify.org?format=json" -TimeoutSec 5
        Write-Host "[✓] 连通成功 当前外网 IP -> $($response.ip)" -ForegroundColor Green
    }
    catch {
        Write-Host "[x] 连通失败，无法访问公网 请检查本地客户端是否已启动且端口一致" -ForegroundColor Red
    }
}

Set-Alias -Name setproxy -Value Set-Proxy
Set-Alias -Name unsetproxy -Value Clear-Proxy
Set-Alias -Name testproxy -Value Test-ProxyConnection

保存并关闭记事本。

3. 配置脚本执行策略

如果在重新打开 PowerShell 时，终端抛出错误提示 无法加载文件 ... 因为在此系统上禁止运行脚本，这是因为 Windows 默认的 PowerShell 脚本执行策略为受限模式（Restricted）。

以管理员身份启动一个 PowerShell 窗口，执行以下命令放行本地脚本。

powershell

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser -Force

重新打开普通 PowerShell 窗口。现在，任何时候只要需要代理，直接输入 setproxy 即可一键开启；如果本地代理客户端改成了 10808 端口，直接输入 setproxy -Port 10808；输入 testproxy 即可查看当前出网公网 IP；测试完毕后输入 unsetproxy 即可瞬时恢复直连。

Git 客户端代理的三种粒度精细化配置

Git 是一款非常独特的工具，它既支持 HTTPS 传输协议，也支持基于 SSH 密钥的传输协议。两者的代理配置机制截然不同。

text

+--------------------------------------------------------------------------+
|                        Git 协议传输模式分流机制                          |
+--------------------------------------------------------------------------+
                                     |
         +---------------------------+---------------------------+
         |                                                       |
         v                                                       v
+-------------------------------+         +-------------------------------+
|     Git HTTPS 协议克隆        |         |       Git SSH 协议克隆        |
| (https://github.com/org/repo) |         | (git@github.com:org/repo.git) |
+-------------------------------+         +-------------------------------+
         |                                                       |
         v                                                       v
+-------------------------------+         +-------------------------------+
|  调用 Git 内置 http.proxy 模块 |         |   调用系统 OpenSSH (ssh.exe)   |
+-------------------------------+         +-------------------------------+
         |                                                       |
         v                                                       v
+-------------------------------+         +-------------------------------+
| 走 HTTP/Socks5 代理接口       |         | 走 ~/.ssh/config ProxyCommand |
| (127.0.0.1:7890)              |         | (connect.exe 转发)            |
+-------------------------------+         +-------------------------------+

1. 全局配置法（不推荐）

很多教程会教读者直接配置全局代理。

bash

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

这种粗暴的配置存在严重弊端。一旦公司内部搭建了私有 GitLab、Gitea 仓库，或者需要向国内 Gitee 平台推送代码，Git 会同样强行把内网流量送入代理。代理服务器无法解析内网域名或无法回环，就会导致内部代码库推送完全瘫痪。

2. 针对特定域名的条件代理法（行业推荐最佳实践）

Git 官方配置引擎原生支持针对特定 URL 前缀与域名设定专属代理。这种方式仅在访问目标域名时走代理，内网与其他平台保持纯净直连。

在终端中执行以下两条精准规则配置。

bash

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

如果使用的是基于 Socks5 协议的代理端口，也可以配置为 Socks5 格式。

bash

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

查看当前 Git 配置是否生效。

bash

git config --global --get-regexp proxy

如果终端输出 http.https://github.com.proxy http://127.0.0.1:7890，说明规则配置无误。

如果后续需要移除该局部规则，执行以下指令即可清除。

bash

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

3. SSH 协议代理配置（解决 git@github.com 超时）

如果习惯使用 SSH 密钥（形如 git clone git@github.com:username/repo.git），前面配置的 http.proxy 是完全不会生效的。因为 Git 底层使用的是系统的 ssh 客户端建立连接。

针对 SSH 连接，需要通过修改用户主目录下的 SSH 配置文件进行管道重定向。

在 Windows 下，打开文件路径 C:\Users\你的用户名\.ssh\config。如果文件不存在，新建一个无后缀的文本文件命名为 config。

在文件中加入以下配置内容。

text

Host github.com
    User git
    Port 22
    Hostname github.com
    ProxyCommand connect -S 127.0.0.1:7890 %h %p

这里的 connect 是 Git for Windows 自带的一个轻量级网络代理连接工具，通常位于 C:\Program Files\Git\mingw64\bin\connect.exe。只要在 Git Bash 或将 Git 路径加入了系统 PATH 的终端中，connect 都可以直接被调用。

参数说明。

-S 127.0.0.1:7890 代表使用本地 Socks5 协议代理。
如果本地客户端只开放了 HTTP 代理，可以换成 -H 127.0.0.1:7890。
%h 代表目标主机名，%p 代表目标端口号。

保存文件后，在终端中测试 SSH 连通性。

bash

ssh -T git@github.com

如果终端返回 Hi username! You've successfully authenticated, but GitHub does not provide shell access.，说明针对 GitHub 的 SSH 加密通道已经完全打通。

常用开发包管理器与容器代理矩阵

软件工程日常开发中，仅解决 Git 往往还不够。前端构建、Python 环境、Java 架构以及容器拉包都需要各自的代理通道支持。

1. NPM / Yarn / PNPM 前端生态

Node.js 生态拥有自己的配置体系。虽然当设置了终端全局环境变量 all_proxy 时大部分网络库会自适应，但在部分复杂构建脚本中，显式配置包管理器的代理能保证稳定性。

NPM 设置与清除

bash

# 设置 NPM 代理
npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890

# 查看当前 NPM 代理配置
npm config get proxy
npm config get https-proxy

# 清除 NPM 代理配置
npm config delete proxy
npm config delete https-proxy

Yarn 设置与清除

bash

# Yarn v1 设置
yarn config set proxy http://127.0.0.1:7890
yarn config set https-proxy http://127.0.0.1:7890

# Yarn v1 清除
yarn config delete proxy
yarn config delete https-proxy

PNPM 设置与清除

PNPM 与 NPM 共享底层规范，同样可以通过类似方式管理。

bash

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

2. Python Pip 代理设置

Python 的 pip 工具在没有代理的情况下下载庞大的机器学习框架（如 PyTorch、TensorFlow）时容易发生数据中途截断。

单次临时运行指定代理

bash

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

配置文件永久指定代理

在 Windows 系统中，创建或编辑配置文件 C:\Users\你的用户名\pip\pip.ini，写入以下段落。

ini

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

这样每次执行 pip install 时都会自动经由本地代理下载轮子文件。

3. Java 生态 Maven 与 Gradle 代理配置

Java 项目在拉取公共中央仓库依赖时，如果不走代理，下载经常陷入极慢状态或直接触发 SocketTimeout 异常。Java 虚拟机并不直接继承 Windows 宿主机的通用环境变量，需要针对构建工具自身配置文件进行参数定义。

Maven 全局代理配置

编辑 Maven 安装目录或用户目录下的 settings.xml（通常位于 C:\Users\你的用户名\.m2\settings.xml），在 <proxies> 标签内填入本地代理节点。

xml

<proxies>
  <proxy>
    <id>local-proxy</id>
    <active>true</active>
    <protocol>http</protocol>
    <host>127.0.0.1</host>
    <port>7890</port>
    <nonProxyHosts>localhost|127.0.0.1|*.corp.domain.com</nonProxyHosts>
  </proxy>
</proxies>

Gradle 全局代理配置

在用户目录下的 Gradle 全局属性文件 C:\Users\你的用户名\.gradle\gradle.properties 中添加以下参数。

properties

systemProp.http.proxyHost=127.0.0.1
systemProp.http.proxyPort=7890
systemProp.https.proxyHost=127.0.0.1
systemProp.https.proxyPort=7890
systemProp.http.nonProxyHosts=localhost|127.0.0.1|*.corp.domain.com

配置后，无论是 IntelliJ IDEA 还是命令行执行 Gradle 构建，下载远程依赖包都会自动走本地代理通道。

4. Docker 容器拉取镜像代理配置

Docker 容器的架构比较特殊。在 Windows 上运行 Docker Desktop 时，Docker 守护进程实际上运行在一个名为 WSL2（Windows Subsystem for Linux）的轻量级 Linux 虚拟机内部。

在终端中设置 $env:http_proxy 只能影响当前终端向 Docker 服务发送 API 控制指令，根本无法改变 Docker 后台拉取镜像（docker pull）的网络路径。

要在 Docker Desktop 中正确配置出网代理，请遵循以下步骤。

打开 Docker Desktop 视窗主界面。
点击右上角的齿轮图标进入 Settings（设置）。
在左侧菜单中选择 Resources（资源） 下的 Proxies（代理）。
勾选 Manual proxy configuration（手动代理配置）。
在 Web Server (HTTP) 栏中填写 http://127.0.0.1:7890。
在 Secure Web Server (HTTPS) 栏中填写 http://127.0.0.1:7890。
在 Bypass proxy settings for these hosts & domains（旁路名单）中填写 localhost,127.0.0.1,docker-registry.somecompany.com。
点击右下角 Apply & restart（应用并重启）。

text

+--------------------------------------------------------------------------+
|                  Docker Desktop 代理流转架构                             |
+--------------------------------------------------------------------------+
Windows 宿主系统                      WSL2 Docker 守护虚拟机 (Engine)
+-----------------------+             +------------------------------------+
| 终端执行: docker pull | ----------> | dockerd 守护进程                   |
+-----------------------+   Docker    |                                    |
                            Socket    | 读取 Settings 注入的代理环境变量:  |
                                      | HTTP_PROXY=http://192.168.x.x:7890 |
                                      +------------------------------------+
                                                        |
                                                        v
                                      +------------------------------------+
                                      | 转发至宿主机代理客户端核心 7890    |
                                      +------------------------------------+

配置完成后，Docker 引擎在执行远程 Registry 握手与层文件分块传输时，即可顺利跑满带宽。

WSL2 子系统终端跨网络代理打通

在 Windows 10 与 11 中，众多开发者选择在 WSL2 虚拟子系统中进行代码编译与开发。由于 WSL2 默认架构采用独立的虚拟化网络命名空间（NAT 模式），子系统拥有独立的虚拟网卡与子网 IP，无法直接将代理指向 127.0.0.1:7890（因为那代表 WSL2 虚拟机自身）。

1. 传统 NAT 模式下的宿主机 IP 动态提取

在默认 NAT 模式下，WSL2 访问宿主机的 Windows 系统需要使用宿主机在虚拟交换机上的 IP 地址。在 WSL2 的 ~/.bashrc 或 ~/.zshrc 中添加以下自适应函数脚本。

bash

# 获取宿主机虚拟 IP
export HOST_IP=$(ip route show default | awk '{print $3}')

# 定义 WSL2 代理开关函数
function set_proxy() {
    export http_proxy="http://${HOST_IP}:7890"
    export https_proxy="http://${HOST_IP}:7890"
    export all_proxy="socks5://${HOST_IP}:7890"
    echo "[+] WSL2 代理已指向宿主机 -> http://${HOST_IP}:7890"
}

function unset_proxy() {
    unset http_proxy https_proxy all_proxy
    echo "[-] WSL2 代理已清除，恢复直连"
}

同时，必须在 Windows 宿主机代理客户端的设置中开启**“允许局域网连接”（Allow LAN）**，并在 Windows 防火墙中放行该端口，WSL2 的虚拟网卡数据包才能成功进入代理软件。

2. 现代 Mirrored 镜像网络模式（Windows 11 最佳实践）

如果使用的是 Windows 11 23H2 及更高版本，微软为 WSL2 引入了全新镜像网络特性（Mirrored networking）。在此模式下，WSL2 与 Windows 宿主机共享完全相同的网络命名空间与 IP 地址，直接打破了传统虚拟化网络隔阂。

在 Windows 用户目录 C:\Users\你的用户名\.wslconfig 文件中写入以下配置。

ini

[wsl2]
networkingMode=mirrored

在 PowerShell 中执行 wsl --shutdown 重启子系统。进入 WSL2 后，直接使用 127.0.0.1:7890 即可与宿主机无缝互通，完全无需再费力提取动态网关 IP，网络体验与原生 Linux 彻底一致。

自动化终端网络切换脚本

为了在不同开发工程与网络环境之间快速切换，编写了一个自动化批处理脚本。将以下代码保存为 terminal_proxy_switch.bat，双击或在终端中运行即可通过交互式菜单瞬间完成状态切换。

bat

@echo off
chcp 65001 >nul
title 终端网络代理一键维护工具

:MENU
cls
echo ======================================================
echo          Windows 终端开发代理自动化配置工具
echo ======================================================
echo  1. 开启 Git 针对 GitHub 域名的精准局部代理 (推荐)
echo  2. 清除 Git 针对 GitHub 的局部代理设置
echo  3. 写入当前用户永久环境变量 (http_proxy / all_proxy)
echo  4. 清除当前用户永久环境变量
echo  5. 探测 GitHub 与公网 IP 连通性
echo  6. 退出程序
echo ======================================================
set /p CHOICE=请输入操作编号 (1-6): 

if "%CHOICE%"=="1" goto SET_GIT
if "%CHOICE%"=="2" goto UNSET_GIT
if "%CHOICE%"=="3" goto SET_SYS
if "%CHOICE%"=="4" goto UNSET_SYS
if "%CHOICE%"=="5" goto TEST_NET
if "%CHOICE%"=="6" exit
goto MENU

:SET_GIT
echo [*] 正在为 GitHub 配置局部代理 127.0.0.1:7890...
git config --global http.https://github.com.proxy http://127.0.0.1:7890
git config --global https.https://github.com.proxy http://127.0.0.1:7890
echo [✓] Git 针对 GitHub 的专属代理已成功挂接！
pause
goto MENU

:UNSET_GIT
echo [*] 正在清除 Git 代理规则...
git config --global --unset http.https://github.com.proxy
git config --global --unset https.https://github.com.proxy
git config --global --unset http.proxy
git config --global --unset https.proxy
echo [✓] Git 所有代理配置项已清除完毕！
pause
goto MENU

:SET_SYS
echo [*] 正在持久化当前用户代理环境变量...
setx http_proxy "http://127.0.0.1:7890" >nul
setx https_proxy "http://127.0.0.1:7890" >nul
setx all_proxy "socks5://127.0.0.1:7890" >nul
echo [✓] 用户级持久化变量已生效，重新打开 CMD/PowerShell 即可载入。
pause
goto MENU

:UNSET_SYS
echo [*] 正在清除用户持久化环境变量...
REG delete HKCU\Environment /F /V http_proxy >nul 2>&1
REG delete HKCU\Environment /F /V https_proxy >nul 2>&1
REG delete HKCU\Environment /F /V all_proxy >nul 2>&1
echo [✓] 用户环境变量已完全清空，请重新打开终端！
pause
goto MENU

:TEST_NET
echo [*] 正在探测网络连通性...
curl -I -m 5 https://github.com
echo.
echo [*] 当前终端外网识别 IP:
curl -m 5 https://api.ipify.org
echo.
pause
goto MENU

该脚本覆盖了高频维护场景，避免了每次手工敲击命令与查询注册表的麻烦。

常见故障诊断与 FAQ 问答

在终端代理配置过程中，以下几个问题最为常见。

1. 为什么设置了代理后，终端克隆反而报 Connection refused？

Connection refused（连接被拒绝）说明请求成功发送到了指定的代理端口，但目标端口上并没有任何程序在监听。

引发该问题最常见的原因有两个。

本地代理客户端没有运行，或者中途发生崩溃退出。
代理客户端实际监听的端口并不是 7890（例如部分客户端默认是 10808 或 10809）。

可以通过在终端执行 netstat -ano | findstr 7890 检查端口是否存在监听进程。若端口不同，将配置中的端口改为实际监听数值即可。

2. 为什么在终端使用了 export 或者 set，关闭窗口后就失效了？

环境变量在操作系统中分为三个层级，分别是临时进程级、当前用户级以及系统全局级。

在当前打开的 CMD 或 PowerShell 窗口中运行的 set 或 $env: 属于进程级变量。当终端窗口关闭时，该进程分配的内存上下文被系统彻底回收，变量自然随之销毁。这是保护操作系统网络纯净性的合理机制。若需要每次打开终端都拥有代理能力，推荐将控制别名写入 PowerShell 的 $PROFILE 文件中。

3. Git Clone 提示 `SSL certificate problem: unable to get local issuer certificate` 该怎么处理？

这是因为本地某些抓包审计软件或代理工具开启了 MITM（中间人解密）功能，向网络链路上注入了自签名证书，导致 Git 的 OpenSSL 库校验失败。

在确信本地环境安全的情况下，可以执行以下命令临时忽略 SSL 证书链验证。

bash

git config --global http.sslVerify false

但更为严谨的做法是定位并关闭代理客户端中不必要的 HTTPS 解密功能，保证根证书链的真实与完整。

4. 局域网有另外一台电脑开启了代理，本地终端如何借用该代理？

只要代理客户端所在电脑在设置中开启了“允许局域网连接”（Allow LAN），并且 Windows 防火墙放行了对应端口，局域网内的其他设备均可直接共用该代理。

假设运行代理客户端的宿主机局域网 IP 为 192.168.1.100，在本地终端执行以下命令即可。

powershell

$env:all_proxy="http://192.168.1.100:7890"

这种配置方式特别适合虚拟机、树莓派或独立测试工作站快速接入出海网络。

Windows CMD、PowerShell 与 Git Bash 设置终端代理 解决 Git Clone 超时卡死 ​

为什么终端环境天然不走 Windows 系统代理 ​

典型终端网络超时报错大表 ​

终端网络通信拓扑与转发路径 ​

Windows CMD 环境变量临时与持久化设置 ​

1. 当前 CMD 会话临时代理 ​

2. 清除 CMD 当前会话代理 ​

3. Windows 全局用户环境变量持久化 ​

PowerShell 核心函数编写与配置文件持久化 ​

1. 基础临时设置语法 ​

2. 编写高复用性 PowerShell 控制函数 ​

3. 配置脚本执行策略 ​

Git 客户端代理的三种粒度精细化配置 ​

1. 全局配置法（不推荐） ​

2. 针对特定域名的条件代理法（行业推荐最佳实践） ​

3. SSH 协议代理配置（解决 git@github.com 超时） ​

常用开发包管理器与容器代理矩阵 ​

1. NPM / Yarn / PNPM 前端生态 ​

NPM 设置与清除 ​

Yarn 设置与清除 ​

PNPM 设置与清除 ​

2. Python Pip 代理设置 ​

单次临时运行指定代理 ​

配置文件永久指定代理 ​

3. Java 生态 Maven 与 Gradle 代理配置 ​

Maven 全局代理配置 ​

Gradle 全局代理配置 ​

4. Docker 容器拉取镜像代理配置 ​

WSL2 子系统终端跨网络代理打通 ​

1. 传统 NAT 模式下的宿主机 IP 动态提取 ​

2. 现代 Mirrored 镜像网络模式（Windows 11 最佳实践） ​

自动化终端网络切换脚本 ​

常见故障诊断与 FAQ 问答 ​

1. 为什么设置了代理后，终端克隆反而报 Connection refused？ ​

2. 为什么在终端使用了 export 或者 set，关闭窗口后就失效了？ ​

3. Git Clone 提示 SSL certificate problem: unable to get local issuer certificate 该怎么处理？ ​

4. 局域网有另外一台电脑开启了代理，本地终端如何借用该代理？ ​

Windows CMD、PowerShell 与 Git Bash 设置终端代理解决 Git Clone 超时卡死

为什么终端环境天然不走 Windows 系统代理

典型终端网络超时报错大表

终端网络通信拓扑与转发路径

Windows CMD 环境变量临时与持久化设置

1. 当前 CMD 会话临时代理

2. 清除 CMD 当前会话代理

3. Windows 全局用户环境变量持久化

PowerShell 核心函数编写与配置文件持久化

1. 基础临时设置语法

2. 编写高复用性 PowerShell 控制函数

3. 配置脚本执行策略

Git 客户端代理的三种粒度精细化配置

1. 全局配置法（不推荐）

2. 针对特定域名的条件代理法（行业推荐最佳实践）

3. SSH 协议代理配置（解决 git@github.com 超时）

常用开发包管理器与容器代理矩阵

1. NPM / Yarn / PNPM 前端生态

NPM 设置与清除

Yarn 设置与清除

PNPM 设置与清除

2. Python Pip 代理设置

单次临时运行指定代理

配置文件永久指定代理

3. Java 生态 Maven 与 Gradle 代理配置

Maven 全局代理配置

Gradle 全局代理配置

4. Docker 容器拉取镜像代理配置

WSL2 子系统终端跨网络代理打通

1. 传统 NAT 模式下的宿主机 IP 动态提取

2. 现代 Mirrored 镜像网络模式（Windows 11 最佳实践）

自动化终端网络切换脚本

常见故障诊断与 FAQ 问答

1. 为什么设置了代理后，终端克隆反而报 Connection refused？

2. 为什么在终端使用了 export 或者 set，关闭窗口后就失效了？

3. Git Clone 提示 `SSL certificate problem: unable to get local issuer certificate` 该怎么处理？

4. 局域网有另外一台电脑开启了代理，本地终端如何借用该代理？