如何在Composer中配置HTTP缓存代理-composer-PHP中文网

composer不支持http缓存代理，仅支持网络层代理（http-proxy/https-proxy）和镜像源两种机制；必须同时配置http-proxy与https-proxy（均用http://协议），且需url编码特殊字符，镜像源与代理不可共存。

如何在composer中配置http缓存代理

Composer 本身不支持标准 HTTP 缓存代理（如 Squid、Nginx proxy_cache），它没有内置的 Cache-Control 解析、ETag 处理或 304 响应复用逻辑。所谓“HTTP 缓存代理”在 Composer 场景下，实际指的是两种完全不同的东西：一种是**网络层代理（http-proxy）用于绕过网络限制**，另一种是**镜像源（mirror）用于加速重复下载**。混淆这两者会导致配置无效、命令卡死或静默失败。

composer config -g http-proxy 和 https-proxy 必须同时设

Composer 默认对 packagist.org 发起 HTTPS 请求，但它的 http-proxy 配置只影响 HTTP 协议流量；https-proxy 才控制 HTTPS 流量是否走代理。漏掉任意一个，就会出现：

Loading composer repositories 卡住不动（实际是部分请求直连超时）
日志里看不到明确错误，只有超时或 cURL error 7
即使代理服务正常，curl -x http://127.0.0.1:7890 https://packagist.org/packages.json 能通，Composer 仍失败

正确写法（注意协议必须是 http://，不是 https://）：

composer config -g http-proxy http://127.0.0.1:7890
composer config -g https-proxy http://127.0.0.1:7890

带认证时，密码含 @ 或 : 必须先 rawurlencode()，否则解析 URI 失败：

php -r "echo rawurlencode('pa@ss:word');"

输出 pa%40ss%3Aword，再拼成 http://user:pa%40ss%3Aword@127.0.0.1:7890。

别把镜像源（mirror）当成缓存代理

很多人以为配个 https://mirrors.aliyun.com/composer/ 就是“用了缓存代理”，其实这是完全不同的机制：

镜像源是完整同步 packagist.org 元数据+包文件的独立站点，Composer 直连它，不经过你本地代理
它不缓存你的请求，只是提供更快的物理节点和 CDN 分发
镜像源和代理不可共存：repo.packagist.org.proxy 和 repo.packagist.org 的 url 不能同时生效，后者会覆盖前者

如果你公司已有内网镜像（如腾讯云、华为云私有镜像站），直接切源更稳：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

composer config -g repo.packagist.org url https://mirrors.tencent.com/composer/

此时无需任何 http-proxy，也别留着旧代理配置，否则可能干扰 DNS 解析或触发 TLS 不匹配。

为什么 SOCKS5 代理容易失败

Clash、Proxifier 等工具常暴露 socks5://127.0.0.1:7891 端口，但 Composer 对 SOCKS5 支持有限：

仅 Composer ≥ 2.2 支持 socks5:// 协议前缀
旧版（如 2.1.x）会直接忽略该配置，退化为直连，现象仍是卡在 Loading...
SOCKS5 不转发 DNS 请求时，packagist.org 域名解析仍可能被污染或超时

验证方式不是看 Composer 是否报错，而是运行：

curl --proxy socks5://127.0.0.1:7891 -I https://packagist.org/packages.json

如果这行失败，Composer 必然失败；如果成功，再确认 Composer 版本：composer --version。低于 2.2 就得换 HTTP 代理或升级 Composer。

代理配置后仍卡住？先排除环境变量干扰

Composer 会优先读取系统环境变量 HTTP_PROXY 和 HTTPS_PROXY，它们的值若与 composer config 冲突，会导致行为不可预测：

Linux/macOS 下检查：env | grep -i proxy
Windows 下检查：set | findstr -i proxy
临时清空测试：HTTP_PROXY= HTTPS_PROXY= composer install

更稳妥的做法是统一用 composer config -g 配置，然后显式 unset 环境变量，避免 CI/CD 或多用户场景下意外继承。

真正难调试的点在于：所有失败表现都一样——卡住、无报错、没进度。必须一层层验证，从 curl -x 到 composer config -g --list，再到确认代理进程监听的是 0.0.0.0:port 而非 127.0.0.1:port（尤其 Docker 容器内运行时）。