Understanding the Network Architecture
WSL2 runs on a lightweight utility VM that uses Hyper-V or the Windows Hypervisor Platform. Unlike WSL1, which integrates directly with the Windows kernel, WSL2 has its own private network interface. When you bind a service to localhost or 127.0.0.1 inside WSL2, it only listens on the loopback interface within that virtual machine. Consequently, attempts to connect via localhost from Windows will fail because the traffic never reaches the WSL2 instance.
The solution involves identifying the dynamic IP address assigned to the WSL2 virtual network adapter on the Windows side. This IP changes every time WSL2 restarts unless specific configuration steps are taken. You need to discover this IP and then ensure your Windows Firewall allows inbound connections to the specific port your application is using.
Locating the WSL2 Virtual Adapter
Windows creates a virtual network adapter named "vEthernet (WSL)" when WSL2 is active. To find the IP address associated with this adapter, open PowerShell as an administrator and run the following command:
Get-NetIPAddress -InterfaceAlias "vEthernet (WSL)" | Select-Object IPAddressThis command queries the network interfaces installed in Windows and filters for the one specifically created for WSL2. The output will display the IPv4 address currently assigned to your Linux VM. Note this address down, as you will need it to establish connections from Windows applications such as browsers, database clients, or IDEs.
Configuring Windows Firewall Rules
Even if you have the correct IP address, Windows Defender Firewall may block incoming traffic on the port your service is listening on. By default, inbound connections are denied for most non-system services. You must create an explicit rule to allow this traffic.
Open PowerShell as Administrator and execute the following command, replacing <PORT> with the actual port number your application uses (e.g., 8080, 3000, or 5432):
New-NetFirewallRule -DisplayName "WSL2 Port Forwarding" -Direction Inbound -LocalPort <PORT> -Protocol TCP -Action AllowThis command creates a new inbound rule that permits TCP traffic on the specified port. It does not restrict the source IP, allowing any connection from the WSL2 VM to reach your service. If you want to restrict access only to the WSL2 VM, you can add the -RemoteAddress parameter with the IP address you found earlier. However, for most development scenarios, allowing the port broadly is sufficient and easier to manage.
Connecting from Windows Applications
Once the firewall rule is in place, you can connect to your WSL2 service using the IP address obtained in the previous step. For example, if your Python Flask app is running on port 5000 inside WSL2, and the WSL2 IP is 172.18.16.5, you would navigate to http://172.18.16.5:5000 in your Windows browser.
If you encounter connectivity issues, verify that the service inside WSL2 is binding to 0.0.0.0 instead of 127.0.0.1. Binding to 0.0.0.0 ensures the service listens on all available network interfaces within the VM, including the one connected to the Windows host. Many frameworks default to 127.0.0.1 for security reasons, so explicitly setting the host to 0.0.0.0 is a common requirement.
Handling Dynamic IP Changes
A significant challenge with WSL2 networking is that the IP address changes whenever the Linux distribution restarts. This means your hardcoded IP addresses in configuration files or bookmarks may become invalid after a reboot. To mitigate this, you can create a simple script that retrieves the current IP and updates your hosts file or connection strings dynamically.
Alternatively, you can use port forwarding utilities like netsh to map a static port on the Windows host to the dynamic port in WSL2. However, this approach is more complex and often unnecessary if you simply use the current WSL2 IP. For developers who prefer stability, consider using WSL1 for simpler networking needs, though this sacrifices performance benefits. If you experience unresponsive behavior during these operations, refer to our guide on Troubleshooting Unresponsive WSL2 on Windows 10 for deeper diagnostic steps.
Verifying Connectivity
After configuring the firewall and ensuring your service binds correctly, test the connection from Windows using telnet or Test-NetConnection in PowerShell. Run the following command to check if the port is reachable:
Test-NetConnection -ComputerName <WSL2_IP> -Port <PORT>If the TcpTestSucceeded field returns True, your connection is established successfully. If it returns False, double-check that the service inside WSL2 is actually running and listening on the expected port. You can verify this by running netstat -tuln inside WSL2 to see active listeners.
Frequently Asked Questions
Why does localhost work in WSL1 but not WSL2?
WSL1 translates Linux system calls directly to Windows NT kernel calls, sharing the same network stack as Windows. WSL2 runs a full Linux kernel in a VM, isolating its network stack. Therefore, localhost in WSL2 refers only to the VM's internal loopback, not the Windows host.
How do I make the WSL2 IP address static?
WSL2 does not natively support static IPs for the vEthernet adapter. The recommended approach is to use a startup script in WSL that detects the current IP and updates local configurations, or to rely on the firewall rule allowing all inbound traffic on the specific port regardless of the source IP.
Can I forward ports automatically on WSL2 start?
While there is no built-in auto-forwarding, you can create a PowerShell profile script that runs New-NetFirewallRule every time you open a terminal. Alternatively, use tools like wsl-port-forwarder which automate the process of mapping host ports to guest ports upon WSL initialization.
What if my Windows Firewall blocks the connection despite the rule?
Ensure that the firewall rule is enabled and set to apply to the correct network profiles (Domain, Private, Public). Sometimes, third-party antivirus software or corporate firewalls override Windows Defender settings. Check your security suite logs to see if the connection attempt was blocked at a different layer.
Is it safe to open all ports for WSL2?
Opening specific ports for known services is generally safe. Avoid creating overly broad rules that expose unused ports. Only allow traffic on ports where your application explicitly listens. Regularly audit these rules to ensure they are still necessary, especially if you change the services you run in WSL2.