The WSL 2 Networking Challenge
Windows Subsystem for Linux (WSL) 2 brought incredible performance improvements and full system call compatibility to Windows developers. However, it completely changed how networking functions. Unlike WSL 1, which shared the host’s IP address, WSL 2 operates inside a lightweight Hyper-V utility VM. This means WSL 2 is assigned a dynamic IP address on a virtual NAT network that changes every time Windows reboots.
For developers running local servers, databases, or Docker containers inside WSL 2, this dynamic IP is highly frustrating. Connecting to your WSL services from Windows, or from other devices on your local network, requires checking the IP address repeatedly.
Why You Cannot Set a Truly Static IP Directly in WSL 2
Microsoft designed the WSL 2 networking stack to be ephemeral. While you can technically assign an IP address to the eth0 interface inside the Linux instance using standard ip commands, the Hyper-V virtual switch routing will not recognize it, and external traffic will not route properly. The IP address must be assigned by the Hyper-V Virtual Switch.
However, we can achieve a persistent, custom IP address by automating a script that assigns the IP to both the WSL instance and the Windows virtual network adapter immediately upon boot.
Step-by-Step: Forcing a Custom IP Address for WSL 2
This method involves creating a PowerShell script that executes automatically when Windows starts. It configures the Hyper-V virtual switch on the Windows side and the network interface on the Linux side to use a specific subnet and IP address.
Step 1: Determine Your Desired Subnet
Choose an IP subnet that does not conflict with your physical home or office network (e.g., 192.168.1.x). For this guide, we will use the 192.168.50.0/24 subnet.
- Windows Virtual Switch IP:
192.168.50.1 - WSL 2 Instance IP:
192.168.50.2
Step 2: Create the Configuration Script
Open Notepad or your preferred text editor and paste the following PowerShell script:
$wsl_ip = "192.168.50.2"
$win_ip = "192.168.50.1"
$prefix_length = 24
# Ensure WSL is running
wsl -u root -- ip addr add $wsl_ip/$prefix_length dev eth0
wsl -u root -- ip route add default via $win_ip
# Configure Windows vEthernet Adapter
Get-NetAdapter -IncludeHidden | Where-Object Name -match "WSL" | New-NetIPAddress -IPAddress $win_ip -PrefixLength $prefix_length
Save this file as Set-WslIp.ps1 in a permanent location, such as C:\Scripts\.
Step 3: Bypass Execution Policies (Optional but Recommended)
By default, Windows restricts running unsigned PowerShell scripts. To allow this specific script to run, open PowerShell as an Administrator and execute:
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
Step 4: Automate the Script on Logon
To ensure this IP is set every time you log in, we will use the Windows Task Scheduler.
- Press the Windows Key, type Task Scheduler, and open it.
- Click Create Task… in the right-hand pane.
- On the General tab, name the task “WSL Static IP” and check the box for Run with highest privileges.
- On the Triggers tab, click New…, select At log on from the dropdown, and click OK.
- On the Actions tab, click New…, and enter the following:
- Program/script:
powershell.exe - Add arguments:
-ExecutionPolicy Bypass -WindowStyle Hidden -File "C:\Scripts\Set-WslIp.ps1"
- Program/script:
- Click OK to save the task.
Port Forwarding to Expose WSL 2 to Your LAN
Now that WSL 2 has a consistent IP (192.168.50.2), you can easily map ports from your Windows host to WSL 2. If you want other devices on your Wi-Fi network to access a web server running in WSL on port 8080, run this in an Administrator PowerShell:
netsh interface portproxy add v4tov4 listenport=8080 listenaddress=0.0.0.0 connectport=8080 connectaddress=192.168.50.2
To view your active port forwards, use netsh interface portproxy show v4tov4. Remember that you may also need to open port 8080 in the Windows Defender Firewall.
Conclusion
While Microsoft’s architectural choices for WSL 2 networking prioritize isolation and dynamic allocation, you can override this behavior with automation. By locking the virtual switch to a dedicated subnet, you restore the predictability needed for serious web development and network testing on Windows 11.