Golang HTTP Client空闲连接复用异常：为何优先复用HTTPS连接？

首先，你的核心疑问在于：为什么HTTP请求触发302重定向到HTTPS后，后续请求复用的是HTTPS连接，而不是最后使用的HTTP连接？结合http.Transport的源码逻辑和你的测试场景，原因可以拆解为以下几点：

1. HTTP与HTTPS连接池完全独立 #

Golang的http.Transport用connectMethodKey来区分不同连接池，这个key包含协议类型（HTTP/HTTPS）、目标主机地址、代理配置等核心信息。也就是说：

• HTTP连接会被存入对应HTTP协议的专属空闲连接子池；
• HTTPS连接则会进入HTTPS协议的子池。
  两个池子完全隔离，绝不会互相复用连接——这是你看到HTTPS连接能稳定复用，但HTTP连接不行的基础逻辑。

2. 重定向场景下HTTP连接被挤出空闲池 #

你的测试代码设置了MaxIdleConnsPerHost: 1，这意味着每个目标主机最多保留1个空闲连接。结合你的日志一步步拆解：

• 第一次work1请求http://www.qq.com：先建立HTTP连接（172.26.33.1:49356 => 58.250.137.36:80），完成重定向响应后被放回HTTP空闲池；随后建立HTTPS连接并放回HTTPS空闲池。
• 第二次work1请求：此时HTTP空闲池里还有www.qq.com的连接，但日志显示新建了HTTP连接——这是因为客户端处理重定向时，会自动发起新的HTTPS请求，而初始HTTP连接虽然被放回，但后续没有立即复用的情况下，当work2请求http://httpbin.org时，新的HTTP连接会占用MaxIdleConnsPerHost:1的唯一名额，直接把www.qq.com的HTTP空闲连接挤出了池子。
• 再次运行work1时，HTTP空闲池里只剩httpbin.org的连接，和www.qq.com的HTTP地址不匹配，只能新建HTTP连接，随后重定向到HTTPS，复用之前保留的HTTPS连接。

简单来说：你的work2请求占用了HTTP空闲池的唯一名额，把www.qq.com的HTTP连接挤出去了，导致后续work1的HTTP请求无法复用旧连接。

3. HTTPS连接能稳定复用的原因 #

每次work1的重定向最终都指向同一个HTTPS地址（https://www.qq.com），而且没有其他HTTPS请求来占用MaxIdleConnsPerHost:1的名额，所以这个HTTPS空闲连接一直被保留在池子中，每次都能被复用。

验证与解决方案 #

验证方法 #

• 注释掉work2的调用，重新运行测试：你会看到work1的HTTP连接可以被复用，因为没有其他HTTP请求占用空闲池名额。
• 把work2的请求改成HTTPS地址：此时work2会占用HTTPS空闲池的名额，work1的HTTPS连接也会无法复用。

解决方案 #

• 如果需要复用特定HTTP主机的连接，调高MaxIdleConnsPerHost的数值，确保每个需要复用的HTTP主机都能保留一个空闲连接；
• 如果你已经知道目标地址会重定向到HTTPS，直接请求HTTPS地址，避免不必要的HTTP连接建立；
• 调整IdleConnTimeout，延长空闲连接的保留时间（默认是90秒，你的测试间隔是1秒所以超时不是问题，但如果间隔更长需要注意）。

内容的提问来源于stack exchange，提问作者nucleon