Force Ethernet First on Windows 10 and 11: The Forgotten Interface Metric Tweak That Keeps Wi‑Fi in Check

Windows 10 and 11 still harbor a networking secret that can give Ethernet the absolute priority it deserves over Wi‑Fi—and it is buried inside an arcane setting called the interface metric. While the modern default for most Windows installations is to let the operating system automatically decide which network adapter to use, the algorithm often leaves Wi‑Fi as the primary gateway even when a gigabit Ethernet cable is plugged in firmly. The result? Unnecessary latency, slower file transfers, and a general sense that your router’s wired port is being ignored. For power users who manage local servers, stream high‑bitrate video, or simply demand the lowest possible ping for online gaming, manually lowering the Ethernet adapter’s metric is the single most reliable method to tell Windows: “This connection matters more.”

This article dissects the interface metric, explains why it still matters in an era of Wi‑Fi 6E and 7, and provides step‑by‑step guidance for both the graphical interface and PowerShell. The technique applies equally to Windows 10 and Windows 11, and once set, the priority remains in effect across reboots, sleep cycles, and even driver updates. No third‑party software is required.

What Is an Interface Metric and Why Does It Matter?

The interface metric is a numerical weight that the Windows TCP/IP stack assigns to every network adapter on your PC. Think of it as a cost value: the lower the number, the cheaper the route, and the more preferred that adapter becomes when the system must decide which default gateway to use for outbound traffic. Windows automatically computes a metric based on the link speed and other heuristics—for example, a 1 Gbps Ethernet adapter typically receives a metric around 25, while Wi‑Fi often lands at 55 or higher. But these automatic values can be misleading in real‑world scenarios because the algorithm does not consider factors like congestion, signal stability, or jitter.

The critical detail is that Windows always routes packets through the interface with the lowest metric that can reach the destination. If your Ethernet and Wi‑Fi are both connected to the same subnet (a common home setup), the one with the smaller metric wins for all internet‑bound traffic. By manually setting the Ethernet metric to a value much lower than the Wi‑Fi metric, you create an unbreakable preference that survives any dynamic reordering Windows tries to perform.

Why Automatic Selection Fails

Microsoft’s automatic metric calculation is far from perfect. It assigns a value using the formula: Metric = 1 / (Link Speed in Mbps) * 1000. For a 100 Mbps link, that gives 10; for 1000 Mbps, it gives 1. The problem is that this calculation is often overridden by vendor‑specific logic or altered by virtual adapters (Hyper‑V switches, VPN clients, and loopback interfaces) that can inject their own low metrics. Worse, the automatic metric is recalculated on connection events, meaning a Wi‑Fi disconnect and reconnect might temporarily drop the Wi‑Fi metric below Ethernet, suddenly routing all traffic over wireless until the next recalculation.

Users consistently report that Windows 10 and 11 still prefer Wi‑Fi even when Ethernet is connected, especially after resuming from sleep or when the Wi‑Fi network is marked as “private.” This is not a bug but an intentional design choice: Microsoft believes that most users want to stay on Wi‑Fi for mobility, and the system assumes a simultaneous Ethernet connection is for a different network. In an enterprise environment, where wired and wireless often lead to the same corporate LAN, this behavior causes confusion and support tickets. The manual metric adjustment is the IT pro’s answer.

How to Set the Ethernet Metric via the GUI

The most approachable way to adjust the metric is through the classic Network Connections panel. Here’s how:

1. Press Windows + R, type ncpa.cpl, and press Enter.
2. Identify your Ethernet adapter—usually named “Ethernet” or something vendor‑specific like “Intel(R) Ethernet Connection I219‑V.”
3. Right‑click the adapter and choose Properties.
4. Select Internet Protocol Version 4 (TCP/IPv4) and click Properties.
5. Click the Advanced button, then uncheck Automatic metric.
6. In the Interface metric field, enter a low number. The best practice is to use 1 for Ethernet and leave Wi‑Fi on automatic (which will assign a value of 55 or higher), ensuring Ethernet always wins.
7. Click OK on all dialogs to save.

Repeat the same steps for Internet Protocol Version 6 (TCP/IPv6) if you use IPv6—which you almost certainly do, as modern browsers default to IPv6 when available. Forgetting IPv6 is one of the most common reasons the tweak “didn’t work” after a restart.

After applying the changes, you can verify the metric immediately. Open a Command Prompt and run:

netsh interface ip show interfaces

Look for the “Metric” column next to each interface. Your Ethernet should now show 1.

PowerShell: The One‑Liner That Rules Them All

For those who prefer automation or need to deploy the setting across dozens of machines, PowerShell’s native module NetTCPIP provides the ultimate precision. The following commands set both IPv4 and IPv6 metrics for the Ethernet adapter. Replace Ethernet with the exact name of your adapter if it differs.

# Set IPv4 metric to 1
Set-NetIPInterface -InterfaceAlias "Ethernet" -AddressFamily IPv4 -InterfaceMetric 1

Set IPv6 metric to 1

To disable the automatic metric for all adapters at once and apply custom values, you can use:

Get-NetIPInterface | Where-Object { $.ConnectionState -eq "Connected" } | Set-NetIPInterface -AutomaticMetric Disabled

Then manually assign metrics based on adapter type:

# Ethernet adapters get metric 1
Get-NetAdapter | Where-Object { $.MediaType -eq "802.3" } | ForEach-Object { Set-NetIPInterface -InterfaceIndex $.ifIndex -AddressFamily IPv4 -InterfaceMetric 1; Set-NetIPInterface -InterfaceIndex $.ifIndex -AddressFamily IPv6 -InterfaceMetric 1 }

Wi‑Fi adapters get metric 50

These commands target all Ethernet and Wi‑Fi adapters without needing to know their names, making them ideal for deployment scripts.

What About the Old "Route" Command?

Seasoned administrators remember the route command used to manipulate the routing table directly. While you can still add a persistent route with a lower metric for Ethernet, it is far less elegant and does not affect all traffic uniformly. Forcing the interface metric at the IP layer is the correct, modern approach because it influences every route that uses the interface, not just specific destination networks.

If you are still using netsh, the old equivalent is:

netsh interface ip set interface "Ethernet" metric=1

But this only sets the metric for IPv4. PowerShell is the way forward.

Verification: Ensure the Change Sticks

After setting the metric, it is crucial to confirm that Windows actually respects your manual override. Two commands give the full picture:

Get-NetIPInterface -AddressFamily IPv4 | Select-Object InterfaceAlias, InterfaceMetric, AutomaticMetric

This lists all adapters, their current metrics, and whether automatic metric is enabled. You should see your Ethernet adapter with InterfaceMetric = 1 and AutomaticMetric = Disabled.

To test real‑world routing priority, open PowerShell and run:

Find-NetRoute -RemoteIPAddress 8.8.8.8 | Select-Object IPAddress, InterfaceAlias, RouteMetric

The interface with the lowest RouteMetric (which is a combination of the interface metric and the specific route metric) is the one Windows uses to reach 8.8.8.8. It should show your Ethernet adapter.

Finally, perform a live traceroute:

tracert 8.8.8.8

The first hop should be your Ethernet gateway, not your Wi‑Fi router IP.

Troubleshooting Common Gremlins

• IPv6 Is Still Winning: Even after setting IPv4 metric to 1, Windows may prefer IPv6 over Wi‑Fi because IPv6 has its own separate metric. Always set both protocols.
• Virtual Adapters Interfere: VPN clients and virtual switches often inject routes with a metric of 1. If a VPN is active, its virtual adapter may override your Ethernet setting. Disconnect the VPN or adjust its metric as well.
• Group Policy or MDM Override: In domain‑joined machines, a Group Policy Object (GPO) might be enforcing a custom metric policy. Run gpresult /r and look for network‑related policies.
• Driver Updates Reset the Metric: Rarely, a major driver update can reset the interface properties. If your Ethernet preference vanishes after a driver install, simply re‑apply the PowerShell commands.
• Adapter Renaming: If you use PowerShell by alias, ensure the adapter name has not changed. Wi‑Fi adapters sometimes rename themselves after driver updates.

Real‑World Impact: What Do You Gain?

On the surface, the improvement might seem subtle—but for anyone who handles large file transfers across the LAN or relies on low‑latency connections for remote desktop, the difference is night and day. An Ethernet connection, even a 100 Mbps one, provides consistent sub‑millisecond jitter, whereas Wi‑Fi can introduce spikes of 10‑50 ms depending on interference. By forcing Windows to route through the wired interface, you eliminate those unpredictable delays.

Gamers benefit from a stable ping that does not fluctuate when a microwave oven or neighboring Wi‑Fi network springs to life. Video editors working on network‑attached storage see sustained throughput without the Wi‑Fi driver periodically scanning for networks. And for IT administrators managing headless servers in a mixed wired/wireless environment, the manual metric adjustment is a one‑time fix that prevents help‑desk calls about “slow RDP sessions.”

The Automated Alternative: PowerShell Script at Boot

To make the setting bulletproof, you can create a scheduled task that runs at system startup to reapply the metric. This guards against any unforeseen changes. Use Task Scheduler to trigger the following script with highest privileges:

$ethernet = Get-NetAdapter | Where-Object { $.MediaType -eq "802.3" -and $_.Status -eq "Up" } | Select-Object -First 1
if ($ethernet) {
    Set-NetIPInterface -InterfaceIndex $ethernet.ifIndex -AddressFamily IPv4 -InterfaceMetric 1
    Set-NetIPInterface -InterfaceIndex $ethernet.ifIndex -AddressFamily IPv6 -InterfaceMetric 1
}

Set the task to run at system startup with the SYSTEM account, and you never have to think about it again.

The Bigger Picture: Windows Network Stack Evolution

Microsoft has long been aware of user frustration over network priority. In Windows 10 version 1809, the company introduced a new “Network List Manager” logic that was supposed to prefer Ethernet when both connections led to the same DNS suffix. Yet, forum threads and Reddit posts prove that the feature does not work consistently—especially in home environments where the Wi‑Fi and Ethernet use the same router IP range. The manual metric approach bypasses all that heuristic guesswork and simply hands control back to the user.

With Windows 11, the networking stack remained largely unchanged, and the same manual metric technique applies without modification. The upcoming Windows 11 24H2 update does not alter this behavior; in fact, the graphical method through ncpa.cpl continues to be a hidden gem that many IT professionals rely on daily.

Final Thoughts

Setting the interface metric is not a hack—it is a documented, supported feature of the Windows networking stack. It exists precisely for the scenario when you want to enforce a strict priority. For the vast majority of desktop users who dock their laptop at a desk with Ethernet, this tweak eliminates the need to manually disable Wi‑Fi every time they connect a cable. It is the kind of small, persistent quality‑of‑life improvement that exemplifies the power‑user ethos.

No registry hacks are needed, no third‑party utilities are required, and the change is fully reversible by simply clicking “Automatic metric” again. If you have ever stared at a spinning loading icon while your Ethernet cable dangled unused, take two minutes to apply the metric tweak. Your network stack will thank you with every byte it sends through copper instead of air.