You're importing a database in phpMyAdmin, or your WordPress site is chugging along fine, and then it stops cold with #2006 - MySQL server has gone away. No warning, no gradual slowdown — just a dead connection mid-task. Unlike a "too many connections" error, this one usually shows up when everything looked healthy a second ago. Here's what's actually happening and how to fix it on a cPanel or VPS setup.
Symptom: Where This Error Shows Up
A few common places customers hit this:
- Importing a large
.sqlfile in phpMyAdmin — it gets partway through and dies with2006 - MySQL server has gone away. - A WordPress page that sits idle in a browser tab for a while, then on the next click throws
Error establishing a database connection, but a refresh fixes it. - A long-running terminal" class="auto-link">WP-CLI command (
wp search-replace, a big migration script) that dies mid-run with the same message. - A cron job or backup script that queries the database, sleeps, then queries again — and the second query fails.
- PHP error logs showing
SQLSTATE[HY000]: General error: 2006 MySQL server has gone away.
The pattern to notice: it's almost always tied to time (a connection sitting idle too long) or size (a single query or packet that's too big for MySQL to accept). That's different from error 1040 ("too many connections"), which is about hitting a connection-count ceiling under load, not a single connection timing out or overflowing.
Cause 1: The Connection Timed Out
MySQL/MariaDB closes idle connections automatically after a set number of seconds, controlled by two variables:
wait_timeout— how long a non-interactive connection (like PHP, phpMyAdmin's backend) can sit idle before MySQL drops it.interactive_timeout— same idea, but for interactive clients like an SSHmysqlsession.
Shared cPanel servers usually ship with a conservative default (often 60–120 seconds). If your script opens a database connection, does something slow that doesn't touch MySQL for a couple of minutes (calling an external API, processing a large file, waiting on user input), then tries to run another query on that same connection, MySQL has already hung up. The next query fails with 2006 even though the database itself is perfectly fine.
Cause 2: A Query or Import Is Too Large
The second common trigger is max_allowed_packet — the largest single chunk of data MySQL will accept in one go (a big INSERT, a wide row, a large BLOB, or one giant line in a .sql dump). If your import file has a single INSERT statement stuffed with thousands of rows on one line, and that line exceeds max_allowed_packet, MySQL severs the connection rather than truncating the data silently.
This is exactly why big database migrations dumped with certain tools (or exported with "extended inserts" all on one line) fail partway through in phpMyAdmin, even though the same file imports fine via SSH with the right settings.
Cause 3: MySQL/MariaDB Actually Restarted
Less common, but worth ruling out: if the mysqld service itself crashed or was restarted (OOM killer, a resource limit on shared hosting, a manual service restart by an admin), every open connection at that moment gets the same "gone away" error, regardless of timeout or packet size. If this is happening randomly across otherwise unrelated scripts, check the MySQL error log before touching timeout settings.
Fix: For phpMyAdmin Import Failures
Don't fight this in the browser — import over SSH instead, it's both faster and immune to PHP's own upload/execution limits:
mysql -u your_cpanel_user -p your_database_name < /home/youruser/backup.sqlIf you don't have SSH access, or the file genuinely needs phpMyAdmin, raise the packet size first. In WHM: WHM → Service Configuration → MySQL/MariaDB Configuration → my.cnf, and under [mysqld] add or increase:
[mysqld]
max_allowed_packet = 256M
wait_timeout = 600
interactive_timeout = 600Save and let MySQL restart (WHM will prompt you). On a VPS without WHM, edit /etc/my.cnf or /etc/my.cnf.d/server.cnf directly, then run systemctl restart mysqld (or mariadb, depending on your distro).
Fix: For WordPress "Database Connection" Drops
If it's specifically WordPress losing the connection after idle periods (common with long admin sessions, or plugins that run slow background tasks), you have two options:
- Raise
wait_timeoutas above — the simplest fix if you control the server. - Avoid holding one connection open across idle time if you're on shared hosting and can't touch server config. WordPress normally opens a fresh database connection per request, so this mostly bites long admin operations, custom scripts, or plugins that keep a connection alive in the background.
If you're using an object cache (Redis or Memcached via a caching plugin), check its persistent-connection setting too — some configurations keep their own long-lived MySQL connection that can go stale the same way and needs the same wait_timeout fix, or a reconnect-on-failure option in the plugin's settings.
Fix: For WP-CLI or Custom Scripts
For long-running scripts, don't rely on one connection staying open for the whole job. Either:
- Batch the work and reconnect between chunks (e.g., process 500 rows, close the connection, reopen for the next 500).
- Or bump
wait_timeouttemporarily for that session only:SET SESSION wait_timeout=28800;right after connecting.
Quick Reference
| Symptom | Likely Cause | Fix |
|---|---|---|
| Import dies partway through | max_allowed_packet too small | Raise it in WHM MySQL config, or import via SSH |
| Fails after page sits idle | wait_timeout too short | Raise timeout, or use persistent/object caching |
| Fails randomly, unrelated scripts | mysqld crashed/restarted | Check MySQL error log, look for OOM kills |
| Long WP-CLI job dies mid-run | Single connection held open too long | Batch the work, reconnect between chunks |
Prevention
A few habits that keep this from recurring:
- When exporting databases for migration, use "one row per INSERT" instead of extended inserts if the destination has a low
max_allowed_packetyou can't change. - Set
wait_timeoutto something realistic for your workload (600–1800 seconds is common) rather than leaving a shared-hosting default that assumes short-lived connections. - If you're scripting backups or migrations, always wrap database calls in retry logic that reconnects on a 2006 error instead of dying outright.
- Keep an eye on
/var/log/mysqld.log(ormariadb.log) after any unexplained batch of "gone away" errors — it'll tell you immediately if the service itself was the one that dropped, versus a timeout or packet limit.
Frequently Asked Questions
Is "MySQL server has gone away" the same as "Too many connections"?
No. "Too many connections" (error 1040) means MySQL is refusing new connections because it's already at its configured limit. "Server has gone away" (error 2006) means a connection that was already open got dropped — usually from sitting idle past wait_timeout, or from a single query/packet exceeding max_allowed_packet.
Can I fix this without SSH or WHM access?
Partially. You can add reconnect logic in wp-config.php or your application code, and you can split large imports into smaller files to stay under the packet limit. But changing wait_timeout and max_allowed_packet server-wide requires WHM or root access — on shared hosting without WHM, ask support to raise these for your account.
Why does the same import work in SSH but fail in phpMyAdmin?
phpMyAdmin runs through PHP, which has its own execution time and memory limits layered on top of MySQL's own limits. A large import can hit either PHP's timeout or MySQL's packet limit first. Importing directly with the mysql command over SSH skips PHP entirely, so it's less likely to fail on a large file.
Will raising wait_timeout cause other problems?
Not usually, but on a busy server it means idle connections hold their slot in max_connections longer. If you raise wait_timeout significantly, keep an eye on connection counts afterward, and make sure your application isn't leaking connections it never closes.
How do I know if it's an OOM kill and not a timeout?
Check dmesg or /var/log/messages for an "Out of memory: Killed process" entry mentioning mysqld. If it's there, the fix is memory-related (add swap, tune innodb_buffer_pool_size down, or upgrade RAM) rather than a timeout setting.
