MySQL Connection Errors for VPS: MySQL Server Has Gone Away, 1045, 2002 & 2003 Fixes

A database connection failure can stop a website from loading, prevent application logins or interrupt an import. The exact message matters: “Access denied”, a missing local socket and “MySQL server has gone away” point to different checks.

Start by recording the error and checking whether the application uses a local Unix socket or a TCP connection. Check service status and logs before changing credentials, firewall rules or server limits.

This guide covers common MySQL connection errors on a Linux VPS using systemd. Examples use MySQL 8.x; MariaDB commands, authentication behaviour, service names and configuration paths may differ. Verify your installed version and keep a backup before editing configuration.

Key Takeaways

• Match the error to authentication, local sockets, TCP reachability or a dropped session.
• Error 1045 means authentication was rejected; verify the exact account, host and authentication method.
• The error 2002 is an indication of a problem with the sockets or services.
• MySQL error 2003 may be a result of firewalls or issues caused by remote connection.
• “MySQL Server Has Gone Away” is usually a problem with the timeout limits and packets.
• Check service status and the relevant application and database logs before changing settings.
• Adequate user privileges and configuration prevent a lot of connection problems on MySQL.

What are MySQL connection errors?

Not all database connection issues have the same cause. Some may be due to the wrong username and password. Others could be because of the database service being down or the server refusing any kind of connection.

Error Type	Common Cause	Typical Errors
Authentication	Incorrect username, password, or privileges	Error 1045
Local Connection	Socket file missing, MySQL service stopped	Error 2002
Network Connection	Firewall, port blocking, bind address	Error 2003
Server Disconnect	Timeout, packet size, crashed connection	MySQL Server Has Gone Away

MySQL Error 1045 (Access Denied)

One of the common authentication errors is:

ERROR 1045 (28000):
Access denied for user 'username'@'localhost'
(using password: YES)

The server was reached but rejected authentication for the user and host shown. Check the account, password, authentication method and permitted client host. A database-level privilege error can also occur after authentication and should be diagnosed separately.

Reasons for MySQL Error 1045

• Incorrect username
• Wrong password
• User not existing
• User having no permission for a particular host
• Mismatch of authentication plugin
• Restrictions for root account
• Account or authentication settings changed without updating the application

An authentication rejection shows that a server answered the connection attempt. It does not prove that every part of the database or application is healthy.

Step 1: Check the Username and Password

Double-check the credentials that you are using. Try to log in manually:

mysql -u username -p

Then input your password after the prompt. Successful logging means the problem can be in your config file and not MySQL.

Check the database settings for WordPress in:

wp-config.php

Check Database:

• Name
• Username
• Password
• Host

Step 2: Verify User Existence

Use an existing authorized database administrator account. The example below prompts for a password; some Ubuntu/MariaDB installations instead use local socket authentication with sudo mysql. Do not change root authentication just to match an example.

mysql -u root -p

Check existing users:

SELECT User, Host
FROM mysql.user;

Possible output:

root       localhost
wordpress  localhost
appuser    192.168.1.25

Create a separate application account only if it is genuinely missing. Replace the sample account, database and password with your own values. Do not put a production password in shared notes or a shell command.

CREATE USER 'appuser'@'localhost'
IDENTIFIED BY 'REPLACE_WITH_A_UNIQUE_PASSWORD';

Step 3: Verify User’s Privileges

Check the grants on the exact user-and-host account. Missing database privileges and a failed authentication handshake are related but distinct problems.

See user privileges:

SHOW GRANTS FOR 'appuser'@'localhost';

Sample output:

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, DROP
ON appdb.*
TO 'appuser'@'localhost';

Grant only the privileges the application needs on its own database. The following runtime example allows reading and changing rows. Installation or schema migrations may need separate, temporary schema privileges; do not grant server-wide access to fix a login error.

GRANT SELECT, INSERT, UPDATE, DELETE
ON appdb.*
TO 'appuser'@'localhost';

CREATE USER, ALTER USER and GRANT take effect without a manual FLUSH PRIVILEGES. That reload is relevant after direct grant-table changes, which this guide does not recommend. See when privilege changes take effect.

Use supported account-management statements rather than modifying the mysql system tables directly.

Step 4: Host Verification

A MySQL user account comprises two parts. Username and Host. Those are different user accounts:

'user'@'localhost'
and
'user'@'%'

For remote access, match the account host to the trusted application server. The example uses one private client IP. Confirm the source address MySQL actually sees, including any NAT or tunnel, before creating the account.

CREATE USER 'appuser'@'192.168.1.50'
IDENTIFIED BY 'REPLACE_WITH_A_UNIQUE_PASSWORD';

Grant privileges:

GRANT SELECT, INSERT, UPDATE, DELETE
ON appdb.*
TO 'appuser'@'192.168.1.50';

A single trusted client address is narrower than a wildcard range. Use a private network, VPN or SSH tunnel where practical, and keep firewall access restricted.

Step 5: Check Authentication Plugins

There are various authentication plugins available in new MySQL versions. Let us check what authentication plugin the user uses:

SELECT user,
host,
plugin
FROM mysql.user;

Result:

caching_sha2_password
mysql_native_password
auth_socket

If the client does not support the account’s authentication method, update the driver or connector and check the documentation for the installed database version. Do not assume every listed plugin is available or downgrade authentication as a routine fix.

ALTER USER 'appuser'@'localhost' 
IDENTIFIED BY 'REPLACE_WITH_A_NEW_UNIQUE_PASSWORD';

The ALTER USER ... IDENTIFIED BY statement shown here resets a password; it does not explicitly select a named authentication plugin. Coordinate a password reset with the application configuration.

Step 6: Change the Password

Change the password in case of suspicion that it is not correct.

ALTER USER 'appuser'@'localhost'
IDENTIFIED BY 'REPLACE_WITH_A_NEW_UNIQUE_PASSWORD';

Set the database configuration in your code after resetting your password.

How to Solve MySQL Error 1045

✔ Verify that your username is correct.

✔ Check your password and confirm that it matches your application settings.

✔ Confirm that the server address is correct.

✔ Ensure your MySQL user exists.

✔ Verify your permissions.

✔ Review the user’s permissions and privileges.

✔ Finally, verify that the authentication plugin is compatible with your application.

Check the database error log and application connection settings before increasing timeout or packet limits.

MySQL Error 2002 (Can’t connect to local MySQL server through socket)

Error 2002 commonly means a local client could not reach the configured Unix socket. Authentication has not succeeded through that failed connection. Compare the client socket setting with the running server and check the underlying operating-system error.

The message usually looks as follows:

ERROR 2002 (HY000):
Can't connect to local MySQL server through socket
'/var/run/mysqld/mysqld.sock'

This message does not necessarily mean that there is no socket file. It might simply mean that the service is not running or the wrong path is being used.

Causes of MySQL Error 2002

• MySQL service is not running.
• Incorrect socket directory.
• Socket file was removed.
• Permissions on socket directory are wrong.
• The configuration settings for my.cnf are wrong.
• MySQL will not start.
• Disk space is full.

Step 1: Check if the MySQL Service is Active or Not

Check whether the database service is running before making any changes in the configuration files.

For Ubuntu/Debian:

sudo systemctl status mysql

For MariaDB:

sudo systemctl status mariadb

Start the database service if the database service is not running:

sudo systemctl start mysql

Start the service on startup:

sudo systemctl enable mysql

Step 2: Find the Socket File

If an authorized local connection works, query the running server for its socket path. If it does not, inspect service logs and configuration instead; a command that connects to MySQL cannot discover settings from a stopped server.

mysql -u YOUR_ADMIN_USER -p -e "SHOW VARIABLES LIKE 'socket';"

Example output:

| socket | /var/run/mysqld/mysqld.sock |

The configuration file may also be viewed. Some common places where the configuration file is stored include:

/etc/mysql/my.cnf
/etc/mysql/mysql.conf.d/mysql.cnf
/etc/my.cnf

Look for:

socket=/var/run/mysqld/mysqld.sock

The client and server should use the same socket file.

Step 3: Find Out Whether the Socket File Exists

Determine whether the socket file is present:

ls -l /var/run/mysqld/

A missing file can indicate a stopped service, a different configured socket path or a startup failure. Use the actual service status and log to distinguish these cases.

Step 4: Check MySQL logs

If there have been any recent problems with starting MySQL, they will be logged:

sudo journalctl -u mysql

There is also an option to check the error log. Possible locations are:

/var/log/mysql/error.log
/var/log/mysqld.log

Possible problems listed in logs are:

• Configuration problems
• Corrupted tables
• Permissions problems
• InnoDB cannot start
• Disk full problem

Fix the problem and try starting MySQL again.

Step 5: Restart the Service

After correcting the diagnosed cause, validate the changed configuration using the procedure supported by your installed MySQL or MariaDB version. A restart interrupts database connections, so arrange a suitable window and use the actual service name:

sudo systemctl restart mysql

Check if the socket file is present:

ls -l /var/run/mysqld/

Step 6: Verify Directory Permissions

If the runtime directory exists but the socket is not created, inspect ownership and the startup log. Do not apply recursive ownership changes or broad write permissions to database directories.

Verify permissions:

ls -ld /var/run/mysqld

Typical ownership is:

mysql:mysql

How to Fix MySQL Error 2002

✔ Make sure the MySQL server is running.

✔ Verify the path to the socket.

✔ Verify the configuration file.

✔ Check MySQL logs.

✔ Restart MySQL.

✔ Permissions should be verified.

✔ Verify that there is sufficient disk space on the VPS.

MySQL Error 2003 (Connection Refused)

MySQL error 2003 refers to the problem of TCP/IP connection and not to the local socket connection. An example of this error looks like this:

ERROR 2003 (HY000):

Can't connect to MySQL server on '192.168.1.100' (111)
or
Connection refused

This means that an unsuccessful attempt was made to set up a connection between the system and MySQL.

Reasons for MySQL Error 2003

• MySQL is not listening on port 3306.
• Firewall is blocking the packets.
• IP address is incorrect.
• Hostname is incorrect.
• Bind address is incorrect.
• The remote connection is not enabled.
• Firewall issue with cloud providers.
• SELinux/AppArmor issue.

Step 1: Does MySQL Listen on Port 3306?

Run:

sudo ss -tulpn | grep 3306

The output should look like this:

LISTEN 0 80 0.0.0.0:3306

An empty result means this check found no listener matching port 3306. The server may be stopped, use another port or have TCP disabled. Check the real port and binding before opening a firewall rule.

Step 2: Check the Bind Address

Check the server configuration:

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Check if you have this line:

bind-address=127.0.0.1

This setting binds the TCP listener to loopback. If another machine needs access, prefer a private interface or a tunnel and set the appropriate private listener address. Do not expose MySQL publicly just to make the connection work; restrict both network rules and database accounts.

Step 3: Check Firewall Rules

For UFW:

sudo ufw status

Only if a direct private connection is required, adapt this example to the actual trusted client IP and database port. Check provider-level firewall rules separately:

sudo ufw allow from 192.168.1.50 to any port 3306

For firewalld:

sudo firewall-cmd --list-all

Inspect the active firewalld zone and its source restrictions. A blanket public allow rule is not required; permit only the intended client and actual port.

Step 4: Network Connectivity

Network connectivity test to the server:

ping your-server-ip

Test the MySQL port:

nc -zv your-server-ip 3306

Your answer should be in this format:

Successful Connection to 203.0.113.10 3306 port

A timeout can result from routing, filtering or an unavailable host. A refused connection can indicate no listener or an active rejection. Ping may be blocked even when the database is reachable, and an open TCP port does not establish successful database authentication.

Step 5: Permissions for Remote User

A correct host definition is needed for the remote user.

Example:

CREATE USER 'appuser'@'192.168.1.50'
IDENTIFIED BY 'REPLACE_WITH_A_UNIQUE_PASSWORD';

Grant privileges:

GRANT SELECT, INSERT, UPDATE, DELETE
ON appdb.*
TO 'appuser'@'192.168.1.50';

Step 6: Examine SELinux or AppArmor

SELinux or AppArmor on some versions of Linux can be used to place additional security requirements.

With SELinux:

getenforce

Only the policy should be changed if MySQL is unable to create any network connections because of SELinux restrictions.

Ubuntu uses AppArmor. See if:

sudo aa-status

The policy should be modified only after the logs show that the cause of the issue is in the AppArmor policy itself.

MySQL Error 2003 Fix Checklist

✓ MySQL listens on the port.

✓ MySQL port number 3306.

✓ Bind address.

✓ Firewall configuration.

✓ Connectivity check.

✓ Remote user permissions.

✓ SELinux/AppArmor logs.

MySQL Server Has Gone Away

This notorious error message pops up when a connection has already been established. Error 2006 is generated by an unexpected termination of the session performed by the MySQL server.

Typical message:

MySQL server has gone away

Applications face this problem when performing large data imports, backups, complex queries, or leaving the connection idle for some time.

Reasons for MySQL Server Has Gone Away

• Timeouts.
• Too large SQL packets.
• Running long queries.
• Server crash.
• Network failures.
• Corrupted connections.
• Inadequate server resources.

Check the server log and the application’s connection-pool idle timeout first. Increase a database timeout only if that is the diagnosed cause. Back up configuration; these values are examples, not recommended defaults:

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Example:

[mysqld]
wait_timeout=600
interactive_timeout=600

Restart the server:

sudo systemctl restart mysql

If the log or client reports an oversized packet, compare the server and client limits before changing them. This is an example server setting; choose a justified size and account for its memory implications:

Example configuration:

[mysqld]
max_allowed_packet=128M

Restart the service afterwards.

Use database-aware import/export options or smaller transactions where appropriate. Do not split a SQL dump at arbitrary line boundaries, which can break statements, routines or transactions.

Check server resources. An operating-system OOM kill can terminate MySQL, but low free memory alone does not establish that cause. Check the system log as well as the database log before resizing a VPS.

Monitor memory consumption:

free -h

Monitor CPU activity:

top

You should think about increasing the capacity of your VPS when a server frequently runs out of memory. Database sites need additional RAM and faster storage as their load grows.

Error Log Inspection: Inspect the latest MySQL activities

sudo journalctl -u mysql

Check for:

• Out of memory errors.
• Abnormal shutdowns.
• Storage issues.
• InnoDB failures.
• Corruption of the tables.

Error logs usually give an explanation of why the connection is lost.

Make Sure MySQL Is Working: Check whether the server works properly before you try to debug authentication and network problems. Check service status.

Ubuntu and Debian:

sudo systemctl status mysql

MariaDB:

sudo systemctl status mariadb

Correct status has:

Active: active (running)

Start MySQL:

sudo systemctl start mysql

Stop MySQL:

sudo systemctl stop mysql

Restart MySQL:

sudo systemctl restart mysql

Autostart of MySQL:

sudo systemctl enable mysql

Read the logs:

sudo journalctl -u mysql --since "30 minutes ago"

This command quickly shows all the startup failures, configuration problems, permission errors, and unexpected shutdowns without parsing long logs.

Conclusion

Diagnose MySQL connection errors by matching the error to the failing stage: authentication for 1045, the local socket for 2002, TCP reachability for 2003, or an interrupted session for “server has gone away”. Make one evidence-based change, reconnect and test the actual application before closing the incident.

FAQs