Connection refused 说明目标端口无服务监听，与密码、驱动、SSL等无关；需依次排查数据库服务状态、监听地址（如0.0.0.0:3306）、端口配置及防火墙/安全组策略。
Connection refused 一定是端口没通，不是密码或驱动问题
这个错误说明 DBeaver 已发出 TCP 请求，但目标地址+端口上压根没人监听。它卡在连接建立最前端，和账号密码、JDBC 驱动版本、SSL 设置全无关。你填对了密码也连不上，换驱动也白搭。
排查必须从宿主机视角出发，分三步验证：
- 确认容器确实在运行且端口已映射：
docker ps输出里PORTS列必须有类似0.0.0.0:3306->3306/tcp的条目；若只有3306/tcp，说明启动时漏了-p，得重建容器 - 确认宿主机能自己连通该映射端口：
telnet 127.0.0.1 3306或nc -zv 127.0.0.1 3306；失败就不是 DBeaver 的问题，而是 Docker 映射没生效或服务根本没起来 - 确认数据库进程真在监听外部请求：进容器执行
ss -tlnp | grep :3306，看监听地址是不是*:3306或0.0.0.0:3306；如果是127.0.0.1:3306，MySQL/PostgreSQL 就拒绝所有外部连接，需改配置文件里的bind-address
DBeaver 主机字段填 127.0.0.1 还是容器 IP？看你怎么暴露端口
填错主机地址是新手最常踩的坑。关键判断依据只有一个：你用的是宿主机端口映射，还是跨 Docker 网络直连。
绝大多数情况——用 docker run -p 3306:3306 或 ports: ["5432:5432"] 启动的——DBeaver 的主机必须填 127.0.0.1，端口填映射到宿主机的那个数字（比如 3306）。此时你连的是“宿主机的 3306”，Docker 内核自动转发到容器内。
只有当你明确需要容器间通信（比如另一个应用容器要连数据库容器），才用容器 IP：docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' 取出的 172.17.0.2 这类地址，此时端口必须填容器内数据库监听的真实端口（如 3306），**绝不能填宿主机映射端口**。
KingBaseES / TDengine 等国产库连不上，大概率是驱动不对
PostgreSQL 驱动能连上 KingBaseES 或 TDengine 的表，但很快会在元数据加载、类型识别、函数调用等环节报错。这不是“勉强能用”，而是“表面通、深层断”。
必须用官方 JDBC 驱动：
- KingBaseES：去人大金仓官网下载
kingbase8-8.x.x.x.jar，在 DBeaver 的“驱动管理器”中新建驱动并导入该 JAR；不要复用 PostgreSQL 模板 - TDengine：官方驱动包名含
taos-jdbcdriver，注意区分社区版与企业版；Maven 下载失败（如 URL 出现.${packaging.type}）就手动下载 JAR 加载 - 加载后检查驱动类名：
com.kingbase8.Driver或tsql.TSDBDriver，不是org.postgresql.Driver
端口映射“看起来存在”但实际失效，可能是 NAT 规则残留
曾遇到 docker ps 显示 0.0.0.0:6041->6041/tcp，但 tcpdump 抓包发现流量被 DNAT 到一个早已删除的旧容器 IP（如 172.17.0.4），而当前 TDengine 容器 IP 实际是 172.17.0.5。这是 Docker 网络规则未及时刷新导致的“幽灵映射”。
解决方法很直接：
- 停掉相关容器：
docker stop - 删掉容器：
docker rm - 清理网络残留：
docker network prune（慎用，会清空所有未使用的自定义网络） - 重启 Docker 服务：
sudo systemctl restart docker（最彻底，尤其在长期运行的服务器上）
这类问题不会报具体错误，只会表现为“连接超时”或“Connection refused”，且反复 docker restart 无效——必须重置网络状态。
