Connection reset by peer本质是TCP层RST包触发的强制断连，非HTTP错误；常见原因包括云数据库wait_timeout过短、防火墙/NAT超时、SSH跳板机中断、服务端主动kill连接及客户端未启用保活心跳。
Navicat 连接外网数据库被对端重置（Connection reset by peer）的常见原因
这不是 Navicat 本身的问题，而是 TCP 层连接在中途被主动关闭，且关闭方不是 Navicat。最常发生在：云数据库（如阿里云 RDS、腾讯云 CDB）、带防火墙/NAT 的中间设备、SSH 跳板机，或数据库服务端主动 kill 连接时。错误现象通常是执行中突然中断，报错含 Connection reset by peer 或 Lost connection during query，而非超时等待。
检查数据库服务端的 wait_timeout 和 interactive_timeout
这两个参数直接决定空闲连接存活时间。云数据库通常禁用 SET GLOBAL，只能通过控制台修改参数组；自建库可临时调整：
-
SHOW VARIABLES LIKE 'wait_timeout';—— 控制非交互式连接（如 Navicat 自动任务、定时导出） -
SHOW VARIABLES LIKE 'interactive_timeout';—— 控制交互式连接（如手动查询窗口） - 两者建议设为相同值（例如
28800秒），否则容易出现“一个连着，另一个断了”的不一致行为 - 永久生效需在 MySQL 配置文件
[mysqld]段添加并重启mysqld，仅SET SESSION无效于后续新连接
Navicat 客户端必须启用的三项保活配置
只调服务端参数没用——客户端不发心跳，服务端照样当你是死连接。这三个开关缺一不可：
- 编辑连接 → “高级” → 勾选
Reconnect when connection is lost：这是真重连机制，不是简单提示报错 - 同页勾选
Keep connection alive，值设为60；**不要勾选“仅当有查询时发送 ping”**：同步/导出/备份阶段无 query，不勾等于白开 - 工具 → 选项 → 环境 → “保持连接间隔”设为略小于服务端
wait_timeout（例如服务端是 300 秒，这里设240）
容易被忽略的隐性断连诱因
即使心跳和重连全开，以下情况仍会触发 Connection reset by peer，且不走重连流程：
- 执行无
LIMIT的DELETE FROM logs WHERE created_at ：连接长期占用，<code>wait_timeout不起作用，但服务端可能因执行超时直接KILL -
ORDER BY status, created_at LIMIT 20却只有status单列索引：触发Using filesort，查询拖慢，中间链路（如 NAT 网关）先断 - 事务未结束：
BEGIN后没COMMIT或ROLLBACK，连接卡在非空闲态，心跳包被忽略，重连不触发 - 走 SSH 隧道时，跳板机
/etc/ssh/sshd_config缺少ClientAliveInterval 30和ClientAliveCountMax 3：SSH 层先断，MySQL 层根本收不到请求
真正麻烦的是这种“连接看似活着、实则已废”的状态——它不报错，也不重连，就卡在那里等 timeout，直到某次发包被对端拒绝，才爆出 Connection reset by peer。
