🚨 MySQL Error Guide: 'Host is blocked because of many connection errors' — Unblock & Fix

Overview

MySQL raises error 1129 when a single client host accumulates too many failed or aborted connection attempts. The server then refuses every new connection from that host — including healthy application traffic — until it is explicitly unblocked:

ERROR 1129 (HY000): Host '10.20.0.34' is blocked because of many connection errors;
unblock with 'mysqladmin flush-hosts'

The block is per client host (identified by the resolving IP or hostname), not per user, so one flaky app instance, load balancer, or health-check probe can lock an entire host out of the database even though credentials are valid.

MySQL 8.0 keeps a per-host error counter in the internal host cache. When the counter for a host reaches max_connect_errors (default 100), the host is blocked. MariaDB behaves the same way and uses the same variable and message. Note that on MySQL, if skip_name_resolve is OFF, DNS failures during connection setup also increment this counter, which is a frequent hidden cause.

Symptoms

• Every connection from one specific application server or subnet fails with error 1129 while other hosts connect fine.
• The block appears suddenly after a deploy, a network blip, or a DNS change — not gradually.
• Credentials are correct; connecting to the same MySQL from a different host works immediately.
• Health-check endpoints or connection poolers report a spike of connection failures right before the block.
• SHOW GLOBAL STATUS LIKE 'Aborted_connects'; climbs steadily.
• Restarting the app “fixes” it briefly, then the host gets blocked again.

Common Root Causes

• A client opening TCP connections and closing them before the handshake completes — port scanners, aggressive TCP health checks, or a misconfigured load balancer probing port 3306.
• DNS / reverse-DNS resolution failures on the server when skip_name_resolve is OFF: each failed name lookup during connect counts as a connection error.
• Repeated authentication or protocol errors from one host (wrong TLS settings, an old client library, or a bad handshake).
• max_connect_errors set too low for an environment with transient network noise.
• A crash-looping application that hammers MySQL with half-open connections while restarting.
• Aborted connections from network timeouts between the app tier and the database (MTU/firewall/idle-timeout mismatches).

Diagnostic Workflow

First confirm the block and identify the host from the error itself, then inspect the host cache. On MySQL 8.0 the host cache is exposed through Performance Schema:

SELECT IP, HOST, HOST_VALIDATED, SUM_CONNECT_ERRORS,
       COUNT_HOST_BLOCKED_ERRORS, COUNT_NAMEINFO_PERMANENT_ERRORS
FROM performance_schema.host_cache
ORDER BY SUM_CONNECT_ERRORS DESC;

Check the configured threshold and the running abort counters:

SHOW VARIABLES LIKE 'max_connect_errors';
SHOW GLOBAL STATUS LIKE 'Aborted_connects';
SHOW GLOBAL STATUS LIKE 'Connection_errors_%';

The Connection_errors_* counters are the key discriminator. High Connection_errors_internal or Connection_errors_tcpwrap points at the server side; a large COUNT_NAMEINFO_PERMANENT_ERRORS in the host cache points squarely at DNS. Confirm whether name resolution is even in play:

SHOW VARIABLES LIKE 'skip_name_resolve';

If it is OFF, test reverse DNS for the blocked IP from the database host:

host 10.20.0.34
getent hosts 10.20.0.34

Finally, watch what the offending host is doing at the network layer — a flood of short-lived connections to port 3306 is the fingerprint of a probe or crash loop:

ss -tn state all '( dport = :3306 or sport = :3306 )' | head

Example Root Cause Analysis

A payments service started returning 1129 for its entire Kubernetes node pool an hour after a cluster upgrade. Credentials were unchanged and a psql-style manual connect from a laptop worked.

performance_schema.host_cache showed three node IPs with SUM_CONNECT_ERRORS at 100+ and a non-zero COUNT_NAMEINFO_PERMANENT_ERRORS. skip_name_resolve was OFF, and host 10.20.0.34 on the DB server timed out — the cluster upgrade had rotated the internal DNS resolver and reverse lookups for the new node subnet were failing.

Because reverse DNS failed on every connect, each new pod connection incremented the per-host error counter until it crossed the default max_connect_errors of 100 and the host was blocked. The application itself was healthy; the “connection errors” were entirely server-side DNS failures.

The immediate fix was FLUSH HOSTS to clear the cache. The durable fix was enabling skip_name_resolve (the servers were already granted by IP, not hostname), which removed DNS from the connection path entirely and stopped the counter from ever incrementing on lookup failures.

Prevention Best Practices

• Enable skip_name_resolve on servers whose grants use IP addresses or % — it removes DNS from the connect path and eliminates the most common hidden cause of 1129. This requires a restart (or set it in the config and reload).
• Fix reverse DNS if you must keep name resolution: ensure PTR records exist for every client subnet.
• Point health checks at a real handshake, not a bare TCP open/close on port 3306, so probes stop generating connection errors.
• Raise max_connect_errors to a large value (for example 10000) in environments with unavoidable transient noise, so a brief blip does not block a host.
• Alert on Aborted_connects and Connection_errors_* rate so you see the climb before a host is fully blocked.
• Firewall port 3306 to known application subnets so scanners and unrelated probes never reach it.

Quick Command Reference

-- Unblock all currently blocked hosts (clears the host cache)
FLUSH HOSTS;                 -- MySQL 5.7 / MariaDB
TRUNCATE TABLE performance_schema.host_cache;   -- MySQL 8.0 equivalent

-- See which hosts are accumulating errors
SELECT IP, SUM_CONNECT_ERRORS, COUNT_HOST_BLOCKED_ERRORS
FROM performance_schema.host_cache ORDER BY SUM_CONNECT_ERRORS DESC;

-- Inspect and raise the threshold at runtime
SHOW VARIABLES LIKE 'max_connect_errors';
SET GLOBAL max_connect_errors = 10000;

-- Server-side error breakdown
SHOW GLOBAL STATUS LIKE 'Connection_errors_%';
SHOW GLOBAL STATUS LIKE 'Aborted_connects';

# From the DB host: unblock (5.7 / MariaDB) and test reverse DNS
mysqladmin flush-hosts
getent hosts <blocked-ip>

Note: on MySQL 8.0, FLUSH HOSTS is deprecated in favor of TRUNCATE TABLE performance_schema.host_cache; both clear the block. MariaDB continues to use FLUSH HOSTS.

Conclusion

Error 1129 is a symptom of connection errors, not bad credentials: a client host tripped the max_connect_errors counter and MySQL fenced it off. Unblocking is trivial — FLUSH HOSTS (or truncating the host cache on 8.0) — but that only resets the counter. The lasting fix is to stop the errors accumulating: enable skip_name_resolve when DNS is the culprit, point health checks at a real handshake, firewall the port to known subnets, and raise max_connect_errors where transient noise is unavoidable. Use performance_schema.host_cache and the Connection_errors_* counters to prove which of those it is before you change anything.