Database Login Shows Connection Refused After Update – Fix

You update your database (MySQL, PostgreSQL, or whatever you're running), and suddenly the login page throws a 'connection refused' error. Been there. Last month, a small biz client updated their MySQL from 5.7 to 8.0, and their whole inventory system went dark. The fix took less than 5 minutes. Here's the troubleshooting flow — start with the simplest thing, and stop when it works.

Fix 1: Restart the Database Service (30 seconds)

Updates often leave the old service running, or they kill it and don't start the new one. Don't overthink it.

For Linux (systemd):

sudo systemctl restart mysql   # or postgresql or mariadb
sudo systemctl status mysql

If the status says 'active (running)', you're probably good. If it says 'failed' or 'inactive', move to Fix 2.

For Windows:

Open Services (Win + R, type services.msc), find MySQL or PostgreSQL, right-click and Restart. Check the 'Startup Type' is set to Automatic.

Real scenario: Had a client whose update turned off the service. No error message — just refused connection. Restart fixed it in 10 seconds.

Fix 2: Check the Port and Firewall (5 minutes)

Updates can change the default port (e.g., MySQL from 3306 to 3307, PostgreSQL from 5432 to something else). Also, firewalls sometimes block the port after an update.

Check what port the database is listening on:

sudo netstat -tulpn | grep -E '3306|5432'

If you see a different port, update your app config. If nothing shows, the service isn't bound to that port — might be misconfig.

Check the firewall:

sudo ufw status   # for Ubuntu
sudo firewall-cmd --list-all   # for CentOS/RHEL

Make sure port 3306 or 5432 is open. If not, add it:

sudo ufw allow 3306/tcp   # for MySQL

Real story: Client's Windows update turned on the built-in firewall, blocking port 3306. Opened it, and boom — login worked.

Fix 3: Verify the Database Config File (15+ minutes)

If the service runs but still refuses, it's likely a config issue. Updates sometimes overwrite or corrupt config files.

MySQL/MariaDB:

Check /etc/mysql/my.cnf or /etc/my.cnf. Look for:

bind-address — should be 127.0.0.1 if local, or 0.0.0.0 if remote access needed. If it's set to a wrong IP, change it.
port — make sure it matches what your app uses.

After editing, restart the service.

PostgreSQL:

Check /etc/postgresql/*/main/postgresql.conf. Look for:

listen_addresses — should be 'localhost' or '*' for remote.
port — same deal.

Also check pg_hba.conf for authentication rules. If the update changed the auth method to scram-sha-256 and your app expects md5, you'll get refused. Change it back:

# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    all             all             127.0.0.1/32            md5

Fix 4 (Advanced): Check Logs and Permissions

If none of that works, check the database logs. They tell you exactly what's wrong.

Log locations:

MySQL: /var/log/mysql/error.log or /var/log/mysqld.log
PostgreSQL: /var/log/postgresql/postgresql-*.log

Look for lines with 'refused' or 'error'. Common issues:

User permissions changed: After update, the database user might not have access from localhost. Run: GRANT ALL PRIVILEGES ON *.* TO 'youruser'@'localhost'; FLUSH PRIVILEGES;
Disk space full: Check with df -h. If the disk is full, the database can't start. Free up space.
SELinux blocking: On RHEL/CentOS, run sudo setenforce 0 to test. If that fixes it, add a rule for the database port.

Final tip: If you're on a managed server (like cPanel), contact the host. Sometimes the update breaks the socket file location. They'll fix it fast.

That's it. Start with the restart, then check the port and firewall, then dig into the config. You'll be back online in no time.