解决Composer镜像更新时由于网络MTU限制导致的连接超时-composer-PHP中文网

卡在resolving dependencies且curl -v卡在tcp connect阶段，说明问题出在链路层mtu不匹配导致ip分片失败、syn包被静默丢弃；需通过ping -m do验证并调低mtu至1400，再配合http.timeout=600及default_socket_timeout同步调整方可解决。

解决composer镜像更新时由于网络mtu限制导致的连接超时

卡在Resolving dependencies且curl -v卡在TCP connect阶段

这说明问题出在链路层，不是DNS也不是HTTP超时，而是MTU不匹配导致IP分片失败、SYN包被静默丢弃。现象是curl -v https://mirrors.aliyun.com/composer/packages.json停在* Connected to mirrors.aliyun.com (123.56.123.45) port 443 (#0)之后无响应，ping -s 1472 mirrors.aliyun.com能通但ping -s 1473超时。

根本原因是运营商或中间防火墙对大于1400字节的IP包做了限制，而默认MTU（1500）+ TCP/IP头部（40字节）= 1540 > 1400，触发分片后被丢弃。

临时验证：运行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到1280以下——会影响其他服务，1400是兼顾兼容性与性能的常用值

Composer update仍报cURL error 28，但curl -v已通

说明底层cURL已能建连，但TLS握手或首字节响应慢触发了http.timeout。此时MTU已调低，但Composer默认60秒太短，尤其镜像节点TLS握手延迟高时。

Discussion Composer

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

下载

必须设http.timeout而非process-timeout：composer config -g http.timeout 600
注意：该值单位是秒，不是毫秒；Composer v2.9.6起生效，旧版需升级
PHP CLI的default_socket_timeout会覆盖此设置，检查php -i | grep default_socket_timeout，若为60则需同步调高：php -d default_socket_timeout=600 $(which composer) update
避免设为0——无限等待会掩盖真实链路故障，600是实测国内弱网下的安全上限

换镜像源后仍卡在Downloading某一个包

MTU问题常表现为“部分包可下、部分包卡死”，因为不同CDN节点路由路径不同，有的经过受限链路，有的走直连。这不是镜像源本身问题，而是你本地到特定边缘节点的路径MTU不一致。

先确认是否单点故障：运行curl -v https://mirrors.aliyun.com/composer/p2/laravel/framework.json（替换为报错包的实际路径）
若同样卡在TCP connect，说明该镜像节点所在线路MTU更低，尝试切中科大源：composer config -g repo.packagist composer https://mirrors.ustc.edu.cn/composer/
中科大镜像使用IPv6优先，对MTU敏感度更低；如需强制IPv4，加环境变量：COMPOSER_IPV4=1 composer update
别依赖--prefer-dist绕过——它只影响下载方式，不改变TCP建连行为

CI/CD中MTU问题更隐蔽

Docker容器、GitHub Actions runner或Kubernetes Pod默认继承宿主机MTU，但云厂商网络栈常做透明分片，导致本地调试正常、CI里却超时。错误日志往往只显示cURL error 28，看不出链路层问题。

GitHub Actions中加诊断步骤：

run: |
  ip link show eth0 | grep mtu
  ping -c 2 -s 1400 -M do mirrors.aliyun.com

Docker构建时显式指定MTU：docker run --mtu=1400 -it php:8.3-cli composer update
K8s中通过pod.spec.networkOptions或CNI插件配置，但更推荐在entrypoint里动态检测并调整：ip link set dev eth0 mtu 1400 || true
最稳妥的做法：CI脚本开头统一执行composer config -g http.timeout 600 + COMPOSER_IPV4=1，双保险

MTU问题最难缠的地方在于它不报错、不重试、不提示——连接就是“慢得奇怪”，而且只影响特定包、特定时刻、特定网络路径。调http.timeout只是兜底，真正要根治，得从ping -M do开始一层层往下压。