不能。自建镜像仅加速元数据（packages.json等）同步，不托管zip包，dist.url仍指向github等原始地址，国内直连仍超时；真正加速需代理或镜像zip文件本身，并用satis等工具重写dist.url指向内网http地址。
自建镜像真能解决下载慢问题吗
不能。自建镜像只加速 packages.json 和 provider 文件的同步，不托管 ZIP 包——dist.url 仍指向 GitHub、GitLab 等原始地址。国内机器直连这些地址依然超时或被重置，换源后 composer install 还是卡在 downloading zip。
验证方式很简单：composer show monolog/monolog --verbose，看输出里的 dist.url 字段，大概率还是 https://github.com/...。阿里云、腾讯云等公开镜像也一样，它们不存 ZIP，只缓存元数据。
- 真正要加速 ZIP 下载，得把 dist 文件也代理或镜像到局域网可直连的 HTTP 地址
- 这要求你部署 Web 服务（如 Nginx）暴露
/dist/路径，并确保每个 ZIP 都能被GET到 - 还要改写所有包的
dist.url，靠 Satis 或私有 Packagist 工具生成带新地址的packages.json
为什么 composer config -g repo.packagist 对自建无效
这条命令只替换元数据入口，不触碰 ZIP 下载逻辑。哪怕你把 repo.packagist 指向自己搭的 https://pkgs.internal/，Composer 仍会从原始 dist.url 下载 ZIP——它根本不读你的镜像服务器上的 ZIP 路径。
常见误区：以为改了 repo.packagist 就万事大吉。实际运行 composer install -vvv 会看到大量 GET https://github.com/xxx/yyy.zip 请求，和你配的镜像 URL 完全无关。
- 必须让 Satis 或类似工具在构建时重写
dist.urls，指向你自己的/dist/目录 -
satis.json中要显式配置"archive": {"directory": "dist", "format": "zip"} - Nginx 的
root必须精确匹配 Satis 输出目录，且需声明types { application/json json; }，否则返回text/plain导致 Composer 拒收
自建镜像的硬性成本和坑点
不是“搭个服务就行”，而是整套基础设施+持续维护。一个可用的私有镜像至少要撑住三类压力：元数据同步、ZIP 存储、HTTP 并发服务。
- 首次全量同步 Packagist（
require-all: true）可能拉取 40GB+ 数据，内存溢出、磁盘满、超时中断很常见 - ZIP 文件权限常被 SELinux 或文件系统锁死，
https://pkgs.internal/dist/xxx.zip返回 403 不是配置错，是chmod或chown没跑到位 - 镜像 URL 必须以
/结尾，少一个斜杠就拼成https://pkgs.internalpackages.json，404 不报错，只静默 fallback 到官方源 - CI/CD 流水线里若没统一配置用户级
~/.composer/config.json，Web 服务用www用户跑，而你终端用ubuntu用户，全局配置根本不起作用
什么情况下才值得自建
只有两个真实场景：企业内网完全无法访问外网，或对包内容有强审计/合规要求（比如禁止任何未签名的 GitHub ZIP 进入生产环境）。
除此之外，直接用阿里云镜像 + 本地代理（如 proxychains 或公司统一出口代理）更省事。95% 的“慢”其实来自 TLS 握手和 DNS 解析，不是带宽瓶颈。
别低估同步延迟——新发布的包在自建镜像里可能滞后数小时甚至一天，而阿里云镜像平均 5–10 分钟同步一次。你花两天搭完，发现刚发布的 Laravel 11 还装不上，就得手动补同步逻辑。
