Composer本身不支持自动就近调度，必须依赖DNS层GSLB、镜像源显式配置及边缘缓存三者协同；仅改repo.packagist.org配置无效，因Composer仅发起HTTP请求，不感知地理位置、不触发智能解析、不动态切换节点。
Composer 本身不处理 DNS 就近调度，所谓“就近”必须靠外部 DNS 层（GSLB）配合镜像源配置才能生效；直接改 Composer 配置无效。
为什么 composer config -g repo.packagist.org 设置 CDN 域名 ≠ 真正就近
Composer 只是把 repo.packagist.org 配置项当普通 URL 发起 HTTP(S) 请求，它不会：
- 解析域名时触发智能 DNS（GSLB）调度
- 感知客户端地理位置或运营商归属
- 根据延迟动态替换 URL 或切换节点
常见错误现象：composer install 卡在 Downloading https://mirrors.aliyun.com/p2/...，但多地 dig mirrors.aliyun.com 返回相同 IP → 说明没走 GSLB，所有请求被 DNS 解析到同一个中心节点。
验证镜像是否真有地域分发能力
别只信文档，动手测三件事：
- 在不同地区（北京/广州/上海/海外）分别执行：
dig mirrors.aliyun.com，看返回 IP 是否不同 - 用
curl -w "%{time_total}s\n" -o /dev/null -s https://mirrors.aliyun.com/health测真实延迟 - 确认关键路径（如
/packages.json、/p2/）被 CDN 缓存且 TTL ≥ 60 秒，避免频繁回源
若 dig 结果全一样，或 curl 延迟无差异，那这个“镜像”只是单点托管，不是边缘分发。
必须同时满足的三个条件才可能就近
缺一不可：
- Composer 显式配置为镜像 CDN 域名：
composer config -g repo.packagist.org '{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}'（注意末尾/） - DNS 提供商开启 GSLB：阿里云、腾讯云、华为云等 CDN 控制台需勾选“智能解析”或“全局负载均衡”
- 边缘节点缓存策略合理：确保
Cache-Control: public, s-maxage=300类响应头存在，否则每次请求都穿透到源站
写错键名会静默失效：repos.packagist 是旧版（1.x）写法，Composer 2.2+ 只认 repo.packagist.org。
CI 环境中无法依赖 DNS GSLB 怎么办
CI 节点（如 GitHub Actions、GitLab Runner）通常固定出口 IP，GSLB 效果弱。此时应：
- 用测速脚本预选最快镜像：
for url in https://mirrors.tuna.tsinghua.edu.cn/composer/ https://mirrors.aliyun.com/composer/; do curl -s -w "%{http_code} %{time_total}\n" -o /dev/null $url; done - 将测得最低延迟的 URL 写入 CI 步骤：
composer config -g repo.packagist.org "$BEST_MIRROR" - 禁用 TLS 校验（仅限可信内网）：
composer config -g secure-http false，避免老旧 CA 导致握手失败
真正影响“就近”效果的从来不是 Composer 配置本身，而是你能否确认 DNS 解析行为、CDN 缓存状态和网络出口位置这三点。漏掉任一环，换再多镜像地址也没用。
