A Netplan Wi-Fi block can be syntactically valid and still be wrong for a particular Ubuntu Server. The two values that cannot safely be copied from an example are the interface name and the renderer.

A configuration that names wlp2s0 assumes the machine actually has an interface with that name. Setting renderer: networkd assumes the installation is intended to use systemd-networkd; for Wi-Fi, that backend also relies on wpa_supplicant. Other installations may already be managed by NetworkManager.

The reliable sequence is inspection first, configuration second.

Identify the wireless interface before writing YAML

Linux interface names vary with hardware and naming policy. A Wi-Fi device might appear as wlan0, wlp2s0, wlp3s0, or another wl... name.

Start with:

ip link

For more detail:

sudo lshw -C network

If the expected wireless interface does not appear, editing Netplan is premature. Check whether the kernel sees the adapter and whether firmware failed to load:

lspci -k | grep -A3 -i network
lsusb
sudo dmesg | grep -i -E 'wifi|wlan|firmware|iwlwifi|rtl|brcm'

A radio can also be blocked independently of Netplan:

rfkill list
sudo rfkill unblock wifi

The interface name found here is the name that belongs under wifis:. Do not substitute wlan0 or wlp2s0 merely because an example uses it.

Inspect the existing Netplan state

Netplan reads YAML from /etc/netplan/. Multiple files can contribute to the effective configuration, so looking at only one file can hide an existing renderer or device definition.

Inspect both the files and the merged state:

ls -l /etc/netplan/
sudo netplan get

Also check which network service is active:

systemctl is-active systemd-networkd
systemctl is-active NetworkManager

An active service alone does not prove that it owns a particular interface, but these checks reveal the environment before a renderer is changed.

This distinction matters because Netplan is a configuration abstraction. It generates configuration for a backend such as systemd-networkd or NetworkManager; it is not itself the process that associates with the access point.

A valid networkd Wi-Fi definition has a dependency

For a server intentionally using systemd-networkd, a minimal DHCP configuration can look like this:

network:
  version: 2
  renderer: networkd
  wifis:
    wlp2s0:
      dhcp4: true
      access-points:
        "ExampleSSID":
          password: "replace-with-the-real-passphrase"

The YAML structure is valid, but wlp2s0 is only correct if that interface exists.

There is another important boundary: systemd-networkd does not implement Wi-Fi association by itself. Netplan’s networkd backend requires wpa_supplicant for Wi-Fi support. Verify that the required component exists instead of treating a valid YAML document as proof that the machine can associate:

dpkg -l wpasupplicant

If it is missing and the server currently has another working network path, install it through the package manager:

sudo apt update
sudo apt install wpasupplicant

Changing the renderer merely to make an example match the machine is usually the wrong direction. Preserve the backend already intended by the installation unless there is a concrete reason to migrate it.

NetworkManager changes the operational path

If the system is already managed by NetworkManager, keep that ownership explicit:

network:
  version: 2
  renderer: NetworkManager
  wifis:
    wlp2s0:
      dhcp4: true
      access-points:
        "ExampleSSID":
          password: "replace-with-the-real-passphrase"

NetworkManager also exposes Wi-Fi discovery and connection management through nmcli:

nmcli device status
nmcli radio wifi on
nmcli device wifi list
sudo nmcli device wifi connect "ExampleSSID" password "replace-with-the-real-passphrase"

That is useful when interactive discovery is preferable to manually entering an SSID. A successful nmcli connection also creates connection state managed by NetworkManager, so avoid simultaneously maintaining competing definitions for the same interface without a deliberate design.

Validate before applying remotely

Network configuration has an unusual failure mode: a syntax or routing mistake can remove the SSH path used to repair it.

Run the parser and generator first:

sudo netplan generate

When changing networking over SSH, prefer:

sudo netplan try

netplan try applies the configuration with a confirmation mechanism and can roll it back when it is not confirmed. That makes it safer than immediately committing an untested remote-network change.

After validation, apply the configuration:

sudo netplan apply

Then inspect state rather than relying only on the absence of an error:

ip address
ip route
sudo netplan status

Test the layers separately:

ping -c 3 1.1.1.1
ping -c 3 ubuntu.com

If an IP address works but a hostname does not, the problem is no longer basic Wi-Fi association; DNS configuration becomes the next boundary to inspect.

File permissions matter when credentials are stored in YAML

A Wi-Fi passphrase placed directly in Netplan YAML is sensitive configuration. Restrict the file so ordinary local users cannot read it:

sudo chown root:root /etc/netplan/01-wifi.yaml
sudo chmod 600 /etc/netplan/01-wifi.yaml

Use the actual Netplan filename on the machine rather than creating 01-wifi.yaml blindly. Existing installer or cloud-init files may already define the device.

This is also a reason to inspect all files under /etc/netplan/ before adding another one. Netplan combines configuration, and a second definition can produce behavior that is harder to reason about than a single intentional source.

Static addressing should be added only after association works

A static address introduces routing and DNS variables that are independent of Wi-Fi authentication. Establish the wireless link with DHCP first when diagnosing a new setup. Once association and DHCP are known to work, a static definition can be introduced deliberately:

network:
  version: 2
  renderer: networkd
  wifis:
    wlp2s0:
      dhcp4: false
      addresses:
        - 192.168.1.50/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8
      access-points:
        "ExampleSSID":
          password: "replace-with-the-real-passphrase"

The address, prefix, gateway, and DNS servers must match the local network. Copying 192.168.1.50 from an example can create an address conflict or place the host on the wrong subnet.

Treat Netplan examples as schemas, not machine-specific answers

The useful part of a Netplan example is its structure. Interface names, renderers, addresses, gateways, SSIDs, and credentials belong to the target machine and network.

For Ubuntu Server Wi-Fi, the diagnostic order is more important than any single YAML snippet: confirm that the adapter exists, identify its real interface name, inspect the effective Netplan configuration, determine the intended renderer, verify the renderer’s Wi-Fi dependency, validate the generated configuration, and only then apply it.

That sequence separates hardware detection, radio state, backend ownership, Wi-Fi association, IP configuration, routing, and DNS. When a connection fails, each boundary can be tested independently instead of replacing the entire configuration with another guessed example.

Linux Ubuntu Server Netplan Wi-Fi