VB.NET 4.7 Beta应用单个用户部分下载遇SSL/TLS安全通道创建失败问题

我有一个基于VB.NET 4.7开发的Beta版应用，安装程序会下载主应用及依赖文件（包括app.exe和3个.zip文件），文件存储在mediafire.com和github.com，所有访问URL均为HTTPS。核心下载代码如下：

Using client As New WebClient
        Try
            client.DownloadFile(latestInfo("filelink"), installDir & "\application.exe")
        Catch ex As Exception
            <catch code here>
        End Try
    For i = 1 To CInt(latestInfo("librarylinks"))
        Dim filename = latestInfo(i & "filename")
            Try
                client.DownloadFile(latestInfo(i & "filelink"), installDir & "\\" & filename)
            Catch ex As Exception
                Clipboard.SetText(latestInfo(i & "filelink"))
                If MsgBox($"There was an error downloading a critical resource file - you can try to download it manually - the link is {latestInfo(i & "filelink")} (Press Ctrl-V to paste into your browser). Download it to {installDir} and press OK when done or Cancel to cancel the installation", vbCritical + vbOKCancel, "FILE NOT FOUND") = vbCancel Then
                    Exit Sub
                End If
            End Try
            If LCase(filename).EndsWith("zip") AndAlso File.Exists(installDir & "\\" & filename) Then
                Unzip(installDir & "\\" & filename)
                File.Delete(installDir & "\\" & filename)
            End If
    Next
End Using

此前应用极少出现异常，仅偶尔服务器宕机时触发，从未出现SSL错误，多数用户正常使用。但一位比利时新用户无法完成安装：从日志可见，应用程序可正常下载，但循环下载资源文件时出现**"Could not create SSL/TLS secure channel"**错误。其中应用程序和2个资源文件存储于mediafire，1个资源文件存储于github。

现需解答：

1. 为何仅该用户出现此问题且并非所有下载都报错？
2. 担心添加SecurityProtocolType.Tls12会影响现有正常用户，且无法复现问题、用户不便配合调试，希望找到可通过日志验证的潜在原因。

潜在原因及日志验证方法 #

• 用户系统默认SSL/TLS协议集不兼容部分目标服务器
  VB.NET 4.7默认继承系统的SSL/TLS协议配置，但该比利时用户的系统可能因组策略、安全软件或系统版本差异，禁用了github所需的协议版本（比如TLS 1.2/1.3），而mediafire兼容用户当前启用的旧协议。
  日志验证：让用户通过PowerShell执行Get-TlsProtocol命令导出系统启用的协议列表，或者查看注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols下的启用项，对比正常用户的配置是否存在缺失。

• 用户网络环境存在地区性拦截
  用户所在地区的ISP、企业防火墙或代理服务器可能针对github的流量做了SSL握手拦截/修改，导致TLS协商失败，但未影响mediafire的流量。
  日志验证：让用户直接在浏览器访问报错的github资源链接，记录是否能正常下载；同时检查系统代理设置（Internet选项-连接-局域网设置）是否存在自动配置规则，或询问用户是否使用企业网络、VPN等特殊环境。

• 地区性SSL证书信任缺失
  用户系统的根证书存储未及时更新，导致github使用的CA根证书不被信任，但mediafire的证书已在用户系统的信任列表中。
  日志验证：让用户点击浏览器地址栏的锁图标，查看github下载链接的证书状态是否显示“不受信任”；或导出系统根证书列表，对比正常系统是否缺失对应CA证书。

• WebClient实例的协议复用冲突
  代码中复用了同一个WebClient实例下载所有文件，首次下载mediafire文件时缓存的TLS会话参数，与后续github服务器的协议要求不兼容，导致握手失败。
  日志验证：在现有日志中添加每次下载前的ServicePointManager.SecurityProtocol值记录，查看协议参数是否在请求间发生异常变更；或临时修改代码为每个下载请求创建独立WebClient实例，让用户测试是否解决问题。

关于SecurityProtocolType.Tls12的兼容性说明 #

VB.NET 4.7中设置ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 Or SecurityProtocolType.Tls13不会影响现有正常用户：4.7原生支持这些协议，设置后程序会优先使用服务器支持的最高版本协议，不会强制禁用旧协议（除非仅指定单一协议）。若仍有顾虑，可采用异常触发式设置——仅在捕获到SSL错误时，临时切换协议重试下载，不改变正常用户的默认行为。

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