根本原因是系统级 DNS 配置异常，需检查 /etc/resolv.conf 和本地 DNS 代理状态；Go 工具链依赖系统 resolver 且不缓存 DNS 结果，Alpine 容器中 musl libc 的 timeout 缺失更易超时。
Go 模块下载失败若报 lookup proxy.golang.org: no such host 或类似 DNS 错误，根本原因几乎总是系统级 DNS 配置异常，而非 Go 本身问题——先别改 go env，直接查 /etc/resolv.conf 和本地 DNS 代理状态。
为什么 go get 会卡在 DNS 解析上
Go 模块代理（如 proxy.golang.org、goproxy.cn）本质是 HTTPS 服务，但首次连接前必须完成域名解析。Go 默认使用系统 resolver（即 glibc 的 getaddrinfo），完全依赖 /etc/resolv.conf 中的 nameserver；它不读 /etc/hosts，也不走 systemd-resolved 的 stub 端口（127.0.0.53）除非该地址真在监听且可达。
- 常见现象：运行
go get -v github.com/sirupsen/logrus卡住数秒后报no such host，但curl https://proxy.golang.org成功（说明网络通，DNS 已缓存或被绕过） - 真实瓶颈：Go 在每次模块请求前都会触发一次 fresh DNS 查询，不复用之前结果，因此系统 DNS 响应慢或失败会直接阻塞整个
go get流程 - Alpine 容器中尤其高频：musl libc 不解析
resolv.conf中的options timeout:，而默认超时长达 5 秒以上，抖动时极易超时
go mod download 失败时怎么快速验证 DNS 是否真通
别用 ping 或 curl——它们可能走缓存或 HTTP 重定向，掩盖 DNS 层问题。必须用底层 DNS 工具直连测试：
- 执行
dig proxy.golang.org @8.8.8.8 +short：若返回 IP，说明公网 DNS 可用，问题出在本地配置 - 执行
dig proxy.golang.org @127.0.0.53 +short：若超时或返回空，说明systemd-resolved未运行或上游不可达 - 执行
getent hosts proxy.golang.org：这个命令走完整 NSS 链路（nsswitch.conf→resolv.conf→ 实际查询），结果和 Go 一致，比nslookup更可信 - 临时改
/etc/resolv.conf为nameserver 8.8.8.8后重试go mod download：若立刻成功，确认是原 DNS 配置失效
Go 程序里自定义 DNS 解析器不能解决 go get 问题
go get、go mod download 是 Go 工具链自身行为，完全不走你代码里的 net.Resolver。想控制它的 DNS 行为，只有两个有效入口：
- 设环境变量
GOPROXY=https://goproxy.cn,direct并配GOSUMDB=off（跳过 checksum 验证，避免额外 DNS 查询） - 强制指定 DNS 服务器给整个系统：修改
/etc/resolv.conf，或在systemd-resolved中用resolvectl dns eth0 8.8.8.8，再resolvectl flush-caches - 容器场景下，别信镜像默认配置：Alpine 镜像常无
resolv.conf或只写127.0.0.11（dockerd 内置 DNS），启动时加--dns 8.8.8.8最直接 - CI 环境（如 GitHub Actions）建议硬编码：在 workflow 中插入步骤
echo "nameserver 1.1.1.1" | sudo tee /etc/resolv.conf
排查时最容易被忽略的三个点
一是 /etc/resolv.conf 是符号链接却没检查目标文件内容，比如指向 /run/systemd/resolve/stub-resolv.conf，但 systemd-resolved 实际没运行；二是 search 域导致短名补全失败（如把 proxy 错当成 proxy.internal.company.com）；三是防火墙或云平台安全组放行了 HTTPS 443，却没开 UDP 53——DNS 查询失败是静默的，不会报连接拒绝，只会等超时。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
