.NET Framework 4.8应用中Flurl请求默认使用TLS 1.0的排查求助

这问题我之前帮同事排查过类似的，给你几个具体的方向试试，应该能定位到根因：

1. 检查应用配置文件的强制协议设置 #

首先看看你的app.config（或web.config）里有没有硬编码设置TLS版本的配置，比如：

<system.net>
  <settings>
    <servicePointManager securityProtocol="Ssl3,Tls" />
  </settings>
</system.net>

另外还要检查<runtime>节点里的AppContext开关，比如有没有启用Switch.System.Net.DontEnableSchUseStrongCrypto——这个开关会强制禁用强加密协议，导致应用只能使用TLS1.0及更旧的版本：

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true" />
</runtime>

如果有这些配置，删掉或者修改成允许TLS1.2/1.3的设置。

2. 追踪谁修改了ServicePointManager.SecurityProtocol #

既然你说代码里没手动设置，那大概率是某个第三方依赖在初始化时偷偷改了这个属性。可以用一个简单的调试技巧来抓元凶：
在应用启动的最早期（比如Main方法第一行）添加以下代码：

using System.Net;
using System.Diagnostics;

// 注册协议变更的监听事件
ServicePointManager.SecurityProtocolChanged += (sender, e) =>
{
    // 这里打日志或者直接断点，查看调用栈就能找到修改的代码
    Debug.WriteLine($"SecurityProtocol被修改：从{e.OldValue} 变为 {e.NewValue}");
    var stackTrace = new StackTrace();
    Debug.WriteLine($"调用栈：{stackTrace}");
};

这样一旦有代码修改这个属性，你就能在调试器里看到完整的调用栈，直接定位到对应的依赖库或代码。

3. 检查机器的全局.NET配置（machine.config） #

这台机器的machine.config可能被修改过，影响了所有.NET Framework应用。路径通常是：

• 32位：C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config
• 64位：C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config
  打开这个文件，查找<system.net><settings>节点，看看有没有强制设置securityProtocol的配置，如果有，修改或删除它。

4. 验证系统TLS配置的实际生效状态 #

虽然你检查了注册表，但有时候组策略会覆盖注册表设置，或者修改注册表后没重启机器导致配置未生效。可以用IISCrypto这个本地工具，可视化查看系统启用的TLS协议版本和优先级，确保TLS1.2和1.3是启用状态，并且没有被禁用。

5. 临时强制设置TLS版本（验证用） #

如果以上排查暂时没头绪，可以先在应用启动时手动设置TLS版本，验证是否能解决问题：

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls13;

如果设置后请求能正常使用TLS1.2/1.3，就说明确实是有地方覆盖了.NET 4.8的默认协议设置，再回头用步骤2的方法追踪修改源即可。

6. 对比测试应用与原应用的差异 #

既然你的测试应用能正常使用TLS1.2，那把测试应用和原应用的配置、NuGet依赖版本做个对比：比如Flurl的版本是否一致，有没有哪些依赖是原应用有但测试应用没有的，重点排查那些和网络请求、安全相关的依赖库。

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