OpenTextSocket代理Azure PostgreSQL：HeidiSQL正常但Spring Boot连接失败

• 抛出的java.net.SocketException: Bad address: connect并非PostgreSQL JDBC驱动与libpq-12.dll的连接协议逻辑差异导致，本质是Java应用的数据库连接流量没有被正确路由到OpenTextSocket代理的转发通道，与HeidiSQL的连通性表现差异来自两者对系统网络栈的适配逻辑不同：
  • HeidiSQL依赖的libpq库直接调用系统原生Socket接口，会自动匹配OpenTextSocket客户端在本地系统建立的虚拟网卡路由规则，也就是工具界面显示的1.0.0.1代理映射。这个映射会把对特定虚拟地址的访问流量自动劫持转发到真实的Azure PostgreSQL实例，因此可以正常连通。
  • 当前配置的JDBC URL直接使用了Azure PostgreSQL的公网域名XXX.postgres.database.azure.com，Java进程会对这个公网域名做独立的DNS解析，直接发起公网直连，完全绕开了OpenTextSocket的本地虚拟路由。由于本地公网环境本身不具备Azure PostgreSQL的直连网络可达性，Socket层无法建立合法连接，最终抛出Bad address的连接异常。
  • Java自带的网络栈实现不会自动继承系统级别的路由表规则，和libpq走原生系统Socket的逻辑存在天然差异，这才是连通性不一致的根本原因。

• 替换JDBC连接目标地址
  把原来配置的真实Azure公网域名，替换为OpenTextSocket对应的本地虚拟映射地址1.0.0.1，端口与HeidiSQL里配置的代理映射端口保持一致（通常为5432），调整后的连接URL格式为：jdbc:postgresql://1.0.0.1:5432/dev。注意Azure PostgreSQL的用户名格式仍需保留用户名@数据库实例名的要求，不会因为连接入口地址变化改变数据库侧的身份校验规则。
• 调整Java网络栈的适配逻辑
  如果替换本地虚拟地址后仍连接失败，需要从Java进程的网络配置层面做适配：
  • 启动Spring Boot应用时追加JVM参数，强制Java网络栈优先使用IPv4协议栈访问本地虚拟网卡，避免IPv6路由匹配失败，对应参数为：-Djava.net.preferIPv4Stack=true -Djava.net.preferIPv6Addresses=false
  • 如果OpenTextSocket采用SOCKS代理模式转发流量，可以直接在JDBC连接参数中显式声明代理配置，不依赖系统路由规则，在原有连接URL后追加参数：?socksProxyHost=127.0.0.1&socksProxyPort=OpenTextSocket对应的SOCKS监听端口，让JDBC驱动的连接流量直接通过代理端口转发。
• 跨进程网络可达性验证
  不要直接用HeidiSQL的连通性代替Java进程的连通性判断，需要在Java应用的运行环境下，编写简单的Socket测试脚本，验证配置的连接地址、端口是否可以正常建立TCP连接，排查因为权限隔离导致的网络访问失败。
• 权限类问题排查
  如果始终抛出Bad address错误，需要检查Java进程与OpenTextSocket客户端的运行权限是否一致：比如Windows环境下如果OpenTextSocket是普通用户权限启动、Java应用是管理员权限运行，会因为跨权限访问虚拟网卡接口被系统拒绝，导致Socket连接失败。

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