17370845950

timeout=(3, 10)中第一个数字控制连接超时（TCP握手完成前），第二个控制读取超时（等待响应首字节）。单数字timeout=5等价于(5,5)，生产环境易出问题。

timeout=(3, 10) 中两个数字分别控制什么

第一个是连接超时（connect timeout），即 TCP 握手完成、建立连接前等待的最大时间；第二个是读取超时（read timeout），指连接建立后，等待服务器返回**第一个字节**的时间（不是整个响应体下载完的时间）。

常见误解是认为第二个参数控制“整个请求耗时”，其实不是——一旦开始接收数据，后续的传输（比如大文件分块接收）就不再受这个读取超时约束，除非你手动设置 stream=True 并逐块调用 response.iter_content()，否则默认行为只卡在“等首字节”这一步。

• 若 DNS 解析慢或目标 IP 不可达，connect timeout 会先触发
• 若服务端卡在业务逻辑（如数据库查询未返回 HTTP 响应头），read timeout 会触发
• 若服务端已发响应头但发响应体极慢（例如流式接口每秒只吐 1B），默认不超时；加 stream=True 后需自行对每次 iter_content() 调用设超时

不写元组、只写单个数字会发生什么

传一个数字（如 timeout=5）等价于 timeout=(5, 5)，即连接和读取共用同一阈值。这看似省事，但在生产中容易出问题：

• 内网调用通常连接极快（timeou

  

  t=3 会误杀合法请求
• 公网调用连接可能因网络抖动达 2s，若 read timeout 也只设 2s，留给业务处理的时间几乎为零
• 某些代理或负载均衡器会在连接建立后延迟转发，导致“连接快、读取慢”，单值 timeout 无法精细区分

requests 里 timeout 不生效的几种真实情况

超时参数只作用于 requests 底层的 socket 级操作，以下场景它管不了：

• DNS 解析超时：Python 默认使用系统 getaddrinfo，不受 timeout 控制；需配合 dnspython 或自定义 resolver 才能干预
• SSL 握手耗时：TLS 协商阶段计入连接超时，但若证书链验证复杂或 OCSP 响应慢，可能突破设定值（尤其在旧版 OpenSSL 上）
• 重定向跳转：每次跳转都重新走一遍连接+读取流程，timeout 对每跳单独生效，不是总耗时限制
• Response.content 解析：拿到响应体后调用 .json() 或 .text 触发的编码解码、JSON 解析失败，完全不走 timeout 机制

更稳妥的超时组合建议

没有万能值，但可按场景参考：

• 内网微服务调用：timeout=(0.5, 3) —— 连接必须快，业务允许稍长
• 公网第三方 API：timeout=(3, 15) —— 容忍网络波动，但防服务端 hang 死
• 上传大文件（files=...）：timeout=(5, 60) —— 发送请求体本身不被 read timeout 管，但服务端处理可能卡住，需拉长 read 值
• 绝对不能容忍延迟的健康检查：timeout=(1, 1) + allow_redirects=False

真正难处理的是“既要低延迟又要高成功率”的场景——这时候 timeout 只是第一道防线，后面还得配熔断（tenacity）、降级、异步重试，单纯调数字解决不了根本问题。