MySQL Server Has Gone Away: How to Fix It on a WordPress or cPanel Server

MySQL server has gone away is one of those errors that tells you almost nothing about what actually broke. WordPress shows a white page or a database connection error, the error log records error 2006 or 2013, and the underlying cause could be a timeout, an oversized query, a crashed table, or MySQL itself restarting mid request. Fixing it properly means identifying which of those four it actually is, not applying the first wait_timeout fix you find and hoping.

Read the actual error number before doing anything

Check the PHP error log or MySQL's own error log for the exact error code:

tail -100 /usr/local/cpanel/logs/error_log
grep -i "gone away" /var/log/mysql/error.log

Error 2006 means the connection was already closed when PHP tried to use it, almost always a timeout. Error 2013 means the connection dropped mid query, which points more toward an oversized query, a network blip, or MySQL crashing and restarting under memory pressure. That distinction changes which fix actually applies.

Cause 1: the connection sat idle past wait_timeout

MySQL closes idle connections after wait_timeout seconds, 28800 by default. A long-running admin task, a slow cron job, or a plugin that opens a connection and does other work before querying again can easily exceed that. Check the current value and, if it is unusually low, raise it:

mysql -e "SHOW VARIABLES LIKE 'wait_timeout';"

[mysqld]
wait_timeout = 300
interactive_timeout = 300

Raising wait_timeout too high just delays the same problem and wastes connection slots on abandoned sessions. A few hundred seconds is usually enough; the more durable fix is making sure long PHP requests are not holding a database connection open while doing unrelated work.

Cause 2: a single query is too large for max_allowed_packet

If the error correlates with a specific action, a large import, a bulk post update, an oversized serialized option, the query itself may exceed max_allowed_packet. This is a distinct issue from a plain timeout and needs a different setting entirely. We cover diagnosing this exact packet-size error in detail in got a packet bigger than max_allowed_packet bytes, including how to raise the limit safely on a cPanel server without oversizing memory usage server wide.

Cause 3: a corrupted or crashed table

If the error appears inconsistently, on some pages but not others, and the affected table shows errors under CHECK TABLE, corruption rather than a timeout is the real cause:

mysqlcheck -c wordpress_db -u root -p
mysqlcheck -r wordpress_db -u root -p

For InnoDB tables specifically, a repair via mysqlcheck does not always resolve deeper corruption. Our guide on recovering crashed InnoDB tables walks through the safer recovery sequence, including when to pull from innodb_force_recovery and when to restore from backup instead.

Cause 4: MySQL itself is restarting

If mysqld is being killed and restarted, usually by the OOM killer on a memory constrained VPS, every open connection breaks at once and every visitor sees the error simultaneously rather than one at a time. Confirm this by checking uptime and the system log:

mysqladmin status
dmesg | grep -i "killed process"

If dmesg shows mysqld being killed for memory, the fix is not a MySQL setting at all, it is either reducing innodb_buffer_pool_size to fit available RAM or adding memory to the server, since a database that gets OOM killed under load will keep producing this error regardless of any timeout setting.

Cause 5: a connection pooler or proxy between WordPress and MySQL

On servers running ProxySQL, PgBouncer style poolers, or a load balancer in front of MySQL, the pooler's own idle timeout can close connections before MySQL's own wait_timeout would, producing the identical error with a completely different fix, adjusting the pooler configuration rather than MySQL itself. Confirm whether a pooler is in the path before assuming the setting lives in my.cnf.

A WordPress-side mitigation, not a fix

WordPress can be told to reconnect automatically after a dropped connection, which papers over occasional timeouts without addressing the underlying cause:

define( 'WP_ALLOW_REPAIR', false );

The actual mitigation is in wp-db.php's retry logic, which WordPress core already includes for a single retry on a lost connection. This helps with rare, isolated timeouts. It does not help if the real cause is table corruption or memory pressure, since the retry will fail the same way immediately after reconnecting.

Putting it together

MySQL server has gone away has four genuinely different root causes that happen to produce the same message: an idle connection timeout, an oversized query, table corruption, or MySQL itself crashing under memory pressure. Check the error log for the specific error number first, confirm whether the error is isolated to specific actions or affects every visitor at once, and match the fix to the actual cause rather than raising wait_timeout and hoping the problem was that simple.

iServerSupport provides Linux server management including MySQL configuration, memory tuning and database troubleshooting, so a recurring connection error gets traced to its actual cause instead of masked with a timeout increase.