MySQL ERROR 2013: Lost Connection to Server During Query

Error 2013 is a client-side error: the connection to MySQL was established, then dropped while a request was in flight. The cause is either the server closing the connection (a timeout, a limit or a crash), or something between you and the server cutting it.

ERROR 2013 (HY000): Lost connection to MySQL server during query
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0

The second form, which mentions "reading initial communication packet", means the drop happened during the handshake, before any query ran. That points at the network, a firewall, a proxy protocol mismatch, or a server that is overloaded or out of connections.

Step 1: has the server just restarted?

Check uptime and the error log before anything else:

SHOW GLOBAL STATUS LIKE 'Uptime';

A small number means MySQL restarted recently. Read the error log (path from SHOW VARIABLES LIKE 'log_error') around the time of the failure. A crash looks like "mysqld got signal 11" or "InnoDB: Assertion failure". An out-of-memory kill leaves nothing in MySQL's log, so check the kernel:

sudo dmesg -T | grep -i -E "out of memory|killed process"
sudo journalctl -k | grep -i oom

If the OOM killer chose mysqld, reduce memory settings such as innodb_buffer_pool_size, per-connection buffers and max_connections, or add RAM or swap. If the server crashed, fix that first, and see MySQL server has gone away for the sibling symptom.

Step 2: the query ran longer than a timeout

While the server sends or receives data, three settings apply:

• net_read_timeout (default 30 seconds): how long the server waits for more data from the client mid-request.
• net_write_timeout (default 60 seconds): how long it waits to write to the client. A slow client reading a huge result set can trigger it.
• wait_timeout (default 28800 seconds): idle connection lifetime. Hitting this is more likely to give error 2006 on the next query.

Check and raise as needed:

SHOW VARIABLES LIKE 'net_%_timeout';
SET GLOBAL net_read_timeout = 120;
SET GLOBAL net_write_timeout = 300;

Put the values in [mysqld] in my.cnf to keep them. Big imports and exports over a slow link are classic triggers. Also consider whether the query should take that long at all: add indexes, paginate, or stream.

There are client-side limits too: PHP's mysqlnd and connectors have their own read timeouts, and PHP's max_execution_time may kill the script. Check your driver settings.

Step 3: packet size

A statement bigger than max_allowed_packet can cause a dropped connection on some versions rather than a clean error. Check the value and raise it on both sides, as covered in error 1153.

Step 4: something in the network is cutting idle or long connections

Firewalls, NAT gateways, load balancers and proxies all drop connections that look idle for too long, often between 60 seconds and an hour depending on the device. A long-running query sends no packets until it finishes, so the middlebox drops the flow. Symptoms: the failure always occurs after about the same number of seconds.

Fixes:

• Enable TCP keepalive on the client (the OS-level net.ipv4.tcp_keepalive_time on Linux, or the driver's keepalive option).
• Use a shorter query, or run it closer to the database.
• Raise the idle timeout on the load balancer, NAT or proxy such as ProxySQL, HAProxy or a cloud load balancer, if configurable.
• Test the path with the Port Checker and check whether the failure depends on location with Down From Where.

Step 5: connection limits and handshake failures

If you see the "reading initial communication packet" variant, check:

SHOW GLOBAL STATUS LIKE 'Aborted_connects';
SHOW GLOBAL STATUS LIKE 'Aborted_clients';
SHOW VARIABLES LIKE 'connect_timeout';

Aborted_connects rising points to failed handshakes (bad credentials, protocol or TLS mismatches, port scanners). A client connecting to the wrong port, for example a PostgreSQL or HTTP port, produces exactly this text. Also look at too many connections. In a MySQL 8 and MariaDB mix, mismatched TLS settings can also produce handshake drops.

Step 6: reproduce and narrow down

1. Run the failing statement from the mysql client on the database server itself. If it works locally, the network is the culprit.
2. Run it from the app host with mysql -h. If this fails while the local one works, check the firewall.
3. Time how long it runs before failing. A constant time suggests a timeout, a random one suggests a crash or network loss.
4. Check whether other queries are also failing, with an Uptime Monitor on a database-backed page.

Next steps

• Review MySQL server has gone away.
• Raise the packet limit with error 1153.
• Learn why connections drop in ERR_CONNECTION errors explained.
• Find out where a failure begins with the Outage Root Cause Finder.

FAQ

What is the difference between errors 2013 and 2006?

2013 happens while a query is running or during the handshake. 2006 ("server has gone away") typically appears when you reuse a connection the server already closed.

Should I set net_read_timeout very high?

Only as far as needed. Very high values let stuck clients hold connections, so raise it moderately and fix the slow query or transfer.

Can a firewall cause this?

Yes. Idle or long-lived connections cut by a firewall, NAT or load balancer look exactly like this to the client.

Does the error mean data was lost?

The interrupted statement was not committed unless it had already finished. Check whether your transaction completed before retrying.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.