What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
MySQL error 2013, CR_SERVER_LOST, means the client lost its connection while communicating with the server. The message may read “Lost connection to MySQL server during query,” but the same failure can happen during the initial handshake, result transfer, or reuse of an idle pooled connection.
The reliable fix is to identify when the disconnect occurs, then change the matching endpoint, network, timeout, packet, or connection-pool setting. First verify that mysqld is running and that the client uses the correct host, port, socket, or named pipe. Do not increase every timeout at once: a generic change can hide a network fault, increase memory use, or cause duplicate writes after an unsafe retry.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problems
What MySQL error 2013 means
Error 2013 (CR_SERVER_LOST) is a client-side communication error. It does not identify one single root cause. MySQL can lose contact with the server at several phases:
| When it fails | Typical wording or symptom | Most likely area to investigate |
|---|---|---|
| Before login completes | “Reading authorization packet,” connection timeout, or failure immediately after starting the client | DNS, endpoint, firewall, server load, or connect_timeout |
| While a query is running | “Lost connection to MySQL server during query” | Network interruption, slow reads or writes, server crash, or a packet limit |
| While rows are being returned | Small results work but a large result stops partway through | net_write_timeout, client read timeout, network path, or oversized row/packet |
| After a long idle period | A pooled connection fails on its first statement after sitting unused | wait_timeout, interactive_timeout, or an idle firewall/router policy |
| Only with large values or bulk SQL | BLOBs, long strings, or large INSERT/REPLACE batches disconnect | max_allowed_packet on the server or client |
| At every attempt | Cannot establish a usable session at all | Wrong host, port, socket, named pipe, DNS, listener, or stopped server |
Oracle MySQL documentation describes frequent lost connections as usually indicating network connectivity trouble. It also identifies a server-side timeout as the most common explanation for “MySQL server has gone away.” Timing separates those broad categories much faster than changing variables at random.
#1 Best Overall
How do I fix “Lost connection to MySQL server during query”?
Use this order. It preserves evidence and limits each change to the phase that failed.
- Confirm the server and endpoint. Check that
mysqldis running and listening. Compare the client’s host, TCP port, Unix socket, or named pipe with the server configuration. A valid username and password cannot compensate for a wrong endpoint. - Record the exact phase. Note whether the message appeared during authorization, query execution, result reading, or reuse of an idle connection. Save the timestamp, host and port (or socket), query size, row count, driver version, server version, and whether the server restarted.
- Check logs and counters. Inspect the MySQL error log around that timestamp. Set
log_error_verbosityto3when more disconnect detail is needed. CheckAborted_connectsfor failed initial connections andAborted_clientsfor clients that disconnect improperly or are closed after idle periods. - Compare a small and a large request. Run a lightweight query, then reproduce with the same operation that failed. If the small request succeeds but a large BLOB, long string, or bulk statement fails, investigate packet limits. If both fail only on a slow or distant link, investigate network and read/write timeouts.
- Apply one narrow fix and retest. Change the setting associated with the observed phase, repeat the original workload, and compare the error log and counters before and after. Keep a record of the old value so the change can be reversed.
Quick endpoint checks
From the same machine and account that runs the application, test the intended endpoint explicitly:
mysql -h db.example.test -P 3306 -u app_user -pIf the deployment uses a Unix socket, use the configured socket instead of assuming TCP. If it uses a named pipe on Windows, verify that both the server and connector are configured for that pipe. A connection to a different server can look like a timeout or authentication problem while actually being an endpoint mistake.
Why does “MySQL server has gone away” happen?
That message commonly means the server timed out and closed an inactive connection, but it can also follow a crash, a network reset, or a packet-size violation. Treat it as a symptom. Correlate the client timestamp with the server error log and ask three questions:
- Did
mysqldrestart or report an out-of-memory, assertion, or fatal error? - Was the connection idle, and if so, for how long?
- Did the failed statement contain an unusually large value, row, or batch?
If the server process died, timeout tuning is not a fix. Preserve the error log, crash information, server version, and failing statement shape before restarting repeatedly.
Fix a wrong host, port, socket, DNS record, or network path
Endpoint errors must be corrected before variable tuning. Verify the hostname resolves to the intended address from the application host, that the configured TCP port is open in both directions, and that a firewall or load balancer is not sending traffic to an outdated backend. For local connections, compare the client’s Unix socket or named pipe with the listener used by mysqld.
Symptoms of an endpoint or network problem
- Every query fails, including a trivial connection test.
- The error changes when you switch between hostname and IP address.
- Connections work inside the database host but fail from the application host.
- Failures coincide with TCP resets, route changes, DNS outages, cable or switch faults, or load-balancer events.
- Only long transfers fail, suggesting an idle policy, packet loss, or a device that terminates slow sessions.
Check routing, DNS, firewall rules, load-balancer idle settings, and TCP reset events with the team responsible for the network. Connector documentation notes that the MySQL protocol does not automatically ping an idle connection; an intervening firewall or router can therefore close it without the application noticing.
Fix an initial handshake or authorization timeout
When the message mentions reading the authorization packet or the failure occurs before a session is established, investigate DNS resolution, server load, and the path between client and server first. Oracle MySQL documents a default connect_timeout of 10 seconds (2026 documentation). MySQL suggests increasing it when a slow or distant connection genuinely needs more time.
How to change it safely
- Measure the normal connection time from the application host and confirm that the server is accepting connections.
- Inspect the error log and
Aborted_connectsto distinguish slow authorization from rejected or malformed attempts. - Raise
connect_timeoutmodestly on the server configuration, or through the supported dynamic setting for your deployment. - Retest several fresh connections, including during the busiest expected period.
- Revert the increase if connections still fail at the same point; a longer timeout cannot repair bad DNS, a blocked port, or an overloaded server.
Increasing this value keeps connection attempts open longer and can consume more server and network resources when many clients are unreachable.
Fix a slow query or result transfer
For an active transfer, distinguish data moving from client to server from rows moving back to the client. Oracle MySQL documents a default net_read_timeout of 30 seconds (2026 documentation). It controls how long the server waits while reading more data from a client. A slow link, a very large statement, or millions of rows sent in stages may need a higher value.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #3
Server-to-client writes
Review net_write_timeout when the server is sending results and the client or network is too slow to accept them. Align the server setting with the client driver’s socket read timeout so the client does not give up first. Increasing only the server value cannot help if a proxy or driver closes the connection earlier.
Transfer troubleshooting steps
- Run a small query that returns a few rows.
- Run the failing query with a restricted result, such as a smaller date range or row limit, if that is safe for the application.
- Measure whether failure time is consistent with a timeout boundary.
- Check network latency, packet loss, and intermediary idle or maximum-duration policies.
- Increase
net_read_timeoutornet_write_timeoutonly when the evidence shows a legitimate slow transfer. - Retest with the original result size and compare the client and server logs.
Do not use a timeout increase to conceal an unbounded query. Reducing the result set, streaming rows correctly, paginating, or moving a large export to a controlled job can reduce the time a socket remains open.
Fix idle pooled connections and stale sessions
MySQL normally closes an inactive noninteractive connection after 8 hours by default; the configurable variable is wait_timeout. Interactive sessions use interactive_timeout. A firewall or router may impose a shorter idle limit, so matching the server timeout to the pool’s lifetime does not guarantee that an idle connection remains usable.
Pool settings that prevent stale-connection failures
- Set the pool’s maximum idle age below the shortest known server or network idle limit.
- Validate a connection before borrowing it, using the driver’s validation mechanism.
- Where supported, issue a lightweight
/* ping */query rather than a business statement to test liveness. - Enable TCP keepalive when it is appropriate for the operating system and network policy.
- Discard and recreate a connection after a failed validation instead of returning it to the pool.
Reconnect logic must be transaction-aware. If a write may have reached the server before the socket failed, blindly repeating it can create duplicate rows, duplicate charges, or other side effects. Use idempotency keys, transaction status checks, or application-specific recovery rather than an unconditional retry.
Fix oversized packets, BLOBs, and bulk statements
A MySQL communication packet can contain one SQL statement, one returned row, or a replication event. If either the client or mysqld receives a packet larger than its max_allowed_packet, MySQL issues ER_NET_PACKET_TOO_LARGE and closes the connection.
Rank #4
The documented server default is 64 MB, and the protocol maximum is 1 GB (Oracle MySQL documentation, 2026). Both client and server limits matter. Raising only the server value will not help a connector that still rejects the packet, and raising both values increases the maximum amount of memory a connection may need.
Packet-size diagnosis
- Small statements succeed while a BLOB, long text value, or very large INSERT/REPLACE fails.
- The failure occurs at roughly the same payload size on repeated attempts.
- The error log or client reports a packet-too-large condition.
Safer packet fixes
- Measure the largest statement, row, and parameter value generated by the application.
- Check the server value and the connector’s client-side value.
- Increase both limits only as far as the workload requires, with enough server memory for concurrent connections.
- Prefer smaller INSERT or REPLACE batches, chunked BLOB uploads, and bounded parameter sizes when the application permits them.
- Retest the largest legitimate payload, not merely a small sample.
A larger packet limit is not free capacity. If many sessions send large packets concurrently, memory pressure can trigger a separate server failure.
Inspect logs, status counters, and variable values
Capture a before-and-after snapshot whenever you change a setting:
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →SHOW GLOBAL STATUS LIKE 'Aborted_connects';
SHOW GLOBAL STATUS LIKE 'Aborted_clients';
SHOW GLOBAL VARIABLES LIKE 'connect_timeout';
SHOW GLOBAL VARIABLES LIKE 'wait_timeout';
SHOW GLOBAL VARIABLES LIKE 'interactive_timeout';
SHOW GLOBAL VARIABLES LIKE 'net_read_timeout';
SHOW GLOBAL VARIABLES LIKE 'net_write_timeout';
SHOW GLOBAL VARIABLES LIKE 'max_allowed_packet';Use the server error log to determine whether the server closed the connection, restarted, or reported a fatal condition. A rise in Aborted_connects points toward initial connection failures. A rise in Aborted_clients is consistent with clients disappearing, stale sessions being closed, or applications not terminating connections cleanly. Counters are supporting evidence; interpret them with timestamps and the exact client phase.
Choose the fix by failure phase
| Observed phase | Primary setting or component | What must change | Main risk | Verification |
|---|---|---|---|---|
| Initial handshake | connect_timeout, DNS, endpoint, server load |
Server configuration, client endpoint, or network | Longer-held connection attempts | Fresh connections succeed; Aborted_connects stops rising |
| Active read from client | net_read_timeout |
Server and, if applicable, client socket timeout | Sessions remain open longer | Large request completes without a read timeout |
| Result write to client | net_write_timeout and client read timeout |
Server, driver, or network path | More resources held during slow delivery | Large result transfers completely |
| Idle pool reuse | wait_timeout, interactive_timeout, pool validation, network idle policy |
Pool and network policy, sometimes server | Stale or unsafe retries | Borrowed connections pass validation after the normal idle interval |
| Large packet | max_allowed_packet and batch size |
Client and server, or application batching | Higher per-connection memory use | Largest valid payload succeeds without packet errors |
| All attempts | Listener, host, port, socket, named pipe, DNS | Endpoint or network | Diagnosing the wrong server | Explicit endpoint test reaches the intended instance |
Common mistakes and recovery paths
Changing every timeout together
This removes the timing clue that identifies the failing phase. Restore the documented or previously known values, reproduce the issue, and change only the variable associated with the observed message.
Raising max_allowed_packet without changing the client
The smaller side still rejects the payload. Confirm both values and consider smaller batches before increasing limits.
Assuming wait_timeout explains every “server gone away” error
An idle timeout cannot explain a failure during the first connection or a packet that is too large. Check the error phase, server restart history, and network events.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Retrying a failed write automatically
The server may have committed the write before the connection dropped. Determine whether the operation is idempotent or use an application-level idempotency mechanism before retrying.
Ignoring the server restart
If the error log shows that mysqld stopped or restarted, investigate crashes, resource exhaustion, and host health. Timeout changes will not correct a process that is terminating.
Preventing future lost-connection errors
- Keep a record of the server, connector, and operating-system versions for every incident.
- Monitor error-log events,
Aborted_connects,Aborted_clients, connection counts, and server restarts together. - Set pool idle and lifetime limits below the shortest confirmed network or server idle policy.
- Use bounded query results, streaming APIs, and controlled export jobs instead of unbounded result transfers.
- Chunk bulk writes and large BLOBs so one communication packet is not unnecessarily huge.
- Document which settings are global, session-specific, client-side, or controlled by a network device.
- Test recovery with a transaction-aware procedure before enabling automatic reconnects.
Final verification checklist
- The client reaches the intended host, port, socket, or named pipe.
- The exact disconnect phase and timestamp are recorded.
- The error log has been checked at the same timestamp, with
log_error_verbosity=3when necessary. Aborted_connectsandAborted_clientshave been compared before and after the change.- The selected timeout or packet setting matches the phase that failed.
- Client and server values are compatible.
- The original workload, including its real payload size and idle interval, has passed a repeat test.
- Any retry path has been reviewed for duplicate side effects.
Error 2013 is best solved as a communication-path diagnosis: verify the endpoint, classify the timing, use logs and counters, then apply the smallest phase-specific fix. That approach addresses network faults, handshake delays, slow transfers, stale pooled sessions, and oversized packets without turning a temporary symptom into a larger capacity or data-integrity problem.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
