必须同时配置http-proxy和https-proxy，且https-proxy值必须以http://开头；否则HTTPS请求静默直连，导致“Loading composer repositories”卡死或cURL error 28。
Composer 本身不监听或暴露任何端口，所谓“调整端口代理失败”是误解了代理机制——你不是在调 Composer 的端口，而是在配它走哪个代理地址和端口。失败根源几乎全是 https-proxy 配置错误或缺失。
为什么只设 http-proxy 一定连不上
Composer 对 HTTP 和 HTTPS 请求完全分离路由：所有包仓库（packagist.org、GitHub、GitLab）全走 HTTPS，必须经 https-proxy 字段发起 CONNECT 隧道；只配 http-proxy 会让 HTTPS 请求静默 fallback 到直连，结果就是卡在 Loading composer repositories 或反复报 cURL error 28，但不提示具体原因。
-
https-proxy的值协议头必须是http://，哪怕你的代理服务跑在 HTTPS 端口上——例如http://127.0.0.1:7890才合法，https://127.0.0.1:7890或127.0.0.1:7890都会静默失效 - 必须同时配置两个字段：
composer config -g http-proxy http://127.0.0.1:7890和composer config -g https-proxy http://127.0.0.1:7890 - 验证是否生效：
composer config -g --list | grep -E "(http|https)-proxy"，输出里必须有两行且格式合规
代理端口连通性怎么快速验证
别等 composer install 卡住再排查。用 curl 直接复现链路：
- 先确认代理服务本身可达：
telnet 127.0.0.1 7890或nc -zv 127.0.0.1 7890，失败说明代理没启动或端口不对 - 再测代理能否转发 HTTPS：
curl -x http://127.0.0.1:7890 -I https://packagist.org/packages.json - 如果返回
502 Bad Gateway，说明代理服务自身转发异常（比如把 CONNECT 请求错发给了 HTTP 上游）；如果卡住或超时，大概率是 TLS 握手失败或认证未通过
NTLM 代理（如公司域环境）怎么办
Composer 原生不支持 NTLM 认证，设了 http-proxy 也会直接返回 407 Proxy Authentication Required。不能靠改 Composer 配置解决，必须加一层中转代理：
- Windows 推荐用
cntlm或px，让它们监听127.0.0.1:3128并处理 NTLM 认证 - 然后把 Composer 的两个代理都指向它：
composer config -g http-proxy http://127.0.0.1:3128和composer config -g https-proxy http://127.0.0.1:3128 - 验证中转层：
curl -x http://127.0.0.1:3128 -I https://packagist.org/packages.json，若仍报 407，说明cntlm或px的域账号/密码/域名没配对
端口没问题但还是连不上？检查这些隐藏关卡
代理端口通了，不代表 Composer 就能连上——还有几个常被忽略的环节：
-
http.timeout默认只有 300 秒（5 分钟），弱网下极易触发超时；运行composer config -g http.timeout 600提高阈值 - PHP 的
default_socket_timeout若低于你设的http.timeout（常见默认值是 60），会提前掐断连接；查它：php -i | grep default_socket_timeout，必要时在php.ini中调高 - 某些代理（如 Clash）启用了 TLS 终止但证书不受信任，cURL 会拒绝继续，此时可能静默 fallback 到直连——用
composer install -vvv观察日志里是否出现SSL certificate problem
真正卡住的地方，往往不在代理端口本身，而在 CONNECT 隧道建立后那一小段 TLS 握手或上游响应处理。别只盯着 http-proxy 字段反复重试，先用 curl -x 把代理链每一环都敲实。
