How to Fix MySQL Error 1129: Host Blocked Due to Many Connection Errors

ERROR 1129 (HY000): Host '<hostname>' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts' is raised when MySQL has counted too many consecutive failed connection attempts from a specific host and has blocked that host entirely. The error symbol is ER_HOST_IS_BLOCKED.

Impact

Once a host is blocked, every new connection attempt from that host is immediately rejected with error 1129 — before any authentication even takes place. Legitimate application connections, database administration tools, and monitoring agents all fail simultaneously. From the application side this typically surfaces as a connection refused or driver-level error rather than an authentication failure, which can make it look like a network outage.

In ORMs and connection pools the failure usually manifests at pool initialization or during a pool replenishment cycle. Frameworks that aggressively retry failed connections on startup (Spring Boot, Django, Rails) may make the situation worse by generating additional failed attempts from the same host, keeping the block in place or triggering it on other hosts.

Common Causes

Repeated authentication failures from an application. A misconfigured application (wrong password, wrong username, or connecting before the MySQL user account exists) retries rapidly and exhausts the max_connect_errors counter in minutes. This is the most common cause in production.
Connection pool misconfiguration after a credential rotation. When application credentials are rotated but the running pool still holds the old password, the pool continually attempts to reconnect with the stale credentials until the host is blocked.
Network interruptions mid-handshake. Connections that are dropped after the TCP handshake but before authentication completes — due to load balancer timeouts, firewalls performing TLS inspection, or flapping network links — are counted as connect errors.
CI/CD pipelines or migration scripts with wrong connection strings. Automated scripts that run frequently (seeding, migrations, health checks) with an incorrect DSN can trigger the block across multiple pipeline runs.
max_connect_errors set too low. The default is 100 in MySQL 5.6 and later. In high-traffic or test environments with many transient connections, even legitimate noise can accumulate to this threshold if DNS resolution is slow or the host name changes between connections.

Troubleshooting and Resolution Steps

Immediately unblock the host. You need to clear the error counter before any new connections from that host will succeed:
```
-- From a MySQL session on a non-blocked host (e.g., localhost):
FLUSH HOSTS;
```
Or from the shell without an existing MySQL session:
```
mysqladmin -u root -p flush-hosts
```
As of MySQL 8.0.26, a more targeted alternative is available that avoids resetting all host counters at once:
```
TRUNCATE TABLE performance_schema.host_cache;
```
Identify which hosts are currently blocked or close to the threshold. Query the Performance Schema host cache to see connection error counts before they reach the limit:
```
SELECT host, sum_connect_errors, count_host_blocked_errors
FROM performance_schema.host_cache
ORDER BY sum_connect_errors DESC;
```
Find and fix the root cause. Check the MySQL error log for authentication failures from the offending host:
```
grep "Access denied" /var/log/mysql/error.log | tail -50
```
Then verify the application's connection credentials and database user configuration:
```
SELECT user, host, account_locked, password_expired
FROM mysql.user
WHERE user = 'your_app_user';
```

Raise max_connect_errors if the default is too strict for your environment. This buys time while you investigate, but does not replace fixing the underlying cause:

-- Check the current value:
SHOW VARIABLES LIKE 'max_connect_errors';

-- Raise it at runtime (takes effect immediately, not persistent):
SET GLOBAL max_connect_errors = 1000;

To make the change persistent, add it to my.cnf:

[mysqld]
max_connect_errors = 1000

Verify DNS resolution is stable. MySQL tracks connect errors per resolved IP address, but it stores the hostname. If a host resolves to different IP addresses over time (e.g., rolling deploys, short TTL DNS), error counts may accumulate unexpectedly. Check skip_name_resolve:
```
SHOW VARIABLES LIKE 'skip_name_resolve';
```
Setting skip_name_resolve = ON makes MySQL track hosts by IP only, which avoids DNS-induced counter inflation.

Additional Information

Related error codes: Error 1045 (ER_ACCESS_DENIED_ERROR) is the authentication failure that increments the counter leading to 1129. If you see a surge of 1045 errors in your logs, a 1129 block may follow.
MySQL 8.0 host cache: In MySQL 8.0 the host cache is exposed through performance_schema.host_cache, making it easier to inspect and reset without a full FLUSH HOSTS.
Replica and ProxySQL environments: In replication setups, FLUSH HOSTS must be run on each server individually — it does not propagate to replicas. If ProxySQL sits in front of MySQL, the block applies at the MySQL layer, not the proxy layer; ProxySQL will still accept connections but forward them to a blocked MySQL host.
Connection poolers: PgBouncer-style poolers are not relevant here, but Java connection pools (HikariCP, c3p0) and Node.js pools (mysql2/promise-mysql) will surface 1129 as a pool acquisition timeout if retries are bounded, or as a flood of driver errors if retries are unlimited.

Frequently Asked Questions

Why does FLUSH HOSTS fix the problem immediately even though the application password is still wrong? FLUSH HOSTS resets the sum_connect_errors counter for all hosts in MySQL's internal host cache. The next connection attempt starts with a clean count. If the underlying authentication problem is not fixed, the host will be blocked again once max_connect_errors is reached again.

How do I find out what max_connect_errors is set to without logging in to MySQL? If you can't connect at all from the blocked host, connect from a different host (e.g., directly on the MySQL server via 127.0.0.1 or a Unix socket) and run SHOW VARIABLES LIKE 'max_connect_errors';. Alternatively, check the [mysqld] section of my.cnf or my.ini.

Can I prevent this error in production without raising max_connect_errors? Yes. The most reliable prevention is fixing the root cause (correct credentials, stable network). For extra safety, set up alerting on the sum_connect_errors column in performance_schema.host_cache so you catch hosts approaching the limit before they are blocked.

Does this error appear in AWS RDS or Aurora MySQL? Yes. On managed MySQL services you cannot edit my.cnf directly, but you can set max_connect_errors via a custom parameter group. FLUSH HOSTS and TRUNCATE TABLE performance_schema.host_cache both work on RDS and Aurora MySQL with a sufficiently privileged user.