一、问题现象
近期处理了一起现网问题：uxdbadmin 无法连接部署于麒麟 V10（ARM）上的数据库。同一套环境在内部测试时连接正常，到了现网却始终连不上，报错为 Error getting JDBC meta data，随后连接被关闭。
二、排查过程
1. 排除操作系统安全设置
起初怀疑是麒麟系统的安全设置限制（如内核参数、防火墙、SELinux 或安全加固策略）。逐项核查并排除后，问题依旧存在，说明故障点不在操作系统层面。
2. 用 uxsql 对照，定位故障边界
随后测试发现，使用 uxsql 以默认方式远程连接该库可以正常连通。
这一对照结果价值很大：数据库服务本身正常、端口可达、账号可用，问题并不出在数据库这一端。在相同链路下，uxsql 能通而 uxdbadmin 不能通，说明被拦截的是具有特定流量特征的那部分连接，而非网络整体不通。怀疑范围由此从"服务端故障"收敛到"针对性的流量拦截"。
3. 跨网段判断，转入抓包分析
进一步核对发现，客户端与服务端不在同一网段（客户端 10.2.242.x，服务端 10.2.197.x），访问需经中间网络设备转发。既非本机直连，就不能只看两端日志，于是转入抓包分析。
4. 抓包取证：RST 来源可疑
抓包结果显示：连接过程中确实出现了 RST 报文，但 RST 并非由客户端或服务端发出。报文源地址虽指向这两端，实际来源却是中间设备。
TCP 连接由第三方以两端地址伪造 RST 强制中断，是典型的链路设备主动阻断特征。据此判断，故障链路上存在安全设备对连接进行了干预。
三、根因与解决
将分析结果反馈客户后，客户对该链路进行排查，确认中间部署了 WAF（Web 应用防火墙）。
调整 WAF 针对该访问的放行策略后，uxdbadmin 连接恢复正常，问题解决。
四、经验总结
出现"端口可达但特定客户端连不上"的现象时，应优先排查链路中间的安全设备，不要过早陷入后端应用与数据库的排查。先做连通性对照实验（如换用不同客户端），能快速划定故障边界。
RST 报文的源地址不可轻信，需结合网络拓扑判断是否由中间设备伪造。两端都没有发出 RST 却出现了 RST，基本可以认定链路存在主动阻断。
安全设备除显式策略外，默认策略同样要纳入排查范围。 部分拦截正是由默认策略本身触发的，若不调整默认策略，问题仍会复现。