Red Hat 网络配置的核心在于通过 NetworkManager 与配置文件双轨并行管理，在确保服务持久化的前提下，利用 nmcli 与手工编辑 /etc/sysconfig/network-scripts/ 实现灵活、可审计的网络环境，对于生产环境，强烈建议默认使用 NetworkManager,并在关键变更前执行原子化备份与回滚方案。
理解 Red Hat 网络管理架构
Red Hat Enterprise Linux（RHEL）及衍生系统（如 CentOS、Rocky Linux）从 RHEL 8 开始，NetworkManager 已成为唯一默认网络管理服务，它同时管理物理网卡、虚拟网桥、VLAN、 bond 等对象。
- 传统配置文件位置：
/etc/sysconfig/network-scripts/ifcfg-<接口名> - 动态状态查看：
nmcli device status - 连接配置查看：
nmcli connection show
关键认知：在 RHEL 8/9 中，ifup/ifdown 脚本已被 NetworkManager 操作取代，手工修改配置文件后 必须使用 nmcli connection reload 或 nmcli connection up 生效。
静态 IP 配置的标准流程
使用 nmcli 快速配置（推荐）
nmcli connection mod ens160 ipv4.method manual ipv4.addresses 192.168.10.10/24 ipv4.gateway 192.168.10.1 ipv4.dns "223.5.5.5 8.8.8.8" nmcli connection up ens160
优点：语法简洁、自动刷新连接配置、避免手写错误。
手工编辑配置文件（适合脚本化批量部署）
编辑 /etc/sysconfig/network-scripts/ifcfg-ens160：
BOOTPROTO=none
ONBOOT=yes
IPADDR=192.168.10.10
PREFIX=24
GATEWAY=192.168.10.1
DNS1=223.5.5.5
DNS2=8.8.8.8修改后执行：
nmcli connection reload nmcli connection up ens160
独立见解：很多运维人员在 RHEL 8 之后仍然习惯关闭 NetworkManager，改为传统的 network.service，但这种方式会丢失 连接活跃度自动切换、设备级策略路由 等高级功能，除非对系统有极端轻量化要求,否则不建议关闭。
多网卡绑定与 VLAN 配置
生产环境中，多网卡绑定（bond）是保证链路冗余的常见手段。
Bond 配置示例（active-backup 模式）
nmcli connection add type bond con-name bond0 ifname bond0 mode active-backup nmcli connection add type ethernet con-name bond-slave-1 ifname ens160 master bond0 nmcli connection add type ethernet con-name bond-slave-2 ifname ens224 master bond0 nmcli connection modify bond0 ipv4.method manual ipv4.addresses 10.0.0.10/24 nmcli connection up bond0
故障恢复体验：当主网卡失联时，从网卡会自动接管，/var/log/messages 中会记录链路切换事件，建议同时开启 arp_interval=1000 和 arp_ip_target=网关地址,确保链路状态检测准确。
VLAN 子接口
nmcli connection add type vlan con-name vlan100 ifname vlan100 dev bond0 id 100 nmcli connection modify vlan100 ipv4.method manual ipv4.addresses 192.168.100.1/24
注意：VLAN 标签在 Linux 中不要与物理接口完全同名,避免路由表混乱。
路由与 DNS 高级配置
策略路由
当服务器连接多个业务 subnet 时，普通静态路由难以做到源地址选路，此时可使用 NetworkManager 的路由规则：
nmcli connection modify <连接名> +ipv4.routing-rules "priority 100 from 192.168.10.0/24 lookup 100"
然后在 /etc/iproute2/rt_tables 中增加 table 100，并通过 ip route add ... table 100
填充规则。
独立见解：多数云服务器场景下，策略路由并不常用，但面对混合云双线接入（例如同时访问内网 IDC 和公网），策略路由远比修改 /etc/iproute2/rt_tables 更易维护,建议在配置文件中写入注释说明。
DNS 配置
- 全局 DNS 使用
/etc/NetworkManager/NetworkManager.conf的[global-dns]段 - 单连接 DNS 使用
nmcli connection modify <连接名> ipv4.dns "x.x.x.x" - 注意
dns-search用于指定域搜索后缀
故障排查方法论
当网络不通时，按以下顺序排查,避免盲目重启网络服务：
- 检查链路层：
ethtool ens160确认 Link detected: yes - 检查协议层：
ip addr show确认 IP 地址是否准确 - 检查路由：
ip route show确认默认网关存在 - 检查连通性：
ping -c 3 网关ping -c 3 外网IP - 检查 DNS：
dig +short baidu.com或getent hosts baidu.com
systemctl status NetworkManager 显示 active，但网络仍然不通，优先查看 journalctl -u NetworkManager -f 实时日志，比读取 /var/log/messages 更高效。
酷番云实战经验案例
酷番云某客户在迁移业务至云端时，原内部服务器使用静态 IP 并绑定多网卡，但云环境中底层虚拟化不支持传统 bond 的网卡直通模式,我们给出的解决方案是：
- 在云端使用 VPC 内网多 IP 绑定 到同一张弹性网卡，代替物理 bond，实现业务 IP 不变。
- 利用酷番云控制台的 安全组策略 与 Linux 内部
iptables
- 将原服务器的
ifcfg-eth0配置转换为nmcli脚本化配置，并把配置文件提交到 Git 仓库,实现版本化管理。
结果：迁移过程零停机，重构后的网络配置在后续版本升级时仍然保持兼容。核心经验：云环境下，优先利用底层网络能力（如弹性网卡辅助 IP），而非在系统内部强行模拟硬件特性，这样运维更简洁、故障率更低。
相关问答
问题 1：Red Hat 系统修改主机名后，为什么网络服务会异常？
主机名修改与网络服务不是直接因果关系，但如果主机名配置在 /etc/hosts 中与网卡 IP 绑定，而新主机名未同步更新对应条目，会导致部分服务（如 SSH、DNS 解析）无法识别本机身份,建议使用：
hostnamectl set-hostname newname echo "192.168.1.10 newname" >> /etc/hosts
然后重启 NetworkManager，测试 localhost 解析是否正常。
问题 2：使用 nmcli 配置后，重启系统 IP 丢失，如何定位？
先检查连接状态：nmcli connection show --active，如果显示已激活但重启后消失，通常是因为 ONBOOT=no,执行：
nmcli connection modify <名称> connection.autoconnect yes
如果配置正确但仍丢失，查看是否开启了 DHCP 且 IP 租约超时，最后检查 NetworkManager 日志：
journalctl -b -u NetworkManager | grep -i 'ensd+'
互动区
你在处理 Red Hat 网络配置时遇到过最棘手的问题是什么？是 bond 切换失败、DNS 解析延迟，还是重启丢配置？欢迎在评论区分享你的排障经历,一起探讨更高效的处理方案。
图片来源于AI模型，如侵权请联系管理员。作者：酷小编，如若转载，请注明出处：https://www.kufanyun.com/ask/768675.html
