遇到python多线程连接服务器失败，先别急着加线程数，正确的做法是隔离连接资源、限制并发上限，再根据报错类型调整超时和重试参数。 多数情况下，问题出在线程共用连接、系统连接数打满、或者服务器端限流,而不是Python本身的并发能力不行。
python多线程连接服务器超时和失败，多半出在这三类原因
共享一个连接对象，线程互相踩脚
很多同学喜欢把requests.Session或者Socket对象写在全局，然后丢给ThreadPoolExecutor去用，这其实是踩了线程安全的大坑。requests.Session内部维护了连接池和Cookie，多个线程同时读写时，轻则连接复用乱套，重则直接抛ConnectionResetError，行业共识认为，网络连接对象只要涉及多线程，就应该做到每线程一个实例,至少也要用线程锁保护起来。
最简单的验证方法：在每次请求时打印连接对象的ID，你会发现多个线程的ID都一样，说明大家都在抢同一个连接,这时候报什么错都不意外。
并发连接数把本机或服务器端口打满
当线程数量突然增加到几十甚至上百个，每个线程都发起独立连接，本机的可用端口和文件描述符很快耗尽，常见报错是Too many open files或者Cannot assign requested address，服务器端也不是无限接收的，nginx的worker_connections、MySQL的max_connections都有上限。
业内专家指出，很多线上故障不是代码逻辑错，而是连接数触顶，排查时先看两端日志，如果服务器日志里没有收到连接请求，那就是客户端自己没发出去,基本就是本机端口或fd耗尽了。
服务器主动断连或拒绝新连接
有些服务器专门设置了并发限制，比如同一个IP只能有五个连接，超过就拒绝，还有一些云厂商的安全组、防火墙会对高频新建连接做限流，这种情况下，你的线程越勤奋,失败得越快。
这类问题有个特征：单线程运行完全正常，线程一多就随机失败，而且失败频率和线程数成正比，看到这个规律,优先怀疑服务器端策略。
python多线程连接服务器失败怎么办？分四步排查最省时间
第一步：把报错原文完整记录下来
不要笼统说“连接失败”，先看清异常类型。socket.gaierror是DNS解析问题，socket.timeout是超时，ConnectionRefusedError是端口没开放或服务没起来，ConnectionResetError则可能是连接被服务器重置，用traceback.format_exc()把完整堆栈打印到日志,比反复猜原因有效得多。
第二步：检查线程池和连接池是否各司其职
线程池管任务并发，连接池管连接复用，两者不能混为一谈，如果你的代码里每个线程直接connect()，那再大的连接池也帮不上忙，建议用urllib3的PoolManager，或者requests.Session配HTTPAdapter，把连接池的maxsize设置为与线程池线程数接近的值。
下面是一个简单的配置例子：
import requests
from requests.adapters import HTTPAdapter
session = requests.Session()
adapter = HTTPAdapter(pool_connections=20, pool_maxsize=20)
session.mount('https://', adapter)
注意这个session仍然不能直接多线程共用，要么用threading.local保存每个线程自己的session，要么用concurrent.futures的线程池让每个任务自己创建session，连接池的作用是让每个线程内部的连接可复用,而不是让多个线程共享一个连接。
第三步：给每个连接设置合理的超时和重试
没有设置超时的连接，在服务器无响应时会一直挂着，线程池很快被占满，后续任务全部排队,这就是为什么很多人觉得多线程性能更差。
连接超时和读取超时一定要分开设置，连接超时控制在1秒以内，读取超时根据业务允许的延迟调整，重试要加退避，比如第一次等1秒，第二次等2秒，第三次等4秒，不要所有线程失败后立刻重试，那会造成“重试风暴”。
第四步：从服务器端确认并发策略
如果代码这边都检查过了，仍然失败，就去服务器端看，自己的服务器就查nginx -T里的worker_connections，查ss -s看连接状态，查MySQL的max_connections，第三方服务就翻API文档，看有没有并发数或QPS限制，很多时候服务器端默认配置只有几百并发，你线程一开就上千,失败是必然的。
python多线程连接数据库失败，重点检查连接池和事务隔离
不少人用Python写爬虫或数据分析脚本时，会遇到多线程连接数据库失败的情况，数据库连接和HTTP连接还有一个不同点：事务状态和连接强绑定。
连接池大小要主动控制
MySQL默认的连接数上限通常不高，每个线程都去创建一个新连接，分分钟打满，使用SQLAlchemy连接池，设置pool_size和max_overflow，让线程复用空闲连接，连接池的最大连接数还应该小于数据库max_connections,留一部分给其他应用。
事务不能跨线程共享
如果线程A拿到了连接，开启事务，还没提交就归还给连接池，线程B拿到这个连接去做查询，就可能读到脏数据或者直接报错，数据库连接一旦涉及事务，就必须在线程内部完整处理,确保提交或回滚之后再把连接归还。
python多线程ssh连接失败，多半是认证和参数握手的锅
不要复用同一个SSHClient实例
paramiko的SSHClient对象不是线程安全的，多个线程同时调用connect()时会互相干扰，甚至抛出奇怪的加密异常，正确做法是每个线程自己创建SSHClient，用完关闭，如果任务量很大，用线程池限制并发数,一般同时执行3到5个SSH连接就足够了。
设置banner_timeout和auth_timeout
连接慢的服务器，默认握手超时可能不够，在connect()方法里显式传banner_timeout=10、auth_timeout=10，避免长时间卡死，多线程SSH连接失败时，常见原因是用户名或密钥在每个线程里的传递方式不对，建议把认证参数封装成一个不可变对象,避免多个线程修改。
用实际场景验证解决方案
假设你要写一个脚本，检测一批服务器的22端口是否开放,最早的版本可能是：
from concurrent.futures import ThreadPoolExecutor
def check(ip):
import socket
s = socket.socket()
s.connect((ip, 22)) # 可能失败
s.close()
跑起来会发现部分IP报错，时好时坏,优化后的思路是：
- 每个线程函数内部创建独立的socket对象；
- 设置
connect_timeout=2； - 失败后等1秒再重试一次；
- 线程数限制为10。
改进后输出就会稳定很多，这看起来是“小问题”，但实际项目中,多线程连接失败往往就是这种细节叠加出来的。
常见问题解答：python多线程连接服务器相关
问题1：python多线程连接服务器失败，重试多少次合适？
建议最多重试两次，如果第一次失败，等1秒重试；第二次失败，等2秒再试一次；第三次仍然失败，记录日志并跳过，无限重试会导致线程堆积,反而让系统更慢。
问题2：python多线程连接服务器卡住不报错，是什么原因？
最常见的原因是没有设置超时参数。connect()默认会一直等下去，线程池里的线程全部卡住后，程序看起来像死循环，给socket设置settimeout，或者给线程池的future.result(timeout=5)加等待上限,就能快速定位。
问题3：连接池和线程池大小怎么配合？
线程池控制任务并发数，连接池控制每个线程或整个进程的连接复用，配合原则是：连接池最大连接数不要小于线程池大小，否则部分线程拿不到连接；也不要超过服务器上限，具体数值要根据服务器负载测试得出,没有万能配置。
回到最初的问题：python多线程连接服务器失败，核心是让每个线程都拥有安全、受控的连接资源，同时对系统限制有清晰的预期，把这三点做到位,绝大多数报错都能消除。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/786167.html
