Server throws "Unable to determine default interface" and I have lost the web UI — what is it actually complaining about?

It is asking for a default route, and you almost certainly do not have one. The phrase "default interface" means "the interface the default route points out of", and if there is no default route there is no answer to give.

On a console, print the routing table. If there is no line for the default destination, that is the whole problem and everything else follows from it.

Why creating a bridge does this, specifically. This is the single most common way to end up here and it catches everyone once.

Before: your physical interface holds the address, the netmask and the gateway, and the gateway installs a default route.

When you build a bridge for virtual machines, the physical interface must become a plain member of the bridge with no address of its own, and the bridge takes over the address, the netmask and the gateway. What tends to happen instead is that the bridge gets created and given an address, the physical interface keeps its old address too, and the gateway ends up attached to neither properly — or to an interface that is now enslaved and cannot route.

Result: two interfaces with addresses, no default route, and a system that cannot answer the question "which interface do I send outbound traffic through".

Fixing it from the console. Most of these systems have a console menu with a network configuration option, and this is what it is for. Reconfigure so that:

• the physical interface is a bridge member with no address
• the bridge holds the static address and netmask
• the default gateway is set once, at the system level, and points at your router

Apply, then print the routing table again and confirm a default route exists pointing out of the bridge.

Why the web UI is gone and why that is a symptom rather than a second problem. If the address moved to an interface that is not correctly up, or nothing has a route back to your subnet, the UI is listening but unreachable. It will come back with the route. Do not go debugging the web service.

The one trap to avoid. These systems usually apply network changes with a test-and-revert timer — the new config is applied, and if you do not confirm it within a couple of minutes it rolls back, precisely so that a bad change over the network does not lock you out. On a console that safety net feels like the machine undoing your fix for no reason. Confirm the change when prompted, and prefer doing all of this from the physical console rather than over the network you are currently reconfiguring.

Adding the DHCP variant, because it produces the identical error from a different direction.

If the interface was on DHCP and you switched it to static — or built the bridge and the bridge came up on DHCP with no server answering on that path — you get an address but no gateway, and therefore no default route. Same message.

So the check is not "do I have an IP address", it is specifically "do I have a default route". Those are different questions and the first one being yes tells you nothing.

If you set a static address anywhere in this process, make absolutely sure you also set the gateway. Half the network configuration forms in the world let you save one without the other.

Before you touch anything else: export your configuration to a file and get it off the machine, assuming you can still do that from the console.

Network surgery on a headless box is where people end up doing a fresh install. Having a current config export turns that from a weekend into an hour.

Also, if this box runs virtual machines or containers with their own network settings, note that fixing the host's routing may not fix theirs — a guest pointed at a gateway that no longer exists on the bridge will still be isolated after the host is healthy.