Moving My Pi-hole to Ethernet: The Checks That Made the Migration Complete

During routine maintenance, my Raspberry Pi stopped connecting over Wi-Fi, and Pi-hole became unavailable. I did not establish which update or setting caused the failure. What I did decide was that household DNS should move to Ethernet rather than continue depending on that wireless connection.

I completed the migration on September 26 using the same Raspberry Pi Zero 2 W. The new connection was a Micro-USB OTG Ethernet adapter and a CAT 5 cable to the switch. The adapter went into the port labeled USB; the existing power connection stayed in PWR IN.

The original project notes explain the DNS filtering setup and its maintenance workflow. This change was about the network connection underneath it, with a few client-side assumptions that also needed attention.

First, prove the wired path

Seeing a wired client appear in the router was an early check. It did not tell me whether Pi-hole could answer requests or whether the rest of the network was actually using it.

I identified the Ethernet interface and its address, checked the route, and tested SSH and DNS. The wired interface had its own MAC address, so it needed the correct DHCP reservation. The router continued handling DHCP; there was no reason to turn on another DHCP server inside Pi-hole.

Only after Ethernet worked did I disable Wi-Fi. I then reconnected and checked the service again. This gave me a clear active path instead of leaving both interfaces available and guessing which one a successful connection had used.

The router’s DHCP settings were updated to advertise the wired Pi as the DNS server. On the Mac, I renewed the network configuration and checked the resolver it had actually received. A saved router setting and a client using that setting are separate observations. I wanted both before considering household DNS migrated.

I also kept rollback instructions in the runbook: take Pi-hole out of the household DNS path, restore the router’s fallback DNS settings, renew affected client leases, and verify ordinary browsing before troubleshooting further.

The shortcut that still pointed backward

One leftover was on the Mac rather than the Pi. My OpenSSH shortcut had the old wireless address hard-coded in its configuration. Ordinary hostname resolution could find the wired Pi, but the shortcut was still steering SSH toward the previous address.

The maintenance script made this more confusing because it resolved the hostname independently of the OpenSSH alias. It could work while the familiar SSH command still failed. Those two results were consistent once I checked how each connection selected its destination.

I updated the shortcut and tested that exact command against the wired address. Host-key verification stayed enabled. The migration did not require treating an identity warning as an inconvenience to bypass.

That repair was specific to the Mac I checked. Another computer with its own SSH configuration would need its own inspection. Changing the server’s connection does not update every client’s saved assumptions.

The final verification included a controlled reboot. Afterward, the Pi retained its reserved wired address, its default route used Ethernet, and Wi-Fi remained disabled. Trusted SSH worked. Local and network DNS queries succeeded over UDP and TCP, a test domain was blocked, and an external HTTPS request succeeded. The admin endpoint responded, and the service checks found no failed system services.

Those results support a completed migration and a working service immediately afterward. They do not establish months of stability, or prove that every household device was checked. My notes explicitly leave long-term behavior and an additional client check unresolved.

I recorded the new connection and the repaired SSH shortcut in the runbook. The follow-up is to watch for dropouts during ordinary use and check any other computer whose saved shortcut still assumes the old address. The next troubleshooting session should start with those recorded facts instead of rediscovering which connection the Pi uses.