ora-28040只发生在低版本客户端连接高版本服务器（如11g客户端连19c数据库），19c客户端连11g服务器不会触发该错误；真实原因多为角色误判、jdbc堆栈误读、网络配置或密码状态问题。
Oracle 19c 客户端连接报 ORA-28040，基本可以确定你搞反了客户端和服务器角色——ORA-28040 不会由 19c 客户端连 11g/12c 服务器触发，它只出现在「低版本客户端 → 高版本服务器」场景（比如 11g 客户端连 19c 数据库）。你看到的错误，大概率是日志抄错、堆栈没看清，或者误把 JDBC 报错堆栈当成了服务端日志。
查清谁在连谁：ORA-28040 只发生在“老客户端连新库”
Oracle 的认证协议控制逻辑是单向的：SQLNET.ALLOWED_LOGON_VERSION_SERVER 是数据库服务器用来决定“谁能连我”，SQLNET.ALLOWED_LOGON_VERSION_CLIENT 是数据库自身作为客户端时（比如走 DB Link）去连别的库用的。19c 客户端（如 SQL*Plus、Navicat OCI 模式、Instant Client）本身不读服务端的 sqlnet.ora，也不受其中 _SERVER 参数影响；它只按自己驱动内建规则发起协商。而 11g 服务器压根没有 _SERVER 参数，不做协议版本校验，只认密码哈希格式（10G、11G）和账户状态。
所以如果你真用 19c 客户端连 11g 服务器失败，真实原因通常是：
-
ORA-12514（服务名不对）、ORA-12170（TNS timeout）、防火墙拦截 - JDBC URL 里用了 19c 才支持的语法（比如
oracle.net.authentication_services=(KER)） - 用户被锁、密码过期、监听器没起来
- 应用实际走的是 JDBC Thin 模式，但你却去改服务器端
sqlnet.ora（它根本不用这个文件）
JDBC Thin 连 19c 报 ORA-28040？看堆栈里的包名
真正该怀疑 ORA-28040 的场景，是 Java 应用用 JDBC 连 19c 数据库失败，且错误堆栈里出现 oracle.jdbc.driver.T4CTTIoauthenticate.receiveOsesskey 或 oracle.jdbc.driver. 开头的类。这说明握手卡在客户端驱动层，服务器是 19c 或更高。
此时问题不在服务端参数配置，而在：
- 驱动版本太旧：必须用
ojdbc8.jar（对应 JDK 8+）或ojdbc11.jar（JDK 11+），ojdbc6.jar和更早的不支持 SHA-2 密码哈希 - JVM TLS 版本未启用：JDK 8u161+ 默认禁用 TLSv1.1，需确保 JVM 启动参数含
-Dhttps.protocols=TLSv1.2 - 连接字符串里漏了
?useSSL=false（仅限某些旧版驱动兜底，不推荐）
改 sqlnet.ora 之前先确认它是否生效
如果确认是「11g/12c 客户端连 19c 服务器」出的 ORA-28040，才需要动服务端 sqlnet.ora。注意以下几点：
- 文件必须放在数据库服务器端：
$ORACLE_HOME/network/admin/sqlnet.ora（Linux）或%ORACLE_HOME%\network\admin\sqlnet.ora（Windows） - 必须同时设置两个参数，缺一不可：
SQLNET.ALLOWED_LOGON_VERSION_SERVER = 12和SQLNET.ALLOWED_LOGON_VERSION_CLIENT = 12 - 写错参数名（比如漏掉
_SERVER后缀）或文件编码带 BOM，Oracle 会静默忽略整行，日志里查不到加载痕迹 - 改完必须重启监听器：
lsnrctl stop && lsnrctl start；部分环境还需重启数据库实例才能生效 - 即使参数设对，若用户密码仍是 10G 格式（
SELECT password_versions FROM dba_users WHERE username = 'XXX'返回只有10G），仍会紧接着报ORA-01017，需重置密码生成 12C/19C verifier
最常被忽略的一点：JDBC Thin 模式下，sqlnet.ora 完全无效。这时候调参数、重启监听、甚至重启数据库，都解决不了问题——得换驱动、调 JVM、检查连接串。
