GitHub 克隆慢、Docker 镜像拉取卡住，表面上都像是“网络不快”，实际可能是不同环节出了问题：代码传输经过 Git 客户端，容器镜像由 Docker daemon 拉取，npm 和 pip 又各自读取代理设置。先分清请求是谁发出的，再调整对应位置，比反复换节点或堆叠配置更有效。

本文按工作流拆解常见瓶颈，提供可撤销的配置方法。示例中的代理地址和端口均为占位内容，需替换成当前客户端实际提供的本地代理地址；如果不使用代理，就不要照抄代理配置。

先定位瓶颈：区分客户端、守护进程与目标服务

下载速度受本地网络、服务端响应、跨网路由、DNS、代理路径和目标站点限流等因素共同影响。一次失败不能直接证明是节点问题：连接超时更像是路径或代理不可达，名称解析失败要查 DNS，认证错误通常与凭据有关，HTTP 429 则表示请求受到限速。把这些情况分开，才能选对排查方向。

4

主要排查层

3

常见下载工具

1

每次只改一项

可以先记下发生问题的命令、时间、目标仓库或镜像名，以及完整错误信息。随后用同一台设备、同一网络分别测试 Git、Docker 和包管理器。如果只有 Docker 慢，优先看 daemon 的代理配置；若多个工具同时异常，再检查系统网络、DNS 或代理客户端状态。不要公开带有访问令牌、私有仓库地址或账户信息的日志。

还要把 DNS 解析、TCP/TLS 建连和实际传输区分开。域名解析成功只说明找到地址，不代表连接路径顺畅；能打开仓库网页，也不意味着 Git 对象、镜像层或发布附件使用的所有请求都能顺利完成。大文件下载与 API 请求可能命中不同的域名或限速策略。

GitHub 与 Git：检查克隆、对象传输和发布附件

先确认问题发生在哪一步。克隆仓库时若在建立连接阶段失败，检查网络和代理；若已经开始接收对象后速度下降，可能是传输路径、仓库体积或网络波动；如果只有 Git LFS 文件或发布附件慢，还要考虑它们与普通 Git 对象使用的请求路径并不完全相同。可以用小型公开仓库做对照，但不要把仓库内容或私有地址上传到第三方测速网站。

在使用 HTTP 代理的环境中，可仅为当前仓库设置 Git 代理，避免影响其他项目：

git config --local http.proxy http://127.0.0.1:端口
git config --local --get http.proxy

这里的端口需要替换为客户端提供的实际 HTTP 代理端口。若使用的是 SOCKS 代理，应确认 Git 当前调用的网络库支持相应协议，再采用客户端文档给出的格式；不要把 HTTP 代理地址误填成 SOCKS 地址。若设置后出现证书错误，检查系统时间、代理证书和企业网络的 TLS 检查策略，不要通过关闭证书校验来绕过提示。

测试完成后，如果不再需要这项设置，可以在仓库目录中移除：

git config --local --unset http.proxy

使用 `--global` 会把代理应用到当前用户的所有仓库，排查时不宜一开始就这样设置。`git config --show-origin --get http.proxy` 可以帮助定位代理配置来自哪个文件。若克隆速度正常、但拉取发布附件仍慢，分别检查附件来源域名、浏览器下载和终端下载的表现，不要假定一个 Git 设置会覆盖所有客户端请求。

Docker 镜像拉取：代理要配给 Docker daemon

`docker pull` 发起命令的是终端里的 Docker CLI，但镜像下载通常由 Docker daemon 执行。因此，仅在当前终端设置 `HTTP_PROXY`，不一定会让 daemon 使用代理。Linux 上的 Docker Engine、macOS 或 Windows 上的 Docker Desktop，代理入口和生效方式可能不同；应按所用版本的官方说明配置，并在修改后按要求重启相关服务。

先观察错误类型和实际目标。连接超时、DNS 解析失败、TLS 握手错误与认证失败各有不同排查方向。可以用 `docker info` 查看 daemon 状态，并对同一镜像重复拉取以确认问题是否稳定复现；如果镜像较大，网络中断后重新拉取的表现也可能不同。不要为了“提速”随意填写来路不明的镜像加速地址，也不要关闭镜像签名或证书验证。

Docker Desktop 用户应检查应用设置中的代理选项，而不是只在终端配置环境变量。Linux 用户则要确认服务管理器启动的 daemon 是否读取了预期配置；修改系统服务配置前，先备份现有内容，并核对配置格式和当前 Engine 版本的支持范围。配置后再次检查 daemon 状态，再进行拉取测试。公司网络若使用自签名证书，应按管理员提供的方式安装受信任证书，不能把证书校验失败当作普通速度问题。

  • ✅ 先区分 Docker CLI 与 Docker daemon，确认代理设置落在实际发起下载的一侧。
  • ✅ 修改前备份配置，改动后重启需要重启的服务并验证状态。
  • ✅ 私有镜像先核对登录状态、仓库权限和令牌有效性。
  • ❌ 不要把账户密码、访问令牌或私有仓库凭据写进公开日志。
  • ❌ 不要用来源不明的镜像站，也不要通过关闭 TLS 校验处理证书报错。

如果拉取失败提示权限不足，先执行 `docker login` 并核对镜像名称、标签和账户权限；如果是连接问题，再检查 daemon 的代理和 DNS。通过浏览器能打开某个镜像站，不代表 Docker daemon 已经可以连接它，二者可能运行在不同网络环境中。

npm、pip 与本地代理：按工具设置并及时清理

npm 和 pip 通常由当前运行它们的进程发起请求，和 Docker daemon 的代理配置不是一回事。终端环境变量适合临时测试，但会影响同一终端启动的其他程序；工具自身的持久配置更容易跨项目生效，也更容易在换网络后遗忘。建议先采用临时设置验证，再决定是否保留。

在类 Unix shell 中，可在当前终端设置代理变量进行测试：

export HTTP_PROXY=http://127.0.0.1:端口
export HTTPS_PROXY=http://127.0.0.1:端口

变量值应以客户端实际提供的代理协议和端口为准。Windows PowerShell 可用 `$env:HTTP_PROXY` 和 `$env:HTTPS_PROXY` 设置当前会话变量；关闭终端后，临时变量通常不再保留。若代理需要用户名或密码，避免将完整凭据写进命令历史、脚本仓库或 CI 日志，优先使用安全的凭据管理方式。

npm 可以检查当前配置来源，再按需要设置或删除代理；pip 可以通过安装命令的 `--proxy` 参数进行单次测试。不同版本对配置文件、环境变量优先级和代理格式的处理可能不同，遇到异常先查看工具自身的配置输出与文档。安装依赖时出现校验和不匹配、证书过期或包版本不存在，通常不是简单提高代理速度就能解决的问题。

尤其不要把 `trusted-host` 或跳过 TLS 验证当作通用提速选项。它们可能降低对下载来源的安全检查。若企业证书拦截导致 HTTPS 验证失败，应向网络管理员确认受信任证书和适用配置；如果错误来自索引地址或依赖版本，则应先修正包源与项目锁定文件。

配置结论

Git、Docker、npm 和 pip 的代理入口并不相同。先用单次、可撤销的设置验证问题，再决定是否保存长期配置；每次只改一个位置，才能知道哪项调整真正有效。

CI、API 与日常工作流：把诊断放回运行环境

CI 中的构建任务运行在 Runner 或容器内部，开发电脑上的代理设置不会自动传过去。排查时先确认 Runner 的网络出口、DNS、代理变量和证书信任，再确认构建容器是否继承了这些配置。自托管 Runner 还需检查服务进程启动环境；容器构建则要分别考虑构建阶段与 Docker daemon 的网络配置。

代理认证信息应保存在 CI 平台提供的密钥存储中，通过受控变量传递，并避免在调试输出中打印完整环境变量。日志中如果出现代理 URL，检查是否包含用户名、密码或令牌；发现凭据暴露时应按平台流程撤销或轮换。缓存可以减少重复下载，但要关注缓存键、依赖锁文件和缓存污染风险，不能把未知来源的缓存当作可信构建结果。

GitHub API 请求与 Git 克隆也应分开判断。收到 401 或 403 时先核对令牌权限、组织策略与账户认证；出现限流响应时，查看服务返回的限流信息并减少重复轮询，必要时使用符合权限要求的认证方式。更换网络出口不会自动增加 API 配额，也不能解决权限配置错误。若仅 API 变慢而仓库克隆正常，优先检查请求频率、响应状态码和调用端超时设置。

预算选择应从重复工作量和故障影响出发，而不是只看一次下载的峰值速度。个人开发者可以先使用现有网络与工具缓存，记录哪些任务反复耗时；团队则应核算 Runner 带宽、缓存存储、依赖镜像维护和凭据管理的成本。使用 VPN 或其他代理工具时，还要确认客户端是否支持当前系统、目标应用流量是否实际经过该连接，以及公司策略是否允许。需要了解连接与客户端下载方式，可从 JiuVPN 首页查看相关信息；不要据此推断某个具体仓库、镜像或 API 一定会提速。

最后，把排查结果整理成可复现的记录：运行环境、工具版本、请求目标、错误类型、代理是否启用及配置改动。测试时先恢复基线，再一次调整一个变量；验证结束后清理临时代理和测试凭据。这样既能避免配置残留，也能在网络、软件版本或 CI 环境变化后快速重新定位问题。