答案是dns解析失败、tls握手卡住或mtu不匹配导致连接超时，需先用ping/dig验证域名解析，再通过curl --resolve直连或hosts绑定绕过dns，最后按需调整http.timeout等参数。

Composer 报 Connection timed out 或 Could not resolve host，90% 不是配置写错了，而是 DNS 解析失败、TLS 握手卡住，或本地链路 MTU 不匹配——换镜像源只是补救，必须先让域名能解析、TCP 能建连，再谈超时调参。

看到 “Could not resolve host” 就停住？先查 DNS，别碰 composer config

这行错误和 composer.json 或全局镜像配置完全无关。Composer 连 mirrors.aliyun.com 的 IP 都没拿到，后续所有参数（http.timeout、process-timeout）全不生效。

• 运行 ping mirrors.aliyun.com：返回 unknown host → 确认 DNS 失效，立刻改系统 DNS（Linux/macOS 改 /etc/resolv.conf 加 nameserver 8.8.8.8；Windows 在网络适配器里手动设）
• 用 dig mirrors.aliyun.com @114.114.114.114 +short 验证是否真能解析出 IP；若能但本地默认 DNS 不行，说明被污染
• 临时绕过 DNS 测试镜像服务本身：用 curl --resolve 直连（例如 curl -I --resolve mirrors.aliyun.com:443:223.5.5.5 https://mirrors.aliyun.com/composer/packages.json），秒回 200 → 纯 DNS 问题
• hosts 绑定是最稳的应急方案：223.5.5.5 mirrors.aliyun.com 写入 /etc/hosts（macOS/Linux）或 C:\Windows\System32\drivers\etc\hosts（Windows），再执行 sudo dscacheutil -flushcache 或 ipconfig /flushdns

卡在 “Downloading https://…”？只调 http.timeout，别碰 process-timeout

这一阶段已进入 HTTP 层，http.timeout 控制单次请求从 DNS 查询、TCP 连接、TLS 握手到响应头返回的总耗时（单位秒）。默认 60 秒对国内镜像明显不够，而 process-timeout 此时完全不参与。

Discussion Composer

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

下载

• 全局生效：composer config -g http.timeout 600
• 项目级更可靠（尤其 CI）："config": { "http": { "timeout": 600 } } 写进 composer.json
• 临时覆盖优先级最高：COMPOSER_HTTP_TIMEOUT=600 composer install
• 别信 default_socket_timeout：Composer 自 1.10+ 已绕过 PHP 原生 socket 设置，改它无效；但 php -d default_socket_timeout=600 $(which composer) install 可作为兜底手段
• 同步设 http.connect-timeout 和 http.max-retries（Composer 2.2+）：composer config -g http.connect-timeout 60、composer config -g http.max-retries 3

换镜像后还是超时？检查 URL 格式、缓存、配置优先级

镜像不是设了就生效。常见失效原因：URL 少斜杠、键名过时、项目级硬覆盖、缓存未清。

• 阿里云镜像正确地址是 https://mirrors.aliyun.com/composer/（末尾 / 必须有），清华镜像同理；少一个会 404
• Composer 2.2+ 必须用 repos.packagist.org 键名，旧写法 repo.packagist 会被静默忽略
• 执行 composer clear-cache：旧缓存里的错误地址可能还在内存中
• 检查是否被项目级配置覆盖：composer config repo.packagist（不加 -g）看输出；若有，删掉 composer.json 里的 repositories 字段
• 验证镜像是否真生效：curl -I https://mirrors.aliyun.com/composer/packages.json 应秒回 200 OK；再跑 composer show -p | head -5 看包列表是否正常加载

curl -v 卡在 * Connected to… 之后？可能是 MTU 导致的链路层丢包

现象是 curl -v https://mirrors.aliyun.com/composer/packages.json 停在 * Connected to mirrors.aliyun.com (123.56.123.45) port 443 (#0) 后无响应，ping -s 1472 通但 ping -s 1473 超时 → 运营商或中间防火墙限制了大于 1400 字节的 IP 包。

• 验证：ping -s 1400 -M do mirrors.aliyun.com 若报 Packet too big，确认 MTU 问题
• 临时修复（Linux/macOS）：sudo ifconfig eth0 mtu 1400（替换 eth0 为实际网卡名）
• Windows 管理员 CMD：netsh interface ipv4 set subinterface "以太网" mtu=1400 store=persistent
• MTU 设 1400 是兼顾兼容性与性能的常用值，别低于 1280
• MTU 调低后仍报 cURL error 28，说明 TLS 握手或首字节响应慢，此时才需要同步调高 http.timeout 到 600

真正卡住的地方往往不在 Composer 配置里，而在 DNS 解析、TLS 握手、MTU 分片这些底层环节。调参前先用 curl -v 和 ping -M do 定位到具体哪一层断开，比盲目加大 timeout 更省时间。