DBeaver导入项目后出现getsockopt连接拒绝错误求助

核心排查方向 #

导入DBeaver项目后出现的连接失败，大概率是端口转发链路被干扰或者DBeaver配置被项目覆盖导致的，按以下步骤逐一排查：

1. 验证WSL2端口映射是否正常 #

Windows侧的localhost:6432是通过portproxy转发到WSL2内部的，先确认这条链路没断：

• 打开PowerShell，执行：

  netsh interface portproxy show all
  

  检查是否存在0.0.0.0:6432指向WSL2内部IP的条目（WSL IP可以通过wsl hostname -I获取）
• 如果没有该条目，重新配置转发：

  # 先获取WSL2的IP
  $wslIp = wsl hostname -I | Trim
  # 添加端口转发
  netsh interface portproxy add v4tov4 listenport=6432 listenaddress=0.0.0.0 connectport=6432 connectaddress=$wslIp
  

• 进入WSL2终端，确认端口被监听：

  ss -tulpn | grep 6432
  

  必须看到有进程（比如Rancher相关的转发进程）在监听6432端口

2. 检查DBeaver的网络配置是否被覆盖 #

导入的项目可能自带全局网络设置，覆盖了本地的正常配置：

• 打开DBeaver，进入编辑 > 偏好设置 > 连接 > 网络，确认代理设置为「无」，没有强制使用特定代理或网络接口
• 逐个检查连接的「连接设置」：确认主机是localhost，端口是6432，没有被项目导入时修改为其他值
• 可以尝试新建一个空白工作区，先手动创建一个能正常连接的配置，再导入项目，对比配置差异

3. 确认Rancher Desktop的集群端口转发有效 #

WSL2内部的6432端口需要映射到内网集群的服务，先验证WSL内部的连通性：

• 在WSL2终端执行Postgres测试命令（Oracle同理用对应的客户端）：

  psql -h localhost -p 6432 -U 你的用户名 -d 目标数据库名
  

  如果WSL内部能连接，说明问题出在Windows侧的portproxy或DBeaver；如果WSL内部也连不上：
  • 打开Rancher Desktop，进入Settings > Port Forwarding，确认6432端口已正确绑定到集群内的目标服务
  • 重启Rancher Desktop的Kubernetes集群，或者重新配置集群内的Service端口转发规则

4. 修复DBeaver的配置冲突 #

如果是项目导入导致的配置污染，直接清理旧配置：

• 关闭DBeaver，找到配置目录（默认路径：C:\Users\你的用户名\.dbeaver或.dbeaver4）
• 备份data-sources.json和connections.xml后删除这两个文件
• 重新启动DBeaver，先恢复之前能正常连接的手动配置，再逐步导入项目中的连接，避免一次性覆盖所有配置

5. 排除Windows防火墙干扰 #

临时关闭Windows防火墙测试连接，如果能正常连接，说明是防火墙拦截了：

• 打开Windows Defender防火墙，添加入站规则：允许6432端口的TCP连接
• 添加出站规则：允许DBeaver程序访问网络

内容的提问来源于stack exchange，提问作者Petersaber