Aborted MySQL connections: find out who causes them

Q: Are aborted connections dangerous?

Mostly noise — but they can exhaust max_connections during spikes and may indicate an attack, so a steadily climbing counter deserves the 10-minute trace.

The problem

MySQL’s Aborted_connects counter keeps climbing. Something connects with wrong credentials, times out or dies mid-handshake — thousands of times a day. It wastes connection slots, pollutes logs, and sometimes is the first sign of a brute-force attempt or a broken script looping on a bad password. The counter tells you that it happens, never who.

The solution

VpsMonitor.Pro’s consolidated MySQL connections check shows active connections, the abort counters and their growth in one place. When you need the culprit, two built-in trace actions use the kernel audit system: one catches who connects to MySQL without credentials, the other records every connection for 10 minutes — process, user and source — and then cleans up after itself.

The traces are engineered to be safe on production: the audit rule is always removed afterwards (even if the SSH session drops) and the kernel is told to drop events rather than stall the server under load. The result reads like a story: which PHP pool, cron script or remote host is responsible — so the fix is editing one config file instead of guessing.

Frequently asked questions

What typically causes thousands of aborted connections?

A site whose config has an outdated database password, monitoring tools probing the port, brute-force attempts, or scripts that open connections and exit without closing them.

Are aborted connections dangerous?

Mostly noise — but they can exhaust max_connections during spikes and may indicate an attack, so a steadily climbing counter deserves the 10-minute trace.

Does the audit trace slow MySQL down?

It traces connection attempts, not queries, with the kernel set to drop events instead of blocking. The impact for the 10-minute window is negligible.