阿里云ecs用户应使用内网地址http://mirrors.cloud.aliyuncs.com/composer/，http协议免tls握手、低延迟（20–50ms）、零公网带宽消耗；需全局配置且末尾带/，并清缓存验证生效。
直接换 ECS 内网镜像地址，比公网 HTTPS 镜像快 3–5 倍，且不走公网带宽；关键不是“加个镜像”，而是用对协议、路径和用户权限。
阿里云/腾讯云 ECS 必须用内网地址
公网镜像（如 https://mirrors.aliyun.com/composer/）在 ECS 上会绕行公网，多出 DNS 解析、TLS 握手、NAT 转发三重延迟，实测首字节时间常超 800ms。内网镜像直连后端存储，延迟压到 20–50ms。
- 阿里云 ECS 推荐：
http://mirrors.cloud.aliyuncs.com/composer/（注意是http，非https，ECS 内网不校验证书） - 腾讯云 ECS 推荐：
http://mirrors.tencentyun.com/composer/ - 华为云 CCE 节点可用：
http://repo.huaweicloud.com/composer/ - 命令必须带
-g和末尾/：composer config -g repo.packagist composer http://mirrors.cloud.aliyuncs.com/composer/
为什么 http 在 ECS 内网反而更稳
Composer 2.0+ 默认拦截 HTTP 源，但在 ECS 内网场景下，http 是有意为之的优化：跳过 TLS 握手开销，避免证书链校验失败（内网无 CA 信任链），同时规避 IPv6 fallback 导致的 30 秒等待。
- 若强制用 HTTPS 内网地址（如
https://mirrors.cloud.aliyuncs.com/composer/），多数 ECS 实例会因证书不可信而静默重试 3 次后 fallback 到官方源 -
http地址必须配在repo.packagist字段，不能塞进repositories数组里——后者不控制元数据请求路径 - 验证是否生效：
composer config -g repo.packagist输出应含"url": "http://mirrors.cloud.aliyuncs.com/composer/"
CI/CD 或 systemd 服务中镜像不生效？查执行用户
全局配置写在 ~/.composer/config.json，但 CI 脚本、systemd 服务、宝塔部署通常以 www、git 或自定义用户运行，它们读的是各自家目录下的配置文件，跟你的终端用户完全隔离。
- 在 Jenkins 或 GitHub Actions 中，别依赖
composer config -g，改用临时参数：composer install --repository=http://mirrors.cloud.aliyuncs.com/composer/ - systemd 服务需显式指定用户：
User=www，并确保该用户已执行过sudo -u www composer config -g repo.packagist composer http://mirrors.cloud.aliyuncs.com/composer/ - 宝塔计划任务里，先切用户再操作：
sudo -u www bash -c "composer clear-cache && composer install"
并发下载调太高反而拖慢，10 是安全甜点值
http-max-concurrent-downloads 控制 dist 包并行请求数，设高了会触发内网 DNS 缓存竞争或临时文件冲突，尤其在低配 CI 容器里容易报 file_put_contents(/tmp/): failed to open stream。
- 推荐值：
composer config -g http-max-concurrent-downloads 10 - 不要设 15+：阿里云内网镜像虽支持 HTTP/2，但后端存储有连接池限制，超 12 并发易触发 503
- 旧版配置项
parallel-downloads已废弃，设了也不生效，别浪费时间调试 - 验证是否启用：
composer install -vvv日志中应出现类似Downloading https://... (10 concurrent)
真正卡住的从来不是带宽，而是请求没发到内网地址、并发数撞上后端限流、或者根本没清旧缓存——这三处错一个，内网镜像就等于白配。
