SQLSTATE HY000 General Error 2006 — The MySQL server has gone away

Yeah, this error is annoying. You're in the middle of something and suddenly your PHP script or WordPress site throws 'SQLSTATE HY000 General Error 2006 — MySQL server has gone away'. I've seen it hundreds of times. The fix is almost always the same two settings.

The Quick Fix

Open your MySQL config file. On Ubuntu or Debian it's /etc/mysql/mysql.conf.d/mysqld.cnf. On CentOS or RHEL it's /etc/my.cnf. Add these lines under the [mysqld] section:

[mysqld]
wait_timeout = 600
max_allowed_packet = 64M

Then restart MySQL:

sudo systemctl restart mysql

Or if you're on MariaDB:

sudo systemctl restart mariadb

That's it. 9 times out of 10 this kills the error immediately.

Why This Works

The wait_timeout setting tells MySQL how long to keep an idle connection open. Default is often 28800 seconds (8 hours) on some systems, but I've seen it set to 60 seconds on shared hosts. If your PHP script takes longer than that to run — say you're processing a CSV import or generating a report — MySQL drops the connection. You get 'gone away'.

The max_allowed_packet setting controls the biggest SQL statement MySQL will accept. Default is 4MB or 16MB on older versions. If you're inserting a large blob, a big JSON field, or running a huge INSERT statement, MySQL kills it with error 2006. Bumping it to 64MB or 128MB fixes that.

I've fixed this on WordPress sites with huge wp_options tables, on Laravel apps doing batch processing, and on custom PHP scripts handling file uploads. It's the same root cause every time.

Less Common Variations

Sometimes the fix above doesn't cut it. Here's the next things to check.

1. PHP Max Execution Time

If your script runs longer than PHP allows, PHP kills the connection before MySQL times out. Check your php.ini:

max_execution_time = 300

Set it to something higher — 300 seconds is usually fine for a batch job. Don't go crazy, 3000 seconds is a code smell.

2. MySQL Connection Pooling

If you're using PHP-FPM with persistent connections, a stale connection can trigger this. Switch to non-persistent connections in your code:

// Instead of PDO::ATTR_PERSISTENT => true
$pdo = new PDO('mysql:host=localhost;dbname=test', 'user', 'pass');

Or add a reconnect loop. Here's a simple one for PDO:

try {
    $pdo->query('SELECT 1');
} catch (PDOException $e) {
    if ($e->getCode() == 2006) {
        $pdo = new PDO(...);
    }
}

3. Server Resource Limits

If your MySQL server is running out of memory or max connections, it'll kill idle sessions. Check max_connections and innodb_buffer_pool_size. On a small VPS with 1GB RAM, I've seen MySQL kill connections because the buffer pool was set too high. Lower it to 256MB or 512MB.

[mysqld]
max_connections = 150
innodb_buffer_pool_size = 256M

4. Network Timeout

If MySQL is on a different server, a firewall or load balancer might kill idle connections. Check the TCP timeout settings on the network gear. On Linux you can adjust tcp_keepalive_time but that's rare. Usually the MySQL config fixes it.

Prevention

Once you've got the error fixed, don't let it come back. Here's what I do:

• Set wait_timeout to 600 seconds minimum. 10 minutes gives scripts enough time without eating too many resources.
• Set max_allowed_packet to 64MB minimum. Go to 128MB if you handle large files.
• Add a reconnect check in your code. For long-running scripts, ping the database every 100 rows or so.
• Monitor your slow query log. Run SET GLOBAL slow_query_log = 1 and check which queries take over 5 seconds. Those are the ones hitting the timeout.
• Upgrade PHP and MySQL. Old versions have bugs. PHP 7.4 and MySQL 5.6 are known for weird connection drops. PHP 8.x and MySQL 8.0 are stable.

I've seen this error on shared hosting, on dedicated servers, even on AWS RDS. The fix is always the same. Start with the config file, then check PHP timeout, then look at resources. 99% of the time you're done after the first step.