必须同时配置 http-proxy 和 https-proxy，因 Composer 的 Packagist 请求走 HTTPS，仅配 http-proxy 无效；https-proxy 值仍用 http:// 协议，且需 URL 编码特殊字符，优先检查环境变量冲突与代理是否支持 CONNECT 隧道。
Composer 在企业内网里连不上 packagist.org，不是它慢，是根本没发出去——网关拦截了 HTTPS 请求，必须用 HTTP 代理透传，且 http-proxy 和 https-proxy 必须同时配对，缺一不可。
为什么只配 http-proxy 会静默失败
Composer 对 Packagist 的元数据请求（如 https://packagist.org/packages.json）走的是 HTTPS 协议，而 http-proxy 配置只影响 HTTP 流量；https-proxy 才真正接管这些 HTTPS 请求。漏掉它，Composer 就会直连外网，被网关丢包或超时，现象就是卡在 “Loading composer repositories”，日志里却看不到明确错误。
-
https-proxy的值仍必须写成http://127.0.0.1:8080，不是https://——填错协议头会静默忽略 - 验证是否生效：运行
composer config -g --list | grep -E "(http|https)-proxy"，必须看到两行输出 - 某些旧版文档提到的
proxy（无 s）字段已弃用，以http-proxy和https-proxy为准
curl -x 能通，但 Composer 还是卡住？检查这三处
手动用 curl -x http://127.0.0.1:8080 https://packagist.org/packages.json 成功，只说明代理进程和基础链路 OK，不代表 Composer 就能用。真正卡点常在：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 代理地址里含
@、:、/等字符但未 URL 编码，例如密码pa@ss/word必须先执行php -r "echo rawurlencode('pa@ss/word');"得到pa%40ss%2Fword，再拼成http://user:pa%40ss%2Fword@127.0.0.1:8080 - 系统环境变量
HTTP_PROXY或HTTPS_PROXY与 Composer 配置冲突——Composer 优先读环境变量，若设了又没生效，先unset HTTP_PROXY HTTPS_PROXY再试 - 代理服务本身不支持 CONNECT 隧道（即无法中转 TLS 流量），此时
file_get_contents(): SSL operation failed是典型表现，换用纯 HTTP 代理地址（非 HTTPS）可绕过
遇到 407 Proxy Authentication Required 怎么办
这是 NTLM 认证代理（常见于 Windows 域控环境）返回的标准响应，Composer 原生不支持 NTLM，任何 http-proxy 配置都无效。
- 不能靠改 Composer 参数解决，必须加一层本地中转：用
cntlm或px启一个监听127.0.0.1:3128的普通 HTTP 代理，再让 Composer 连它 - 确认公司是否有免认证的 bypass 代理出口（比如
http://bypass-proxy.internal:8080），直接配这个更省事 - 临时测试可清空代理：
composer config -g http-proxy '' && composer config -g https-proxy ''，但别长期留空
镜像源和代理别混着用
如果公司已有私有镜像（如阿里云、腾讯云或 Artifactory 部署的内网镜像），就别配代理——直接切源更稳，也避免 TLS 不匹配、DNS 解析异常等衍生问题。
- 全局切换阿里镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 私有镜像示例：
composer config -g repo.packagist composer http://internal-mirror.yourcompany.com/composer（注意必须是repo.packagist，不是repo.packagist.org） - 切源后务必清理残留代理：
composer config -g --unset http-proxy && composer config -g --unset https-proxy
最麻烦的从来不是命令怎么写，而是代理链路里任意一环（本地代理进程、防火墙策略、网关 ACL、甚至 DNS 转发规则）出问题，现象都一样：没报错，只卡住。逐层用 curl -x 验证，比反复重装 Composer 有用得多。
