WireGuard not starting after reboot usually needs a startup-state investigation before a routing change. Identify the intended interface and its systemd unit, distinguish disabled from failed, read the first relevant error, and repair only that cause before scheduling another boot test.

Key Takeaways:

Keep provider console access independent of the tunnel being repaired.

Enabled is a boot policy; active is a current service state.

A healthy unit with broken traffic belongs to a different diagnostic branch.

Where should you start with WireGuard not starting after reboot?

This procedure covers Ubuntu 24.04 LTS, distribution WireGuard tools, and a native wg-quick@wg0 service. It follows official documentation and has not undergone a complete author end-to-end test. The checks describe what you should observe, not author-recorded results. The self-hosting maintenance framework helps separate host ownership from client configuration.

Have sudo access and a verified provider console or another administrative path outside wg0. Record the incident time, expected interface, previous working boot, and any configuration or package change. Do not repeatedly reboot a shared host or stop unrelated services. If you cannot reach a recovery console, stop before operations that may replace the only management route.

An existing wg0 with fresh peer handshakes but no application access belongs to the connected-without-internet routing checks. Restarting a working unit can hide the distinction and interrupt other devices. First establish whether the interface failed to appear, failed during setup, or is working while a downstream layer fails.

Step 1: Read wg-quick systemd state without exposing keys

On the affected server, run the following checks individually. A nonzero exit from a state query is evidence to interpret, not a reason to blindly execute the next repair:

sudo systemctl is-enabled wg-quick@wg0
sudo systemctl is-active wg-quick@wg0
sudo systemctl is-failed wg-quick@wg0
sudo systemctl status --no-pager wg-quick@wg0
ip -brief link show wg0
sudo wg show interfaces

Check the unit name against the actual interface. wg-quick@home0 reads a different file from wg-quick@wg0; a correctly enabled wrong instance cannot start your intended interface. Ubuntu explicitly exposes interface lifecycle through the instance name.［1］

Observation	Meaning	Next action
Disabled and inactive	Boot activation is not configured for this instance	Confirm ownership before enabling it
Enabled and failed	Boot requested a start, but setup failed	Read this boot's first relevant error
Enabled and active, interface present	Lifecycle may be healthy	Test peers and then route/application layers
Active (exited) with interface present	A oneshot unit can remain active after setup exits	Inspect unit type and interface rather than expecting a daemon PID
Interface present, unit inactive	Another process or manual action may own it	Reconcile ownership before starting a second manager

Systemd Type=oneshot with RemainAfterExit=yes can represent completed setup as active after the command exits. WireGuard's Linux data path does not need a long-running wg-quick process. Conversely, an active status alone is not proof that all desired networking is correct.［2］

Step 2: Find the first failure and the actual owner

Read logs for the failed boot and inspect the packaged unit plus any local overrides:

sudo journalctl -b -u wg-quick@wg0 --no-pager -n 100
sudo systemctl cat wg-quick@wg0
sudo systemctl show wg-quick@wg0 -p FragmentPath -p DropInPaths -p Type -p RemainAfterExit

These views can reveal infrastructure names, hook arguments or errors containing configuration text. Review them privately and redact before sharing. Never add a command that prints the full private-key configuration merely because it would simplify a support report. If the failed boot is the previous boot, select its journal explicitly rather than assuming the current boot still contains the incident.

Look for the first failed command in that invocation: missing file, malformed key, address conflict, unavailable helper, DNS lookup failure, or an unsuccessful PostUp. Later cleanup errors may be consequences. Record the exact unit and error category; do not publish credentials copied into hooks.

Confirm who manages the interface. A panel, NetworkManager, a container or a manual wg-quick up can conflict with the native unit. Do not stop another manager as a guess. If its ownership is intentional, leave this procedure and use that manager's lifecycle documentation. If a migration changed the host or interface names, reconcile them with the migration configuration inventory before editing the unit.

Step 3: Check WireGuard config persistence and dependencies

For this instance, wg-quick expects /etc/wireguard/wg0.conf. Verify the file and directory metadata without printing the secret contents:

sudo stat -c '%U:%G %a %n' /etc/wireguard /etc/wireguard/wg0.conf
sudo test -s /etc/wireguard/wg0.conf
command -v wg
command -v wg-quick
command -v resolvectl

Use root ownership and restrictive permissions: directory 0700, file 0600, unless an independently reviewed management policy requires another arrangement. A missing or empty file needs recovery from a trusted backup, not a permissions change. Preserve the previous file under a unique protected name before any edit.

Open it with sudoedit through your trusted console. Check the interface name, the existing address, key formatting, peer public keys, and hook commands. A private key must be a valid locally generated value, not a documentation placeholder. Do not regenerate the server key as a generic startup repair; that would also require coordinated client identity changes.［3］

Check SaveConfig: if true, shutdown can have replaced file edits with live settings. Reconcile the intended file with the last known live inventory before adopting a file-managed configuration with the setting absent or false. A saved backup may predate revocations; remove those identities before bringing it back into service.［3］

Could DNS or a hook block startup?

A hostname Endpoint needs a working resolver during setup. Inspect the host's resolver service and resolve only your authorized endpoint using the usual local tools, such as getent ahosts YOUR_ENDPOINT_NAME. Compare the result with the intended endpoint; an arbitrary public name resolving successfully proves little about this specific dependency. The Endpoint resolution explanation separates initial resolution from later peer roaming.

Ubuntu commonly uses systemd-resolved; wg-quick's DNS= helper requires resolvconf rather than automatically configuring resolved. Check which mechanism your file actually uses. Ubuntu documents resolvectl hooks as one option, with the interface-specific DNS policy reviewed explicitly. Do not add DNS= and several competing resolver managers together, or suppress a failed hook with unconditional success.［1］［3］

Network ordering can help a known dependency, but network-online.target does not guarantee that every DNS service or remote endpoint is reachable. Inspect the distribution unit and actual wait-online implementation before a narrow override. Do not mask dependencies, add unlimited sleep loops, disable the firewall, or clear every route to make the red status disappear.

Step 4: Make the smallest repair, then start once

Choose the action supported by the evidence. A disabled, otherwise working instance can be enabled after you confirm it is the intended owner. A missing configuration can be restored from its trusted backup with current revocations applied. A bad hook needs its helper or syntax corrected. A malformed unit override needs its own narrow repair; changing peer keys will not fix it.

If unit or drop-in files changed, reload systemd's unit definitions. A configuration-only change does not need daemon-reload. Then attempt one controlled start of an inactive interface:

sudo systemctl daemon-reload
sudo systemctl start wg-quick@wg0
sudo systemctl is-active wg-quick@wg0
sudo wg show wg0 latest-handshakes

The first line applies only to the unit-change branch. If the unit is already active, do not use this block as a substitute for deciding whether a peer-only reload or a maintenance restart is appropriate. A start failure returns you to its new journal evidence; do not continue into repeated restarts.

After successful manual startup and application checks, set boot policy if required:

sudo systemctl enable wg-quick@wg0
sudo systemctl is-enabled wg-quick@wg0

enable configures future activation and does not by itself prove that a failed service now runs. Capture the previous enablement state so recovery can restore it. Clearing a failed marker also does not repair the failed command.［1］［2］

Step 5: Which checks make an authorized reboot meaningful?

Confirm the recovery console, trusted backup, and the repaired unit's current behavior first. Obtain permission to reboot that specific host if you do not already control its maintenance window. A container restart is not evidence for the host's boot lifecycle.

Check method	Expected observation	Failure action
Read enabled/active/interface before reboot	Intended owner starts the intended interface	Resolve ownership or startup error first
Reboot in the authorized window; query the same unit	Interface appears and no setup failure is logged	Use the console and inspect this boot's journal
Authorized client initiates permitted traffic	New handshake and required service response	Separate key, endpoint and forwarding causes
Recheck file and revoked peer inventory	Intended configuration persists without old identities	Inspect SaveConfig or an external writer
Repeat independent administration access	Recovery path still works	Stop acceptance and restore management first

When wg0 is healthy, test only the traffic scope you intended. For an internet-exit configuration, verify the client's selected public exit as described below; check DNS, IPv6 and tunnel-disconnect behavior separately. A private-service split tunnel does not require its browser IP to change. Do not claim that reboot success provides a traffic-blocking policy.

Use the public IP check from the actual client application path, not from the server's browser. If handshakes recover but traffic remains broken, return to the routing branch rather than undoing a now-correct startup repair.

Step 6: Restore the last trusted startup configuration

If the repair introduces a regression, use the independent console. Stop only this unit if necessary, restore the specific changed file or drop-in from its protected copy, reapply later credential revocations, and reinstate its recorded ownership and permissions. Run daemon-reload only if unit definitions were restored. Restore prior boot enablement as appropriate, then start once and repeat the required checks.

With an active SaveConfig policy, a stop could overwrite an edited file; restore the trusted file after stopping, and reconcile that policy before another startup. Do not delete vendor units, remove unrelated drop-ins, flush firewall rules, or restore the whole host just to reverse one configuration change. If the first recovery attempt fails, preserve the error and keep the service unavailable rather than opening access broadly.

A similar separation of binary, configuration and unit ownership matters for the Xray upgrade and rollback workflow, although its commands are different. Once service has recovered, assess the ongoing responsibilities of a self-managed exit if maintaining boot dependencies is becoming the larger task.

Summary

Classify disabled, failed and active states before choosing a repair.
Preserve independent management and trusted configuration with current revocations.
Verify a real authorized host reboot and application behavior separately.

FAQ

Why is the unit enabled but not running?

Enablement describes future activation, not its success. Read the current boot's journal to identify which setup command failed before changing network settings.

Is active (exited) an error?

For a oneshot unit with RemainAfterExit, that state can be normal. Check the unit definition, interface and peer traffic instead of expecting a persistent process.

Should I enable wg-quick@wg0 on every server?

Enable only the instance that owns your intended interface. Systems managed by a panel, NetworkManager or a container need their own lifecycle configuration.

Can DNS break startup even when the key is correct?

A hostname Endpoint or resolver hook can fail independently of keys. Inspect that dependency and its actual management mechanism before rotating credentials.

Does daemon-reload apply a WireGuard peer edit?

Daemon-reload rereads systemd unit definitions. Apply peer-file changes through the appropriate interface reload; address and hook changes may require a controlled restart.

Can I reboot until the service starts?

Repeated boots do not identify the failed prerequisite and can disrupt others. Repair the first relevant error and test one authorized reboot with a recovery console.

What if the recovered backup contains a revoked peer?

Remove later-revoked identities before applying the restored configuration. A technically valid old backup must not override subsequent access-control decisions.

Sources:

Ubuntu — Common tasks in WireGuard VPN — https://ubuntu.com/server/docs/how-to/wireguard-vpn/common-tasks/
Ubuntu Noble — systemd.service(5) — https://manpages.ubuntu.com/manpages/noble/man5/systemd.service.5.html
Ubuntu Noble — wg-quick(8) — https://manpages.ubuntu.com/manpages/noble/man8/wg-quick.8.html

Sources checked 11 October 2026.

Related Articles:

WireGuard Not Starting After Reboot: Service Checks