Database Connection Refused After Server Migration — Real Fixes

1. Bind Address Still Points to Old Server or Localhost

This is the #1 cause I see. You move your app to a new server, but the database itself is still listening only on localhost or the old IP. The app tries to connect to the new server's IP, but MySQL/MariaDB/PostgreSQL says "nope, I only talk to localhost."

For example: you had MySQL on server A with IP 192.168.1.10, then you move to server B with IP 10.0.0.5. You update your app config to point to 10.0.0.5, but MySQL's config file still says bind-address = 127.0.0.1 or bind-address = 192.168.1.10. Connection refused.

Fix it:

1. Open your MySQL config file. On Ubuntu/Debian it's /etc/mysql/mysql.conf.d/mysqld.cnf. On RHEL/CentOS it's /etc/my.cnf.
2. Look for bind-address. Change it to 0.0.0.0 to listen on all interfaces, or set it to the new server's IP directly. If the line is commented out, uncomment it.
3. Restart MySQL: sudo systemctl restart mysql.
4. Test from the app server: mysql -u youruser -h new-server-ip -p. If that works, you're good.

Pro tip: If you're using Docker, check the container's network — it might be binding to the wrong interface too. I had a client last month whose entire print queue died because of this after a Docker migration.

2. Firewall Blocking the Database Port

Even if the database server is listening correctly, the firewall on the new server might block the port (3306 for MySQL/MariaDB, 5432 for PostgreSQL). Or the network firewall between servers blocks it. After a migration, firewall rules often get missed.

Check and fix:

1. On the database server, check if the port is listening: sudo ss -tlnp | grep 3306. You should see 0.0.0.0:3306 or *:3306.
2. Check ufw or firewalld: sudo ufw status or sudo firewall-cmd --list-all. If 3306 isn't allowed, add it: sudo ufw allow 3306/tcp or sudo firewall-cmd --add-port=3306/tcp --permanent && sudo firewall-cmd --reload.
3. Test from the app server: telnet new-server-ip 3306. If it hangs or says "Connection refused", the firewall is blocking or the DB isn't listening.

Gotcha: Cloud firewalls (AWS security groups, Azure NSGs) also need rules. I've seen people open the OS firewall but forget the cloud security group. Check both.

3. User Privileges Not Updated for New IP

You migrated the database, but the user account in MySQL still has user@'old-server-ip'. The app tries to connect from the new server IP, and MySQL says "nope, you're not allowed from there."

Fix it:

1. On the database server, log into MySQL: mysql -u root -p.
2. Check the user's host: SELECT host, user FROM mysql.user WHERE user = 'youruser';
3. If it shows the old IP, update it: RENAME USER 'youruser'@'old-ip' TO 'youruser'@'new-ip'; Or create a new user for the new IP. Then FLUSH PRIVILEGES;
4. If you want to allow from any IP (not recommended for production), set host to '%' — but that's a security risk.

Real scenario: Had a client whose WordPress site broke after moving to a new VPS. The DB user was tied to the old server's private IP. A quick RENAME USER fixed it in 30 seconds.

Quick Reference