全局代理配置对项目无效，因Composer优先读取项目composer.json中的config字段；若其内含http-proxy或https-proxy，全局设置即被完全忽略。

为什么全局代理配置对项目无效

Composer 的 http-proxy 和 https-proxy 配置是分作用域的：全局配置（-g）只影响未进入任何项目的终端环境，一旦你在某个项目目录下执行 composer install，Composer 会优先读取该项目根目录下的 composer.json 中的 config 段——如果它里面也定义了 http-proxy 或 https-proxy，全局设置就完全被忽略。

如何给单个项目单独配代理

直接在项目级 composer.json 的 config 字段里写死代理地址，是最可靠的方式。注意必须同时设两个字段，且格式严格：

• https-proxy 的值协议头必须是 http://，哪怕你的代理服务监听的是 HTTPS 端口（例如 http://127.0.0.1:7890）
• 若代理需认证，用户名/密码含 @、/、: 必须 URL 编码，比如密码 pa@ss/word 要写成 pa%40ss%2Fword
• 配置完别忘了运行 composer diagnose，确认没有报 “You are running Composer with SSL/TLS protection disabled” 这类警告

示例片段（插入到项目 composer.json 的 config 内）：

"config": {
    "http-proxy": "http://127.0.0.1:7890",
    "https-proxy": "http://127.0.0.1:7890"
}

项目级代理配置后仍不生效的常见原因

不是配置没写，而是被其他地方覆盖或校验失败：

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• composer.json 里 repositories 字段若存在自定义源（比如内网 Nexus），Composer 会绕过代理直连该地址——此时要检查该源是否支持 HTTPS、域名能否解析
• 项目目录下存在 .env 或部署脚本（如 GitHub Actions 的 run 步骤）里显式执行了 composer config --unset http-proxy，会把刚写的配置清掉
• PHP 进程本身禁用了 allow_url_fopen 或未启用 openssl 扩展，代理配置再对也发不出 HTTPS 请求；用 php -m | grep openssl 和 php -i | grep allow_url_fopen 快速验证

临时禁用项目代理做对比验证

当你怀疑代理配置干扰了某次安装，不要删配置，而是用环境变量临时绕过：

Linux/macOS：HTTP_PROXY= HTTPS_PROXY= composer install

Windows PowerShell：$env:HTTP_PROXY=""; $env:HTTPS_PROXY=""; composer install

如果这时能成功，说明问题确实出在代理链路上——接着查代理进程是否运行、端口是否被防火墙拦截、或是否公司网络强制走 NTLM 认证（此时需用 cntlm 或 px 中转）。

项目级代理配置真正生效的关键，是它必须出现在 composer.json 里，且不能被同文件中更高优先级的字段（如 repositories）或运行时环境变量覆盖。很多人卡在“明明写了却没走代理”，其实只是漏看了这一行："type": "package" 类型的仓库定义，会彻底跳过所有 proxy 设置。