CMake ExternalProject 下载的代理设置
在假定一次成功的 CMake 配置就能证明后续依赖下载走同一条链路之前，先定位 ExternalProject 背后的进程和下载步骤。
CMake 配置成功。构建稍后才开始，尝试下载外部依赖，并在代理处失败。先前的成功未必真正执行过那次下载。
ExternalProject_Add() 创建的步骤可能在构建期间运行。启动这些步骤的进程，其环境可能与配置主项目的终端或 IDE 不同。在 CI 中，配置与编译可能是不同的作业，这种差异很容易被忽略。
定位网络操作
- URL 下载使用 CMake 的下载路径。
- Git 源会调用自带受支持配置的 Git 传输。
- 自定义
DOWNLOAD_COMMAND使用项目指定的任意程序。
不要假定一个程序的代理设置会配置全部三者。在更改依赖 URL 之前，先阅读失败步骤的命令和错误。
如果所选的下载器支持代理环境变量，就把它们提供给真正执行该步骤的进程。对于客户端接受 HTTP 代理的公开下载，在允许该链路时，HTTP 代理列表可提供端点候选。传入同名的普通 CMake 缓存变量，并不自动等同于设置子进程的环境变量。
也要与 FetchContent 区分开：它通常的依赖填充发生在配置期间，因此在那里可用的做法并不能证明 ExternalProject 构建步骤的环境。
旧答案建议用自定义下载器绕过历史上的重定向限制，这并不能证明每个现代故障都需要新的下载命令。先确认当前错误是重定向、代理认证、证书信任，还是单纯的不可达。在修复相应链路的同时，保留预期的归档哈希和 TLS 校验。