配置 约 11 分钟

开发者 VPN 配置全攻略：GitHub、Docker、npm 提速一篇配齐

从 GitHub clone 到 Docker 镜像、npm 和 pip 依赖下载，逐项配置开发环境的网络路径。了解 VPN 分流、DNS、CI Runner 与账号凭据保护，并按实际流量选择预算方案，让常用开发工具连接更稳定。

开发环境里的 VPN 配置，重点不是把所有软件一股脑切到代理，而是让 GitHub、Docker、npm 和 pip 按各自的网络机制访问，同时保留公司内网、本地服务等连接的正常路径。浏览器能打开网页，不代表 Git、容器守护进程或 CI Runner 也已经走上相同路径。本文按“客户端与系统—开发工具—依赖源—自动化任务”的顺序梳理配置方法，并说明如何验证 DNS、代理规则与凭据保护。

4 类

常见开发工具

3 层

网络排查范围

1 个

任务对应一条基准路径

先理清网络路径：VPN、系统代理与应用代理

VPN 客户端、系统代理和应用自身的代理设置并不是同一层配置。VPN 客户端可能通过虚拟网卡接管较广范围的流量，也可能只设置系统代理；系统代理主要影响会读取操作系统代理设置的应用；Git、npm 等工具还可能另有独立配置。Docker 的镜像拉取则通常由 Docker 守护进程发起，不一定跟随终端里运行的 shell，也不一定能访问宿主机上只绑定到本地回环地址的代理。

因此，配置前先确认客户端当前使用的是规则分流还是全局模式，以及它是通过系统代理还是虚拟网卡接管连接。规则分流通常更适合日常开发：代码托管、软件仓库等需要特定网络路径的请求按规则代理，公司内网、局域网和本地开发服务则按需直连。全局模式可以作为短时排查手段，但若长期使用，可能让内网域名、私有制品库或本机服务也走到不合适的出口。

代理成功也不等于 DNS 一定按预期解析。域名查询可能由操作系统、浏览器安全 DNS、VPN 客户端或应用自己的解析逻辑处理。若 GitHub 页面能打开但克隆失败，或同一域名在浏览器与终端得到不同结果，应把 DNS、代理路径和工具配置分开检查，不要立即把问题归咎于线路速度。

请求来源 常见网络配置位置 验证重点
浏览器 系统代理、浏览器设置或 VPN 虚拟网卡 目标页面是否可访问，浏览器是否启用独立 DNS
Git 与 npm 工具配置、环境变量或系统代理 终端是否继承代理，配置是否覆盖了系统设置
Docker 镜像拉取 Docker Desktop 或守护进程代理设置 守护进程能否访问代理及镜像仓库
CI Runner 运行器环境、任务变量与网络策略 执行任务的机器是否有相同出口与凭据权限

如果还没有完成客户端安装与订阅导入，可以先查看新手指引，再回来配置各个开发工具。订阅链接属于连接配置，应从可信的服务入口获取并妥善保管；不要把它写进项目仓库、构建日志或公开 issue。

配置 GitHub 与 Git：先区分 HTTPS 和 SSH

GitHub 网页可以访问，但 git clone 超时，常见原因包括终端没有继承系统代理、Git 自己保存了旧代理，或者仓库采用的传输方式与当前网络规则不匹配。先查看 Git 当前代理配置，再确认终端环境变量和 VPN 客户端的分流规则；不要在多个地方重复配置后忘记请求最终采用了哪一项。

git config --show-origin --get-regexp 'http\..*proxy'
env | grep -i proxy

如果客户端在本机提供 HTTP 代理，可在 Git 中设置对应地址。下面的端口只是示例，应替换成客户端实际显示的本地代理地址；若客户端没有提供该端口，不要照抄示例。设置后可用一条小型、无敏感内容的仓库请求验证，再决定是否保留为全局配置。

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

# 不再需要该设置时，删除 Git 的全局代理项
git config --global --unset http.proxy

GitHub 仓库使用 HTTPS 或 SSH，网络路径和认证方式不同。HTTPS 克隆会使用 HTTPS 连接，认证通常交由 Git Credential Manager、操作系统凭据存储或令牌流程处理；SSH 则需要检查 SSH 客户端与密钥配置。给 Git 设置 HTTP 代理，不代表 SSH 连接也自动按同样方式转发。遇到 SSH 超时，应先确认当前网络规则是否覆盖 SSH 连接，再根据组织要求选择 HTTPS 或经批准的 SSH 配置，不要把访问令牌或私钥粘贴到代理地址中。

代理与认证应分开管理。不要将含用户名、密码或令牌的代理 URL 直接写入项目级 .gitconfig 并提交，也不要把个人访问令牌放在克隆命令、脚本参数或 CI 的明文日志里。若仓库访问失败但网页正常，先确认仓库权限、凭据是否过期、远程地址是否正确，再检查代理连通性；访问路径正常并不会自动赋予账号仓库权限。

Docker 镜像与包管理器：配置发起请求的进程

Docker：检查守护进程使用的代理

执行 docker pull 时，发起镜像请求的往往是 Docker 守护进程，而不是当前终端里的命令行进程。因此，即便 shell 中设置了 HTTPS_PROXY，Docker 拉取镜像仍可能失败。Docker Desktop 用户应优先检查应用设置中的代理选项；Linux 上使用 Docker Engine 时，应按所用发行版与 Engine 文档配置守护进程代理，并在修改后按要求重新加载或重启服务。

守护进程代理配置中，地址和例外列表都应按本机环境填写。若代理运行在宿主机的 127.0.0.1，Docker 守护进程所处的网络环境未必能把这个地址解释为宿主机本身；Docker Desktop、远程 Docker 主机与本机 Engine 的访问方式也可能不同。不要把示例地址原样当作通用设置。配置 no-proxy 时，可将需要直连的本机地址、内网域名或内部制品库加入例外，但范围应尽量具体，避免意外绕过预期的网络路径。

{
  "proxies": {
    "http-proxy": "http://proxy.example:3128",
    "https-proxy": "http://proxy.example:3128",
    "no-proxy": "localhost,127.0.0.1,.example.internal"
  }
}

这是配置结构示例，其中主机名、端口和内网域名都需要替换；如果已有 Docker 配置文件，应合并字段而不是直接覆盖整份文件。配置后分别验证镜像拉取和构建：镜像拉取由守护进程获取基础镜像，构建步骤中的包下载则由构建容器或构建阶段执行，两者可能使用不同的代理环境。仅仅能拉取基础镜像，不能证明 Dockerfile 中的依赖安装也已通畅。

npm 与 pip：优先保留 HTTPS 仓库地址

npm 下载慢或超时，先查看当前 registry 与代理配置，判断问题是仓库可达性、代理继承还是 DNS 解析。通常应优先使用项目或组织认可的包源；如果团队维护内部 registry，应遵循团队的认证与网络要求，不要为了临时提速随意切换到来源不明的镜像。改 registry 可能影响锁文件、包可用性和依赖审计结果，不只是改变下载速度。

npm config get registry
npm config get proxy
npm config get https-proxy
npm config set registry https://registry.npmjs.org/

npm 的代理项只在需要显式指定代理时设置，并使用客户端实际提供的地址。切换电脑、网络或客户端后，旧的本地代理地址可能已不可用；可以查看环境变量与 npm 配置的来源，避免两套设置互相覆盖。若依赖安装提示认证失败，应检查项目的包源与凭据配置，不要把带令牌的 .npmrc 文件提交到公开仓库。

pip 可使用 HTTPS 代理环境变量，包索引地址则应采用组织批准的源或官方配置。以下是当前 shell 会话中的示例写法，代理地址需要按实际环境替换；在 Windows PowerShell 等环境中，设置环境变量的语法不同，应使用对应 shell 的命令格式。

export HTTPS_PROXY=http://127.0.0.1:7890
python -m pip config list
python -m pip install package-name

排查时可以临时在一个新终端中设置或移除代理变量，比较同一个依赖请求的表现。不要为解决证书或连接问题而关闭 TLS 校验，也不要将私有包源的密码直接写在命令历史里。依赖下载的安全性不仅取决于链路，还取决于包源可信度、证书验证和项目锁定文件。

动手配置：从客户端到工具逐项验证

以下流程适合在个人开发机上定位网络问题。每次只改一层配置，并记录改动位置；这样当问题出现时，可以撤销最近一次变化，而不是同时重置 VPN、DNS、Git 和包管理器。

  1. 确认 VPN 客户端已经导入有效配置，选择符合目标服务地区要求的线路，并记录当前是规则分流、系统代理还是虚拟网卡模式。先不要同时启动多个代理客户端，以免系统路由和本地监听端口互相干扰。
  2. 打开终端检查代理环境变量、Git 代理和 npm 配置。确认代理地址确实由正在运行的客户端提供；如果环境变量里还留着旧地址，先清理或更新，再测试 GitHub 网页与 Git 命令。
  3. 对 Git 使用一项不含敏感数据的仓库操作验证 HTTPS 路径。若 HTTPS 正常而 SSH 失败，按传输方式分别排查，不要用更换出口地区来代替检查 SSH 配置或仓库权限。
  4. 在 Docker Desktop 或 Docker Engine 对应位置检查守护进程代理。先验证镜像拉取，再验证构建阶段的依赖下载；若只有构建阶段失败，检查 Dockerfile 与构建环境是否需要单独传递代理，而不是直接假设守护进程配置失效。
  5. 查看 npm 的 registry 与代理配置，再用 pip 检查包索引和 HTTPS 代理。保持仓库地址、认证方式与项目要求一致；若只有某个私有包失败，先核对访问权限和凭据，再判断网络问题。
  6. 最后测试公司内网域名、本机开发服务和常用国际代码仓库，确认分流没有把应直连的流量送到错误路径。更换 VPN 线路或网络环境后，重新执行相关检查，因为 DNS 缓存与客户端规则可能影响结果。

如果需要判断 DNS，可以先对比系统解析结果与目标应用的访问表现，并检查 VPN 客户端提供的 DNS 设置。浏览器的安全 DNS、容器内部 DNS 和宿主机 DNS 可能不同；一次网页检测不能代表所有工具的解析路径。不要在没有备份的情况下随意改系统 DNS，更不要将内部域名查询结果或公司网络信息公开发布。

排查顺序：先确认请求由哪个进程发出，再检查该进程使用的代理与 DNS，最后核对目标服务权限；浏览器连通只是其中一项验证。

CI Runner 与凭据安全：不要照搬个人电脑设置

CI Runner 可能运行在自托管机器、容器或云端环境中，其网络出口、DNS 和代理配置未必与开发电脑相同。流水线中的 Git checkout、Docker 镜像拉取和 npm、pip 安装也可能分别由不同组件执行。先判断失败发生在任务准备、镜像拉取还是构建命令阶段，再查看对应阶段的运行日志与网络配置。日志只应保留排查所需信息，代理凭据、订阅内容和访问令牌应做遮盖处理。

自托管 Runner 如确实需要 VPN 接入，应由有权限的管理员按组织网络策略配置，并确认 DNS、路由与内网例外项不会让流水线请求意外流向不受信任的出口。公共 Runner 通常由平台管理网络环境，不应擅自将个人订阅链接或个人账号凭据放入共享任务。通过 CI 的密钥管理功能注入必要凭据，并遵守最小权限原则；不要把密钥写入仓库文件、镜像层、构建参数或调试输出。

VPN 能改变网络连接路径，但不能替代 HTTPS/TLS、代码签名、依赖锁定、仓库权限控制或密钥管理。它也不能保证第三方服务始终可用，或让受组织策略限制的资源自动获得授权。面向日常开发，建议把“能连上”与“配置安全”分开验收：前者检查实际工具请求和内网直连，后者检查凭据是否最小化、日志是否脱敏、依赖源是否可信。

  • ✅ 先确认失败的是浏览器、Git、Docker 守护进程还是构建容器。
  • ✅ 每次只改一处代理或分流配置，并保留恢复方式。
  • ✅ 将内网域名、私有仓库和本地服务按组织要求设置直连或专用路径。
  • ❌ 不要把订阅链接、令牌、私钥或含凭据的代理 URL 提交到代码仓库。
  • ❌ 不要通过关闭 TLS 校验或使用不明包源来掩盖网络故障。

预算选择也应结合实际使用方式：轻量开发可先估算代码仓库与依赖下载的月度流量，持续拉取镜像或多设备工作则要留意流量余量。VPNJH 的月订阅档位为 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB；流量包为 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完为止且永久不过期。按实际用量选择即可，不必为了开发工具配置而预设固定消耗。

免费试用