首先，咱们得先理清Fiddler显示的信息到底代表什么——Fiddler作为代理，相当于在你的应用和支付服务商之间插了一脚：

• 你看到的请求部分的TLS1.0，是你的应用和Fiddler之间的连接版本；
• 响应部分的TLS1.2，是Fiddler和支付服务商服务器之间的连接版本。

这就导致你没法直接通过Fiddler判断应用和服务商之间的实际TLS版本，得换更靠谱的验证方式，同时也要确保应用本身确实能强制使用TLS1.2，毕竟.NET 4.0默认是不支持TLS1.2的，注册表修改有时候会有局限性。

一、先确认实际使用的TLS版本 #

不要依赖Fiddler，直接抓应用和服务商之间的原始流量：

• 用Wireshark抓包，过滤目标支付服务商的IP或域名，找到TLS握手的Client Hello包，查看其中的Version字段——如果是0x0303，就是TLS1.2；0x0301是TLS1.0。
• 或者在应用代码里添加日志，输出当前的安全协议设置：

  // 在发起支付请求前添加
  var currentProtocol = System.Net.ServicePointManager.SecurityProtocol;
  // 输出到日志，比如用内置Trace或日志框架
  System.Diagnostics.Trace.WriteLine($"Current Security Protocol: {currentProtocol}");
  

  如果输出里包含Tls12，说明代码层面已经生效。

二、更可靠的强制TLS1.2方案（代码层面） #

注册表修改是全局设置，但有时候.NET 4.0应用可能不会正确读取这个配置，或者被应用内的代码覆盖。最稳妥的方式是直接在代码里指定：

• 在应用启动时（比如Global.asax的Application_Start方法里）添加：

  System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;
  

• 如果你的应用有多个独立的HTTP请求逻辑，确保每个请求发起前都设置这个值（或者在全局初始化时设置一次，后续请求会继承这个配置）。

三、为什么注册表修改可能没生效？ #

.NET 4.0的ServicePointManager默认不会自动启用TLS1.2，注册表修改（比如设置SchUseStrongCrypto）是让.NET框架优先使用强加密协议，但有些环境下（比如服务器上有多个.NET版本共存，或者应用池配置有特殊设置）可能不生效。代码层面的设置是直接覆盖默认值，优先级更高。

四、验证修改后的效果 #

1. 关闭Fiddler，让应用直接发起支付请求；
2. 用Wireshark抓包，确认Client Hello里的TLS版本是1.2；
3. 或者联系支付服务商，让他们帮忙查看你的请求使用的TLS版本（很多服务商后台有请求日志）。

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