Migrating a Linux Home Server from Wi-Fi to Ethernet Without Breaking Your Infrastructure: A Real Troubleshooting Case Study

 

 

Migrating a Linux Server from Wi-Fi to Ethernet: More Than Just Plugging in a Cable

Table of Contents

• Introduction
• The Mistake of Thinking This Is Just About a Network Cable
• Why Servers Should Not Depend on Wi-Fi
• The First Rule of Linux Troubleshooting
• Understanding the Existing Network Configuration
  • Discovering Network Interfaces
  • Identifying the Active Connection
• The Hidden Risk: MAC Addresses and DHCP
• How a Simple Interface Change Can Break Services
• Planning the Migration Before Touching the Hardware
• Creating a DHCP Reservation
• Connecting Ethernet for the First Time
• Validating Network Connectivity
  • Verifying the IP Address
  • Verifying the Default Route
  • Verifying DNS Resolution
  • Verifying Internet Connectivity
• Safely Disabling Wi-Fi
• Validating the Entire Infrastructure
  • Internal DNS
  • Nginx
  • Grafana
  • Prometheus
  • Samba
  • Jellyfin
  • Calibre-Web
• Common Failure Scenarios and Troubleshooting
• Lessons Learned
• Final Thoughts

 

At first glance, migrating a Linux server from Wi-Fi to Ethernet seems trivial.

Connect a cable.

Disable Wi-Fi.

Done.

That assumption is exactly what makes many infrastructure changes risky.

In my case, the server started as a small Fedora Server installation used primarily for experimentation. Over time, it evolved into a production-like homelab environment running:

• Grafana
• Prometheus
• Loki
• Alloy
• Jellyfin
• Calibre-Web
• Samba
• Nginx
• Internal DNS services
• Multiple Docker containers

At that point, the server was no longer a lab machine.

It had become infrastructure.

And infrastructure changes require a different mindset.

This article is not about memorizing commands.

It is about understanding how experienced Linux administrators think before making changes.

The Mistake of Thinking This Is Just About a Cable

Many beginners approach migrations like this:

Connect Ethernet
↓
Disable Wi-Fi
↓
Done

The problem is that Linux systems rarely exist in isolation.

Every component has dependencies.

A better question is:

What depends on this network interface?

That single question completely changes how you approach troubleshooting.

Why Servers Should Not Depend on Wi-Fi

Wi-Fi is designed for convenience.

Servers are designed for reliability.

When evaluating infrastructure, three characteristics matter more than anything else:

• Stability
• Availability
• Predictability

Wireless networks introduce variables that administrators cannot fully control:

• Signal strength
• Interference
• Driver behavior
• Router instability
• Latency fluctuations

Ethernet removes most of those variables.

The goal is not necessarily higher speed.

The goal is predictable behavior.

Predictability is one of the most valuable qualities in infrastructure management.

The First Rule of Linux Troubleshooting

Before changing anything, I needed to understand the current state of the system.

The first question was:

Which network interfaces exist on this server?

To answer that, I used:

ip addr

A simplified output might look like:

lo
wlp2s0
enp1s0

At this stage, no changes are being made.

We're simply collecting information.

This distinction is critical.

Good troubleshooting begins with observation, not modification.

Identifying the Active Connection

Next, I needed to determine which interface was actually being used.

For that:

nmcli device

Example output:

DEVICE      TYPE       STATE
wlp2s0      wifi       connected
enp1s0      ethernet   disconnected

This immediately answered two important questions:

1. Is Wi-Fi currently active?
2. Is Ethernet recognized by the operating system?

Both answers were yes.

Several possible troubleshooting paths could already be eliminated.

The Hidden Risk: MAC Addresses and DHCP

This is where the real challenge appeared.

Every network interface has a unique MAC address.

Example:

Wi-Fi
AA:AA:AA:AA:AA:AA

Ethernet
BB:BB:BB:BB:BB:BB

Most home routers identify devices based on MAC addresses.

Changing interfaces often means:

New MAC Address
↓
New DHCP Lease
↓
New IP Address

The migration was no longer about networking.

It was about infrastructure dependencies.

How a Simple IP Change Can Break Everything

My server was using:

192.168.15.34

That IP address was referenced throughout the environment.

Examples included:

• Prometheus scrape targets
• Internal DNS records
• Reverse proxy configurations
• Samba shares
• Documentation
• Monitoring dashboards

If the server received a different IP address, multiple services could fail simultaneously.

This is why experienced administrators think about dependencies before making changes.

Planning the Migration Before Touching the Hardware

Instead of immediately plugging in the cable, I decided to eliminate the biggest risk first.

The solution was a DHCP reservation.

The logic became:

Ethernet MAC Address
↓
DHCP Reservation
↓
192.168.15.34

Now the server would continue receiving the same IP address regardless of which interface was being used.

The most significant risk had been removed before the migration even started.

Connecting Ethernet for the First Time

Only after addressing the DHCP issue did I physically connect the cable.

Then I verified the interface status again:

nmcli device

Expected result:

DEVICE      TYPE       STATE
enp1s0      ethernet   connected
wlp2s0      wifi       connected

Ethernet was now active and operational.

Verifying the IP Address

The next question was straightforward:

Did the server receive the expected IP address?

To verify:

hostname -I

Expected result:

192.168.15.34

This confirmed that the DHCP reservation was functioning correctly.

Verifying the Default Route

An IP address alone does not guarantee connectivity.

The next step was checking the routing table:

ip route

Example output:

default via 192.168.15.1

The server knew where to send outbound traffic.

Another important dependency had been validated.

Verifying DNS Resolution

Next, I validated DNS configuration.

resolvectl status

This command reveals:

• Active DNS servers
• Search domains
• Interface associations

Only after confirming DNS configuration did it make sense to test external connectivity.

Testing Connectivity

First, I tested raw IP connectivity:

ping 8.8.8.8

Question answered:

Can the server reach the outside world?

Then I tested name resolution:

ping google.com

Question answered:

Is DNS functioning correctly?

These tests may look similar, but they validate entirely different layers of the network stack.

Safely Disabling Wi-Fi

Only after Ethernet had been fully validated did I disable Wi-Fi.

The goal was to remove unnecessary complexity.

Benefits included:

• Eliminating routing ambiguity
• Simplifying troubleshooting
• Preventing accidental fallback to wireless networking

The fewer variables a server has, the easier it becomes to diagnose problems.

Validating the Entire Infrastructure

Many administrators stop once internet access works.

That would have been a mistake.

The migration was not complete until every dependent service was verified.

Internal DNS

I tested internal hostname resolution:

grafana.home
jellyfin.home
books.home

Successful resolution confirmed that DNS services remained healthy.

Prometheus

Inside Prometheus:

Status → Targets

Expected state:

UP

If targets had suddenly become DOWN, the first suspicion would be an unexpected IP change.

Grafana

The primary question was:

Is Grafana still receiving metrics?

Healthy dashboards confirmed that data sources remained accessible.

Samba

Before checking Samba itself, I first verified basic connectivity.

Only after confirming network reachability would it make sense to investigate:

systemctl status smb

This approach prevents wasted troubleshooting effort.

Jellyfin and Calibre-Web

Finally, I verified application access through the browser.

This validated:

• Networking
• DNS
• Reverse proxy functionality
• Application availability

Common Troubleshooting Scenarios

Ethernet Receives No IP Address

Start with:

nmcli device

If the interface does not appear:

• Cable issue
• Driver issue
• Hardware issue

If the interface exists but receives no IP:

• DHCP issue
• Router issue
• Switch issue

Server Receives the Wrong IP

Verify the interface MAC address:

ip link

Compare it against the DHCP reservation.

Many "network problems" are simply configuration mismatches.

Internal DNS Stops Working

Do not immediately investigate DNS software.

Ask the simplest question first:

Did the server receive the correct IP address?

That single check often saves hours of troubleshooting.

Prometheus Targets Become DOWN

Work through the dependency chain:

1. Did the IP change?
2. Is the target service running?
3. Is Node Exporter available?
4. Is network connectivity intact?

The order matters.

The Most Important Lesson

The commands used during this migration are not advanced.

Most Linux administrators already know them.

The value was never in the commands.

The value was in the questions being asked.

Linux administration is not about memorizing syntax.

It is about understanding relationships between systems.

When you learn to see DHCP, DNS, monitoring, routing, applications, and documentation as interconnected components, troubleshooting becomes a logical process instead of trial and error.

Final Thoughts

The migration from Wi-Fi to Ethernet was completed successfully without changing the server's IP address or disrupting services.

The physical change took only a few minutes.

The real work happened beforehand.

By identifying dependencies, anticipating risks, validating assumptions, and testing each layer of the infrastructure, the migration remained predictable and controlled.

That is ultimately what Linux administration is about.

Not running commands.

Understanding systems.