“Connection reset by peer”表明数据库服务端主动断开已建立的连接，主因是MySQL的wait_timeout/interactive_timeout超时、中间设备空闲断连或SSL/认证配置不匹配。
Connection reset by peer 说明数据库服务主动断开了连接
这个错误不是“连不上”，而是“连上了又立刻被踢”。TCP 连接已建立，MySQL 或 PostgreSQL 已完成握手、认证成功，但在执行查询前或空闲期间被服务端强制关闭。它和 Connection refused 完全不同——后者是没人接电话，前者是接了电话但对方说完一句“你别说了”就挂了。
检查 MySQL 的 wait_timeout 和 interactive_timeout
MySQL 默认会在空闲 8 小时后关闭连接，DBeaver 如果长时间没操作（比如切去写文档半小时），再点查询就容易触发 Connection reset by peer。这不是网络问题，是服务端策略。
-
wait_timeout控制非交互式连接的超时（如 JDBC 连接），默认 28800 秒（8 小时） -
interactive_timeout控制交互式连接（如 mysql 命令行），默认也是 28800 - 可在 MySQL 中执行
SHOW VARIABLES LIKE '%timeout%';查看当前值 - 临时调高：执行
SET GLOBAL wait_timeout = 86400;（需 SUPER 权限） - 永久生效：在
/etc/mysql/my.cnf的[mysqld]段下添加wait_timeout = 86400
验证是否由防火墙或中间设备重置连接
企业网络、云安全组、甚至某些家用路由器会主动中断“空闲 TCP 连接”，尤其当连接保持长时未发包。这类重置不经过数据库，但表现一样。
- 用
telnet your-mysql-host 3306连上后不输入任何内容，等 2–3 分钟，看是否突然断开 - 若 telnet 也复现断开，基本可判定是中间网络设备所为
- 检查云平台安全组是否有“连接空闲超时”设置（如阿里云 SLB 默认 900 秒）
- 本地防火墙（如 Windows Defender 高级安全防火墙）可能启用“TCP 空连接检测”，需禁用
排查 SSL/TLS 握手后不兼容导致的重置
MySQL 8.0+ 默认启用 caching_sha2_password 认证插件，并常配合强制 SSL。如果 DBeaver 连接串里没配对，服务端可能在认证完成后、首次查询前直接 RST。
- 在 DBeaver 连接编辑页 → “驱动属性”标签页，确认以下两项：
-
useSSL设为false（测试阶段先关掉） -
allowPublicKeyRetrieval设为true（应对 caching_sha2_password） - 若必须用 SSL，确保 MySQL 服务端证书可信，且 DBeaver 的 JVM 信任库包含对应 CA
- JDBC URL 示例：
jdbc:mysql://localhost:3306/test?useSSL=false&allowPublicKeyRetrieval=true
真正麻烦的点往往不在配置本身，而在于“重置”发生在连接建立之后——这意味着你得区分是数据库自己关的、网络设备截的、还是驱动和认证机制不匹配导致的伪正常握手。每种情况的日志位置、复现节奏、影响范围都不同，不能只盯着 DBeaver 报错框看。
