Composer只配http-proxy不配https-proxy必然失败，因其所有包操作均走HTTPS，而http-proxy仅处理HTTP请求，HTTPS请求会直连超时或被拒；https-proxy必须以http://开头且需URL编码特殊字符。
只配 http-proxy 而不配 https-proxy，Composer 的 HTTPS 请求就必然失败——这不是“可能失效”，是协议层直接绕过代理。
为什么 http-proxy 配了也没用
Composer 对 HTTP 和 HTTPS 请求走完全独立的代理通道：http-proxy 只用于纯 HTTP 请求（极少），所有包元数据、下载、GitHub 访问等均走 HTTPS，必须由 https-proxy 承载。漏掉它，请求会 fallback 到直连，而国内多数环境直连 packagist.org 就是 Connection refused 或超时。
-
https-proxy的值必须是http://协议开头（哪怕代理本身监听 TLS 端口），填https://或无协议会静默失效 - 密码含
@、/、:必须 URL 编码，例如pa@ss/word→pa%40ss%2Fword - Windows 下若提示 “Could not write to file”，检查
%APPDATA%\Composer\config.json是否存在且当前用户有写权限
composer config -g --list 显示代理但依然不生效
输出有值 ≠ 实际生效。常见干扰项：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 没加
-g：只改了当前项目composer.json，换目录即失效 - NTLM 代理未中转：公司域环境常用 NTLM 认证，Composer 原生不支持；必须用
cntlm或px在本地起一个http://127.0.0.1:3128的中转代理，再把https-proxy指向它 - 代理进程未运行或端口被防火墙拦截：执行
curl -x http://127.0.0.1:3128 -I https://packagist.org/packages.json验证中转层是否通
企业 HTTPS 解密代理（Zscaler/SonicWall）导致 JSON 解析失败
这类代理会劫持 HTTPS 请求，返回 HTML 登录页或人机验证，但 Composer 不校验 Content-Type，直接尝试解析 HTML 为 JSON，然后静默放弃该源、退回到旧缓存甚至官方源——表现为“包找不到”“版本缺失”，而非明显报错。
- 用
curl -I -v https://mirrors.aliyun.com/composer/packages.json查响应头：必须含HTTP/2 200和Content-Type: application/json - 若返回
text/html或跳转到登录页，说明代理在中间篡改；加--noproxy "*"后能正常返回 JSON，则确认是代理根因 - Composer 不读系统
NO_PROXY环境变量，必须显式清空：composer config -g http-proxy ""和composer config -g https-proxy ""
CI/宝塔等多用户环境下的权限错位
你用 root 配的全局代理，但实际运行的是 www 或 git 用户，配置根本没加载。
- 查当前生效用户：
whoami或ps aux | grep composer - 用对应用户重配：
sudo -u www composer config -g https-proxy http://127.0.0.1:8080 - 别信
composer diagnose：它只测packagist.org，和你配的镜像/代理无关；真实依据是composer install -vvv 2>&1 | grep Downloading输出的 URL
最容易被忽略的是：代理配置成功后，Composer 仍可能因 DNS 污染把请求发往错误 IP，或因缓存路径按被劫持后的 URL 存储（比如 https---internal-proxy-company-com-mirrors-aliyun-com-composer），删错缓存目录白忙活。先确认 Downloading 日志里的地址，再决定清哪条缓存。
