.NET Web API对接Grafana Loki 无法创建SSL/TLS安全通道报错

连接失败的核心原因是当前客户端运行环境完全不支持TLS 1.3协议，和代码配置无关：

• Windows Server 2012 R2 自带的Schannel安全组件最高仅支持TLS 1.2协议，没有任何官方补丁可以为该系统添加TLS 1.3支持
• .NET Framework 4.7.2的HTTP请求完全依赖系统Schannel组件完成TLS握手，没有内置独立的TLS协议栈
• 你代码中添加的System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12配置仅能指定使用TLS 1.2，且当前版本.NET的SecurityProtocolType枚举本身就没有定义TLS1.3对应的成员，就算强行传入对应数值底层也无法识别。

• 方案1：调整Loki服务端TLS配置兼容TLS 1.2
  这是生产环境最优方案。在Loki前端的反向代理层（Nginx、Caddy、IIS ARR等）开启TLS 1.2协议支持，配置合规加密套件的同时保留原有TLS 1.3配置即可。整个调整不需要修改现有业务代码、不需要动应用服务器配置，重启代理服务后即可恢复日志上报连接。日志上报属于内部链路场景，TLS 1.2的安全性完全满足需求。
• 方案2：升级应用服务器操作系统
  将部署Web API的Windows Server 2012 R2升级到Windows Server 2022及以上版本，该版本及之后的Windows Server系统Schannel组件原生支持TLS 1.3。升级完成后确认应用正常运行即可自动完成TLS握手，不需要修改业务代码。注意Windows Server 2016/2019即使安装最新补丁也无法完整支持TLS 1.3，不要在这两个版本上做无效调试。
• 方案3：替换Loki Sink的HTTP客户端实现
  如果既不能调整服务端TLS配置、也无法升级服务器系统，可以自定义Serilog.Sinks.Grafana.Loki使用的HTTP客户端，绕过系统Schannel组件，改用自带TLS 1.3实现的第三方HTTP库（比如基于BoringSSL封装的HTTP客户端）注入到Sink配置中。该方案需要额外引入第三方依赖、调试成本较高，仅在前两个方案完全无法落地时使用。

注意：绝对不要在生产环境安装非官方的Win2012R2 TLS1.3支持补丁，这类补丁会破坏系统Schannel组件稳定性，可能导致服务器上所有依赖HTTPS的服务出现随机连接异常。

内容的提问来源于stack exchange，提问作者GrahamJ