Composer本身不处理DNS，所谓“代理DNS”是误称；真正要配的是HTTPS代理（用于CONNECT隧道）或镜像源（绕过DNS解析），二者互斥，不能混用。
Composer 本身不处理 DNS，所谓“代理 DNS”是误称；真正要配的是 HTTPS 代理（用于 CONNECT 隧道）或镜像源（绕过 DNS 解析），二者互斥，不能混用。
为什么“代理 DNS”这个说法不成立
Composer 没有独立的 DNS 代理机制。它依赖 PHP 的 file_get_contents 或 cURL 发起 HTTP/HTTPS 请求，DNS 解析由底层系统或 cURL 决定，Composer 不提供配置项控制 DNS 查询路径。所谓“通过代理优化 DNS”，实际是想解决因 DNS 污染/超时导致的 Could not resolve host packagist.org 问题，但错误归因了根因。
常见现象包括：
-
composer install卡在Loading composer repositories，日志无明确域名错误，但curl https://packagist.org/packages.json同样失败 -
Could not resolve host直接报出，且ping packagist.org也失败 - 设置了
HTTP_PROXY环境变量，但 Composer 完全不读取——它只认自己的http-proxy和https-proxy配置
正确做法：优先换镜像源，而非折腾代理
国内用户 90% 的“DNS 问题”本质是访问 packagist.org 全链路失败（DNS + TCP + TLS），换镜像源可一并绕过。镜像站域名（如 mirrors.aliyun.com）在国内解析稳定、CDN 覆盖广。
执行以下命令之一（推荐清华或阿里）：
composer config -g repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/ composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
验证是否生效：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
composer config -g repo.packagist，输出应为完整 URL，不是null或空 - 加
-vvv运行composer install，日志中所有GET请求地址应含mirrors.tuna.tsinghua.edu.cn或类似域名 - 旧版 Composer（1.x）需用
repos.packagist（注意 s），且值为 JSON 字符串
必须配代理的场景及关键配置点
仅当镜像源也失效（如内网完全屏蔽境外域名、连 mirrors.aliyun.com 都无法解析）时，才考虑 HTTPS 代理。此时必须同时设置两个字段：
-
repo.packagist.org.proxy：控制 HTTP 请求（极少用，基本不用设） -
repo.packagist.org.ssl-proxy：强制用于所有 HTTPS 请求（必须设，且值必须是http://开头，哪怕代理监听 HTTPS 端口）
正确命令示例（全局）：
composer config -g repo.packagist.org.proxy http://127.0.0.1:7890 composer config -g repo.packagist.org.ssl-proxy http://127.0.0.1:7890
易错点：
- 填成
https://127.0.0.1:7890或漏协议头 → 静默 fallback 直连 → 超时无提示 - 只设
http-proxy（已弃用字段）或只设https-proxy（不存在该字段）→ 不生效 - 代理进程未启动、端口被防火墙拦截、或代理不支持 CONNECT 隧道 →
curl -x http://127.0.0.1:7890 https://packagist.org/packages.json直接失败
DNS 层面能做的真实干预只有三件事
如果坚持要从 DNS 入手（比如镜像源也因 DNS 失败），可操作项非常有限，且需系统级配合：
- 修改系统 hosts 文件，硬编码
packagist.org和github.com的 IP（IP 需定期更新，否则失效） - 更换系统 DNS 为
8.8.8.8或1.1.1.1，并清空本地 DNS 缓存（ipconfig /flushdns或sudo dscacheutil -flushcache） - Docker 容器内需显式传入
--dns 8.8.8.8，因为默认继承宿主机但可能被覆盖
注意：composer config -g http.timeout 或 process-timeout 只延长等待时间，不解决 DNS 解析失败本身。
最常被忽略的一点：公司内网若已部署私有 Packagist 镜像（如 Nexus Repository 搭建的 Composer 私库），再额外加代理只会增加跳转层级和故障概率——请求先到本地代理，再出去，再绕回内网镜像，延迟更高且容易丢包。
