副本集连接超时主因是serverSelectionTimeoutMS，非connectTimeoutMS；它控制驱动从多个节点中选择可用服务器的总时限，默认30秒，超时抛MongoServerSelectionError；需结合DNS、白名单、防火墙及连接数排查根本问题。
ConnectTimeoutMS 不是副本集连接超时的主因
直接调大 connectTimeoutMS 通常无效，甚至掩盖真实问题。这个参数只控制「单次 TCP 握手」的等待上限，而副本集连接失败绝大多数时候卡在服务发现阶段——驱动要连多个节点、发 isMaster、等拓扑更新，connectTimeoutMS 根本没机会触发。
真正该调的是 serverSelectionTimeoutMS
副本集环境下，驱动必须从多个候选节点中选出可用主节点（或符合读偏好的节点），这个过程由 serverSelectionTimeoutMS 控制，默认 30000 毫秒。超时后抛出 MongoServerSelectionError，日志里常带 Timed out after 3000ms while waiting for a server...。
实操建议：
- 先确认错误是否含
serverSelectionTimeoutMS字样（注意末尾是字母l和S，不是数字15） - 若环境网络稳定（如内网）、副本集节点数少（≤3），可尝试设为
10000缩短等待，加快失败反馈 - 若跨地域或网络抖动频繁，可适度提高到
45000，但别超过 60000——过长会拖慢整个请求链路 - Node.js 示例：
const client = new MongoClient(uri, { serverSelectionTimeoutMS: 15000 });
为什么光调参数不行？常见干扰项
即使 serverSelectionTimeoutMS 足够长，仍超时，说明底层有阻塞点：
-
dns解析失败：客户端用 IPv6 而 MongoDB 只监听 IPv4，加{ family: 4 }强制 IPv4 - 白名单未放行：Atlas 或阿里云 MongoDB 要求 IP 显式加入网络访问列表，
0.0.0.0/0仅用于测试 - 防火墙拦截端口：确认
27017（或自定义端口）在服务器、云厂商安全组、本地出口策略中全部放行 - 连接数耗尽：云数据库有连接上限，
network error while attempting to run command 'isMaster'很可能就是连不上任何节点
容易被忽略的拓扑探测行为
驱动后台有 monitor thread 定期向每个节点发心跳，日志里出现 MongoSocketReadException: Prematurely reached end of stream 并带 Exception in monitor thread 前缀，属于正常现象——它不阻塞业务线程，也不代表连接失败。但若高频刷屏，可调 heartbeatFrequencyMS 降低探测频率（如从默认 10000 改为 30000），减少干扰。
