git clone、push 频繁超时，先用三步定位问题层级
git clone/push 卡住或超时，背后可能是 DNS 解析绍远路、国际出口拥塞，也可能是 GitHub 对高频/大流量请求的限速。先用三步定位法缩小范围：一是 curl -I https://github.com 看 TCP 能不能通；二是临时挂代理后重试，判断是不是链路问题；三是如果挂上代理依然慢，要考虑是不是限速而不是连通性问题。
团队级配置方案
统一用 url.insteadOf，不要每人各自换镜像
通过 git config 全局配置 url.＜base＞.insteadOf 规则，可以把 GitHub 地址自动替换为加速源，包括子模块递归克隆在内都能自动生效，不需要每次手动切换。团队统一配置比每人各自摸索一套方案，后续排查也更容易。
私有仓库安全提醒
公开仓库 clone 不存在泄露问题，但如果是推送私有仓库或带 token 操作，切勿走第三方镜像，因为镜像方理论上能记录你的 token，私有仓库建议直接走自营稳定链路连 github.com，不依赖不确定的公益镜像方。
大仓库场景的传输优化
除了链路本身，大仓库也可以从减少传输量入手：浅克隆（--depth）只拉最新提交记录，稀疏检出（sparse-checkout）只下载需要的目录，大文件走 Git LFS 本地只保留指针。搭配 core.compression、fetch.parallel 这类参数调优，能进一步缩短大仓库的传输时间。
团队统一链路比每人各自换镜像更稳定
公益镜像难免遇到流量过大被限速或停服的情况，而且公益镜像不适合私有仓库，团队里每个人各自摸索不同的临时方案，维护成本也会随团队规模变大。从链路层面统一优化，既能覆盖公开/私有仓库两种场景，也不需要担心公益镜像随时失效。通宝 VPN 的 IEPL 国际专线搭配 AI 智能路由，能为开发团队提供相对稳定的出口路径，团队席位下每个成员都能用同一套接入方式，不用再为镜像方能不能用、token 安全不安全这些问题担心。
自查清单与总结
git clone/push 超时先用三步定位法确认问题层级，再按下面步骤逐项处理：
- curl 测试基础连通性，区分 DNS/网络层问题还是限速
- 区分公开/私有仓库，私有仓库/带 token 操作不走第三方镜像
- 团队统一配置 url.insteadOf，避免每人各自摸索
- 大仓库优先用浅克隆/稀疏检出/LFS 减少传输量
常见问题
公益镜像能长期依赖吗？
不建议，多个公益镜像因流量过大被迫限速或停服，适合偶尔临时使用，不适合作为团队长期依赖的基础设施。
私有仓库为什么不能走镜像？
镜像方作为中间人，理论上能看到你传输的 token 和仓库内容，涉及凭据的操作必须走可信链路。
已经挂了代理但 clone 还是慢，怎么办？
说明可能不是连通性问题，而是 GitHub 对该链路/IP 段的限速，或代理自身链路质量不稳定，需要换个更稳定的接入方式对比。
