解决java.net.UnknownHostException异常解决总结
内网服务器通过跳板机访问外网时，因跳板机未开启NAT地址伪装，导致域名解析失败。解决方案：首先开启内核IP转发功能，然后配置iptables的出口MASQUERADE规则并持久化保存，即可恢复网络连通，确保业务正常运行。
一、故障现象描述
先说几个核心判断：这个问题的表象很典型——Java应用运行过程中突然报错，提示某个域名解析失败。但深入分析后，根本原因并非DNS配置问题，而是网络链路本身出现了故障。
环境信息
- 内网服务器：192.168.2.199
- 跳板机：192.168.2.202（具备公网网卡 eno4）
- 内网服务器通过跳板机访问外网
报错信息
Java 控制台直接抛出以下异常：
java.net.UnknownHostException: api.weixin.qq.com: 域名解析暂时失败
测试现象
接下来进行常规排查，结果如下：
- 直接执行
nslookup api.weixin.qq.comconnection timed out; no servers could be reached
域名解析直接超时，无法联系到DNS服务器。 - 尝试ping公网DNS（如
119.29.29.29），无任何响应。 - 跳板机本身访问外网完全正常。
这三条测试结果清晰表明：内网服务器无法访问外网，而非某个特定域名解析异常。
二、核心原因分析
重点分析路由表——执行 ip route 后，发现内网服务器的默认网关指向跳板机：
default via 192.168.2.202 dev enp2s0f1
路由配置正确，那么问题究竟出在哪里？
故障根源
逐层排查后，真正原因包含以下三点：
- 链路中断
- IP 无法回程
- 规则失效
内网服务器将数据包发送至跳板机，但跳板机未开启地址伪装（MASQUERADE/SNAT）。数据包到达跳板机后，由于缺少身份转换，被卡住无法转发。
外网服务器收到的请求包源IP为内网私有地址（如192.168.2.199）。此类地址在公网无法路由，导致外网服务器无法将响应数据包返回。
进一步检查发现，跳板机上的 iptables 转发规则要么被修改，要么在系统重启后丢失。原有的NAT规则未生效，这是最直接的原因。
简单来说，内网服务器能够发送数据包，但跳板机未执行身份转换，导致外网无法识别内网地址，响应数据包无法返回。
三、解决方案：开启 NAT 地址转换
明确问题后，解决方案清晰：让跳板机执行地址伪装，实现内网与公网的通信。
步骤一：开启跳板机内核转发功能
首先确保Linux系统允许数据包转发：
# 检查当前状态 sysctl net.ipv4.ip_forward # 若返回值不为1，临时开启 sysctl -w net.ipv4.ip_forward=1 # 永久生效，写入配置文件 echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf sysctl -p
步骤二：配置 iptables 出口 NAT 规则
方案 A：允许整个内网网段上网（推荐）
若整个内网网段需通过跳板机访问外网，使用以下规则：
# -s 指定内网网段，-o 指定公网网卡 iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o eno4 -j MASQUERADE
方案 B：仅允许指定服务器上网（精细化控制）
若仅允许特定服务器（如192.168.2.199）通过跳板机上网，可执行：
# 仅允许 192.168.2.199 访问外网 iptables -t nat -A POSTROUTING -s 192.168.2.199/32 -o eno4 -j MASQUERADE
步骤三：持久化 iptables 规则
为防止重启后规则丢失，需保存规则：
# CentOS / RHEL iptables-save > /etc/sysconfig/iptables # Ubuntu / Debian iptables-save > /etc/iptables/rules.v4
四、技术知识点科普
CIDR 子网说明
关于CIDR表示法，简要说明：
- /24
- /32
子网掩码 255.255.255.0，覆盖 192.168.2.0 ~ 192.168.2.255 整个网段。适用于允许整个内网上网的情况。
子网掩码 255.255.255.255，精确匹配单个 IP 地址。适用于精细化控制，仅允许特定设备上网。
MASQUERADE（地址伪装）
这是解决此类问题的关键机制。它将内网服务器的私有IP临时替换为跳板机的公网IP。外网服务器收到的请求包源IP变为公网可达地址，响应数据包才能顺利返回跳板机，再由跳板机转发给内网服务器。整个过程对用户和应用透明。
五、验证结果
配置完成后，验证效果：
- 内网服务器执行
ping 114.114.114.114—— 网络连通，可访问外网。 - 内网服务器执行
nslookup api.weixin.qq.com—— 域名解析正常，DNS查询成功返回。 - 重启 Java 应用，业务功能恢复正常，不再报错。
至此，问题圆满解决。核心要点：务必为跳板机开启NAT地址伪装，否则内网服务器无法正常访问外网。