dns解析失败是导致“no such host”或“request canceled”错误的主因，需依次执行nslookup、dig、ping验证解析链路，检查/etc/resolv.conf配置有效性，通过daemon.json为docker单独指定dns，清除缓存并排除hosts干扰。
拉取镜像卡在 pulling fs layer 或报 no such hostnet/http: request canceled，大概率是 DNS 解析失败——不是镜像源慢，而是根本没找到服务器地址。先别急着换源或配代理，按顺序验证解析环节是否通畅。
确认 registry 域名能否被系统正确解析
执行以下三条命令，观察输出是否一致且快速：
-
nslookup registry-1.docker.io—— 看是否返回 IPv4 地址（如152.199.20.162），而非server can't find或超时 -
dig registry-1.docker.io +short—— 输出应为简洁 IP 列表；若为空或报connection timed out，说明 DNS 查询链路中断 -
ping -c 3 registry-1.docker.io—— 若 nslookup 成功但 ping 不通，说明 DNS 正常、网络连通性差；若 nslookup 失败，问题就锁定在 DNS 层
检查 /etc/resolv.conf 是否可靠
该文件是系统级 DNS 配置入口，但容易被 NetworkManager、DHCP 或云平台覆盖。常见陷阱包括：
IntoDNS.ai
下载
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
- 内容为空，或只含
nameserver 127.0.0.53（这是 systemd-resolved 的 stub 地址，未必转发有效） - 写入了运营商 DNS（如
223.5.5.5），实测响应常超 300ms，Docker 默认超时仅 30 秒，极易触发失败 - 手动改完后未生效：Ubuntu 24.04 等新版系统需通过
resolvectl或nmcli修改，直接编辑/etc/resolv.conf可能被自动覆盖
强制 Docker 使用指定 DNS，绕过系统配置
即使系统 DNS 有问题，也能让 Docker 守护进程独立使用稳定 DNS：
- 编辑
/etc/docker/daemon.json，加入"dns"字段（注意逗号语法）：
- 保存后执行
sudo systemctl restart docker - 验证是否加载成功：
docker info | grep -i dns应显示你配置的地址
排除 hosts 干扰和缓存残留
DNS 问题有时藏得更深：
- 检查
/etc/hosts是否误写了registry-1.docker.io的错误 IP，导致强制绑定失效地址 - 清空本地 DNS 缓存：
sudo systemd-resolve --flush-caches（systemd 系统）或sudo resolvectl flush-caches - 临时禁用防火墙或安全软件测试，某些策略会拦截 DNS UDP 53 端口请求
