Jetty域名解析失败最直接的原因通常是DNS配置错误、hosts文件未映射或Java安全策略拦截，按“先本地后远端”的顺序排查，多数情况下5分钟内即可定位。下面按从底层网络到Jetty自身配置的顺序，拆成可逐条执行的步骤,每一步都给出具体命令和查看路径。
Jetty域名解析失败怎么快速排查
遇到Jetty启动报UnknownHostException，先别急着改代码，解析失败发生在连接建立之前，Jetty只是把异常抛出来,真正的根因在操作系统或JVM的解析链路上。
第一步：确认系统层能不能解析
在部署Jetty的那台服务器上直接执行：
ping yourdomain.com：看返回的是真实IP还是unknown hostnslookup yourdomain.com：观察是否走对了DNS服务器dig yourdomain.com +short（Linux）：只取解析结果，排除干扰信息
如果系统层就解析不了，问题不在Jetty，继续查/etc/resolv.conf（Linux）或网络适配器DNS设置（Windows），行业共识认为，容器化部署时容器内DNS与宿主机不一致是高频诱因，尤其是K8s环境下的dnsPolicy配置。
第二步：检查hosts文件映射
开发环境和内网环境常靠hosts硬编码,路径分别是：
- Linux/macOS：
/etc/hosts - Windows：
C:\Windows\System32\drivers\etc\hosts
用cat /etc/hosts确认目标域名是否有对应IP记录，格式必须是IP 域名，中间用空格或Tab，写成域名 IP顺序反了不会生效，改完后Linux无需重启，Windows可能需要ipconfig /flushdns刷新缓存。
第三步：确认Jetty的 connector 绑定配置
jetty.xml或jetty-http.xml里<Set name="host">如果写成了某个具体域名，而该域名恰好解析失败，Jetty启动阶段就会直接抛异常，改成0.0.0或留空表示监听所有网卡，能绕开启动期的解析依赖，这一步在“Jetty域名解析失败但IP访问正常”的场景里特别常见用IP能打开管理后台，用域名就启动报错,八成是connector里绑了域名。
Jetty启动报错域名无法解析怎么解决
启动阶段的解析失败和运行期的表现不一样，前者直接中断，后者表现为请求超时,按错误信息分两类处理。
UnknownHostException的定位路径
日志里出现java.net.UnknownHostException: xxx时,先看堆栈最顶端的类名：
- 若是
InetAddress相关，纯系统解析问题，回到第一步 - 若是
org.eclipse.jetty包内抛出，检查jetty.xml中是否配置了需要解析的主机名，比如<Set name="host">或SSL证书里的CN字段
一个实操技巧：在启动脚本里加一行-Djava.net.preferIPv4Stack=true，部分双栈环境会因IPv6优先解析失败而误报,强制IPv4能快速验证。
端口通但域名不通的对比排查
用telnet 目标IP 端口和telnet 目标域名 端口分别测试，IP通、域名不通，说明解析链路有问题；两者都不通,才是防火墙或服务未监听。
对比表如下：
| 测试方式 | 结果 | 指向问题 |
|---|---|---|
| IP + 端口通 | 域名 + 端口不通 | DNS解析或hosts映射 |
| IP + 端口不通 | 域名 + 端口不通 | 防火墙、安全组或Jetty未启动 |
| 两者都通但应用报错 | 解析正常 | 应用层配置（如反向代理头） |
近年来容器场景中，/etc/hosts被编排系统覆盖导致映射丢失的情况占比不小,重启容器后重新写入是常规操作。
Java虚拟机DNS缓存导致Jetty解析异常的排查方法
JVM会缓存DNS解析结果，默认缓存策略在部分JDK版本下是“永久缓存”，域名IP变更后Jetty仍连旧地址，表现为“域名解析失败”的假象。
调整缓存策略的具体参数
启动Jetty时加JVM参数：
-Dnetworkaddress.cache.ttl=10：成功解析结果缓存10秒-Dnetworkaddress.cache.negative.ttl=0：失败结果不缓存
这两个参数通过java.security文件全局配置也生效，路径在$JAVA_HOME/conf/security/java.security（JDK 9+）或$JAVA_HOME/jre/lib/security/java.security（JDK 8），改文件对所有Java进程生效，改启动参数只影响当前Jetty实例,按部署规范选一种即可。
验证缓存是否生效
写一段十行以内的测试代码，循环调用InetAddress.getByName("目标域名")并打印时间戳，配合-Dnetworkaddress.cache.ttl=10观察两次解析间隔是否小于缓存时长，不想写代码的话，直接改hosts文件指向一个不存在的IP，看Jetty日志里报的地址是否立即变化变了说明缓存已失效,没变说明缓存仍在生效。
业内专家指出，缓存类问题最容易在灰度发布、DNS切换、云厂商解析记录变更后集中暴露,排查时优先怀疑缓存而非配置写错。
Jetty域名解析失败常见问题答疑
Jetty域名解析失败但IP能访问是什么原因？
解析发生在建立连接之前，IP能访问说明网络层和Jetty服务本身正常，问题锁定在域名到IP的映射环节，按顺序查三处：服务器/etc/hosts是否有错误映射、resolv.conf指定的DNS能否解析该域名、JVM DNS缓存是否还停留在旧记录，三处都正常时，再检查反向代理（如Nginx）的proxy_pass是否写死了域名而非IP。
Jetty域名解析失败和SSL证书有关系吗？
有间接关系，Jetty配置HTTPS时，如果KeyStore里的证书CN或SAN与访问域名不一致，握手阶段报的是证书错误而非解析错误，但日志里可能混在一起难以区分，判断方法：用openssl s_client -connect 域名:443看返回的证书主题，与访问域名逐字符比对，不一致就重新签发证书,与DNS解析本身无关。
Jetty域名解析失败的排查顺序应该怎样安排？
固定按“系统解析→hosts映射→connector绑定→JVM缓存”四层推进，每层用一条命令验证后再进下一层，系统层用ping或nslookup，hosts层用cat，connector层看jetty.xml的host属性，缓存层调TTL参数验证，顺序颠倒会浪费时间,比如先改JVM参数却发现系统层根本没配DNS。