唯一安全可复现的本地化测试方式是用 curl --resolve 绕过本地 dns 解析链路，强制走指定 ip；它只对本次请求生效，不污染系统配置，且需确保端口与 https 协议一致。
不是“利用DNS劫持”，而是用 curl --resolve 绕过本地 DNS 解析链路，强制走指定 IP——这是唯一安全、可复现、不污染系统配置的本地化测试方式。
为什么不能真搞DNS劫持
DNS 劫持是非法且危险的操作：修改路由器 DNS、伪造本地 DNS 服务、篡改系统 resolver 都可能影响全局网络行为，甚至触发企业安全策略告警。Composer 的镜像测试只需验证「目标域名 + 指定 IP」是否能通 HTTPS，完全不需要动 DNS 层。
-
curl --resolve是 cURL 原生支持的机制，只对本次请求生效，不影响任何其他进程 - 它绕过
/etc/resolv.conf、systemd-resolved、Windows DNS Client Service 等全部中间环节 - 如果
curl --resolve "mirrors.aliyun.com:443:223.5.5.5" -I https://mirrors.aliyun.com/composer/packages.json返回HTTP/2 200，说明镜像服务本身可用，问题纯属你本地 DNS 解析失败 - 若返回 SSL error，说明该 IP 对应的证书不匹配（比如绑了 CDN 或已下线），得换别的 IP，不是 DNS 问题
怎么拿到靠谱的镜像域名真实 IP
别信搜索引擎或旧博客里抄来的 IP，阿里云、腾讯云等镜像站用的是 CDN，IP 经常轮换。必须实时查：
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 用阿里自己的 DNS 查：
dig mirrors.aliyun.com @223.5.5.5 +short | head -n1 - 用 Cloudflare 查：
dig mirrors.aliyun.com @1.1.1.1 +short | head -n1 - 避免用运营商默认 DNS（如 114.114.114.114），它们常返回缓存或污染结果
- 拿到 IP 后，立刻用
curl --resolve测试，别存着明天再用——CDN 节点可能已切换
测试时容易漏掉的 HTTPS 细节
镜像地址是 HTTPS，--resolve 必须带端口和协议一致性，否则会卡在 TLS 握手：
- 错：
curl --resolve "mirrors.aliyun.com:80:223.5.5.5" https://...→ HTTP 端口配 HTTPS 地址，必然失败 - 错：
curl --resolve "mirrors.aliyun.com::223.5.5.5" https://...→ 缺少端口号，cURL 不知道走 80 还是 443 - 对：
curl --resolve "mirrors.aliyun.com:443:223.5.5.5" https://mirrors.aliyun.com/composer/packages.json - 如果目标镜像支持 HTTP/2，加
-v可看到ALPN, offering h2；若只返回 HTTP/1.1，说明该 IP 节点不支持 HTTP/2，但不影响功能
CI/CD 或 Docker 里怎么稳定复现
容器环境没有图形界面、DNS 配置更不可控，--resolve 是最轻量可靠的方案：
- Docker 中直接写进 RUN 指令：
RUN curl -f -s -o /dev/null --resolve "mirrors.aliyun.com:443:223.5.5.5" https://mirrors.aliyun.com/composer/packages.json || exit 1 - GitHub Actions 里加一步检查，避免因 DNS 波动导致误报失败
- 别在 CI 里改
/etc/hosts——不同 runner 的文件系统隔离，改了也白改；--resolve是进程级绑定，100% 生效 - 注意：Composer 2.5+ 启动时仍会尝试解析原始域名做校验，所以即使你配了镜像，DNS 不通照样报错；
--resolve测试通过，才能放心进下一步配源
真正要落地，就两件事：先用 dig 拿最新 IP，再用 curl --resolve 直连验证。所有其它操作——改 hosts、换系统 DNS、装代理——都是兜底手段，不是测试本身。
