requests全局配置SOCKS5代理不起作用的根本原因是urllib3默认不支持SOCKS协议，必须安装PySocks且正确配置proxies、使用socks5h://、复用Session并验证代理服务端健康。
requests全局配置SOCKS5代理为什么不起作用
直接改requests.adapters.DEFAULT_RETRIES或往Session里塞proxies，但请求仍走直连——根本原因是requests底层依赖urllib3，而urllib3默认不支持SOCKS协议。你传了proxies={'https': 'socks5://...'}，它会静默降级为HTTP代理尝试，失败后就 fallback 到直连，不会报错，只在连接阶段卡死或抛ConnectTimeout。
必须显式安装并启用PySocks，否则socks5://前缀会被忽略。验证方法：运行import socks; print(socks.__version__)，没装则报ModuleNotFoundError。
- 装错包也不行：
pip install sockspy或socketproxy都是无效的，只认PySocks - Windows下若用conda，得用
conda install -c conda-forge pysocks，pip装有时会缺编译依赖 - 代理URL中不能漏掉
socks5://或socks5h://——后者强制DNS解析也走代理，防DNS污染
SOCKS5代理配置必须配全这三处
少任何一环，都可能表现为“看着配了，实际没走代理”。尤其容易漏掉HTTPSConnectionPool的适配。
- 安装
PySocks后，requests会自动识别socks5://协议，但仅限http://请求；https://请求需额外确保DNS解析不出代理（否则TLS握手前就失败） - 推荐统一用
socks5h://代替socks5://，例如proxies={'http': 'socks5h://127.0.0.1:1080', 'https': 'socks5h://127.0.0.1:1080'} - 若用
Session对象，必须在get()/post()调用时显式传proxies=...，设在session.proxies上无效（这是requests的已知行为）
连接超时仍发生？检查SOCKS代理链本身是否健康
很多问题其实不在Python代码，而在代理端。常见现象是：浏览器能翻，curl --proxy socks5h://127.0.0.1:1080 https://google.com能通，但Python脚本还是WinError 10060。
立即学习“Python免费学习笔记（深入）”；
- 用
telnet 127.0.0.1 1080确认本地SOCKS服务端口监听正常（Windows需另装telnet客户端） - 检查代理工具（如Clash、Shadowrocket）是否启用了“允许来自局域网的连接”，否则Python进程无法连上本地代理
- 国外网站若启用HTTP/2，部分老旧SOCKS代理（如某些SSR实现）不兼容，可临时加
headers={'Connection': 'close'}禁用keep-alive - 代理延迟高（>800ms）时，
timeout=(3, 7)大概率不够，建议先测单次代理延迟：time curl -x socks5h://127.0.0.1:1080 -o /dev/null -s -w '%{time_total}s\n' https://httpbin.org/ip
并发请求下SOCKS代理的隐藏瓶颈
单线程没问题，一开多线程或多进程就频繁ConnectTimeout，大概率是代理服务端连接数打满或未开启复用。
- Clash配置中确认
allow-lan: true和mode: rule已启用，否则并发连接可能被限速 - 避免在
ThreadPoolExecutor里反复创建Session，每个Session会独占一个SOCKS连接；应复用Session并配pool_connections=10 - 真实场景中，比换代理更重要的是控制并发度：
max_workers=3往往比10更稳，因为多数SOCKS代理对单IP连接数有限制
SOCKS5不是万能隧道，它的稳定性高度依赖代理服务端质量。代码配得再准，上游代理抖动或DNS劫持，照样触发WinError 10060。上线前务必用httpbin.org/ip实测代理出口IP和延迟，别只信日志里的“200 OK”。
