Composer如何利用分流DNS优化国内外源-composer-PHP中文网

单纯配置国内镜像源不够，因composer还需请求github等境外域名，若dns未分流解析，会导致克隆卡住或解析失败；需配合/etc/hosts分域名指向国内ip，并禁用systemd-resolved等干扰服务。

composer如何利用分流dns优化国内外源

为什么直接配国内镜像源还不够

单纯把 repo.packagist 指向阿里云或清华源，只解决了公开包元数据和 ZIP 包的下载路径。但 Composer 实际运行中还会频繁请求 GitHub、GitHubusercontent、packagist.org（用于 fallback 或校验）、甚至私有 Git 仓库——这些域名若仍走默认 DNS，解析可能卡在境外节点，导致 Cloning into ''... 卡住、Could not resolve host github.com 报错，或 TLS 握手超时。

分流 DNS 的核心是按域名分层调度

不是换一个全局 DNS 就行，而是让不同域名走不同解析路径：

mirrors.aliyun.com、packagist.org、github.com 这类关键域名，必须解析到国内 CDN 边缘 IP（如阿里云镜像站返回的 223.6.6.6）
其他泛域名（如 *.google.com、*.microsoft.com）可继续走 114.114.114.114 或 8.8.8.8，避免影响日常浏览

Linux/macOS 下最轻量做法是改 /etc/hosts，Windows 下同理（C:\Windows\System32\drivers\etc\hosts）：

223.6.6.6 mirrors.aliyun.com
223.6.6.6 packagist.org
223.6.6.6 github.com
223.6.6.6 githubusercontent.com
223.6.6.6 npmjs.org

注意：IP 必须用 curl -I https://mirrors.aliyun.com/composer/ 实时确认，不同地区返回可能不同；别直接抄旧文档里的 IP。

systemd-resolved 会偷偷覆盖 hosts 和 resolv.conf

Ubuntu 20.04+、Fedora、Arch 等默认启用 systemd-resolved，它会拦截 DNS 请求并忽略 /etc/hosts 中的部分条目，尤其对 HTTPS 域名。

验证是否启用：systemctl is-active systemd-resolved

Discussion Composer

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

下载

若为 active，必须禁用：

sudo systemctl disable --now systemd-resolved
sudo rm -f /etc/resolv.conf
echo "nameserver 114.114.114.114" | sudo tee /etc/resolv.conf

否则你刚写好的 hosts 条目大概率失效，dig github.com 仍返回境外 IP。

CI/CD 和 Docker 容器里容易漏掉这层

GitHub Actions、GitLab Runner 或自建 CI 节点常复用基础镜像，里面 /etc/hosts 是空的，systemd-resolved 可能未被清理，且 DNS 配置继承自宿主机（而宿主机未必配了分流）。

推荐在 CI 脚本开头显式注入：

echo "223.6.6.6 mirrors.aliyun.com" | sudo tee -a /etc/hosts
echo "223.6.6.6 packagist.org" | sudo tee -a /etc/hosts
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
composer clear-cache

Docker 构建时，可在 Dockerfile 中用 RUN echo "223.6.6.6 github.com" >> /etc/hosts，但更稳妥的是启动容器时加 --dns 114.114.114.114 并配合 hosts 文件挂载。

真正起效的关键不是“有没有配”，而是“谁在执行、在哪执行、DNS 是否被中间件劫持”——这三个变量漏一个，分流就断在第一跳。