Oracle 19c及以后版本无需关闭NetworkManager，问题根源多为/etc/hosts配置错误或resolv.conf被覆盖；runcluvfy报“Network address resolution check failed”是硬性拦截，要求hostname正反向解析严格一致且可通。
oracle 19c 及以后版本不需要关闭 networkmanager，强行关闭反而容易引发网络管理混乱——问题根源几乎总是 /etc/hosts 配置错误或 resolv.conf 被覆盖，而不是 networkmanager 本身。
runcluvfy stage -pre crsinst 报 “Network address resolution check failed”
这是 Oracle 12c+ 的硬性拦截项，不是警告。常见错误现象包括：
ERROR: PRVF-4664 : Found inconsistent name resolution entries for node "node1"PRVF-4657 : Name resolution setup check for "node1" failed- 后续
root.sh执行到ohasd启动时卡死或报ORA-00600
根本原因不是 NetworkManager 是否运行，而是主机名解析不稳定。Oracle 检查逻辑是：对本机 hostname 执行 gethostbyname() 和 getaddrinfo()，要求正向（hostname → IP）和反向（IP → hostname）都必须一致且可解析。
实操建议：
- 用
hostname命令确认当前主机名（如rac1），再执行hostname -i和nslookup $(hostname)，两者输出的 IP 必须完全相同 -
/etc/hosts中必须有形如192.168.10.10 rac1 rac1.localdomain的条目，且不能含多余空格或制表符 - 删掉
/etc/hosts中任何指向127.0.0.1或::1的非localhost条目（比如127.0.0.1 rac1是致命错误） - 确保
/etc/resolv.conf不为空，且至少含一个可用 nameserver；若用 DNS，需确认该 DNS 能正确返回 A 和 PTR 记录
NetworkManager 正在运行，但 /etc/resolv.conf 被清空或覆盖
CentOS/RHEL 7+ 默认启用 NetworkManager，它会动态管理 /etc/resolv.conf。一旦配置不当，runcluvfy 就会因 DNS 解析失败而中止。
实操建议：
- 检查
nmcli dev show输出中对应接口的IP4.DNS字段是否为空；若为空，说明 NM 没配 DNS - 用
nmcli connection modify "System eth0" ipv4.dns "8.8.8.8,114.114.114.114"显式设置 DNS（连接名以nmcli connection show为准） - 执行
nmcli connection down "System eth0" && nmcli connection up "System eth0"刷新配置 - 验证
/etc/resolv.conf是否已更新；若仍被清空，临时加锁：chattr +i /etc/resolv.conf（仅调试用，安装完记得chattr -i） - 不推荐禁用 NetworkManager，除非你明确使用传统
network.service并已停用 NM
静态 IP 配置后仍无法通过 cluvfy 网络检查
即使关了 DHCP、配了静态 IP，runcluvfy 仍可能失败，因为检查不只看连通性，更看解析一致性。
实操建议：
- 不要依赖
ifconfig或ip addr查看 IP 后就认为“配好了”——必须验证ping -c1 $(hostname)和ping -c1 $(hostname -i)都通，且无域名解析延迟 - 如果用了 teamd/bonding 接口（如
team0），cluvfy默认不识别；改用传统命名（ens160）或显式指定接口：runcluvfy.sh stage -pre crsinst -n rac1,rac2 -interface ens160/192.168.10.0/24 - 避免在
/etc/hosts中写别名（如192.168.10.10 rac1 vip1），cluvfy只认第一个名称作为 canonical hostname - Oracle 19c 支持
-fixup自动修复部分 hosts/DNS 问题，但仅限于它能安全修正的范围；不要加-fixup还跳过检查，那是掩耳盗铃
真正复杂的地方在于：Oracle 的网络检查本质是模拟集群节点间通信前的“握手准备”，它比 ping 严苛得多。很多人修好了 /etc/hosts 却忘了反向解析，或者修好了 IPv4 却没处理 IPv6 的 ::1 冲突。这些细节不显眼，但直接决定 CRS 能否启动成功。
