UnknownHostException 本质是系统级 DNS 解析失败，需优先排查网络连通性、DNS 配置、/etc/hosts 格式、Java 环境限制及容器 DNS 策略，而非直接修改代码。
查 UnknownHostException 是不是 DNS 根本没响应
这个异常本质是 JVM 调用系统 socket 时，getaddrinfo() 或 gethostbyname() 返回了失败——连 DNS 服务器都没连上，或者连上了但没回包。别急着改代码，先确认网络层是否通。
- 用
nslookup example.com或dig example.com直接查目标域名，看有没有 A/AAAA 记录返回；如果超时或提示server can't find，说明 DNS 配置或网络有问题 - 换一个公共 DNS 测试，比如
nslookup example.com 8.8.8.8，能通说明本地 DNS（如公司内网 DNS）挂了或策略拦截了 - Java 进程可能被限制 DNS 查询：检查是否设置了
-Dnetworkaddress.cache.ttl=0，但更常见的是容器或沙箱环境禁用了 UDP 53 端口，telnet 8.8.8.8 53会失败
确认 /etc/hosts 有没有写错格式或干扰项
/etc/hosts（Windows 是 C:\Windows\System32\drivers\etc\hosts）优先级高于 DNS，但格式错一个字符就会让整行失效，甚至拖垮整个解析流程。
- 每行只能有一个 IP + 至少一个 hostname，不能有空格分隔 IP 和域名（必须用制表符或空格，但开头/结尾不能有多余空格）
- 注释行必须以
#开头，且#前不能有内容；写成127.0.0.1 localhost # comment是合法的，但127.0.0.1 localhost#comment会让localhost#comment被当做一个主机名去解析，触发UnknownHostException - Java 默认不刷新 hosts 缓存，改完 hosts 后要重启 JVM，否则旧缓存还在用（除非你显式调用
InetAddress.clearCache()，但 JDK 8+ 才支持）
Java 应用里硬编码的 host 字符串有没有拼错或带不可见字符
很多 UnknownHostException 其实不是网络问题，而是传给 InetAddress.getByName() 或 new URL() 的字符串本身就有坑。
- 检查字符串是否含 BOM、全角空格、零宽字符（尤其从配置中心、数据库或前端传入时），用
host.getBytes(StandardCharsets.UTF_8)打印字节序列能快速识别 - URL 构造时容易多写斜杠，比如
http://api.example.com//v1，虽然 HTTP 客户端可能自动纠正，但底层URL.getHost()可能提取出空字符串或非法值 - 使用
URI而非URL解析地址更健壮：new URI("https://api.example.com").getHost()对畸形输入容忍度更高
容器或 Kubernetes 环境下 DNS 配置特别容易漏掉
Docker 默认用宿主机 /etc/resolv.conf，但 K8s Pod 的 dnsPolicy 和 resolv.conf 生成逻辑更复杂，出问题时现象一模一样，排查路径却完全不同。
立即学习“Java免费学习笔记（深入）”；
- 进容器执行
cat /etc/resolv.conf，确认nameserver行存在且指向可用地址；K8s 中若看到127.0.0.11，那是 CoreDNS 的本地代理，得进一步查kubectl get svc -n kube-system确认 CoreDNS 是否就绪 - Pod 的
dnsPolicy: Default会继承节点 DNS，但ClusterFirst下，未匹配 cluster domain（如.svc.cluster.local）的域名才走上游 DNS——如果你访问的是mysql.prod.svc却没配对的 Service，也会报这个异常 - Docker Desktop 或 Kind 等本地集群常默认禁用 IPv6，而 Java 在某些版本下会优先尝试 AAAA 查询，失败后才降级 A；加启动参数
-Djava.net.preferIPv4Stack=true可绕过
真正麻烦的不是找不到原因，是错误堆栈里完全不提 DNS 超时还是 hosts 格式错——它只冷冷抛出 UnknownHostException，连具体查的是哪个 host 都不一定打出来。所以第一反应永远不该是改代码，而是抓包看系统调用了什么、往哪发了什么请求。
