ODP.NET 连接 TCPS 必须显式指定 PROTOCOL=tcps 及正确 SSL 端口（如 2484 或云服务提供的端口），配合 Wallet Location 绝对路径与严格权限，并使用 Oracle.ManagedDataAccess 3.21.10+ 以支持 SHA256 证书；Easy Connect 不支持 TCPS，且加密生效需通过抓包和 SQL 查询双重验证。
ODP.NET 连接字符串里怎么写 TCPS 协议
tcps 不是加个 ssl=true 就能通的——odp.net 要求协议名必须显式写成 tcps，且端口得是数据库监听器实际配置的 ssl 端口（通常是 2484，不是默认的 1521）。如果连的是 oracle cloud atp 或自治数据库，端口和主机名都由云控制台提供，不能手猜。
常见错误现象：ORA-12537: TNS:connection closed 或直接超时，大概率是协议/端口不匹配，或者服务端根本没开 TCPS 监听。
Data Source=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=mydb.adb.us-ashburn.oraclecloud.com)(PORT=1522))(CONNECT_DATA=(SERVICE_NAME=xxxxxx_adb_high.atp.oraclecloud.com)));- Windows 上若用 Easy Connect 语法，
mydb.adb.us-ashburn.oraclecloud.com:1522/xxxxxx_adb_high.atp.oraclecloud.com会失败——Easy Connect 不支持 TCPS，必须用完整 TNS 描述符 - 连接字符串中不要加
Encrypt=true或TrustServerCertificate=true：ODP.NET 对 TCPS 自动启用加密，这些参数只对非 TCPS 的传统 SSL/TLS 场景有效，混用反而触发校验冲突
Wallet 文件路径和权限怎么设才不报 ORA-28759
ORA-28759: failure to open file 是 Wallet 集成最常卡住的地方。ODP.NET 不读取环境变量 TNS_ADMIN，它只认连接字符串里的 Wallet Location 参数，或 .NET 配置中的 oracle.manageddataaccess.client 节点。
使用场景：本地开发、容器部署、IIS 应用池——三者对文件路径解析逻辑不同，尤其 Windows 下的权限陷阱多。
- 推荐方式：在连接字符串中硬编码绝对路径，例如
Wallet Location=C:oraclewalletsmywallet;；路径末尾不能有反斜杠，否则 ODP.NET 会拼出C:oraclewalletsmywallet\cwallet.sso导致找不到文件 - Linux 容器里，确保运行用户（如
dotnet）对整个 wallet 目录有读权限，且cwallet.sso文件不可被组/其他用户写——ODP.NET 检查文件权限，发现宽松就拒绝加载 - 别把 wallet 放进项目 bin 目录下再用相对路径：.NET Core 的
AppContext.BaseDirectory可能指向发布路径、测试运行器路径或临时目录，极难追踪
Oracle.ManagedDataAccess vs Unmanaged 的 Wallet 行为差异
用 Oracle.ManagedDataAccess（纯托管驱动）和 Oracle.DataAccess（旧版非托管）处理 Wallet 时，底层调用链完全不同：前者走 .NET 原生 TLS 栈 + 自研 wallet 解析器，后者依赖 Oracle Client 的 oraocci19.dll 和系统级 SSL 库。
性能 / 兼容性影响：托管驱动启动快、部署简单，但 wallet 中若含 RSA-SHA256 签名证书（常见于新生成的 ATP wallet），部分旧版 ODP.NET（如 19.10 之前）会验证失败；而非托管驱动更“宽容”，但要求服务器装 Oracle Client，且 .NET 6+ 在 Linux 上需额外配 libaio 和 libnsl。
- 优先选
Oracle.ManagedDataAccess3.21.10 及以上版本——它修复了 SHA256 证书解析 bug - 如果必须用非托管驱动，确认
PATH（Windows）或LD_LIBRARY_PATH（Linux）指向正确的 Oracle Client bin/lib 目录，且版本与数据库兼容（比如连 Oracle 23c 最好用 23c client） - 两者都不支持从 wallet 里动态加载 CRL（证书吊销列表），若企业安全策略强制检查 CRL，得换用自签名 CA + 手动信任根证书的方式绕过 wallet
测试 TCPS 连通性时最容易漏掉的两件事
连得上不代表加密生效，也未必代表 wallet 正确起作用。很多团队测完 SELECT 1 FROM DUAL 就认为 OK，结果上线后被安全审计打回。
容易踩的坑：SSL 握手成功 ≠ 数据链路全程加密；wallet 加载成功 ≠ 服务端证书被正确校验。
- 抓包验证：用 Wireshark 过滤
tcp.port == 2484，确认流量是 TLSv1.2+，且 Server Hello 中的证书 Subject 匹配 wallet 里的tnsnames.ora配置的服务名（不是数据库实例名） - 代码里加日志：在 Open() 后立刻查
connection.GetSchema("DataSourceInformation")["DataSource"]，返回值应包含tcps://前缀；再执行SELECT SYS_CONTEXT('USERENV', 'NETWORK_PROTOCOL') FROM DUAL，结果必须是tcps，不是tcp - 别信 Oracle Cloud 控制台的“SSL enabled”开关——它只控制监听器是否接受 TCPS 连接，不保证客户端用了 wallet；哪怕你连的是 TCPS 端口，只要没配
Wallet Location，ODP.NET 会退化成不校验证书的匿名 TLS，这不满足等保三级要求
Wallet 本质是客户端证书信任锚点，不是加密开关。配错路径、权限、协议名，或者驱动版本太老，都会让整个 SSL 链路形同虚设——而这类问题在线上往往静默失败，只在审计时暴露。
