开发者配置 VPN，目标通常不是单纯打开 GitHub，而是让代码托管、容器镜像、npm 与 pip 依赖、API 请求以及 CI 构建在不同网络环境下都能稳定完成。开发工作流中的请求类型很多：Git over HTTPS 需要持续的 TLS 连接，SSH 依赖稳定的长连接，Docker 需要访问镜像仓库和鉴权接口，npm 与 pip 则会同时接触包索引、压缩包下载地址和元数据服务。只把系统代理开关打开，往往只能解决其中一部分问题。
更可靠的思路是先区分“哪些流量需要代理”“哪些流量应当直连”，再根据客户端能力配置规则、DNS 和终端应用参数。Windows、macOS、Linux 官方客户端通常适合快速建立系统级连接；Clash Verge、sing-box、Shadowrocket 等兼容客户端则更适合细分域名、应用和协议。本文按开发者实际工作流拆解配置过程，并说明 GitHub、Docker、npm、pip 和 API 请求失败时应如何定位。
先按开发工作流拆分代理范围
开发环境最容易出问题的地方，是把所有流量都塞进代理，或者只代理浏览器而忽略终端工具。全局代理确实适合首次排查，因为它能快速判断目标服务是否受到当前网络路径影响；但长期使用时，全局模式可能让内网 Git、公司域名、局域网设备和本地开发服务绕远，甚至导致身份验证失败。
建议先列出日常会访问的目标，再决定采用全局、规则还是直连模式。GitHub 网页、Git over HTTPS、容器镜像仓库、npm 包下载、pip 包下载和外部 API 通常需要分别验证。某些服务的网页与实际下载地址并不完全相同，浏览器可以打开，并不意味着命令行请求一定走了同一条路径。
| 工作流 | 需要关注的请求 | 推荐处理方式 | 常见误区 |
|---|---|---|---|
| GitHub 网页与代码拉取 | HTTPS、SSH、仓库页面、Release 或源码下载 | 先用系统代理确认基础连通，再为 Git 单独设置代理 | 浏览器可访问，却忘记终端 Git 没有继承代理 |
| Docker 镜像 | 镜像仓库、鉴权接口、镜像层下载、构建阶段外部请求 | 分别配置 Docker 守护进程与构建工具使用的网络路径 | 只给终端设置代理，Docker daemon 实际仍未配置 |
| npm 与 pip | 包索引、元数据、压缩包、依赖重定向地址 | 使用包管理器自身的代理或镜像配置，并检查证书 | 只修改索引地址，忽略实际包文件来自另一域名 |
| API 与 CI 构建 | API 域名、Webhook、制品仓库、构建脚本下载地址 | 按域名和运行环境分别设置，避免把内网服务送入外部代理 | 本地终端正常，CI Runner 使用了另一套 DNS 和环境变量 |
如果使用 Clash Verge 或 sing-box，建议先从规则模式开始，而不是长期依赖全局模式。规则模式下，开发相关域名可以进入代理组，局域网地址、公司内网后缀和本地开发地址保持直连。Shadowrocket 更适合移动端临时验证 API、网页或远程开发入口，但移动系统的后台限制和应用级权限仍需单独检查。官方客户端则适合不需要复杂分流的用户，连接后再通过 Git、Docker 和包管理器的配置补齐终端流量。
- ✅ 先确认系统连接、节点握手和 DNS 查询都正常。
- ✅ 将代码托管、镜像仓库、包索引和外部 API 分开测试。
- ✅ 内网域名、本机地址和局域网设备默认保持直连。
- ✅ 需要长期使用时优先采用规则分流，排查时再临时切换全局。
- ❌ 不要因为浏览器能打开网页，就认为终端和 Docker 已经生效。
- ❌ 不要同时运行多个占用系统 VPN 或系统代理的客户端。
GitHub 加速的 Git 与 SSH 配置
GitHub 相关操作至少包含网页访问、Git over HTTPS 和 Git over SSH。三者使用的连接入口不同，客户端继承代理的方式也不同。浏览器通常会读取系统代理或兼容客户端的规则；Git 是否使用代理，则取决于 Git 配置、环境变量和当前仓库的远程地址。SSH 又有独立的配置文件，不能简单地把 HTTPS 的设置照搬过去。
如果远程地址是 HTTPS，可以在确认客户端提供本地 HTTP 或 SOCKS 代理端口后，为 Git 设置代理。例如：
git config --global http.proxy http://127.0.0.1:端口
git config --global https.proxy http://127.0.0.1:端口这里的“端口”必须替换成兼容客户端实际显示的本地端口，不要直接复制示例值。若客户端提供的是 SOCKS 入口，可以使用对应的 socks5h 形式，让域名解析也交给代理侧处理。配置完成后，可先执行仓库的远程查询或拉取操作，观察终端是否仍然卡在解析、TLS 握手或对象下载阶段。
不再需要代理时，应明确删除 Git 的全局设置，避免之后切换到办公网络或内网仓库时继续走旧端口：
git config --global --unset http.proxy
git config --global --unset https.proxy
git config --global --get-regexp 'http.*proxy'SSH 场景应编辑用户目录下的 SSH 配置，为代码托管主机指定代理转发方式。不同系统、客户端和代理端口的写法可能不同，关键是确认当前兼容客户端提供了可供 SSH 使用的 SOCKS 或 HTTP CONNECT 入口。完成后先进行主机密钥与身份验证测试，再执行实际的 git clone 或 git fetch。如果网页正常、HTTPS 正常而 SSH 失败，应优先检查 SSH 配置、代理类型和远程地址，而不是反复更换节点。
Git 下载中断还可能来自大文件、Release 附件或子模块。主仓库能够拉取，不代表子模块地址、依赖仓库和附件下载都会自动继承同一配置。检查仓库配置中的远程地址，确认子模块是否使用另一种协议；同时查看 Git 的详细输出，区分 DNS 失败、连接被重置、认证失败与传输超时。不同故障对应的处理方向完全不同。
Docker 提速要同时配置终端与守护进程
Docker 的特殊之处在于，执行 docker pull 时，真正发起镜像请求的可能不是当前终端进程，而是 Docker daemon。桌面版 Docker Desktop 还会在独立的虚拟化环境中运行相关组件。于是，系统代理已经生效、浏览器也能访问仓库，并不代表 Docker 的镜像层下载一定使用了代理。
首先确认 Docker 使用的上下文、守护进程位置以及当前用户连接的 socket。然后根据所用系统和 Docker 发行版提供的配置方式，为 daemon 设置 HTTP、HTTPS 或 SOCKS 兼容的代理入口。修改后必须重启对应服务，并通过日志和实际拉取动作确认配置已经加载。只改 shell 中的 HTTP_PROXY、HTTPS_PROXY，通常只能影响构建命令或脚本，不一定影响 daemon。
Dockerfile 中的构建步骤又是另一层。执行 RUN npm install、RUN pip install 或从外部地址下载工具时，流量可能由 BuildKit、构建容器或构建节点发出。构建参数和环境变量可以传入代理，但不应把带有认证信息的完整代理地址直接写进镜像层，否则可能在镜像历史、缓存或构建日志中留下敏感凭据。更稳妥的做法是使用构建环境的临时凭据机制，并在构建完成后确认最终镜像没有残留代理变量。
对于镜像仓库，至少要分别检查仓库域名、鉴权域名和实际 blob 下载域名。有些仓库登录成功后，会把镜像层重定向到不同的存储入口；规则只覆盖登录域名时，拉取仍可能在下载层阶段失败。使用兼容客户端时，可在规则日志中查看请求实际命中的策略组，确认这些域名没有被错误地分到直连或拒绝规则。
如果 Docker 构建需要访问公司内部仓库，建议采用精确分流：外部镜像和公共依赖走代理，内部域名、私有地址和本地服务直连。还要留意容器内的 DNS 与宿主机不同，宿主机能够解析的内部域名，容器未必能够解析。此时应先确认名称解析和路由边界，再判断是否需要代理。
构建阶段的环境变量边界
Linux shell、Docker daemon、BuildKit 和容器内进程可能拥有不同的环境变量。常见变量包括 HTTP_PROXY、HTTPS_PROXY 与 NO_PROXY，变量名大小写也可能受到工具实现影响。NO_PROXY 应覆盖本机地址、容器网段、公司内部域名和不应外发的服务，但不要把整个公网域名范围粗略加入，否则会让需要代理的依赖重新直连。
验证时可以把流程拆开：先测试镜像仓库登录，再测试单独拉取镜像，接着测试只包含外部依赖的构建，最后再加入内网服务。这样能够判断故障发生在认证、镜像层传输、构建网络还是应用运行阶段。一次性修改所有配置并反复重启，反而会丢失最有价值的错误线索。
120+
国家覆盖
250+
线路数
不限
设备同时在线
14 天
无理由退款
npm 与 pip的索引、证书和代理设置
包管理器失败时，最常见的误判是认为“换一个节点就能解决”。实际上，npm 和 pip 都可能经历元数据查询、依赖解析、文件下载与证书校验多个阶段。索引页面能打开，只说明其中一个请求完成；真正安装时，如果压缩包来自另一个域名，仍可能出现超时、连接重置或校验失败。
npm 可以通过配置文件或命令行设置 registry、代理和严格 SSL 行为。pip 则可通过配置文件、命令行参数或环境变量指定 index、额外索引与代理。开发机上建议把配置写在用户级配置文件中，并记录修改原因；临时排查时使用命令行参数，避免把实验配置永久留在所有项目中。
npm config get registry
npm config get proxy
npm config get https-proxy
python -m pip config list
python -m pip install --verbose 包名如果 npm 能解析依赖但下载文件失败，应查看 verbose 日志中的实际 URL；如果 pip 报证书错误，则先检查系统时间、根证书、企业中间人证书和代理是否进行了 TLS 检查。不要为了绕过错误而长期关闭 SSL 校验，这会削弱包完整性验证，并且可能把真正的证书链问题隐藏起来。
使用 Clash Verge、sing-box 等规则客户端时，包索引和包文件域名都应纳入同一套可验证规则。使用官方客户端时，可以先启用系统代理，再检查 npm、pip 是否继承系统设置；有些命令行工具只读取自己的配置或环境变量，不能假设它们一定理解桌面系统的代理开关。项目中若使用 lockfile，还要注意锁定文件里的地址是否指向特定镜像或私有制品库。
团队协作时，不建议把个人代理地址直接提交到项目仓库。项目配置应保持可移植，代理由开发机、容器构建环境或 CI 的安全变量注入。若公司使用私有 npm registry 或 Python 制品仓库，应将内部地址加入 NO_PROXY 或直连规则，并为认证、证书和网络路径建立单独文档。
DNS 与分流决定了配置是否真正稳定
DNS 不只是“能不能把域名翻译成地址”。当客户端负责代理连接，而系统 DNS 仍在本地网络解析时，可能出现解析结果与实际访问路径不匹配。某些域名在不同网络环境返回不同结果，应用先解析再连接，便可能表现为偶发超时、命中错误入口或切换节点后仍然访问旧地址。
兼容客户端通常提供远程 DNS、加密 DNS、fake-IP 或 redir-host 等模式。选择哪一种，要结合系统、应用和局域网需求。fake-IP 可能与部分局域网设备、企业软件或需要真实地址的应用产生兼容问题；redir-host 更直观，但要注意 DNS 请求到底由谁发出。重要的不是盲目追求某种模式，而是让 DNS 策略与代理规则保持一致。
建议建立清晰的直连范围：本机回环地址、局域网地址、公司内网域名和本地开发域名不应被送入外部代理。公共代码托管、镜像仓库、包管理服务和外部 API 则按照实际连通性进入代理规则。规则修改后要清理 DNS 缓存，重新启动受影响的命令行进程或容器，避免旧解析结果继续干扰判断。
分流日志是很有价值的排查工具。一次失败请求至少应观察域名、解析结果、命中的规则、使用的策略组以及连接阶段。若规则命中代理但 DNS 失败，检查 DNS；若 DNS 正常但 TLS 失败，检查证书和中间代理；若连接完成但应用返回权限错误，则应回到账号、令牌或 API 配额问题。网络工具只负责路径，不会替代服务本身的身份验证。
常见失败原因与实际排查顺序
开发环境故障通常不是单一组件造成的。可以从最底层开始检查：客户端是否已连接、节点是否支持当前协议、系统 DNS 是否可用、目标域名是否命中预期规则、应用是否读取代理设置、服务端是否要求额外认证。每完成一层，就进行一次小范围测试，不要同时更换客户端、节点、端口和包源。
- ✅ 网页打不开时，先检查客户端连接状态、节点选择和 DNS 解析。
- ✅ Git 失败时，确认远程地址类型，并检查 Git 自身的代理配置。
- ✅ Docker 失败时，分别检查 daemon、BuildKit 和容器内命令的网络环境。
- ✅ npm 或 pip 失败时，查看实际下载 URL、证书错误和包管理器配置。
- ✅ CI 失败时，比较 Runner 的 DNS、环境变量、出口路径和凭据权限。
- ❌ 不要把所有错误都归因于节点速度，认证、证书和权限同样常见。
- ❌ 不要在项目仓库提交带账号、密码或令牌的代理 URL。
如果某个节点只对网页有效，却无法支撑 Git 或镜像下载，可能是长连接、TLS 传输、规则匹配或出口策略存在差异。可以更换同一地区的其他线路类型进行对比，例如 IEPL、BGP 或 CN2，但不要只看线路名称就下结论；实际是否适合开发，还要看目标服务、时间段、协议和本地网络的组合。Shadowsocks、VMess、Trojan、Hysteria2 与 WireGuard 的传输特性不同，客户端也不一定完整支持订阅中的每种协议。
预算有限时，可先选择月订阅，按照工作流验证 Git、Docker 和依赖安装是否满足需求；如果只是偶尔构建项目，也可以考虑用完为止且永久不过期的流量包。需要长期使用的用户，应根据每月依赖下载、镜像拉取和 CI 任务量选择额度。当前套餐包括月订阅 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB；流量包包括 ¥158/300GB、¥358/1000GB、¥658/3000GB。月订阅流量按开通日每月重置，中途升级差价折算成剩余天数。
平台方面，35VPN 支持 Windows、macOS、iOS、Android 和 Linux，也可将订阅链接导入 Clash Verge、sing-box、Shadowrocket 等兼容客户端。服务覆盖 120+ 国家、250+ 线路，同时在线设备数不限。准备配置前，可以先查看教程，确认对应系统的客户端获取、订阅导入和规则设置方式；如果需要桌面端文件，再前往下载。支付支持支付宝、微信和 USDT，注册只需用户名与密码，无需邮箱地址，并提供 14 天无理由退款。
最后，建议为自己的开发环境保留一份简短的配置记录：当前客户端、代理类型、DNS 模式、Git 配置位置、Docker daemon 配置位置、包管理器索引以及直连例外。网络变化或重装系统后，按这份记录逐项恢复，比重新尝试各种节点更快，也更容易避免把内部代码、私有仓库或敏感 API 请求误送到不合适的网络路径。