“Connection refused”本质是网络通路未打通，卡在MySQL监听配置、服务器防火墙或云厂商安全组三层之一；需依次排查bind-address、firewall及安全组设置。
远程连接 MySQL 时“Connection refused”到底卡在哪一层
不是 DBeaver 的问题，而是网络通路没打通。这个错误在公共网络下最常见，但很多人一看到就去调 DBeaver 的 SSL 或驱动，白忙半天。真实原因通常是三层中某一层被拦住了：MySQL 服务未监听公网、服务器防火墙封了 3306、或云厂商安全组没放行端口。先确认 MySQL 是否允许远程连接：登录服务器执行 netstat -tuln | grep :3306，如果只显示 127.0.0.1:3306，说明 bind-address=127.0.0.1 没改；必须改成 0.0.0.0 并重启 mysqld。
不用 SSH 隧道时，SSL 连接必须手动填对这三项
公共网络直连数据库，不走 SSH 就只能靠 SSL 加密传输。但 DBeaver 的 SSL 标签页里一堆选项，真正影响连通性的就三个：使用SSL 必须勾选；验证服务器证书 在自签名或内网 CA 场景下建议关闭（否则报 PKIX path building failed）；CA 证书文件 路径必须是本地绝对路径，且文件权限可读（Windows 下注意反斜杠要写成双反斜杠或正斜杠）。MySQL 连接 URL 后还要补上参数：?useSSL=true&requireSSL=true&verifyServerCertificate=false，否则 DBeaver 可能忽略 SSL 设置。
用 SSH 隧道比开公网端口更简单也更安全
与其在云服务器上开 3306 端口并配 SSL，不如直接启用 DBeaver 内置的 SSH 隧道——它本质是把数据库连接流量套进已加密的 SSH 通道里，连证书都不用管。配置时注意：SSH 主机 填跳板机 IP，SSH 端口 通常为 22；数据库主机 要填 127.0.0.1（不是外网 IP），因为隧道另一头是连本机的 MySQL；数据库端口 保持 3306。如果 SSH 登录需要密钥，DBeaver 支持 .pem 或 id_rsa 文件，但不支持密码短语加密的私钥（会卡在认证环节）。
一款AI工具，主要用于运行或监督单遍 Codex 实现，包含预检门控、分步计划执行及严格的 QA 缺陷闭环。适用于执行已批准的售前...，适合需要提升相关任务效率的用户。
密码明文存本地？别信“自动保存”，改用密钥环或禁用
DBeaver 默认把密码以加密形式存在本地配置里，但加密强度依赖系统密钥环（如 Windows Credential Manager、macOS Keychain）。如果你用的是 Linux 桌面环境且没装 gnome-keyring 或 ksecretsservice，它会退化成弱加密甚至明文提示；此时务必在 Preferences → Connections → Connection settings 中取消勾选 Save passwords in connection configuration。更稳妥的做法是创建专用数据库用户，并限制其只读权限和 IP 白名单，而不是强依赖客户端密码保护。
公共网络下真正的风险点不在 DBeaver 设置本身，而在于你是否清楚流量实际经过哪几段链路——是直接暴露端口，还是经由跳板机转发，又或者混用了 SSL 和 SSH 两种机制却没关掉其中一种的验证逻辑。这些地方一旦错位，错误信息往往指向“连接失败”，但真实瓶颈可能隔了三层。
