开发者 GitHub、Docker、npm 加⁠速完整方⁠案

先按开发工作流拆分问题

开发者最容易犯的错误，是打开客户端的全局模式后直接测试所有工具。全局模式确实能快速判断线路是否可用，但它会改变更多请求的路径，可能影响内网域名、数据库连接、局域网服务、公司代码仓库以及本地开发服务器。更适合长期使用的方式，是先建立最小可用配置，再按工具逐项加入代理规则。

GitHub 访问通常包含网页、git over HTTPS、SSH、Release 下载和 API 请求。网页可以通过浏览器代理验证，git 命令则要检查 Git 自身的 proxy 配置；如果使用 SSH 拉取仓库，HTTPS 代理设置不会自动接管 SSH 连接。Docker 又分为客户端与 daemon 两个部分，前者负责发送命令，后者负责真正拉取镜像，因此只给终端设置环境变量不一定足够。npm 和 pip 通常支持 HTTP(S) 代理，但它们还会受到证书校验、私有仓库认证和 lockfile 中地址的影响。

线路选择也应服从任务类型，而不是只看名称。直连线路结构简单，适合先做基础排障；中转线路可能拥有更灵活的入口与出口组合；IEPL 等专线强调承载路径的稳定性，适合对持续传输有要求的场景；BGP、CN2 等名称更多描述网络互联或承载方向，不能单凭名称推断某个仓库、镜像站或包站点一定更快。对于开发工具，稳定建立 TLS 连接、持续传输和正确解析域名，通常比一次短暂的峰值速度更重要。

GitHub 与 Git：网页能开不等于仓库可用

先从 HTTPS 仓库开始排查，因为它通常比 SSH 更容易接入 HTTP 代理。可以查看当前 Git 配置，确认是否存在历史代理、错误端口或指向已经停止运行的本地服务：

git config --global --get http.proxy
git config --global --get https.proxy
git remote -v

如果客户端在本机提供 HTTP 代理端口，可以将 Git 的 HTTPS 请求指向该端口。这里的地址和端口必须以实际客户端显示为准，不要照抄其他教程中的示例值。设置完成后，使用一个体积较小的仓库进行 clone、fetch 和 push 测试，分别观察连接建立、对象传输和身份验证是否都正常。只测试网页只能证明浏览器路径可用，无法证明 Git 进程继承了同样的规则。

git config --global http.proxy http://127.0.0.1:本地端口
git config --global https.proxy http://127.0.0.1:本地端口
git ls-remote https://github.com/组织名/仓库名.git

如果不再需要全局代理，应及时删除，而不是长期保留一条可能失效的配置：

git config --global --unset http.proxy
git config --global --unset https.proxy

SSH 仓库则是另一条路径。执行 [email protected]:组织名/仓库名.git 形式的操作时，Git 需要建立 SSH 连接，HTTP 代理配置不会自动生效。此时可以改用 HTTPS 远端，或者在确认客户端支持的前提下配置 SSH 的 ProxyCommand。企业网络还可能限制 SSH 出站连接，因此不要在多个配置文件中重复叠加规则。若错误信息包含 host key、permission denied 或 publickey，问题重点通常是 SSH 密钥和主机校验，而不是线路速度。

• ✅ 先用 git ls-remote 测试远端可达性，再进行完整 clone。
• ✅ 区分 HTTPS 远端与 SSH 远端，不要用同一套判断方法。
• ✅ 检查 Git 全局配置、仓库级配置和环境变量是否互相覆盖。
• ✅ Release 或大文件下载失败时，单独测试对应下载域名。
• ❌ 不要把访问令牌、SSH 私钥或带凭据的 URL 写入公开日志。

Git LFS 还可能访问与普通仓库不同的存储端点。普通仓库 fetch 成功而 LFS 文件失败时，应查看 LFS 的实际请求地址和凭据状态，不能仅凭 GitHub 首页已经打开就判定线路无问题。对于团队项目，建议把代理配置放在个人环境或受控的开发容器中，避免提交到项目仓库，导致其他成员被迫使用同一个本地端口。

Docker：重点配置真正发起请求的 daemon

Docker 排障的关键，是分清 Docker CLI 与 Docker daemon。执行 docker pull 时，命令由 CLI 发出，但镜像层的下载通常由 daemon 完成。即使终端中设置了 HTTP_PROXY 和 HTTPS_PROXY，daemon 也可能完全看不到这些变量。桌面版 Docker、Linux 上的 systemd 服务以及远程 Docker 主机，配置入口各不相同。

如果使用 Docker Desktop，应在其设置中的代理区域配置，并重启相关服务后再测试。若是 Linux systemd 管理的 Docker 服务，可以通过 drop-in 配置为 daemon 提供代理环境变量。示例中的端口必须替换为本机客户端真实开放的 HTTP 代理端口：

sudo systemctl edit docker

[Service]
Environment="HTTP_PROXY=http://127.0.0.1:本地端口"
Environment="HTTPS_PROXY=http://127.0.0.1:本地端口"
Environment="NO_PROXY=localhost,127.0.0.1,.local"

sudo systemctl daemon-reload
sudo systemctl restart docker

保存后先查看 daemon 状态，再执行拉取。若服务启动失败，优先检查 drop-in 文件格式、代理协议是否匹配以及本地代理是否允许来自 daemon 的连接。Linux 上 127.0.0.1 代表 Docker 所在主机；如果 daemon 在虚拟机、远程服务器或独立容器中运行，这个地址指向的可能不是桌面客户端所在环境。

镜像源与代理是两个不同层次。镜像源可以减少某些公共镜像的跨网络访问，但不一定覆盖私有 Registry、镜像中的软件包地址、构建阶段的 Git 仓库或多阶段构建中的外部下载。代理则更通用，却需要处理证书、认证和网络权限。实际项目中可以先用代理确认路径，再评估是否为常用公共镜像配置可信镜像源。不要把不明来源的镜像源直接写入团队或生产配置。

构建镜像时还要区分构建阶段和运行阶段。docker build 使用的代理参数只应服务于构建过程，避免把代理地址、用户名或令牌固化进镜像层。可以通过构建参数或 BuildKit 的受控 secret 传入，并在 Dockerfile 中避免把敏感变量写进 ENV。构建完成后，使用 docker history 检查是否意外留下凭据或内部地址。

npm、pip 与依赖下载：代理之外还要检查索引

包管理器的请求往往比浏览器更容易暴露配置问题。npm 会读取用户配置文件、项目配置和环境变量，pip 也可能受到全局配置、虚拟环境变量以及项目依赖声明的影响。配置代理前，先确认当前使用的 registry 或 index，避免把“索引地址错误”误判成线路速度问题。

npm 可以查看当前配置：

npm config get registry
npm config get proxy
npm config get https-proxy
npm ping

如果只希望当前项目使用某个代理，优先把配置放在项目范围或当前 shell，而不是无条件写入全局配置。npm 的 proxy 和 https-proxy 应使用客户端实际支持的代理类型；不要为了绕过证书错误而关闭 strict-ssl，这会削弱 TLS 校验。私有 registry 的 token 应放在受保护的用户配置中，并确认日志不会打印完整配置内容。

pip 可用环境变量为单次命令提供代理，也可以在用户配置中持久化。下载失败时，分别测试索引首页、一个具体包和依赖树中的外部 URL：

python -m pip config list
python -m pip install --proxy http://127.0.0.1:本地端口 包名
python -m pip download --no-deps 包名

如果某个项目的 lockfile、requirements 文件或 package 配置中写入了特定域名，包管理器可能在解析依赖时访问多个站点。一个索引可达，并不代表所有依赖源都可达。遇到 TLS 错误时，应检查系统时间、根证书、企业 HTTPS 检查策略和 Python、Node.js 的证书路径；不要直接使用跳过证书验证的参数作为长期方案。

• ✅ 先记录 npm registry 或 pip index，再确认它是否为项目要求的来源。
• ✅ 使用单次命令测试代理，确认有效后再决定是否持久化。
• ✅ 私有仓库认证信息放在用户配置或 secret 中，不写入仓库。
• ✅ 将缓存作为稳定性补充，而不是把缓存误认为网络已经正常。
• ❌ 不要用关闭 TLS 校验的方式掩盖证书链配置错误。

CI 构建与预算：让配置可复现、可撤销

CI 环境与本地电脑最大的区别，是 Runner 的网络出口、DNS、权限和文件系统都可能不同。开发者电脑上能成功执行的 npm ci、pip install 或 docker build，放到 CI 后可能因为没有代理变量、无法解析 Registry、缺少 CA 证书或访问令牌失效而失败。排查时应先打印非敏感的环境信息，例如工具版本、目标域名和代理是否存在，不要直接输出完整 URL、token 或 secret。

建议把 HTTP_PROXY、HTTPS_PROXY 和 NO_PROXY 作为 CI 的受保护变量，按项目或 Runner 范围授权。NO_PROXY 应加入本地回环地址、内部域名、服务发现名称和不应经过外部代理的数据库地址。规则过宽会让外部依赖绕过代理，规则过窄则可能让内部服务被错误送到代理端，二者都可能造成构建失败或安全风险。

Docker-in-Docker、远程 Docker daemon 和普通宿主机 Docker 的代理位置也不同。使用前先确认构建命令实际连接的 daemon，再分别配置 registry 拉取、Dockerfile 构建阶段和最终容器运行阶段。对于 CI 缓存，应使用可信的包缓存或镜像缓存，并设置明确的失效策略；缓存命中可以减少重复下载，但不能替代对新依赖、签名和完整性校验。

预算配置应围绕使用量和稳定性，而不是盲目追求线路数量。个人开发者可以先选择月订阅：¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量按开通日每月重置；需要一次性使用且不希望按月续订时，可考虑¥158/300GB、¥358/1000GB、¥658/3000GB的流量包，用完为止且永久不过期。月订阅中途升级时，差价按剩余天数折算。正式选择前，可根据是否频繁拉取镜像、是否运行大型依赖构建以及是否有多台设备共同使用来评估。

支持 Windows、macOS、iOS、Android 和 Linux 的客户端可以覆盖不同开发设备；兼容客户端也可能通过订阅链接导入 Shadowsocks、VMess、Trojan、Hysteria2 或 WireGuard 等配置，但协议支持取决于具体客户端版本。Clash Verge、sing-box、Shadowrocket 等工具的配置字段和分流语法并不完全相同，导入后仍要检查规则是否命中目标域名。服务支持不限台数同时在线设备，不能替代对订阅链接和本地凭据的保护。

最终验证时，建议按照“断开线路建立基线、连接后检查出口、测试 DNS、执行 Git 命令、拉取一个小型镜像、安装一个依赖、再运行完整构建”的顺序进行。本站的网络检测页面只能帮助确认出口变化，不能代替 Git、Docker 或包管理器的真实测试。需要导入客户端或调整分流时，可以参考使用教程，并将错误日志中的账号、订阅链接、令牌和内部域名先脱敏。