Composer中文镜像下载速度慢的DNS优化方案（网络调优）-composer-PHP中文网

根本原因是本地dns解析污染或tls握手失败，而非镜像地址错误；需强制ipv4、指定可信dns或直连镜像ip（如115.238.219.192），并配置正确ca证书路径以解决php/curl底层网络问题。

composer中文镜像下载速度慢的dns优化方案（网络调优）

为什么换镜像后 still 卡在 DNS 或 TLS 阶段

不是镜像地址错了，而是本地 DNS 解析或 TLS 握手卡住——composer install 日志里出现 Resolving dependencies 之后长时间停在 Downloading https://mirrors.aliyun.com/composer/...，但 curl 直接测又秒回，说明问题出在 PHP/curl 层的底层网络行为。

常见错误现象：日志里反复出现 file_get_contents(): SSL operation failed、Connection timed out after 300000 milliseconds，或卡在 Resolving 后无响应；curl -I https://mirrors.aliyun.com/composer/packages.json 正常，但 composer install -vvv 仍走超时。

PHP 默认用系统 DNS（如 systemd-resolved 或 /etc/resolv.conf），国内某些 ISP 的 DNS 会污染或缓存错误的 AAAA 记录，导致 Composer 强制 fallback 到 IPv6 再超时
cURL 在 PHP 中默认启用 IPv6 fallback，但多数镜像站不支持 IPv6，来回试连浪费 3–5 秒/请求
OpenSSL 版本过旧（如 OpenSSL 1.0.2）在 TLS 1.3 握手时可能卡住，尤其阿里云镜像已默认启 TLS 1.3
Composer 不读系统 proxy 设置，http-proxy 配置漏掉端口或协议（如写成 http://proxy:8080 却没设 https-proxy）会导致 HTTPS 请求失败

强制 IPv4 + 指定可信 DNS 是最稳解法

别依赖系统 DNS，让 Composer 绕过解析阶段直接发请求。核心是让 cURL 层跳过 DNS 查询，用 IP 直连镜像站。

阿里云镜像当前稳定 IP（2026年7月实测）：115.238.219.192（杭州节点），腾讯云：119.28.228.217（广州节点）。验证方式：dig mirrors.aliyun.com +short 或 nslookup mirrors.aliyun.com。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

临时测试：加 -d opcache.enable=0 和 -d disable_functions= 避免 OPcache 干扰，再运行 php -d curl.cainfo=/etc/ssl/certs/ca-certificates.crt -d openssl.cafile=/etc/ssl/certs/ca-certificates.crt -r "echo file_get_contents('https://115.238.219.192/composer/packages.json') ?: 'fail';"
全局生效：编辑 ~/.composer/config.json，把 "url": "https://mirrors.aliyun.com/composer/" 改成 "url": "https://115.238.219.192/composer/"（保留末尾 /）
若用项目级配置（composer config repo.packagist ...），改完立刻删 composer.lock，否则旧 lock 仍含 packagist.org 域名引用
不推荐改 /etc/hosts —— 容器环境、CI runner 用户权限不同，www-data 用户读不到 root 的 hosts

curl 和 OpenSSL 层必须检查的三项

Composer 底层调 cURL，cURL 依赖 OpenSSL，这两层任一出问题，镜像再快也白搭。

查 OpenSSL 版本：php -r "print_r(openssl_get_cert_locations());"，确认 default_cert_file 路径存在且可读；若为 /dev/null 或路径不存在，补 openssl.cafile 配置
禁用 IPv6（最有效）：composer config -g http.ssl.cainfo /etc/ssl/certs/ca-certificates.crt，再加 export COMPOSER_HTTP_SSL_CAINFO=/etc/ssl/certs/ca-certificates.crt 环境变量
验证 cURL 是否支持 HTTP/2：php -r "var_dump(curl_version(CURLVERSION_NOW)['features'] & CURL_VERSION_HTTP2);"，返回 int(1) 表示支持；不支持则降级到 HTTP/1.1，加 composer config -g http.http-version 1.1
Windows 用户注意：set http_proxy=http://127.0.0.1:8888 只对 cmd 生效，PowerShell 要用 $env:http_proxy="http://127.0.0.1:8888"，且必须同时设 https_proxy

CI/CD 中 DNS 问题最容易被忽略的点

本地调通 ≠ CI 能跑通。Runner 环境通常 DNS 更不可控，且默认不加载用户 profile。

GitLab CI 必须显式写 before_script: 块，加 export COMPOSER_HOME=$CI_PROJECT_DIR/.composer，否则 config -g 写进的是 runner 用户家目录，job 容器里根本读不到
Docker 构建时，--network host 或 --dns 114.114.114.114 才能绕过容器内网 DNS 缓存；Alpine 镜像要额外 apk add ca-certificates
GitHub Actions 的 ubuntu-latest 默认用 systemd-resolved，但 Composer 不识别它，必须在 steps 里先运行 sudo sed -i 's/#DNS=/DNS=114.114.114.114/' /etc/systemd/resolved.conf && sudo systemctl restart systemd-resolved
别信 composer global require hirak/prestissimo —— 它在 Composer 2.2+ 已彻底失效，反而会让并发退化为单线程

真正起作用的永远是那三行：composer config -g repo.packagist composer https://115.238.219.192/composer/、composer clear-cache、export COMPOSER_HTTP_SSL_CAINFO=/etc/ssl/certs/ca-certificates.crt。其他都是干扰项。