composer 本身不监听端口，报错中的端口问题实为代理配置或端口冲突所致；需用 curl -x 模拟验证代理连通性，确保 https-proxy 配置为 http://127.0.0.1:端口 且 http-proxy 与 https-proxy 同时存在。
Composer 本身不监听端口，所谓“代理端口占用导致失败”是误判——真正冲突的是你本地代理服务（如 Clash、Proxyman、cntlm）监听的端口被其他进程占了，或 Composer 的 https-proxy 配置错误触发了代理链异常。
为什么 composer install 报错却显示端口相关错误？
常见现象包括：cURL error 7、Connection refused、长时间卡在 Loading composer repositories，甚至某些代理网关返回 502 Bad Gateway。这些都不是 Composer 在 bind() 端口，而是它尝试连接你配置的代理地址（比如 http://127.0.0.1:7890）时失败了。
- 代理进程根本没启动 → 连接被拒绝（
Connection refused） - 代理进程已启动，但端口被另一个程序（如另一实例 Clash、IDE 内置代理、浏览器扩展）占用了 → 同样报
Connection refused - 代理虽运行，但配置了 HTTPS 监听却让 Composer 用
https://填https-proxy→ 配置非法，静默失效，Composer fallback 直连 → 超时或卡住 - 代理自身上游不稳定（如企业 WAF 拦截、TLS 终止失败）→ 返回非标准响应 → 触发
502 Bad Gateway
怎么确认是代理端口被占，而不是网络或权限问题？
别猜，直接复现链路。Composer 底层用 cURL 发请求，所以用 curl -x 模拟最准：
- 查当前配置：
composer config -g --list | grep -E "(http|https)-proxy"，确认两行都存在且格式为http://host:port - 手动测试代理连通性：
curl -x http://127.0.0.1:7890 -I https://packagist.org/packages.json（把端口号换成你配置的实际值） - 如果这步就报
Connection refused，说明127.0.0.1:7890确实没服务在监听 —— 此时要查该端口是否被占，或代理是否未启动 - 如果返回
502或空响应，说明代理进程在，但转发异常 —— 问题在代理自身配置或上游
空闲端口更换：从定位到生效的完整操作
假设你发现 7890 被占，想换到 7891：
- 先确认新端口空闲：
lsof -i :7891（macOS/Linux）或netstat -ano | findstr :7891（Windows），无输出即为空闲 - 改代理配置：启动你的代理软件，把它监听端口从
7890改成7891（具体位置依工具而定，Clash 在config.yaml的mixed-port或socks-port+http-port） - 重启代理进程，确保它真正在
7891上监听 - 更新 Composer 配置：
composer config -g https-proxy http://127.0.0.1:7891（注意必须是http://开头） - 再跑一次
curl -x http://127.0.0.1:7891 -I https://packagist.org/packages.json验证通路
只有这一步成功了，composer install 才可能成功。跳过验证直接试 Composer，容易把代理层问题误判成源站或网络问题。
最容易被忽略的点：代理端口和 Composer 配置必须严格匹配，且仅限 http:// 协议头
很多人改了代理监听端口，却忘了同步改 Composer 的 https-proxy 值；或者填了 https://127.0.0.1:7891，以为“更安全”，结果 Composer 完全不认——它只接受 http:// 开头的 https-proxy 字符串，这是硬编码逻辑，不是文档疏漏。另外，http-proxy 和 https-proxy 必须同时存在，否则 HTTPS 流量会静默走直连，你根本收不到明确报错，只会无限等待。
