根本原因是TLS握手阶段证书验证失败，不是“连不上”而是“不敢信”；Python严格校验域名匹配、签名可信、时间有效、未被吊销四点，任一失败即抛SSLError。
Python抛出SSLError异常，根本原因是TLS握手阶段证书验证失败，不是“连不上”，而是“不敢信”。它不表示网络不通，而是客户端明确拒绝建立加密信任链。
SSL证书验证失败的四个关键检查点
Python（通过ssl模块）在收到服务器证书后，会严格执行四步校验：
-
域名匹配：证书里的
Subject Alternative Name或Common Name必须与你请求的hostname一致。比如用requests.get("https://api.example.com")，但证书只写了example.com，就会触发hostname doesn't match -
签名可信：证书必须由本地CA证书库中某个根证书（或其签发的中间证书）逐级签名。若目标站用的是内网自签名CA、Let’s Encrypt新根
ISRG Root X2（旧certifi未收录），或证书链缺失中间件，校验即中断 -
时间有效：证书
notBefore和notAfter必须包含当前系统时间。系统时钟快了5分钟或慢了2小时，都可能让有效证书被判定为“过期”或“未生效” - 未被吊销：部分配置会启用OCSP或CRL检查。若服务端证书已被CA吊销，且客户端启用了吊销检查（如某些企业安全策略），也会失败
为什么不同环境表现不一致？
同一段代码，在Linux服务器上正常，在Windows开发机上报错，常见原因有：
- Linux发行版通常复用系统级证书路径（如
/etc/ssl/certs/ca-certificates.crt），而Windows/macOS Python安装包默认捆绑certifi包，走certifi.where()返回的路径 -
certifi是独立包，pip install --upgrade python不会升级它；pip install --upgrade certifi才真正更新证书列表 - 某些IDE（如PyCharm）缓存解释器配置，升级
certifi后不重启Python Console，certifi.where()仍返回旧路径 - Docker容器若基于
python:slim镜像，常缺失/etc/ssl/certs，又未预装certifi，直接导致无CA可查
verify=False 为什么危险且治标不治本
设verify=False只是跳过全部四步校验，但问题本身仍在：
- 它无法解决证书链不全、域名不匹配等真实配置缺陷，掩盖了服务端问题
- 中间人攻击风险真实存在：代理工具（Fiddler/Charles）、企业防火墙（Zscaler）、甚至恶意WiFi热点，都能伪造证书并被你的程序接受
- 某些服务（如现代银行API、OAuth2提供方）会主动拒绝
verify=False的客户端，返回400 Bad Request或直接断连 - 它不能修复
pip install失败——因为pip有自己的证书校验逻辑，不受requests设置影响
真正要盯住的，是certifi.where()返回的路径是否最新、是否被实际加载，以及目标服务的证书链是否完整——这些才是可验证、可修复、可长期维护的点。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
