代理频繁断开主因是Composer并发下载与代理连接管理不匹配，需禁用并行（composer config -g parallel false）、启用keep-alive（composer config -g http.keepalive true）、指定HTTP/1.1版本，并确保仅用composer config配置代理、避免环境变量冲突。
代理频繁断开不是 Composer 配置问题，而是底层 HTTP 连接管理与代理服务稳定性不匹配——必须同时调优 Composer 的连接复用策略、禁用并行下载，并确认代理本身支持长连接和 HTTP/1.1 keep-alive。
为什么 composer install 用代理时反复断连
Composer 默认启用并发下载（parallel），每个包单独发起 HTTP 请求；若代理服务不支持多路复用或连接池过小，就会出现大量 Connection refused、curl: (7) Failed to connect 或静默卡在某个包。这不是超时设置能解决的，而是连接被代理主动关闭或拒绝复用。
- 现象包括：同一包反复重试、
composer install --verbose显示多个GET https://...请求在不同时间点失败 - 常见于本地 SOCKS5 代理（如 Clash、Proxyman）、企业中间人 HTTPS 代理、或未开启 keep-alive 的 HTTP 代理
-
http.timeout和process-timeout调高后仍无效，说明问题出在连接建立阶段，而非响应等待
禁用并行下载 + 强制 HTTP/1.1 keep-alive
让 Composer 放弃“并发抢连”，改用串行+复用单连接，大幅降低代理压力：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 全局禁用并行：
composer config -g parallel false - 启用连接复用：
composer config -g http.keepalive true - 如果代理只支持 HTTP/1.1（多数 SOCKS5 代理不支持 HTTP/2），加这一条更稳：
composer config -g http.version 1.1 - 临时验证可用：
COMPOSER_HTTP_KEEPALIVE=1 COMPOSER_PARALLEL=false composer install
代理配置必须显式指定协议和端口，且避免环境变量冲突
Composer 会优先读取 http-proxy 配置项，但若系统级环境变量（HTTP_PROXY）也存在，可能触发双重代理或协议不一致：
- 只用 Composer 自身配置：
composer config -g http-proxy http://127.0.0.1:7890（HTTP 代理）或composer config -g https-proxy https://127.0.0.1:7890（HTTPS 代理） - 不要混用：
export HTTP_PROXY=http://127.0.0.1:7890与composer config同时存在时，行为不可控 - 代理地址末尾不加斜杠，协议必须明确写
http://或https://，否则静默 fallback 到直连 - 验证是否生效：
composer config -g http-proxy应输出完整 URL，空值或null表示未设成功
绕过代理失败的终极方案：离线模式 + 手动补包
当代理持续不稳定，又不能换源（比如项目强依赖私有 VCS 包），可跳过网络阶段，靠缓存和手动干预完成安装：
- 先清缓存防污染：
composer clear-cache - 进离线模式安装：
COMPOSER_DISABLE_NETWORK=1 composer install --no-autoloader - 从
composer.lock中提取失败包的dist.url，用wget -c或浏览器下载到本地 - 手动放进缓存目录：
~/.composer/cache/files/vendor/name/hash.zip（路径按 lock 文件中dist.shasum和name推导） - 再跑一次
composer install --no-scripts，Composer 会跳过网络直接解压缓存包
真正难处理的不是“连不上”，而是“连上了又断”——这时候别硬调超时，重点看连接复用是否打开、代理是否扛得住并发、以及有没有环境变量在暗中干扰。手动补包虽麻烦，但在 CI 或关键发布环节，比反复重试更可控。
