MySQL error 1184 (ER_NEW_ABORTING_CONNECTION) occurs when the server forcibly closes a connection during authentication or handshake due to invalid credentials, network issues, SSL mismatches, or max_connections limits being exceeded.
Error 1184 signals that MySQL rejected your connection attempt before completing the handshake. This happens at the protocol level—during initial TCP connection, SSL negotiation, or authentication—when the server detects a fatal problem. Unlike errors that occur mid-query (like error 2013), this error aborts the connection before any SQL commands can execute. The server logs this as a defensive measure to protect itself from malformed packets, incompatible clients, resource exhaustion, or credential failures.
Verify that your username, password, and hostname are correct. Credentials are verified during the authentication phase, and any mismatch will immediately abort the connection.
# Test connection with explicit credentials
mysql -h 127.0.0.1 -u root -p'yourpassword' mysql
# Check if the user exists and has proper host permissions
mysql> SELECT user, host FROM mysql.user WHERE user='yourusername';
# Grant privileges if needed
mysql> GRANT ALL PRIVILEGES ON *.* TO 'youruser'@'localhost' IDENTIFIED BY 'password';
mysql> FLUSH PRIVILEGES;If you're using a connection string or URL, ensure the format is correct: mysql://user:password@host:3306/database.
The MySQL error log contains the precise reason for the connection abort. This narrows down whether the issue is credentials, packets, SSL, or resource exhaustion.
# On Linux, typical log location
sudo tail -50 /var/log/mysql/error.log
# On macOS with Homebrew
tail -50 /usr/local/var/mysql/$(hostname).err
# In MySQL client, check recent errors
mysql> SHOW ENGINE INNODB STATUS;Look for messages like:
- Got an error reading communication packets → network/packet corruption
- Host is blocked because of many connection errors → too many failed attempts
- max_connections (X) reached → connection limit exceeded
- SSL_ERROR_... → SSL/TLS negotiation failed
If the error log shows max_connections is exhausted, or if you see 1184 errors during traffic spikes, increase the connection limit. The default is 151, which is often insufficient for production.
# Check current max_connections limit
mysql> SHOW VARIABLES LIKE 'max_connections';
# Temporarily increase for testing (resets on restart)
mysql> SET GLOBAL max_connections = 300;
# Make permanent by editing my.cnf or my.ini
[mysqld]
max_connections = 300
# Then restart MySQL
sudo systemctl restart mysqlImportant: Increasing max_connections increases memory usage. Monitor RAM and consider optimizing connection pooling instead of blindly raising the limit. As a rule of thumb, each connection uses ~5-10 MB of RAM. Also note that MySQL actually allows max_connections + 1 connections (the extra is for CONNECTION_ADMIN users).
Network issues during handshake cause packet corruption or timeouts, which trigger the abort.
# Test latency to MySQL server
ping -c 5 your-mysql-host
# Check if port 3306 is reachable
nc -zv your-mysql-host 3306
# On Linux, check firewall rules
sudo iptables -L -n | grep 3306
sudo firewall-cmd --list-all | grep 3306
# On Windows, check Windows Firewall
netsh advfirewall firewall show rule name="MySQL"Verify that:
- The MySQL server is listening on the expected port (default 3306)
- Firewall rules allow inbound traffic on that port
- Network latency is reasonable (< 200ms for remote hosts)
- No load balancers or proxies are dropping idle connections
If the error happens after SSL negotiation, check for version mismatches between client and server.
# Check server's TLS version settings
mysql> SHOW VARIABLES LIKE 'tls_version';
# Example output: tls_version = 'TLSv1.2,TLSv1.3'
# Check what the client is requesting
openssl s_client -connect your-mysql-host:3306 -tls1_2
# If you have an old client that only supports TLS 1.0, upgrade it
# OR lower the server's minimum TLS version (not recommended for security)Ensure your client library (mysql-connector-python, Node.js mysql2, etc.) is up-to-date and supports the server's TLS version. Old drivers may not support TLS 1.2+.
If network latency or slow clients are causing timeouts during handshake, adjust timeout parameters.
# Check current timeout settings
mysql> SHOW VARIABLES LIKE 'connect_timeout';
mysql> SHOW VARIABLES LIKE 'wait_timeout';
mysql> SHOW VARIABLES LIKE 'interactive_timeout';
# Increase connect_timeout (in seconds) in my.cnf
[mysqld]
connect_timeout = 30
# Then restart MySQL
sudo systemctl restart mysql
# For application-level pools, adjust pool connection timeout too
# Example: Node.js with mysql2
const connection = mysql.createConnection({
host: 'localhost',
user: 'root',
password: 'password',
connectTimeout: 30000, // 30 seconds in milliseconds
});The connect_timeout applies to the TCP handshake and authentication phase. Increasing it gives slow clients and high-latency networks more time to complete the handshake.
Applications using connection pools often spike and exceed max_connections at startup. Implement pooling strategies to avoid this.
// Node.js example with mysql2/promise
const mysql = require('mysql2/promise');
const pool = mysql.createPool({
host: 'localhost',
user: 'root',
password: 'password',
database: 'mydb',
waitForConnections: true,
connectionLimit: 10, // Keep this well below server's max_connections
queueLimit: 0,
});
// Good: Stagger connection creation
const connection = await pool.getConnection();
// ...
connection.release();# Python example with mysql-connector
import mysql.connector
from mysql.connector import pooling
config = {
"host": "localhost",
"user": "root",
"password": "password",
"database": "mydb"
}
pool = pooling.MySQLConnectionPool(
pool_name="mypool",
pool_size=5, # Set well below server's max_connections
pool_reset_session=True,
**config
)Best practice: Set your application's pool size to 10-50% of the server's max_connections. If the server allows 300 connections, your pool should use 15-100 at peak. This prevents cascade failures when other applications or connections consume the available slots.
Azure MySQL has specific issues with the init_connect parameter. Setting unsupported server parameters in init_connect triggers error 1184.
-- Check the current init_connect value
SHOW VARIABLES LIKE 'init_connect';
-- Reset to empty (via Azure portal or CLI)
-- Azure Portal: Settings > Server parameters > init_connect = ''
-- Via Azure CLI
az mysql server configuration set \
--resource-group myResourceGroup \
--server-name myserver \
--name init_connect \
--value ''Parameters like require_secure_transport cannot be set via init_connect on Azure—they must be set as server parameters directly. After resetting init_connect, test your connection again.
Error 1184 occurs before the connection is fully established, making it different from mid-query errors like error 2013 (Lost connection). The exact abort reason is logged in the MySQL error log with context like the username, host, and error code. Production systems should monitor error logs and connection pool metrics to catch resource exhaustion early. For high-traffic systems, consider connection pooling proxies like ProxySQL or connection limits enforced at the application level. VPN connections can also trigger 1184 if they drop packets during handshake—enable TCP keep-alives or adjust net_read_timeout and net_write_timeout. MariaDB is compatible with MySQL 1184 and requires identical fixes.
EE_WRITE (3): Error writing file
How to fix "EE_WRITE (3): Error writing file" in MySQL
CR_PARAMS_NOT_BOUND (2031): No data supplied for parameters
How to fix "CR_PARAMS_NOT_BOUND (2031): No data supplied for parameters" in MySQL
CR_DNS_SRV_LOOKUP_FAILED (2070): DNS SRV lookup failed
How to fix "CR_DNS_SRV_LOOKUP_FAILED (2070): DNS SRV lookup failed" in MySQL
ERROR 1146: Table 'database.table' doesn't exist
How to fix "ERROR 1146: Table doesn't exist" in MySQL
ERROR 1040: Too many connections
How to fix "ERROR 1040: Too many connections" in MySQL