Obtain the assigned address, prefix, gateway and DNS values. Record the active profile UUID, device and routes, and keep an independent console. Confirm that cloud or hosting automation will not overwrite the profile after reboot.

1. Inspect nmcli device status and nmcli connection show --active. Match the target device to its actual active profile rather than assuming an interface-name profile exists.
2. Back up or clone the relevant connection configuration through a supported method. Record existing IPv4/IPv6 methods, routes and resolver settings without exposing stored secrets.
3. Modify the intended profile using nmcli or nmtui with provider-approved values. Distinguish setting a complete list from adding one address or route.
4. Use a supported checkpoint or console-backed activation plan for the installed NetworkManager version. Apply the change through the profile workflow, expecting a management-address change to interrupt the original SSH connection.
5. Connect to the new address from an independent session and test routing and DNS. Confirm the intended profile has the appropriate autoconnect behavior and no competing profile will take over.

Before editing an AlmaLinux or Rocky Linux network address, inspect NetworkManager from an authorised shell. Replace ens3 with the actual interface name shown by the first command. This example reads configuration and does not disconnect or reactivate a profile.

nmcli device status
nmcli connection show --active
nmcli -f GENERAL,IP4,IP6 device show ens3

Read the result: Match the active interface to its connection profile, then record the current addresses, gateways and DNS servers. A connection profile name may differ from the interface name. Editing an inactive profile can leave the running address unchanged and produce a surprise after reboot.

Use the provider-assigned address, prefix and route for the planned change. Arrange independent console access before activating a modified management profile. Keep the recorded original profile and address data available so you can recover the existing connection if the new route is wrong.

You may be viewing saved profile values while the device still has an older active configuration, or another profile may own the device. Compare both states and apply the intended profile deliberately.

Inspect both the saved profile and current device state. Test permitted inbound access, outbound connections and any private routes. During an approved maintenance window, confirm the profile persists after restart.

If activation fails, read NetworkManager logs and restore the saved working profile through the console. Do not issue a connection-down command on the only management path without recovery access. On modern releases, avoid editing obsolete network-scripts files that are no longer the active configuration owner.

• Separating DNS failure from network failure on Linux
• Recovering from an SSH lockout using the server console
• Managing firewalld zones and permitted services
• Updating AlmaLinux or Rocky Linux safely with DNF

• networkmanager.dev: Nmcli
• networkmanager.dev: Nm Settings Nmcli