GitLab CI 网络不稳定需分层应对：作业级用 retry 挡偶发抖动（如 DNS 失效、5xx 响应），脚本级嵌入指数退避与降级，基础设施层优化镜像源、缓存及私有 Runner，辅以可观测性留痕。
GitLab CI 在网络不稳定的构建环境中，不能靠“等它变好”来解决问题。关键在于分层应对：在作业层面用 retry 挡住偶发抖动，在脚本层面做退避与降级，在基础设施层面切断瓶颈源头。三者配合，才能让流水线在公网波动、DNS 失效、镜像拉取超时等常见问题下依然可靠运行。
作业级重试：用 retry 控制失败兜底
retry 是最直接的防线，但它只对单次作业失败生效，且每次重试都是全新执行（无状态、不续跑）。适合处理：
• DNS 解析失败
• 连接被拒绝或超时
• 第三方 API 返回 5xx 或无响应
- 基础写法：设置最多重试 2 次（含首次共执行 ≤3 次）
retry: 2 - 精准控制：只对系统或网络类失败重试，避免掩盖脚本逻辑错误
retry: { max_times: 2, when: [runner_system_failure, api_failure] } - 配合健康检查：先探测服务可用性，再执行主任务，减少无效重试
script:- curl -f --max-time 5 https://api.example.com/health || exit 1- npm test -- --host=https://api.example.com
脚本内退避：让请求自己学会等待
CI 层的 retry 不加延迟，连续重试可能触发限流或加重服务压力。真正稳健的做法，是在测试或部署脚本中嵌入指数退避逻辑：
- HTTP 请求使用带重试机制的客户端，例如
retry-axios或node-fetch-retry - Shell 脚本中手动实现简单退避：
for i in $(seq 1 3); doif curl -s --fail https://registry.example.com/ready; then break; fisleep $((2**i));done - 对 Docker 镜像拉取失败，可先尝试本地镜像缓存，再 fallback 到备用仓库地址
基础设施优化：从根上减少网络依赖
很多“网络不稳定”其实是带宽、延迟或出口策略导致的假象。优先排查并优化底层环境：
- 改用自托管 Runner：共享 Runner 的出口带宽常被挤占，私有 Runner 可大幅降低镜像拉取、依赖下载耗时
- 配置私有 Maven/NPM 镜像源：把中央仓库代理到内网 Nexus 或 Artifactory，避免反复穿透公网
- 预加载基础镜像：在 Runner 启动时就 pull 好常用镜像（如
node:18-alpine），跳过构建时网络拉取环节 - 启用 GitLab CI 缓存：对
node_modules、.m2/repository等目录做 job 间复用，减少重复下载
可观测性补位：失败时留下可追溯线索
重试不是隐藏问题，而是争取恢复窗口。每次失败都应留下诊断依据：
- 记录重试前的错误摘要：HTTP 状态码、curl 耗时、exit code
- 自动归档失败时的日志、截图、视频（如 E2E 测试），上传至对象存储，避免被下次重试覆盖
- 在 pipeline 日志中标记重试次数，例如
[RETRY #2] npm test failed with exit code 1 - 对频繁触发重试的作业设置告警，提示可能是第三方服务持续异常，而非偶发抖动
