CircleCI 国内流水线卡住？Git 触发、Runner、缓存与 Artifacts 排查
CircleCI 的网页控制台只是流水线观察入口。一次 Job 还涉及 GitHub 或 Bitbucket 触发、云端执行器或 Self-hosted Runner、容器镜像、依赖源、Cache、Workspace、Artifacts 和实时日志。国内打开项目页很慢，与云端 Runner 内部下载失败不是同一件事。
排查应先锁定 Workflow ID 和失败 Job，不要一上来就 Rerun workflow from start。只有明确知道是瞬时网络问题时才重试；配置错误、权限不足和资源类不匹配会稳定复现，重复运行只增加队列与费用。
控制台、云端执行器与自托管 Runner 分开看
CircleCI Cloud 的 Job 在平台执行环境中运行，Self-hosted Runner 则从自己的网络主动领取任务。浏览器、Runner 和构建访问的依赖源可能位于三个网络，因此必须用具体 Step 与时间点定位。
提交后没有 Workflow
检查 VCS App 授权、项目 Follow 状态、Webhook、目标分支与 config.yml 是否位于正确路径。
Job 一直 Queued
云端执行器需检查并发与资源可用性；Self-hosted Runner 需核对 Resource Class、在线状态和任务标签。
依赖步骤超时
在失败 Step 中识别 Docker Registry、npm、PyPI、Maven 或 Git 子模块，不要用网页加载速度判断 Runner 网络。
Artifacts 打不开
先确认 store_artifacts 已执行且路径正确，再判断浏览器下载连接、权限或保留期。
围绕 Workflow ID 留下可复现证据
- 1
确认触发与配置
记录 Commit SHA、Branch、Workflow 名称和 config.yml 版本，确认 Pipeline Parameters 与过滤条件。
- 2
定位等待位置
区分 Pipeline 未创建、Workflow 未进入、Job Queued 和具体 Step 挂起，四者的责任环节不同。
- 3
查看执行环境
记录 Executor、Docker Image、Resource Class 与 Runner 类型，自托管环境还要检查 Runner 服务日志。
- 4
检查 Cache 与 Workspace
Cache Key 未命中会变慢但不一定失败；Workspace 层持久化路径错误则会让下游 Job 缺文件。
- 5
保存产物和时间
下载测试报告、Artifacts 与失败日志，记录开始时间和 Exit Code，再进行一次有目的的重试。
SSH Rerun 不是长期修复
SSH 调试适合查看临时执行环境，但手工安装的依赖不会写回配置。找到差异后应修改 config.yml、镜像或脚本，保证普通 Job 可重复运行。
忍者云帮助观察 CircleCI，不改变 Runner 配置
忍者云可改善 CircleCI 控制台、实时日志、Artifacts 下载和 VCS 授权页面的跨境连接。若团队从国内维护 Self-hosted Runner，也可让管理员更稳定地查看任务与诊断资料。
线路不会增加并发额度、让离线 Runner 上线，也不能修复 config.yml、Docker 镜像、Cache Key、测试失败和 Secrets 权限。云端 Runner 的出口网络也不会因本地浏览器使用忍者云而改变。
可改善
控制台、VCS 授权、日志流、Artifacts 与诊断页面访问。
不能改变
云端执行器网络、并发、Resource Class、构建配置、测试和密钥权限。
Ninja Cloud
稳定查看 CircleCI Workflow 全链路
忍者云帮助连接控制台、日志和 Artifacts；Runner、资源类、缓存、配置与测试结果仍应在流水线中修复。
常见问题
CircleCI 页面很慢会导致云端 Job 失败吗？
通常不会。浏览器与云端执行器是不同连接，应以具体 Job Step 的日志和 Exit Code 判断。
CircleCI Job 一直 Queued 怎么办？
先检查并发和资源类；若使用 Self-hosted Runner，再核对 Runner 是否在线、Resource Class 是否完全匹配。
Cache miss 是构建失败吗？
不一定。Cache miss 通常只会重新下载或编译；如果后续失败，应检查依赖源、脚本和 Workspace 文件。
忍者云能改善 CircleCI 云端 Runner 下载速度吗？
不能。本地线路只影响你的访问；云端 Runner 的网络由 CircleCI 执行环境决定。