Your site was fine an hour ago. Now half the pages load, the admin dashboard hangs, and the log keeps repeating one line: general error 2006. Nothing was deleted. Nothing was hacked. Your database simply stopped answering mid-sentence.
Quick Answer: The mysql server has gone away error (MySQL error 2006) means the database closed your connection before the query finished. As of August 2026, four causes explain nearly all of it: an idle connection crossing wait_timeout, a statement or import larger than max_allowed_packet, a server under memory pressure, or PHP giving up first. Two config values resolve most cases.
We resolve 20 to 30 client issues every day, and dropped database connections are a regular in that queue. What follows is the same order our engineers work through, written so you can run it yourself instead of waiting on anyone. On stacks like Hostaccent's the answer is usually one setting and a restart, not a lost database.
Before you change anything, take a dump of the database. Every step below is reversible, but a backup you can restore turns a bad afternoon into a five-minute rollback.
What "MySQL Server Has Gone Away" Actually Means
The server ended the conversation, not your code. MySQL accepted the connection, then closed it before the result came back, so your client raises error 2006 the moment it tries to read a reply that no longer exists.
MySQL reports two closely related failures. Error 2006 means the connection was already closed when the client wrote to it. Error 2013, "Lost connection to MySQL server during query", means the link died while a query was still in flight. As of August 2026 both trace back to the same short list of causes, and the same fixes apply to either one. Some drivers phrase it as a MySQL connection lost mid-query and report 2013 instead.
Where it turns up depends on what was talking to the database:
- PHP and WordPress: a white screen, a half-rendered page, or "Error establishing a database connection"
- Command line imports:
ERROR 2006 (HY000) at line 8421partway through a dump - Laravel, Symfony, Magento:
PDOException: SQLSTATE[HY000] [2006]in the application log - Cron and backup jobs: silent failures that stop at roughly the same point every night
- Migrations: an import that halts at the same line on every attempt
The useful signal buried in the message is what it rules out. Wrong credentials produce error 1045 (access denied). A missing database produces 1049. Getting 2006 means authentication worked and the query started, so you are looking at a timing or size problem rather than a permissions one. That deduction saves an hour of resetting passwords you never broke.
It also explains why the error feels so random. One page loads, the next one dies, and refreshing sometimes fixes it for twenty minutes. Each PHP request opens a fresh connection, so whether it survives depends on how long that particular query runs and how much data it moves. Intermittent behaviour is normal here and tells you nothing on its own.
Oracle's own reference manual entry for the gone away error lists the full set of triggers, including killed threads and client-side read timeouts. In practice, four of them account for the overwhelming majority of real incidents.
The Four Causes, Ranked by How Often They Actually Happen
Ranked by how often they show up in production: idle timeouts, oversized packets, resource pressure, then a deliberately terminated connection.
1. The connection sat idle past wait_timeout
MySQL closes non-interactive connections after wait_timeout seconds. The stock default is 28800 seconds (8 hours), but shared hosts, Docker images and tuning scripts routinely cut it to 600 or even 60 to reclaim memory. A persistent connection or a long-running worker then wakes up and writes into a socket the server already closed. Raise the wait_timeout MySQL applies to idle connections.
2. The statement was bigger than max_allowed_packet
Any single statement, result row, or BLOB above max_allowed_packet gets the connection dropped rather than a catchable error. MySQL 8.0 and later ship a 64MB server default, the mysql command line client still defaults to 16MB, and MariaDB commonly ships 16M on both sides. The hard ceiling is 1GB.
3. The server ran out of headroom
When RAM is tight, the Linux OOM killer picks the fattest process, and on a web server that is usually MySQL. The tell is timing, since this version clusters at your busiest hours and vanishes overnight. Also seeing CPU or entry-process warnings? Start with Shared Hosting Resource Limit Exceeded: Causes & Fix (2026).
4. Something closed the connection on purpose
A KILL statement, a panel restarting MySQL for maintenance, PHP's max_execution_time expiring first, or a firewall dropping an idle TCP session all leave the same fingerprint.
Pro Tip: Run
SHOW GLOBAL STATUS LIKE 'Aborted%';before changing a single value. A climbingAborted_clientscounter means connections are closed after being established, which points at timeouts. A climbingAborted_connectsmeans they never got established, which points at credentials or networking.
Our engineers triage this with three questions:
- Fails at the same point every time? Size limit.
- Fails after a pause in activity? Timeout.
- Fails only when the site is busy? Resources.
From the Ticket Queue: According to Hostaccent's own support-queue data (as of July 2026), Linux server issues account for roughly 25% of the tickets we handle each month, and dropped connections sit near the top of that slice.
How to Fix MySQL Server Has Gone Away, Step by Step
Work through these in order. Steps 1 to 3 need no restart; step 4 survives a reboot.
Step 1: Read the current values. Log in with mysql -u root -p and run:
sqlSHOW VARIABLES LIKE 'max_allowed_packet'; SHOW VARIABLES LIKE 'wait_timeout'; SHOW GLOBAL STATUS LIKE 'Aborted_clients';
A max_allowed_packet of 16777216 is 16MB and 67108864 is 64MB. A wait_timeout under 300 on a WordPress host usually means someone tuned it too aggressively.
Step 2: Raise the packet ceiling on the running server.
sqlSET GLOBAL max_allowed_packet = 268435456;
That sets 256MB. It applies to new connections only, so reconnect before retesting, and it reverts on restart until you finish step 4.
Step 3: Give slow work more room.
sqlSET GLOBAL wait_timeout = 600; SET GLOBAL interactive_timeout = 600; SET GLOBAL net_read_timeout = 120; SET GLOBAL net_write_timeout = 120;
net_read_timeout and net_write_timeout are the two most people miss: a query can finish inside wait_timeout and still be cut off while a large result streams back.
Step 4: Make it permanent. Edit /etc/mysql/my.cnf (or /etc/my.cnf.d/server.cnf on MariaDB) and add:
ini[mysqld] max_allowed_packet = 256M wait_timeout = 600 interactive_timeout = 600 net_read_timeout = 120 net_write_timeout = 120 [mysqldump] max_allowed_packet = 256M
Then restart with systemctl restart mysql or systemctl restart mariadb. Be deliberate: a restart terminates every open connection, so pick your quietest window and check the error log afterwards to confirm your values loaded.
Live site and no time to experiment? Our engineers fix this exact error for a small one-time fee, and you get the exact quote before anyone touches your server. Hosted with Hostaccent already? Then a dropped database connection is simply covered by support, at no charge. Have an engineer fix it
Step 5: Check the PHP side. In php.ini, max_execution_time and default_socket_timeout (60 seconds by default) can both end a request before MySQL is finished. The old automatic reconnect setting is gone from current PHP releases, so retry logic belongs in your application. The mysqli configuration reference lists the rest.
Splitting a large import so the connection survives it
If a dump dies at the same line every run, it is a packet limit, and the client is usually at fault. Raising the server value will not help while the mysql client sits at its own 16MB default, so set both:
bashmysqldump --max_allowed_packet=512M --single-transaction --quick db_name > dump.sql mysql --max_allowed_packet=512M -u db_user -p db_name < dump.sql
If one table still breaks it, the culprit is usually a single enormous multi-row INSERT. Dump it again with --extended-insert=FALSE to write one statement per row. The file grows and the import runs slower, but no packet nears the ceiling.
Skip the browser entirely: phpMyAdmin adds its own upload cap (commonly 50MB), so move the file over SSH and import from the shell.
Pro Tip: Wrap long imports in
screenortmux. A dropped SSH session takes themysqlprocess with it, and you get the same 2006 error, caused by your own wifi. Oracle documents the 1GB maximum in its packet too large reference.
The WordPress Fixes That Still Work in 2026 (and the One That Doesn't)
Start with the advice to ignore. A large share of the pages ranking for the server has gone away in WordPress still tell you to edit wp-includes/wp-db.php and add a mysqli_query timeout. That file has been deprecated since WordPress 6.1 and now does nothing but load class-wpdb.php. Beyond that, any edit to a core file is erased by the next automatic update, so even when it appears to work, the fix silently vanishes within weeks.
Do this instead.
Repair the tables. Add define('WP_ALLOW_REPAIR', true); to wp-config.php, visit /wp-admin/maint/repair.php, run the repair, then delete the line again. Leaving it in place exposes that page to anyone. The WordPress documentation covers the constant and its risks.
Find the query that is actually too big. Install Query Monitor and reload the page that fails. Nine times out of ten it is one of four things: a bloated wp_options table with megabytes of autoloaded data, expired transients nobody ever cleared, a search-and-replace running across every post during a migration, or a backup plugin trying to dump the whole database inside a single web request.
Run SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload = 'yes'; and start worrying once the answer clears 1MB.
Use WP-CLI where you can. wp db size --tables shows you the offender in seconds, wp transient delete --expired clears the most common cause of wp_options bloat, and wp db repair does the same job as the browser tool without the security tradeoff. If the site is generally sluggish as well as erroring, work through WordPress Site Slow: Complete Diagnosis and Fix Guide (2026) once the connection is stable.
Do I actually need to edit any WordPress core files to fix this?
No. Every legitimate fix lives in wp-config.php, php.ini, my.cnf, or a plugin you can uninstall. If a tutorial asks you to open anything inside wp-includes, close the tab. Core edits break on update, complicate every future migration, and in this particular case target a file that has not held real code for several major releases. Server-level timeouts are also what drive High TTFB in WordPress, so tuning them does double duty for speed.
When It's Resources, Not Settings: What a Better Plan Changes
If you raised both values, restarted cleanly, and the error returned within a week, you are not looking at a misconfiguration. You are looking at a database that does not have enough memory to work with.
Three checks confirm it. Run dmesg -T | grep -i oom and see whether the kernel has been killing mysqld. Compare innodb_buffer_pool_size against the size of your actual data, because a 128MB buffer pool serving a 3GB WooCommerce database means the server reads from disk constantly. Then watch whether Aborted_clients climbs in step with traffic rather than sitting flat, and measure the data with du -sh /var/lib/mysql so you size against a real number.
On a busy shared database server, none of that is in your hands. Your queries compete for the same buffer pool and CPU as every other account on the box, and one neighbour's runaway export can push the instance into swap for ten minutes. That is the version of this error you cannot configure your way out of.
What dedicated database resources change is ownership. You get your own MySQL instance, RAM that nobody else can claim, and root access to my.cnf, which means the values from step 4 stay exactly where you set them. Sizing the buffer pool to match your actual working set is usually the biggest single win, and it is only available when the memory is genuinely yours. Sites already running short on memory should read Why Is My VPS Running Out of RAM? How to Diagnose and Fix It before sizing anything.
The honest version of the trade-off, though: a VPS also hands you the tuning job, the patching job, and the monitoring job. Across the 4,000+ site migrations our team has run since 2012, the pattern is consistent. Sites hitting this error weekly on shared hosting stop hitting it once the database has memory of its own, and sites that hit it during a single large import never needed to move at all. Database latency feeds straight into your rankings too, which is the link explored in Core Web Vitals Failing? Your Hosting Might Be the Problem.
Your Next Step: A Database That Stays Connected
You can now tell a packet ceiling apart from a starved server. If you fixed it yourself, put both values in my.cnf so the next restart cannot undo your work.
If you would rather the mysql server has gone away error stopped being your job, that is what a managed stack buys. The Economy shared hosting plan at $1.99/mo includes NVMe storage, a 99.9% uptime guarantee and 30 days to change your mind, and it renews at $1.99/mo. One honest limit: it is sized for a single site, so a heavy store belongs on something larger. Still stuck? Open a ticket and have an engineer look at it, with the exact quote shown before any work begins. Flat renewals and real engineers: that is the Hostaccent side of the bargain.
Frequently Asked Questions About MySQL Server Has Gone Away
What does the mysql server has gone away error mean in WordPress?
It means WordPress opened a connection to your database, sent a query, and found the connection closed before an answer came back. The database itself is fine in almost every case. The usual triggers are a wait_timeout set too low by the host, a query larger than max_allowed_packet, or a plugin trying to process the entire database inside one page load. None of them involve lost content.
Is my database lost when I get MySQL error 2006?
Almost never. Error 2006 describes a broken connection rather than damaged data, and your tables are sitting on disk exactly as they were a minute ago. Corruption reports a different error entirely, usually a table crash notice naming the specific table. Restore from a backup only if repair tools report actual damage. Reconnecting and re-running the failed query is the correct first response, not a panic restore.
What should I set max_allowed_packet to?
For most WordPress and WooCommerce sites, 256M is generous and safe. MySQL allocates that memory only when a large statement actually needs it, so a high ceiling costs you nothing during normal traffic. Go to 512M for one-off migrations of databases over 2GB, and remember the absolute maximum is 1GB. Set the same value under [mysqldump] so your backups do not fail for the opposite reason.
Why does the error only appear during large imports?
Because imports send single statements far bigger than anything your site produces in normal use. A dump built with extended inserts can pack thousands of rows into one INSERT, easily clearing the client's 16MB default. Regular page loads never come close, which is why the site works perfectly until you try to move it. Raise the limit on the client and the server, then run the import again.
Can wait_timeout be set too high?
Yes, and this is the trade-off nobody mentions. Every idle connection held open consumes memory and a slot against max_connections, so a very high timeout on a busy server can produce "too many connections" errors instead. Somewhere between 300 and 600 seconds suits most WordPress sites well. The 28800 second default exists for long-lived application servers, not for PHP sites opening and closing connections constantly.
How do I tell if my hosting plan is causing the connection drops?
Watch the timing. Configuration problems fail identically at 4am and 4pm; resource problems cluster at your traffic peaks and clear up overnight. Check whether Aborted_clients rises with visitor count and whether the kernel log shows the OOM killer touching mysqld. If both point at contention, your database needs memory that is not shared with strangers, which is exactly what the Hostaccent support team will tell you after reading those two numbers.
Discussion
Have a question or tip about this topic? Share it below — your comment will appear after review.