Modifying the
bind-address in
/etc/mysql/mysql.conf.d/mysqld.cnf from
127.0.0.1 to
0.0.0.0 is a common but often ineffective step for resolving WSL2 MySQL connection errors. This change alone does not address the fundamental networking architecture of Windows Subsystem for Linux 2, which utilizes a dynamic NAT network. Understanding this distinction is critical before attempting complex configuration overrides that may introduce security vulnerabilities without solving the underlying connectivity problem.
The WSL2 Networking Architecture
WSL2 operates differently than its predecessor, WSL1. Instead of sharing the Windows kernel directly, WSL2 runs a lightweight utility VM with its own full Linux kernel. This means your Ubuntu instance has a private IP address assigned by Hyper-V’s internal virtual switch. When you attempt to connect to MySQL from within the WSL2 Ubuntu terminal using
localhost, it refers to the loopback interface of the WSL2 VM itself, not the Windows host. Conversely, connecting from Windows to WSL2 requires knowing the specific IP address of the WSL2 instance, which changes every time the subsystem restarts. Changing the
bind-address to
0.0.0.0 allows MySQL to listen on all available interfaces, including the private WSL2 IP, but it does not configure the firewall or routing required for external access.
Why bind-address Changes Often Fail
Many users encounter connection refused errors and assume MySQL is blocking connections because it is bound only to
127.0.0.1. While this is true for local-only access, switching to
0.0.0.0 exposes the database to the entire network segment of the WSL2 VM. If you still cannot connect after this change, the issue is rarely the binding configuration. It is typically caused by one of three factors: the MySQL service is not running, the firewall is blocking port 3306, or the client is targeting the wrong IP address. In many cases, simply restarting the MySQL service resolves transient socket issues that mimic binding problems. For more details on managing system services in WSL, see our guide on
Lost Sudo Privileges in WSL Ubuntu, as proper permissions are essential for service management.
Diagnosing the Actual Connection Path
Before modifying configuration files, verify where the connection attempt is originating. If you are trying to connect from a Windows application (like DBeaver or HeidiSQL) to MySQL inside WSL2, you must use the WSL2 IP address, not
localhost. You can find this IP by running
wsl hostname -I in PowerShell or Command Prompt. The output will be an IPv4 address like
172.x.x.x. Use this IP as the host parameter in your database client. If you are connecting from within the Ubuntu terminal,
localhost should work if MySQL is installed correctly. If the connection fails even with
0.0.0.0, check the MySQL error log located at
/var/log/mysql/error.log for specific rejection reasons.
Checking Service Status
Ensure MySQL is actively listening. Run the following command in your Ubuntu terminal:
sudo systemctl status mysql
If the service is inactive, start it with:
sudo systemctl start mysql
Verify it is listening on the expected port by running:
sudo netstat -tlnp | grep 3306
Or using the modern alternative:
ss -tlnp | grep 3306
Look for entries showing
0.0.0.0:3306 or
*:3306 if you have changed the bind address, or
127.0.0.1:3306 if you have not.
Configuring Firewall Rules
Even with correct binding, Ubuntu’s default firewall, UFW, may block incoming connections. Check the status with:
sudo ufw status
If active, allow MySQL traffic:
sudo ufw allow 3306/tcp
Note that this rule applies to connections within the WSL2 environment. For external access from Windows, Windows Defender Firewall may also need configuration, though WSL2 generally handles NAT translation automatically if the service is bound to
0.0.0.0.
Alternative: Using SSH Tunneling
A more secure and reliable method for accessing MySQL from Windows is SSH tunneling. Instead of exposing MySQL to the network, you create an encrypted tunnel through SSH. Connect to your WSL2 instance via SSH from Windows:
ssh username@localhost -L 3307:localhost:3306
Then configure your database client to connect to
localhost:3307. This approach bypasses
bind-address issues entirely and keeps MySQL bound to
127.0.0.1, enhancing security. For troubleshooting SSH connectivity issues in WSL, refer to
Troubleshooting SSH WSL Machine: Can't Connect to Localhost.
Security Considerations
Binding MySQL to
0.0.0.0 exposes it to any device on the WSL2 virtual network. Ensure you set strong passwords for MySQL root and user accounts. Disable remote root login if possible by editing the MySQL user table or using the
ALTER USER command. Regularly update MySQL to patch known vulnerabilities. Avoid exposing WSL2 ports directly to the internet unless absolutely necessary and properly secured.
Frequently Asked Questions
Does changing bind-address to 0.0.0.0 make MySQL accessible from the internet?
No, it only makes MySQL accessible within the WSL2 virtual network. The WSL2 instance is behind a NAT gateway managed by Hyper-V, so external internet access is blocked by default unless port forwarding is explicitly configured on the Windows host.
Why does my MySQL connection fail with "Access denied" after changing bind-address?
This error indicates successful network connectivity but failed authentication. Verify that the username and password are correct and that the user account allows connections from the source IP. Check the MySQL error log for detailed rejection reasons.
Can I use localhost to connect to MySQL from Windows apps in WSL2?
No,
localhost in Windows refers to the Windows loopback interface, not the WSL2 VM. You must use the WSL2 IP address obtained via
wsl hostname -I or set up an SSH tunnel to map a local Windows port to the WSL2 MySQL port.
How do I reset MySQL root password in WSL2 Ubuntu?
Stop the MySQL service, start it with
--skip-grant-tables, connect as root without a password, and use
UPDATE mysql.user to set a new password. Then restart the service normally. Refer to official MySQL documentation for version-specific syntax.
Is it safe to leave bind-address as 0.0.0.0 in production environments?
It is generally unsafe unless strict firewall rules and strong authentication are in place. For development, it is acceptable if isolated within the WSL2 network. For production, restrict binding to specific IPs or use SSH tunneling to minimize exposure.