https-proxy必须以http://开头，否则静默失效；正确格式为http://127.0.0.1:7890（无尾斜杠），填https://或省略协议头均导致HTTPS请求直连，引发卡在Loading composer repositories或cURL error 28。
https-proxy 必须用 http:// 开头，否则静默失效
Composer 对 HTTPS 请求走独立代理路径，https-proxy 字段值协议头强制要求是 http://，哪怕你本地代理监听的是 HTTPS 端口。填 https://127.0.0.1:7890 或 127.0.0.1:7890 都不会报错，但实际请求会 fallback 到直连，结果就是卡在 Loading composer repositories 或反复报 cURL error 28。
正确写法只有这一种形式：http://127.0.0.1:7890（无尾部斜杠）；带认证时也必须保持协议头为 http://，例如：http://user:pa%40ss%2Fword@127.0.0.1:8080。
验证是否生效：运行 composer config -g --list | grep -E "(http|https)-proxy"，确认两行都存在、格式合规、且没有多余空格或换行符。
端口不通的典型表现与快速验证方式
代理进程没启动、防火墙拦截、端口被占、或代理服务监听了错误网卡（如只监听 127.0.0.1 却被配置成 localhost），都会导致连接失败。现象通常是 Connection refused 或超时，但 Composer 不会明确告诉你“端口连不上”，只会卡住或报模糊错误。
绕过 Composer 直接验证代理链：
- 用
curl -x http://127.0.0.1:7890 -I https://packagist.org/packages.json测试——返回200 OK表明代理通；返回502 Bad Gateway说明代理自身转发异常；返回Connection refused就是端口根本没监听 - 检查代理进程是否运行：
lsof -i :7890（macOS/Linux）或netstat -ano | findstr :7890（Windows） - 确认代理服务监听的是
0.0.0.0或127.0.0.1，而非192.168.x.x这类局域网地址
代理地址末尾带斜杠会导致解析失败
http://127.0.0.1:7890/ 这种写法看似合理，但 Composer 内部 URL 解析器会把末尾斜杠当作路径一部分，后续拼接 /packages.json 时变成 http://127.0.0.1:7890//packages.json，触发 400 或 404，且无明确提示。
必须严格使用无尾斜杠格式：http://127.0.0.1:7890。配置后建议直接编辑 ~/.composer/config.json 文件，手动删掉 http-proxy 和 https-proxy 值末尾的 /，避免 shell 变量或脚本自动补全引入。
临时测试可绕过配置文件：HTTP_PROXY=http://127.0.0.1:7890 HTTPS_PROXY=http://127.0.0.1:7890 composer global status —— 成功则说明地址+端口本身没问题，问题出在配置持久化环节。
NTLM 代理或企业 WAF 下的特殊处理
如果你在 Windows 域环境，或公司出口有 WAF，直接设 http-proxy 会收到 407 Proxy Authentication Required，因为 Composer 原生不支持 NTLM 认证。
必须引入中转代理：
- Windows 推荐
cntlm或px，监听127.0.0.1:3128并处理 NTLM，再让 Composer 指向它：http://127.0.0.1:3128 - 验证中转层是否工作：
curl -x http://127.0.0.1:3128 -I https://packagist.org/packages.json，若仍返回407，说明cntlm配置未生效或凭据错误 - 某些 WAF 会伪造 502 页面，此时
curl返回的 HTML 内容里可能含 “Firewall” 或 “Access Denied”，而非标准 HTTP 响应头——这是最隐蔽的失败信号
真正难排查的不是配置有没有写对，而是哪一层在静默吞掉错误：代理进程、中转工具、WAF、DNS、甚至 PHP 的 default_socket_timeout。每次改完一个点，都得用真实网络请求验证，而不是只看 config -g 输出。
