Restart or Reload Network on RHEL, Rocky Linux, AlmaLinux and Fedora

You edited a connection profile, changed DNS, or need to bounce an interface after troubleshooting. On current RHEL, Rocky Linux, AlmaLinux, CentOS Stream, Oracle Linux, and Fedora, NetworkManager is usually in charge—but the right restart command depends on whether you need a reload, a single-profile bounce, or a full daemon restart.

This guide covers current and legacy methods, from the least disruptive nmcli workflows through network.service and ifup/ifdown, and explains which one fits each situation.

Tested on: Rocky Linux 10.2 (Red Quartz); NetworkManager 1.56.0; nmcli 1.56.0-1.el10.

Quick reference

Use the least disruptive command that matches your goal. Replace DEVICE with the kernel interface and PROFILE with the connection name from nmcli device status.

On current NetworkManager-managed releases, prefer the nmcli rows first. network.service is usually absent on modern installs.

Check Which Network Service Manages the System

Before you restart anything, confirm that NetworkManager is active and note the difference between interface names and connection profile names.

Check whether the NetworkManager service is running:

systemctl is-active NetworkManager

Sample output:

active

An active result confirms that the NetworkManager daemon is running. It does not prove that every interface is managed by NetworkManager. Check the STATE column from nmcli device status; devices marked unmanaged are not currently controlled by NetworkManager.

Review overall NetworkManager state next:

nmcli general status

Sample output:

STATE      CONNECTIVITY  WIFI-HW  WIFI     WWAN-HW  WWAN     METERED
connected  full          missing  enabled  missing  enabled  no (guessed)

When NetworkManager connectivity checking is enabled, CONNECTIVITY full indicates that its connectivity test considers the internet reachable. This is stronger than merely having an active link, but it does not replace your own route, DNS, and application-level tests. NetworkManager reports unknown when the connectivity check did not run or is disabled.

List devices and which connection each one uses:

nmcli device status

Sample output:

DEVICE  TYPE      STATE                   CONNECTION
enp0s3  ethernet  connected               enp0s3
enp0s8  ethernet  connected               Wired connection 1
lo      loopback  connected (externally)  lo

The DEVICE column is the kernel interface. The CONNECTION column is the profile name you use with nmcli connection commands.

Show active connection profiles with UUIDs:

nmcli connection show --active

Sample output:

NAME                UUID                                  TYPE      DEVICE
enp0s3              8e253ab6-b35d-3500-826f-61b92fa7bc14  ethernet  enp0s3
Wired connection 1  5d09bf91-b93c-3457-a8b5-f6032b763ca4  ethernet  enp0s8
lo                  162f3f09-08b7-425c-8154-ce1a2ec2e7f0  loopback  lo

Profiles such as Wired connection 1 can sit on a differently named device—always verify both columns before you run connection down or device disconnect.

Which Network Restart Command Should You Use?

Use the least disruptive command that matches your goal. The table below lists every method this guide covers, from preferred reload workflows through legacy service restarts.

Presentation order in the sections below follows the same priority: reload first, then reapply, then one connection, then one device, then daemon-wide commands, then legacy tools.

Reload Network Configuration Without Disconnecting

Start here when you edited a connection profile file or made a change that NetworkManager can apply without tearing the link down.

Reload connection profiles

nmcli connection reload rereads connection profiles from disk. NetworkManager does not automatically notice manually edited profile files, so run reload before device reapply. Reload alone does not necessarily push every setting to an already-active interface.

sudo nmcli connection reload

The command exits silently on success. If you changed DNS, routes, or addresses on an active connection, follow with device reapply or a targeted connection up.

Reapply settings to an active device

nmcli device reapply attempts to update the device with changes made to its currently active connection profile since that profile was last applied. Some properties cannot be changed while the device remains connected, so reapply may not replace a full reactivation.

After editing a profile file, reload first, then reapply:

sudo nmcli connection reload
sudo nmcli device reapply enp0s3

Sample output:

Connection successfully reapplied to device 'enp0s3'.

Only compatible changes can be reapplied. Unsupported edits still need connection down/up or a targeted connection up "PROFILE".

Restart One Network Connection or Device

Use these when reload and reapply are not enough, or you deliberately want to bounce one profile or interface.

Restart a connection profile

If the profile is already down, connection up alone is enough:

sudo nmcli connection up "enp0s3"

Sample output:

Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/16)

To fully restart an active profile, bring it down and back up in one sequence:

sudo nmcli connection down "Wired connection 1" && sudo nmcli connection up "Wired connection 1"

Sample output:

Connection 'Wired connection 1' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3)
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/17)

Quote profile names that contain spaces. Chaining with && reduces the window where the interface stays down, but deactivating the interface carrying your SSH session still drops the connection.

Disconnect and reconnect a device

Device commands operate on the kernel interface, not the profile name. When you run nmcli device connect DEVICE, NetworkManager searches for a suitable connection profile for that device. It may reactivate the previous profile, choose another compatible profile, or create a default profile when none exists.

If you must reactivate one specific profile, use sudo nmcli connection up "PROFILE" instead.

sudo nmcli device disconnect enp0s8 && sudo nmcli device connect enp0s8

Sample output:

Device 'enp0s8' successfully disconnected.
Device 'enp0s8' successfully activated with '5d09bf91-b93c-3457-a8b5-f6032b763ca4'.

On this host NetworkManager reattached the same profile UUID. That is common, but not guaranteed—verify with nmcli device status after the reconnect. Avoid disconnecting the device that carries your SSH session unless you have console or out-of-band access.

Restart NetworkManager or All Networking

These commands affect more than one profile. Reach for them only when narrower nmcli steps did not help.

Restart the NetworkManager service

Restarting the daemon can interrupt every managed interface, VPN, bridge, bond, and VLAN on the host.

sudo systemctl restart NetworkManager

After the service restarts, verify devices and connections before you assume the outage is fixed.

Disable and re-enable NetworkManager networking

This turns off all NetworkManager-managed networking, then turns it back on. Treat it as highly disruptive.

sudo nmcli networking off && sudo nmcli networking on

Chaining with && does not make this safe over SSH—the first command can still drop your session. Use console access when the primary interface is involved.

Restart Networking with nmtui

nmtui is NetworkManager's text UI. It is useful from a local console when you prefer menus over nmcli.

Open the interface:

sudo nmtui

Choose Activate a connection, select the profile you want to deactivate, then activate it again. That workflow bounces one connection interactively.

Deactivating the profile behind your SSH session has the same risk as nmcli connection down—use graphical or serial console access for the primary interface. nmtui does not avoid disruption; it only presents the same actions in a menu.

Use ifup and ifdown on Older Systems

On legacy RHEL or CentOS systems—and some hosts that still ship compatibility scripts—ifup and ifdown may remain available:

sudo ifdown DEVICE && sudo ifup DEVICE

On Rocky Linux 10 and other current NetworkManager-only installs, those commands may be absent entirely. Modern systems should use nmcli instead.

Do not install deprecated network-scripts packages solely to restore ifup and ifdown on a current release. If you still depend on them, plan a migration to NetworkManager-native commands.

Restart the Legacy network Service

Older network-scripts and SysV-managed hosts used a network service:

sudo systemctl restart network

On NetworkManager-managed systems you get:

Sample output:

Failed to restart network.service: Unit network.service not found.

That error means the network.service unit is not available on the current installation. On modern releases, networking is normally managed by NetworkManager, so use nmcli or restart NetworkManager when a daemon restart is actually required.

SysV-era systems may still expose:

sudo service network restart

That path applies only where the legacy init script and network.service unit still exist.

Verify the Network After Restarting

Work through device state, active profiles, IP addressing, routing, DNS, and upstream connectivity in that order so you can see where the failure sits.

Check that interfaces are still connected:

nmcli device status

Sample output:

DEVICE  TYPE      STATE      CONNECTION
enp0s3  ethernet  connected  enp0s3
enp0s8  ethernet  connected  Wired connection 1
lo      loopback  connected  lo

Confirm the expected profiles are active:

nmcli connection show --active

Sample output:

NAME                UUID                                  TYPE      DEVICE
enp0s3              8e253ab6-b35d-3500-826f-61b92fa7bc14  ethernet  enp0s3
Wired connection 1  5d09bf91-b93c-3457-a8b5-f6032b763ca4  ethernet  enp0s8
lo                  162f3f09-08b7-425c-8154-ce1a2ec2e7f0  loopback  lo

Both devices should show connected with the profile you expect.

Confirm addresses are present:

ip -br address

Sample output:

lo               UNKNOWN        127.0.0.1/8 ::1/128
enp0s3           UP             10.0.2.15/24 ...
enp0s8           UP             192.168.56.108/24 ...

Each data interface should be UP with an address in the expected subnet.

Check the default route:

ip route show default

Sample output:

default via 10.0.2.2 dev enp0s3 proto dhcp src 10.0.2.15 metric 102

No default route here usually means DHCP failed or static gateway settings were not applied.

Inspect DNS configuration:

cat /etc/resolv.conf

Sample output:

# Generated by NetworkManager
search nsn-intra.net
nameserver 192.168.0.1

On hosts with systemd-resolved active, resolvectl status adds per-interface DNS detail. When it is not running, resolv.conf and a lookup test are enough.

Test name resolution:

getent hosts google.com

Sample output:

142.251.223.174 google.com

Ping the default gateway:

ping -c 1 "$(ip route | awk '/default/ {print $3; exit}')"

Sample output:

PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data.
64 bytes from 10.0.2.2: icmp_seq=1 ttl=64 time=0.874 ms

A working route with failed DNS lookups points to resolver configuration. Failed gateway pings suggest an upstream or firewall issue outside the profile itself.

If connectivity still fails, review recent NetworkManager logs:

journalctl -u NetworkManager -n 20 --no-pager

Look for DHCP timeouts, authentication failures, or profile activation errors near the time you restarted networking.

Common Problems and Fixes

Best Practices

• Use the least disruptive command: connection reload, then device reapply, before restarting connections or the daemon.
• Target one profile or device instead of restarting all networking when a single interface misbehaves.
• Verify profile and device names with nmcli device status before down, disconnect, or reapply.
• Avoid nmcli networking off, full daemon restarts, and primary-interface bounces over SSH without console access.
• Back up connection profiles under /etc/NetworkManager/system-connections/ before major changes.
• After any restart, confirm IP address, default route, DNS, and gateway reachability.
• Reserve ifup, ifdown, and systemctl restart network for legacy systems that still ship those workflows.

For risky changes over SSH, consider a NetworkManager checkpoint. It runs a command under a temporary rollback point and prompts you to commit or restore when the command finishes:

sudo nmcli device checkpoint --timeout 30 enp0s3 -- \
  nmcli connection up "PROFILE"

Omitting the device name creates the checkpoint for all NetworkManager devices. Specifying the affected interface limits the rollback scope.

Sample output:

Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/19)
Type "Yes" to commit the changes:

Type Yes to keep the change. If you do not confirm before the timeout expires, NetworkManager restores the previous configuration. Test checkpoint behaviour from a console before relying on it in production.

Summary

Match the command to the scope of the change. Reload profiles with sudo nmcli connection reload, apply live updates with sudo nmcli device reapply, reactivate one connection with sudo nmcli connection up, and escalate to device reconnect or systemctl restart NetworkManager only when narrower steps fail. Legacy network.service, service network restart, and ifup/ifdown belong on older network-scripts hosts—not on current NetworkManager-managed releases where network.service is absent.

Official references: NetworkManager documentation, nmcli(1) manual page, and RHEL networking guidance.