关于1-0.5%用户HTTPS GET请求出现非自有证书SSLPeerUnverifiedException的问询

这问题我之前碰过类似的场景，结合你描述的1-0.5%用户出现、异常证书不属于己方服务器的情况，大概率是客户端侧的网络环境被干扰了，给你梳理几个核心原因和排查/解决方向：

一、核心原因分析 #

1. 运营商/第三方透明流量劫持 #

这是最常见的原因，尤其是移动网络用户。比如某些运营商会对HTTPS流量做透明劫持，替换掉原本的服务器证书，用自己的证书来“中间人”处理请求（通常是为了插广告、做安全扫描）。你示例里的hautdebitmobile.orange.fr是法国Orange运营商的移动网络相关域名，基本可以确定是Orange的流量劫持导致的——用户的请求被运营商转发到了他们的中间节点，返回的是Orange的证书，自然和你的服务器主机名不匹配，触发SSLPeerUnverifiedException。

2. DNS劫持/污染 #

用户设备的DNS解析被篡改，导致你的域名被解析到了错误的IP地址（比如第三方服务器、恶意节点），请求发送过去后拿到的是对方的证书，验证失败。这种情况在某些地区或者使用不安全的公共DNS时容易发生。

3. 客户端本地网络配置异常 #

比如用户设备开启了错误的VPN、代理软件，或者系统的证书信任列表被恶意软件篡改，导致请求被强制路由到了第三方节点，拿到了不属于你的证书。

二、排查与解决建议 #

排查步骤（针对出现问题的用户） #

• 让用户切换网络环境：比如从移动数据切换到Wi-Fi，或者关闭VPN/代理，看异常是否消失，以此判断是运营商还是本地配置问题。
• 检查DNS解析结果：让用户用命令行工具（比如nslookup或dig）查询你的域名，对比正常情况下的IP地址，确认是否被解析到错误地址。
• 抓包验证：如果用户配合，可以用Charles、Wireshark等工具抓包，查看请求的实际目标IP和返回的证书链，确认是否被劫持。

全局防护方案（降低发生率） #

• 启用HTTP/3（QUIC）协议：QUIC的加密从握手阶段就开始，中间代理很难进行透明劫持，能有效规避这类问题。
• 证书钉扎（Certificate Pinning）：在客户端代码中硬编码你的服务器证书的哈希值（比如示例里的sha256/AUSXlKDCf1X30WhWeAWbjToABfBkJrKWPL6KwEi5VH0=是对方的，你要存自己的），只有匹配哈希的证书才会被信任。注意：后续服务器证书更新时，要同步更新客户端的钉扎哈希，否则会导致所有客户端无法连接。
• 使用安全DNS：引导用户配置DNS over HTTPS（DoH）或DNS over TLS（DoT），避免DNS被劫持/污染。也可以在客户端代码中指定可靠的DNS服务器（比如Cloudflare的1.1.1.1）。
• 增强客户端异常提示：在捕获到该异常时，给用户提示“当前网络环境可能存在异常，请尝试切换网络或关闭代理”，帮助用户自行排查。

总结 #

这类问题属于客户端侧的网络环境干扰，很难100%杜绝，但通过上述防护手段可以大幅降低异常发生率。如果有条件，可以收集出现问题的用户的运营商、地区、设备类型等信息，能更精准定位问题根源，针对性优化。

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