composer diagnose不检测MTU或链路层参数，仅在应用层发起一次HTTP请求验证仓库连通性，默认只测https://packagist.org，不探测ICMP、TCP MSS或执行Path MTU Discovery。
composer diagnose 不测 MTU，也不碰路径层参数
它完全不涉及网络链路层（如 MTU、ICMP、TCP MSS）的探测或优化。所谓“检测 GitHub 服务器到本地链路”，composer diagnose 压根不会发起 ICMP ping、traceroute 或 TCP Path MTU Discovery 请求——它只在应用层发一次 HEAD 或 GET /packages.json 到配置的仓库地址（默认是 https://packagist.org，不是 GitHub），且仅关注 HTTP 状态码和基础 TLS 连通性。
为什么你看到 GitHub 相关报错却误以为是 MTU 问题
常见现象是 composer diagnose 输出类似 GitHub API limit is low 或卡在 Loading composer repositories 后突然中断，接着 -vvv 日志里出现 cURL error 56: Failure when receiving data from the peer。这看起来像底层丢包，但实际多由以下原因导致：
-
cURL error 56通常是 TLS 握手后数据流被意外截断，90% 情况下是中间代理/防火墙主动 RST，而非 MTU 分片失败 - GitHub API 调用走的是
https://api.github.com，而composer diagnose默认根本不访问该地址——除非你项目里显式配置了vcs类型仓库或启用了github-protocols选项 - 真要测 MTU 路径，得用
ping -M do -s 1472 github.com（Linux/macOS）或ping -f -l 1472 github.com（Windows），composer diagnose不提供等价命令
MTU 异常的真实信号与验证方式
如果你怀疑是 MTU 导致 Composer 卡住（比如下载 ZIP 时反复重传、curl -v 显示 Connection reset by peer 且仅发生在大响应体），请跳过 composer diagnose，直接做三件事：
- 运行
ping -c 4 -M do -s 1472 mirrors.aliyun.com：若失败，逐步减小-s值（1400 → 1300 → 1200），找到最大不丢包尺寸，再加 28 得到实际 MTU - 检查是否启用
IPv6：某些 ISP 的 IPv6 路径 MTU 更小，且curl默认优先走 IPv6；临时禁用：加--ipv4参数或设环境变量export CURL_SSLVERSION=TLSv1.2 - 确认镜像是否真走 GitHub：阿里云/腾讯云镜像本身不代理 GitHub raw 内容，
composer install拉dev-master分支时才可能直连 GitHub——此时应单独测curl -I https://api.github.com/rate_limit，而非依赖diagnose
Composer 层面唯一能缓解 MTU 问题的配置
没有“MTU 设置项”，但可通过降低传输粒度间接规避分片风险：
- 强制使用 HTTP/1.1（绕过 HTTP/2 多路复用对大帧的依赖）：
export COMPOSER_HTTP_VERSION=1.1 - 禁用压缩（减少响应体大小）：
export COMPOSER_NO_ZLIB=1 - 限制并发数防拥塞：
composer config -g parallel-downloads 1，避免多个 TCP 流同时触发路径 MTU 探测失败
真正需要调 MTU 的场景极少，多数所谓“MTU 问题”其实是 TLS 握手失败、代理静默丢包或 DNS 返回 IPv6 地址但本地链路不支持——这些 composer diagnose 都不查，也查不了。
