Error 10054 signals that the TCP socket between database client and server was unexpectedly closed by the remote side, interrupting the query or transaction.
SQL Error 10054: Connection Forcibly Closed by Remote Host occurs when the database server or a network device abruptly terminates the TCP socket. Check firewalls, keep-alive settings, driver timeouts, and server logs; then re-establish or pool connections to resolve the issue.
Error 10054: A connection was forcibly closed by the remote host
Error 10054 is a Winsock connection-reset message that bubbles up through ODBC, JDBC, or native drivers when the database server or an intermediary network device kills an open TCP socket.
The error aborts the current query, cancels in-flight transactions, and forces the client to reconnect before any further SQL can be executed.
Network devices, firewalls, or load balancers may drop idle or long-running connections, instantly producing error 10054 on the next read or write.
Database servers themselves can send TCP RST packets when they crash, restart, hit resource limits, or close connections that exceed timeouts, also triggering 10054.
Begin by identifying whether the drop comes from the server or the network.
Review database logs for forced disconnects; if none appear, inspect firewall and proxy logs.
Raise TCP keep-alive, driver timeouts, and database wait_timeout values so intermediaries do not assume the connection is idle.
Bulk data loads may exceed proxy thresholds; splitting batches or using SET GLOBAL net_buffer_length can prevent sudden resets.
Long-running analytics in SQL Server often fail after 10 minutes when firewalls kill idle sockets; enabling TCP keep-alive or Galaxy’s auto-retry avoids interruption.
Use connection pooling libraries that automatically retry or open new sockets when 10054 occurs, reducing user impact.
Monitor round-trip latency and packet loss; high loss rates increase the odds of a mid-stream TCP reset and therefore error 10054.
Error 121 (“The semaphore timeout period has expired”) often indicates lower-level network trouble and can be resolved with the same keep-alive tuning.
MySQL “Server has gone away” maps to error 2006 and shares identical root causes; raising wait_timeout and max_allowed_packet typically resolves it.
.
If the server never received the COMMIT packet, your transaction is rolled back automatically.
No. A database process crash or manual KILL command can also trigger it.
Yes. Galaxy automatically reconnects and re-runs the query, and its history panel shows what succeeded or failed.
Only if middleboxes restrict MTU or buffer sizes; otherwise packet size is not a direct cause.
.png)
.avif){kind=logo}
