为什么感觉HTTPS代理"变慢"了？
不少朋友在做数据采集、自动化任务或接口调用时，把HTTP代理换成HTTPS代理后，第一反应是"怎么反而慢了"。其实问题往往不在代理本身，而是HTTPS在明文HTTP的基础上多了一层TLS加密流程：每一次新建连接，都要先完成握手，才能正式传输数据。握手需要几次网络往返，往返次数越多、物理距离越远，等待时间就越长。所以，HTTPS代理的性能瓶颈主要集中在两个地方：一是TLS握手的多轮往返开销，二是连接复用没做好，导致握手被反复触发。下面我们逐一拆解，并给出对应的优化办法。
瓶颈一：TLS握手的多轮往返开销
建立一个全新的HTTPS连接，完整过程是这样的：第一步，TCP三次握手，消耗1次网络往返；第二步，TLS握手，如果用的是TLS 1.2协议，需要2次往返，TLS 1.3则压缩到了1次往返；第三步，客户端还要校验证书、执行非对称加密运算，这一步消耗的是双方的CPU计算时间。
把这几步加起来，一个新连接从发起到能传数据，至少要3到4次网络往返。假设你使用的节点往返延迟（RTT）是30毫秒，光建连就要100毫秒上下；如果节点距离远、RTT到了50毫秒以上，建连开销会直接翻倍。对于一天只发几个请求的低频业务，这点开销可以忽略；但如果是高频采集、批量接口调用，每个请求都重新握手，延迟就会被成倍放大——这就是很多人觉得"HTTPS代理慢"的第一大根源。
不同TLS版本的握手成本差别很大，选对协议版本能直接省掉一半以上的握手等待：
| 对比项 | TLS 1.2 | TLS 1.3 |
|---|---|---|
| 握手往返次数 | 2次往返（2-RTT） | 1次往返（1-RTT） |
| 会话复用机制 | 支持，流程较繁琐 | 原生支持，基于PSK更高效 |
| 加密套件 | 数量多、新旧混杂 | 精简淘汰弱算法，更快更安全 |
| 首字节延迟 | 较高 | 明显更低 |
瓶颈二：连接复用不足，握手反复发生
第二个瓶颈，出在连接的使用方式上。很多程序默认走"短连接"模式：发一个请求，就走一遍"TCP握手＋TLS握手→传输数据→关闭连接"的完整流程，下一个请求再从头来一遍。假设你要采集1万个页面，就等于做了上万次握手，其中绝大部分时间都浪费在重复建连上。
长连接（Keep-Alive）的价值，就是让连接建立一次、复用多次：连接保持一段时间不断开，后续请求直接在现有连接上发送，握手成本只付一次。除此之外，代理服务端这一侧还有"连接池"的概念——服务端与目标网站预先建立并维护一批可用连接，请求一到就立刻分配，客户端感知到的等待时间进一步缩短。
常见的复用误区有三个：一是代码里每次请求都新建客户端对象，底层连接根本无法复用；二是没有开启Keep-Alive，或者超时设置得太短，连接刚建好就被断掉；三是并发开得过大，把连接池里的连接反复挤掉重建。这三种情况都会让握手开销反复出现，白白吃掉性能。
| 对比项 | 短连接模式 | 长连接复用模式 |
|---|---|---|
| 建连次数 | 每个请求都握手 | 一次握手，多次使用 |
| 平均单请求延迟 | 高，含完整握手耗时 | 低，省去重复握手 |
| CPU计算开销 | 非对称加密频繁执行 | 大幅减少 |
| 适用场景 | 低频、偶发请求 | 高频采集、批量接口调用 |
五个立竿见影的优化手段
1. 优先使用TLS 1.3。握手往返从两次降到一次，配合会话恢复甚至可以做到更快，这是成本最低的提速手段，只要客户端和服务端都支持就会自动生效。
2. 开启会话复用。TLS的Session ID、Session Ticket（TLS 1.3里是基于PSK的恢复模式）可以把之前协商好的密钥参数"记住"，下次连接跳过证书校验和密钥协商的大头，只做一次轻量恢复，握手时间大幅缩短。
3. 客户端复用连接。使用带连接池的HTTP客户端，把Session对象在多次请求之间共享，而不是每次新建。下面这段Python示例是最典型的写法：
import requests
# 用 Session 复用底层 TCP/TLS 连接，避免每个请求都重新握手
session = requests.Session()
session.proxies.update({
"http": "http://用户名:密码@代理地址:端口",
"https": "http://用户名:密码@代理地址:端口",
})
session.headers.update({"User-Agent": "Mozilla/5.0"})
# 同一会话内连续请求，握手只在第一次发生，后续直接复用连接
for page in range(1, 11):
resp = session.get(
"https://目标网站.com/list?page={}".format(page),
timeout=(3, 10) # 连接超时3秒，读取超时10秒
)
print(page, resp.status_code, len(resp.content))
4. 合理设置Keep-Alive超时。超时太短，连接频繁重建，复用形同虚设；太长则占用连接资源，影响并发能力。一般建议在30到75秒之间起步，再结合目标网站的响应节奏微调。
5. 就近接入代理节点。物理距离决定了RTT的下限，而握手开销与RTT成正比。选择距离目标网站服务器更近的节点，等于从源头压缩每一次往返的时间，效果立竿见影。
代理服务商这一环，同样决定性能上限
客户端的优化决定了下限，而代理链路本身的质量决定了上限。如果代理节点质量差、并发承载弱，客户端优化做得再好也白搭。挑选支撑HTTPS业务的高性能代理服务时，建议重点看这几点：节点分布是否够广、能否就近接入；高并发下的延迟是否稳定；连接保持能力如何，会不会频繁掉线重连；是否原生支持HTTPS代理；API提取和认证流程是否顺畅。
在这一块，天启HTTP是国内值得考虑的选择：自建机房，IP资源覆盖国内多个城市，支持HTTP/HTTPS代理，高并发场景下延迟表现稳定，并提供API批量提取，接入简单，适合数据采集、自动化任务这类对连接性能敏感的业务。需要提醒的是，天启HTTP提供的是国内IP代理服务，如果你的业务场景需要国外IP，它并不适用。
常见问题
Q: HTTPS代理一定比HTTP代理慢吗？
不一定。单看建连环节，HTTPS确实多一次TLS握手；但只要开启长连接和会话复用，握手成本会被多次请求摊薄，整体差距很小。而且HTTPS传输加密更安全，如今多数网站本身就强制HTTPS，走HTTPS代理反而是更匹配的选择。
Q: 怎么判断瓶颈到底在握手还是在带宽？
一个简单的办法：对同一个目标地址连续请求多次，对比第一次和后续请求的耗时。如果第一次明显慢、后面快很多，说明瓶颈在握手建连，做好连接复用即可明显改善；如果每次耗时都差不多，再排查带宽、目标站响应速度和代理节点质量。
Q: 连接复用会不会增加被目标网站限制的风险？
连接复用本身不改变出口IP，也不影响目标站对访问频率的判断，真正需要控制的是请求频率和节奏。合理设置请求间隔，配合天启HTTP的IP池轮换使用，既能享受复用带来的速度提升，也能降低被限制的概率。
Q: 天启HTTP支持HTTPS代理吗？
支持。天启HTTP提供HTTP/HTTPS代理，依托自建机房和高并发架构，可以满足数据采集、自动化任务等对连接性能要求较高的业务场景，通过API提取代理后按文中方法复用连接即可。
Q: Keep-Alive超时设置多长比较合适？
没有绝对标准，一般建议30到75秒之间起步，再根据目标网站的实际情况调整。判断依据很简单：如果日志里频繁出现"连接重建"，说明超时偏短；如果高并发时出现连接排队等待，则说明占用时间偏长，需要适当下调。
