Azure Blob Service TLS 1.2连接异常排查建议咨询

客户端侧优先排查项 #

• 先拿到精确错误信息，不要只凭「连接失败」判断：在代码中捕获Blob操作的完整异常堆栈，重点看内层异常是TLS握手失败、Socket连接重置、还是请求超时。在故障机上用PowerShell执行Test-NetConnection [你的存储账户名].blob.core.windows.net -Port 443，先确认443端口的基础连通性，排除端口被拦截的情况。
• 检查系统层TLS与代理配置：很多办公电脑会被域策略修改SCHANNEL注册表配置，哪怕代码中强制指定TLS 1.2，系统层禁用TLS 1.2客户端协议依然会握手失败，可直接查看注册表路径HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client下的Enabled键值是否为1。同时确认系统全局代理配置：不少企业会默认下发透明代理或全局代理规则，浏览器可自动适配，但C#应用如果未正确读取系统代理配置就会连接失败，可在代码中打印HttpClient.DefaultProxy参数确认。
• 做同环境对照测试：在故障机上安装同SDK版本内核的Azure Storage Explorer，用相同存储账户授权信息连接测试。如果Storage Explorer也连接失败，问题基本在网络侧；如果Storage Explorer可正常上传，回头检查项目依赖，看是否引入了低版本System.Net.Http相关程序集，覆盖了新版SDK的TLS默认配置。

网络侧排查要点 #

• 你计划的直接接运营商WAN口测试是有效的，但不用急着拆线路，先把Netgear路由器上几个默认开启、容易触发兼容问题的功能关闭后复测：包括SPI防火墙、应用层QoS识别、HTTPS/SSL扫描、SIP ALG等功能。不少消费级路由器的老固件对携带特定TLS扩展（比如ALPN、新版加密套件声明）的握手报文存在识别bug，会直接回RST掐断连接，和是否使用VPN无关。
• 排查MTU/MSS不匹配问题：如果办公网线路是PPPoE接入，路由器默认MTU设为1500时，带DF（不分片）标记的TLS 1.2握手大报文会被直接丢弃，而浏览器自带PMTU探测能力可自动调整包大小，普通桌面应用默认没有这个逻辑。可临时把测试电脑网卡MTU改为1400再尝试连接，如果能正常连通，就是路由器未开启MSS钳制功能导致的。
• 抓包对比握手差异：分别在家庭网络正常环境、办公网络故障环境用Wireshark抓443端口的TLS握手报文，对比Client Hello的加密套件列表、扩展字段是否一致，看办公网环境下是Client Hello发出去后直接被路由回RST，还是收到了中间设备返回的TLS Alert报文，可直接定位拦截点。

同类问题常见根因 #

这类场景下网卡硬件故障的概率极低，绝大多数情况是两类原因：一是办公网域策略下发的系统配置修改了TLS或代理规则，二是消费级路由器的应用层流量检测功能对新版Azure SDK的TLS握手逻辑兼容不佳，还有小概率是办公网运营商到Azure公有云的路由拥塞，导致TLS握手超时，可通过tracert命令对比两个网络环境到Blob存储端点的路由跳数、延迟差异确认。

内容的提问来源于stack exchange，提问作者A Bit of Help