goland不参与dns解析，需在go代码中用net.resolver显式配置自定义dns服务器（如127.0.0.1:53），设prefergo:true并配合dialcontext注入http.transport，才能让调试时正确解析localhost或内部服务域名。
GoLand 本身不参与 DNS 解析，它只是 IDE；真正做域名解析的是你运行的 Go 程序（或其依赖的 net 包行为）。所谓“在 GoLand 中配置本地 DNS”，本质是让你启动的 Go 进程绕过系统默认 DNS，直连你指定的 DNS 服务（比如本地 CoreDNS 或 dnsmasq），从而让 localhost 域名、内部服务域名（如 auth.svc.cluster.local）在调试时能正确解析——这对跨域调试前端调后端、微服务间调用很关键。
GoLand 启动配置里不能直接填 DNS 地址
GoLand 的 Run Configuration（如 Go Build 或 Go Test）没有 “DNS Server” 输入框。试图在 Environment Variables 里加 GODEBUG=netdns=cgo 或改 /etc/resolv.conf 是无效路径：前者只影响解析器实现方式，后者在容器/非 root 环境不可控，且不指向你的自定义 DNS。
- 真正可控点在 Go 代码里：用
net.Resolver显式构造解析器 - GoLand 只需确保它运行的是你改过 DNS 行为的代码，并传入正确环境变量（如
COREDNS_ADDR=127.0.0.1:53） - 别在 GoLand 的 “Go tool arguments” 或 “VM options” 里折腾 DNS 相关 flag——它们对 DNS 解析无影响
必须用 net.Resolver + DialContext 才能生效
Go 标准库中，只有显式创建并使用的 net.Resolver 实例才能接管 DNS 查询。全局替换（如改 net.DefaultResolver）不安全，且 http.Client 不会自动用它——Transport 的 DialContext 才是关键入口。
- 错误写法：
net.DefaultResolver = &net.Resolver{...}—— 不推荐，影响所有包，且部分 stdlib 调用仍走系统 resolver - 正确写法：为
http.Transport单独配DialContext，并在其中调用你自己的resolver.LookupHost - 必须设
PreferGo: true，否则LookupHost仍可能 fallback 到 libc，忽略你指定的Dial -
Dial函数里必须用"udp"协议（如"udp://127.0.0.1:53"），TCP 非必需，且超时更长
resolver := &net.Resolver{
PreferGo: true,
Dial: func(ctx context.Context, network, addr string) (net.Conn, error) {
return (&net.Dialer{Timeout: 3 * time.Second}).DialContext(ctx, "udp", "127.0.0.1:53")
},
}
transport := &http.Transport{
DialContext: func(ctx context.Context, network, addr string) (net.Conn, error) {
host, port, _ := net.SplitHostPort(addr)
ips, err := resolver.LookupHost(ctx, host)
if err != nil {
return nil, err
}
for _, ip := range ips {
conn, err := (&net.Dialer{Timeout: 5 * time.Second}).DialContext(ctx, network, net.JoinHostPort(ip, port))
if err == nil {
return conn, nil
}
}
return nil, errors.New("no IP resolved")
},
}
跨域调试时容易忽略的两个坑
你在前端开 localhost:3000，调后端 api.dev.local:8080，看似只是个域名问题，但实际卡点常不在 DNS 本身。
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
-
api.dev.local必须在 CoreDNS/dnsmasq 里有明确 A 记录（如指向127.0.0.1或宿主机 Docker 网桥地址），光配 DNS 服务器地址不够 - 若后端服务跑在 Docker 容器里且监听
0.0.0.0:8080，但前端请求发到api.dev.local:8080，浏览器同源策略不会报错——但若容器没暴露端口或防火墙拦截，你会看到ERR_CONNECTION_REFUSED，误以为是 DNS 问题 - Chrome/Firefox 对
.local域名有 mDNS 特殊处理（尤其 macOS），可能绕过你配的 DNS；建议调试期换用.test或.dev（需确保未被系统拦截）
验证 DNS 是否真走你指定的服务器
最直接的办法不是看日志，而是抓包。在终端执行：
sudo tcpdump -i lo0 port 53 -w dns.pcap
然后在 Go 程序里触发一次 resolver.LookupHost(ctx, "api.dev.local")，打开 dns.pcap 查是否真往 127.0.0.1:53 发了 UDP 查询。如果没出现，说明你的 resolver 没被调用，或者被其他路径（如 net.LookupHost）绕过了。
另一个轻量验证：临时把 CoreDNS 停掉，再运行程序——如果立刻报 dial udp 127.0.0.1:53: connect: connection refused，就证明 DNS 流量确实打到了你指定地址；如果延迟几秒才报 no such host，说明还在走系统默认 DNS。
