去年做一个设备数据采集项目时，我踩过一个印象特别深的坑：PLC 侧的 OPC UA 服务器是设备厂商调好的，我这边要写一个 C# 上位机服务去对接。开发阶段图省事，客户端连接全部走匿名登录（AnonymousIdentityToken），本地用 OPC UA 模拟器测试一切正常，数据读得飞快。结果到了现场，服务一启动就报BadIdentityTokenRejected，查了一下午才发现，人家的服务器在生产环境把匿名登录禁掉了，强制要求用户名密码认证。后来我把认证方式改成了配置驱动，顺带把匿名和用户名密码的双认证兼容切换做了进去，才彻底稳住这种情况。
这篇文章就把这段经历完整展开聊聊，内容包括 OPC UA 身份令牌和安全策略的关系、匿名登录为什么在真实项目里不靠谱、如何在 C# .NET 8 环境下手写一套“服务器能力探测 + 匿名/用户名密码自动切换”的连接逻辑，以及一把高频报错的排查速查表。适合正在用 C# 写 OPC UA 客户端、被认证和证书问题折磨过的人参考，也适合刚接触 OPC UA 上位机开发、想避开这些默认坑的新手提前做心理建设。
1. OPC UA 认证体系：先把身份令牌、安全策略、会话关系理清楚
做 OPC UA 客户端连接，很多人的第一反应是“连上去就行”，于是默认用匿名，或者随便填一个用户名密码。结果一旦报错，看到BadSecurityChecksFailed、BadIdentityTokenRejected、BadCertificateUntrusted这些状态码，很容易一头雾水：这到底是密码错了，还是证书错了，还是安全策略没对上？要搞清楚这些问题，得先把 OPC UA 的认证体系拆开看。
1.1 三种身份令牌：匿名、用户名密码、证书
OPC UA 的“认证”指的是客户端向服务器证明“我是谁”。协议里定义了多种身份令牌（UserIdentityToken），最常见的是这三种：
- AnonymousIdentityToken（匿名）：不携带任何用户凭据，服务器允许就放行，不允许就拒绝。开发调试最方便，生产环境最危险。
- UserNamePasswordToken（用户名密码）：客户端把用户名和密码传给服务器，服务器在本地用户库或外部认证服务里校验。这是工业上位机里用得最多的方式。
- X509IdentityToken（证书身份）：客户端用自己的 X.509 证书作为身份，类似 HTTPS 双向认证，一般用在安全要求很高的场景。
除了这三种，还有 IssuedIdentityToken，通常配合外部令牌服务使用，普通上位机项目基本不会接触到，这里不展开。
需要特别注意一点：身份令牌和传输层的安全策略是两个维度。匿名登录只是说“我不告诉你我是谁”，不代表传输就是明文。匿名 + SignAndEncrypt 这种组合完全合法，只是服务器端权限控制会比较粗放。
1.2 安全策略和消息安全模式：认证之外的另一个坑
很多新手把安全策略（SecurityPolicy）和认证混在一起，一报错就怀疑用户名密码，实际上真正的坑往往在安全策略和证书上。
安全策略指的是客户端和服务器之间加密、签名消息所用的算法套件，常见的有：
None：不加密、不签名，纯明文传输，一般只用在开发调试和封闭内网。Basic256Sha256：目前最主流的策略，签名 + 加密都支持，工业场景的默认选择。Basic256、Basic128Rsa15：老一代策略，部分旧设备还在用，新项目不建议主动选。
消息安全模式（MessageSecurityMode）则分三种：None（不保护）、Sign（签名）、SignAndEncrypt（签名并加密）。
客户端配置的安全策略和模式，必须与服务器端点暴露出来的一致，否则连接阶段就会直接失败。而且，即便你用了Basic256Sha256，如果客户端没有可信的证书链，照样会在握手阶段被拒。所以 OPC UA 的连接问题，很多都不是认证问题，而是策略匹配和证书信任问题。
1.3 SecureChannel 和 Session：认证到底发生在哪一步
要理解匿名登录为什么会有那么多变数，还需要理清 OPC UA 连接的两个层次：
- SecureChannel（安全通道）：客户端先和服务器建立加密通道，这个阶段主要做传输安全协商、证书校验，决定了“通道是否可信”。
- Session（会话）：通道建立后，客户端创建会话，并在会话激活（ActivateSession）时携带身份令牌。身份认证真正发生在这个环节。
所以，匿名登录失败、用户名密码错误这类问题，本质上都发生在 Session 阶段，而不是 SecureChannel 阶段。反过来，证书不受信任、时间不同步这类问题，一般在 SecureChannel 阶段就已经被拦下来了。
把这些搞清楚之后，排错思路就清晰了：先看通道能不能建起来，再看身份令牌能不能被接受。下面要讲的匿名登录陷阱，大部分都属于第二个层面的问题。
2. 匿名登录为什么容易“开发一时爽，现场火葬场”
匿名登录在开发和测试阶段几乎不会出问题，因为本机模拟器、开发服务器默认都允许匿名。但一旦进入真实生产环境，各种限制就来了。这些限制如果不是提前了解，等到了现场才撞上，排查成本会非常高。
2.1 开发服务器和生产服务器的策略差异
OPC UA 服务器大多支持在配置里单独控制每个端点的认证方式。开发环境用的模拟器，通常把所有认证方式全部打开，匿名自然也被允许。而生产环境的 PLC 网关、SCADA 服务器，出于安全要求和管理规范，很可能只保留用户名密码或证书认证。
这就造成一个结果：本地怎么连都通，一部署到现场就报BadIdentityTokenRejected。我在那个项目里就是这种典型情况，代码一行没改，换了一套服务器环境就开始罢工。
应对这种差异，最理想的方式不是写死匿名或者写死用户名密码，而是让客户端在连接前先读取服务器的端点信息，看看它到底支持哪些身份令牌，再结合本地配置选择一种可行的认证方式。这也是后面“双认证兼容方案”的核心思路。
2.2 匿名用户的权限原子化问题：能登录不代表能干事
即使服务器允许匿名，也不代表匿名用户有权限读写所有节点。很多 OPC UA 服务器的权限模型非常细，可以做到“匿名用户只读”“匿名用户只能访问某几个测点”“操作员账号可以下发配方参数”这种粒度。
最常见的场面是：匿名登录成功了，读取模拟量电压电流没问题，但一调用方法写入参数，服务器直接返回BadUserAccessDenied。这时候很多人会怀疑是调用的参数格式不对，折腾半天才发现是权限不够。
所以在设计客户端时，要提前想清楚业务需求：只是做数据采集展示，匿名也许勉强够用；一旦涉及写操作、配方管理、参数下发，就必须用有权限的账号，不能指望匿名用户什么都能干。
2.3 审计、配额与安全日志：匿名会话的隐性成本
除了权限，还有几个很容易被忽略的管理问题。
首先是审计追溯。匿名会话在服务器端没有用户身份，出了误操作、数据异常，查半天也定位不到是哪个客户端、哪个人干的。对产线数据这种严肃场景，这显然是不符合要求的。
其次是连接数和资源配额。不少 OPC UA 服务器对匿名会话会设置较低的最大会话数限制。如果你部署了多个上位机服务，每个服务反复建立匿名会话，很容易把匿名配额占满，后续客户端直接连不上。
最后是安全日志和合规。很多企业的工控安全规范里明确要求关闭匿名访问、强制账号认证。如果软件交付后安全检查不过关，返工成本可不小。
2.4 证书问题：被误认为“匿名登录失败”的常客
匿名登录失败时，第一个跳到脑子里的原因往往是“服务器不让匿名”，但实际情况里，相当一部分报错是证书问题。
比如applicationcertificate cannot be found.这个报错，乍一看跟登录一毛钱关系都没有，但它经常出现在启用了安全策略的客户端连接过程中。原因是客户端自身的应用证书没有被正确加载或创建。没有应用证书，SecureChannel 阶段就过不去，自然走不到认证那一步，表现就像“登录失败”。
所以排查时一定要先分清问题出在 SecureChannel 阶段还是 Session 阶段。如果报错明确指向证书、信任链、时间戳，就别再去纠结用户名密码了。
3. 双认证兼容方案：识别服务器能力，按配置自动选身份
前面说了这么多坑，核心就是想说明一件事：写 OPC UA 客户端，认证逻辑不能写死，必须让程序具备根据服务器能力自动适配的能力。下面我给出一个基于 C# .NET 8 的完整实现方案，设计上有三层考虑：能力探测、配置优先级、失败兜底。
3.1 核心设计：端点能力探测 + 本地配置优先级 + 失败兜底
这套方案的思路可以概括为：
- 连接前先探测服务器端点能力：通过 OPC UA 的 Discovery 服务获取服务器暴露的端点列表，每个 EndpointDescription 里都带有
UserIdentityTokens字段，能直接看到该端点支持哪些身份令牌。 - 本地配置决定优先级：配置文件里指定认证模式，比如
Auto、Anonymous、UsernamePassword。如果是Auto，结合服务器支持情况和本地是否配置了账号来决定最终身份。 - 失败兜底：如果按某种认证方式连接失败，可以根据错误码自动切换到另一种方式重试，但要严格控制降级方向，不能无条件乱降。
这套设计的精髓在于：程序不假设服务器一定允许匿名，也不假设服务器一定需要密码，而是让服务器自己“告诉”客户端它支持什么，再结合本地策略做出最优选择。
3.2 环境准备：.NET 8 项目与 NuGet 包
我用的是 .NET 8 的控制台项目或类库。以控制台项目为例，创建和添加依赖的命令如下：
dotnet new console -n OpcUaDoubleAuthDemo cd OpcUaDoubleAuthDemo dotnet add package OPCFoundation.NetStandard.Opc.Ua注意，老项目里这个包可能叫OPCFoundation.NetStandard.Opc.Ua.Client，现在官方把核心、客户端统一整合到了OPCFoundation.NetStandard.Opc.Ua下，命名空间仍然是Opc.Ua和Opc.Ua.Client。如果项目里引用了旧包，升级时记得留意命名变化。
添加完依赖之后，先写一个配置类，把服务器地址、认证模式、账号密码、安全策略这些都收拢到一处。这样后续部署时只改配置文件，不用动代码。
public enum AuthMode { Auto, Anonymous, UsernamePassword } public sealed class OpcUaClientOptions { public string ServerUrl { get; set; } = "opc.tcp://127.0.0.1:4840"; public AuthMode AuthMode { get; set; } = AuthMode.Auto; public string Username { get; set; } = string.Empty; public string Password { get; set; } = string.Empty; public string SecurityPolicy { get; set; } = SecurityPolicies.Basic256Sha256; public MessageSecurityMode SecurityMode { get; set; } = MessageSecurityMode.SignAndEncrypt; public string ApplicationName { get; set; } = "OpcUaDoubleAuthClient"; public string ApplicationUri { get; set; } = "urn:localhost:OpcUaDoubleAuthClient"; public string CertificateSubjectName { get; set; } = "CN=OpcUaDoubleAuthClient, DC=localhost"; }这里把AuthMode设计成三档：Auto是自动选择，也是推荐的生产模式；Anonymous和UsernamePassword用于强制指定，适合已经明确知道现场环境的场景。
3.3 配置类和连接管理器的具体实现
接下来是连接管理器，核心方法是ConnectAsync。完整代码大致如下：
using Opc.Ua; using Opc.Ua.Client; using Opc.Ua.Configuration; public sealed class OpcUaConnection { public async Task<ISession> ConnectAsync( OpcUaClientOptions options, CancellationToken ct = default) { // 1. 构建应用配置 var config = BuildApplicationConfiguration(options); // 2. 确保客户端应用证书存在 var app = new ApplicationInstance(config); await app.LoadApplicationCertificate(suppressErrors: true); // 3. 获取服务器端点，并选择最佳匹配项 var endpoint = await SelectEndpointAsync(config, options, ct) ?? throw new InvalidOperationException( "未找到匹配的安全策略端点，请检查服务器支持的安全策略。"); // 4. 根据服务器能力 + 本地配置，选择身份令牌 var identity = SelectUserIdentity(options, endpoint.Description); // 5. 创建 Session var session = await Session.Create( config, endpoint, updateBeforeConnect: false, checkDomain: false, sessionName: $"{options.ApplicationName}-{DateTime.Now:HHmmss}", sessionTimeout: 60000, identity: identity, preferredLocales: new[] { "zh-CN", "en-US" }); return session; } private static ApplicationConfiguration BuildApplicationConfiguration( OpcUaClientOptions options) { return new ApplicationConfiguration { ApplicationName = options.ApplicationName, ApplicationUri = options.ApplicationUri, ApplicationType = ApplicationType.Client, SecurityConfiguration = new SecurityConfiguration { ApplicationCertificate = new CertificateIdentifier { StoreType = CertificateStoreType.X509Store, StorePath = "CurrentUser\\My", SubjectName = options.CertificateSubjectName }, TrustedPeerCertificates = new CertificateTrustList { StoreType = CertificateStoreType.X509Store, StorePath = "CurrentUser\\Root" }, TrustedIssuerCertificates = new CertificateTrustList { StoreType = CertificateStoreType.X509Store, StorePath = "CurrentUser\\Root" }, RejectedCertificateStore = new CertificateTrustList { StoreType = CertificateStoreType.X509Store, StorePath = "CurrentUser\\RejectedCertificate" }, AutoAcceptUntrustedCertificates = false, AddAppCertToTrustedStore = false }, TransportQuotas = new TransportQuotas { OperationTimeout = 30000, MaxMessageSize = 4194304, MaxStringLength = 1048576, MaxByteStringLength = 1048576 }, ClientConfiguration = new ClientConfiguration { DefaultSessionTimeout = 60000 }, TraceConfiguration = new TraceConfiguration { TraceMasks = Utils.TraceMasks.Information } }; } private static async Task<ConfiguredEndpoint?> SelectEndpointAsync( ApplicationConfiguration config, OpcUaClientOptions options, CancellationToken ct) { var endpointConfig = EndpointConfiguration.Create(config); endpointConfig.OperationTimeout = 15000; // 主动拉取服务器端点列表，而不只是盲猜 EndpointDescriptionCollection descriptions; try { using var discoveryClient = DiscoveryClient.Create( config, options.ServerUrl); descriptions = await discoveryClient.GetEndpointsAsync(ct); } catch (Exception ex) { Console.WriteLine($"获取服务器端点失败: {ex.Message}"); return null; } // 首选配置中指定的安全策略；如果没有完全匹配， // 退回到服务器支持的第一个可用端点。 var selected = descriptions .Where(d => d.SecurityPolicyUri == options.SecurityPolicy) .Where(d => d.SecurityMode == options.SecurityMode) .OrderByDescending(d => d.SecurityLevel) .FirstOrDefault(); selected ??= descriptions.FirstOrDefault(); if (selected == null) { return null; } return new ConfiguredEndpoint(null, selected, endpointConfig); } }这套代码的关键点有三个：
第一，DiscoveryClient.GetEndpointsAsync拉取真实端点列表，能拿到服务器实际支持的安全策略、消息安全模式和身份令牌类型。这比闭着眼睛连接靠谱得多。
第二，安全策略的匹配要留有余地。现场的老 PLC 网关可能只支持None或者Basic256，如果你在配置里写死Basic256Sha256，连接必然失败。所以我在选端点时做了回退逻辑，找不到完全匹配的端点，就用服务器返回的第一个端点。
第三，ApplicationInstance.LoadApplicationCertificate负责加载或创建客户端应用证书。开发阶段证书缺失时，这个调用能帮我们自动生成一份自签证书。如果库版本较老表现不一致，可以改用CertificateFactory.CreateCertificate手工创建并保存，这个后面单独说。
3.4 认证令牌选择逻辑与失败重试
选好了端点，下一步就是根据服务器支持的令牌类型来决定用匿名还是用户名密码。这是整篇文章最核心的一段逻辑：
private static UserIdentity SelectUserIdentity( OpcUaClientOptions options, EndpointDescription endpoint) { var supportedTypes = endpoint.UserIdentityTokens .Select(t => t.TokenType) .ToHashSet(); bool supportsAnonymous = supportedTypes.Contains(UserTokenType.Anonymous); bool supportsUserName = supportedTypes.Contains(UserTokenType.UserName); switch (options.AuthMode) { case AuthMode.Anonymous when supportsAnonymous: return new UserIdentity(new AnonymousIdentityToken()); case AuthMode.UsernamePassword when supportsUserName: return new UserIdentity(options.Username, options.Password); case AuthMode.Auto when supportsUserName && !string.IsNullOrWhiteSpace(options.Username): Console.WriteLine("服务器支持用户名密码认证，优先使用账号登录。"); return new UserIdentity(options.Username, options.Password); case AuthMode.Auto when supportsAnonymous: Console.WriteLine("未配置账号或服务器不支持用户名认证，降级为匿名连接。"); return new UserIdentity(new AnonymousIdentityToken()); default: throw new InvalidOperationException( $"服务器端点不支持当前认证方式。匿名支持: {supportsAnonymous}，" + $"用户名密码支持: {supportsUserName}"); } }这段逻辑看起来简单，但它把“匿名陷阱”的两个核心问题都回避掉了：
- 如果服务器只支持用户名密码，程序不会傻乎乎地去用匿名。
- 如果服务器只支持匿名，程序也不会非要用账号，而是自动降级。
当然，上述只是连接前的选择。还有一个更极端的场景：服务器端点列表里明明写着支持匿名，但真正创建 Session 时却被拒绝（部分第三方服务器实现确实存在这种不一致）。针对这种情况，可以在连接外层加一层失败重试：
public async Task<ISession> ConnectWithFallbackAsync( OpcUaClientOptions options, CancellationToken ct = default) { try { return await ConnectAsync(options, ct); } catch (ServiceResultException sre) when (sre.StatusCode == StatusCodes.BadIdentityTokenRejected || sre.StatusCode == StatusCodes.BadUserAccessDenied) { // 如果当前用的是匿名，且本地配置了账号，则尝试用账号重连 if (options.AuthMode == AuthMode.Auto && !string.IsNullOrWhiteSpace(options.Username)) { Console.WriteLine("匿名连接被拒绝，尝试使用用户名密码重连。"); options.AuthMode = AuthMode.UsernamePassword; return await ConnectAsync(options, ct); } throw; } }这里有一个重要的设计原则：重试方向只能是匿名切换成账号，或者 Auto 下未配置账号时降级匿名，绝不能把 “用户名密码失败”当成“服务器不支持账号”然后降级成匿名。生产环境里账号失败往往意味着密码错误或权限问题，盲目降级会带来安全隐患，也把原本应该暴露的问题掩盖了。
连接成功之后，建议顺手读一个已知节点作为冒烟测试，确认会话真正可用：
var node = new NodeId("ns=2;s=Demo.Tag1"); var value = await session.ReadValueAsync(node, CancellationToken.None); Console.WriteLine($"{node} = {value.Value}");如果依赖批量读取，也可以直接用ReadValuesAsync一次读多个节点，返回结果与传入的 NodeId 顺序一一对应。
3.5 证书管理：少踩“证书找不到”的坑
证书这块单独拎出来说，因为applicationcertificate cannot be found这类报错纠缠了我很久。这个报错通常有两种来源：
一是ApplicationConfiguration.SecurityConfiguration.ApplicationCertificate没有配置，或者配置的SubjectName与证书存储里实际存在的证书不匹配。这时候 UA 栈在握手阶段找不到可用证书，直接抛异常。
二是证书存储目录没有访问权限。如果上位机服务跑在 Windows 服务里，用的是 LocalService 或 SYSTEM 账户，它的“当前用户”证书存储和交互式登录用户的CurrentUser存储是两套。代码里写的CurrentUser\\My，在不同账户下指向不同的物理位置。如果服务账户没有权限创建证书，哪怕代码里写了创建逻辑，也会在写证书这一步失败。
处理方式有两种：
- 开发调试时，用
ApplicationInstance.LoadApplicationCertificate或CheckApplicationInstanceCertificates自动生成自签证书，把AutoAcceptUntrustedCertificates临时设为 true，快速验证功能。 - 生产环境，提前用脚本或工具生成好客户端证书，导入到目标账户的证书存储，并在
TrustedPeerCertificates里加入服务器证书。这一步应该纳入部署流程，而不是让程序运行时临时生成。
如果证书已经损坏，或者想强制重建，可以通过删除证书存储里的旧证书，再重新连接让它重建。不过最省心的做法还是把证书管理做成部署脚本的一部分，避免在运行环境里动态处理证书信任这种高风险操作。
4. 常见错误与排查实录：一张速查表 + 三个部署建议
做 OPC UA 客户端开发，最大的难点不在于写代码，而在于出错之后能不能快速定位问题。下面把我在项目里遇过的高频报错整理成一张表，后面再给三个部署层面的改进建议。
4.1 高频错误速查表
| 报错 / 状态码 | 可能原因 | 解决思路 |
|---|---|---|
applicationcertificate cannot be found. | 客户端应用证书未加载、未生成，或证书存储无权限 | 用ApplicationInstance加载证书；检查证书存储路径和账户权限 |
BadCertificateUntrusted | 客户端证书不被服务器信任 | 将客户端证书导入服务器的受信任证书列表，或临时设置 AutoAccept（仅限调试） |
BadSecurityChecksFailed | 证书链校验失败，常见原因是对端时间偏差、应用 URI 不匹配 | 检查服务器与客户端时间是否同步；核对 ApplicationUri 和证书 SAN |
BadIdentityTokenRejected | 用户名密码错误，或服务器不支持当前身份令牌类型 | 核对账号密码；用 GetEndpoints 查看 UserIdentityTokens 支持情况 |
BadUserAccessDenied | 用户可以登录，但对目标节点没有操作权限 | 检查服务器端授权模型，给账号分配角色或节点权限 |
BadSecurityModeRejected | 安全策略不匹配 | 从 GetEndpoints 返回的端点列表中选择匹配项，避免写死策略 |
连接超时 /BadConnectionRejected | 防火墙拦截、服务器会话数满 | 检查 4840 端口放行情况；排查服务器最大连接数配置 |
BadCertificateTimeInvalid | 服务器或客户端系统时间偏移过大 | 部署 NTP 时间同步，这是最常见的“隐藏炸弹” |
这里特别要强调BadUserAccessDenied和BadIdentityTokenRejected的区别。前者是认证通过但权限不够，后者是认证本身失败。我之前一度把这两个混在一起排查，浪费了不少时间。在很多服务器日志里，这两个错误的状态码是完全不同的，看报错一定要先确认具体是哪个。
4.2 排查工具链：UA Expert、UA 日志、数据包视图
排查认证问题，我有一套固定的工具组合，基本能覆盖百分之八九十的场景。
第一个是 UA Expert（官方免费客户端）。用它的连接向导连接目标服务器时，它会把服务器端点支持的安全策略、消息安全模式、身份令牌类型全部列出来。这个信息非常关键，比对着协议文档查半天有效得多。如果 UA Expert 用某个认证方式能连上，而自己的程序连不上，问题基本就锁定在代码配置与证书处理上。
第二个是 UA 栈日志。把ApplicationConfiguration.TraceConfiguration.TraceMasks设置成Utils.TraceMasks.All，客户端会输出非常详细的握手日志。证书校验失败、安全策略协商失败这类问题，日志里都会明确写出来。生产环境可以把它关掉或调到 Information 级别，避免日志刷屏。
第三个是数据包视图。Wireshark 对 OPC UA 协议有基础解析能力，能看到 TCP 连接、SecureChannel、Session 的报文流程。它适合确认连接是否真正建立、在哪一步被打断。因为 OPC UA 报文内容本身是二进制编码且可能加密，所以我不建议一上来就抓包，那是排错工具箱里最后一件武器。
4.3 部署环节三件事：信任链、时间同步、配置外置
最后聊三个部署层面的经验，都是在真实项目里用代价换来的。
第一，把证书信任链做成部署脚本。客户端证书由哪台机器签发、需要导入到哪些服务器的信任列表，服务器证书是否需要导入到客户端机器的 Root 存储，这些都应该在部署文档里写清楚。到了现场再手工配，非常容易漏。
第二，时间同步必须搞定。OPC UA 证书都有有效期，如果客户端机器和服务器机器时间偏差太大，证书校验会直接失败，报错还会伪装成各种奇怪的状态码。在工控现场，最省事的方式就是都用 NTP 对同一台时间源同步。
第三，连接配置全部外置。服务器地址、认证模式、用户名密码、安全策略，这些全部放到配置文件或配置中心里，不要写死在代码里。现场换服务器、改密码是常事，配置外置之后，运维只需要改配置文件，完全不用碰代码。这也是我在这套方案里坚持把OpcUaClientOptions独立出来的原因。
另外，连接管理器最好被设计成可复用实例，而不是每次用完就丢。OPC UA Session 的创建和销毁是有成本的，高频断连重连对服务器端也会造成额外压力。如果上位机要同时采集多台服务器，建议每个服务器一个连接实例，自己管理重连和退避策略，而不是在代码里到处 new Session。
最后再补几句实际的体会
这段内容到这里其实已经把双认证方案的代码和排查思路都讲透了。我个人的习惯是：连接逻辑永远做成 Auto 模式先行，默认优先用户名密码，只有确认服务器不支持账号认证时才退回匿名。日志里每次降级到匿名都要打出明确警告，这样哪怕现场出问题，翻日志也能立刻知道程序是按什么认证方式连上的。
还有一个细节，很多人在第一次连接 OPC UA 服务器时，会把AutoAcceptUntrustedCertificates直接设成 true 快速跑通。我建议这个方法只用于开发环境，一旦上生产，必须回到严格的证书校验。证书校验一旦绕过，整个安全策略就形同虚设，跟裸奔没什么区别。
OPC UA 的认证和证书体系初看挺绕，但拆开之后就是“策略匹配、证书信任、身份令牌”三件事。把这三件事在代码层面理顺，匿名登录那些坑基本就不会再踩了。后面如果你们项目里遇到比这更诡异的连接问题，可以顺着 SecureChannel 和 Session 两个阶段一条条排查，思路对了，问题就已经解决一半。
