ORA-28040错误本质是Oracle 21c服务端强制拦截不兼容认证协议的连接，因默认SQLNET.ALLOWED_LOGON_VERSION_SERVER=12要求SHA-256，而旧客户端（如ojdbc8）仅支持AuthenticationProtocol=11及以下，导致握手被熔断，必须升级客户端或谨慎降级服务端协议并同步管理用户PASSWORD_VERSIONS。
oracle 21c 默认拒绝旧版客户端连接，根本原因不是“连不上”，而是它主动关闭了握手通道——ora-28040 错误背后是服务端强制执行的认证协议拦截，靠客户端改配置或重试无法绕过。
ORA-28040 不是网络问题，是服务端协议熔断
旧版客户端（如 Oracle 11g/12c 客户端、ojdbc8、ODP.NET 19.x）默认使用 AuthenticationProtocol=11 或更低（SHA-1 / MD5），而 Oracle 21c 在 sqlnet.ora 中默认启用 SQLNET.ALLOWED_LOGON_VERSION_SERVER=12，相当于在入口处加了一道安检闸机：不满足 SHA-256 认证能力的连接请求，直接丢弃，连 TCP 握手完成后的 SSL 协商阶段都进不去。
- 现象：客户端日志只显示“TNS: no listener”或空连接超时，Wireshark 抓包可见服务端在收到 Client Hello 后立即发 RST
- 关键证据：数据库 alert.log 里会出现
WARNING: inbound connection timed out (ORA-3136)或明确写Authentication protocol mismatch - 注意：
SQLNET.ALLOWED_LOGON_VERSION_CLIENT是客户端参数，对 21c 服务端无效，别白配
调整 SQLNET.ALLOWED_LOGON_VERSION_SERVER 必须配合 PASSWORD_VERSIONS
单纯把 SQLNET.ALLOWED_LOGON_VERSION_SERVER 改成 8、10 或 11 是危险操作，可能让已哈希的用户密码失效——因为 Oracle 会按最低协议版本重新生成密码散列，导致高版本客户端反而连不上。
- 先查用户当前支持的协议版本：
SELECT username, password_versions FROM dba_users WHERE username = 'HR'; - 若结果含
12C或21C，说明该用户密码已升级；此时设ALLOWED_LOGON_VERSION_SERVER=11会导致该用户无法用 21c 客户端登录 - 安全做法：仅对明确需兼容的老客户端用户（如报表工具专用账号），用
ALTER USER hr IDENTIFIED BY VALUES '...'手动注入旧格式哈希（需提前从 12c 环境导出），再设ALLOWED_LOGON_VERSION_SERVER=11 - 生产环境强烈建议设为
12（最低要求），然后升级客户端，而非降级服务端安全水位
OOB（Out-of-Band）参数不是万能开关，它只影响部分路径
网上流传的 SQLNET.OUTBOUND_CONNECT_TIMEOUT 或 DISABLE_OOB=ON 配置，对解决 ORA-28040 完全无效。这些参数控制的是连接建立后的中断检测或紧急中断信号（如 Ctrl+C），和认证协议协商完全不在同一协议层。
-
DISABLE_OOB=ON仅影响 Oracle Net 的紧急数据通道，用于ALTER SYSTEM KILL SESSION类操作，与登录握手无关 -
SQLNET.INBOUND_CONNECT_TIMEOUT控制服务端接受连接后等待客户端发送第一个包的超时，但ORA-28040发生在更早的协议协商阶段，此参数尚未生效 - 真正起作用的只有两个服务端参数：
SQLNET.ALLOWED_LOGON_VERSION_SERVER和配套的用户密码版本管理
最易被忽略的一点：修改 sqlnet.ora 后必须重启监听器（lsnrctl reload），但无需重启数据库实例；然而如果客户端已缓存 TNS 别名解析结果（比如用 tnsping 测试过），需清空本地 tnsnames.ora 缓存或重启应用进程，否则仍走旧协商路径。
