住宅代理比直连更慢，而这不是一个 bug。你的流量经由一台真实家庭网络上的真实消费者设备路由，而这恰恰就是为你换来真实用户信任的东西，它要花掉一些毫秒。这里有一个下限，再多的调优也钻不到它下面去。
但大多数性能抱怨都漏掉了这一点：人们在搏斗的那大部分延迟，并不是那个下限，而是他们自己加上去的开销。 每个请求都重新握手、过紧的地理过滤、过大的负载，以及重试风暴，通常远比那一跳住宅要贵。这份指南把不可削减的与其余的分开，并走一遍那些真正能挪动这个数字的技术，大致按影响力排序。
首先，搞清时间花在了哪里
一个经代理的请求是一条链：你的客户端 → gateway → 出口设备 → 目标，再返回。时间分成四桶：
- 连接建立 —— 到 gateway 的 TCP 握手、CONNECT 隧道，然后是到目标的 TLS 握手。这通常是最大的可避免开销，而且你每建一条新连接就要再付一次。
- 住宅那一跳 —— 真实的消费者设备和它的家庭网络。这就是下限。它随设备和网络质量而变，你没法把它调优掉。
- 目标响应时间 —— 站点自身要花多久。这不是代理的错，而且在你怪罪别的任何东西之前，值得先把它隔离出来。
- 重试 —— 一个被封或超时、必须重试的请求，花掉的不只是它自己的延迟，它还会成倍放大你的有效延迟。
只有第二桶是固定的。其余三桶都归你来优化。
1. 复用连接（单条最大的胜利）
每一条全新的连接，都要付出穿过代理的完整握手链，而它很容易就盖过请求本身。如果你的代码每个请求都建一条新连接，你就是在一遍又一遍地缴这笔税。
用一个带连接池的 session 或 client，而不是一次性调用：
import os, requests
USER, PASS = os.environ["SHIFTER_USER"], os.environ["SHIFTER_PASS"]# 用粘性会话，好让池中的连接留在同一个出口 IP 上proxy_url = f"http://{USER}-country-us-sid-job1-ttl-600:{PASS}@p.shifter.io:443"proxies = {"http": proxy_url, "https": proxy_url}
with requests.Session() as s: # 池化 + 复用连接 s.proxies.update(proxies) for url in urls: r = s.get(url, timeout=30) # 握手只付一次，而非每个请求值得理解的那个矛盾：轮换与连接复用是互相拉扯的。 如果你每个请求都轮换到一个新 IP，那每个请求就是一条新连接、一次新握手。当你确实需要每请求轮换时那没问题，但要意识到，你是在用延迟换轮换。
2. 在工作负载允许的地方使用粘性会话
承接上面：一个粘性会话（sid + ttl）把你钉在一个出口 IP 上，而这正是让池化连接真正可复用的前提。在逻辑工作单元之间轮换，按任务、按目标、按身份，而不是在每一个单独的请求之间轮换。
如果一个流程横跨数个本来就该看起来像同一个用户的请求（翻阅结果、一个多步页面），那么粘性既是正确的行为，也是更快的那个。选择正确的模式见粘性 vs 轮换住宅代理。
3. 用并发来扩展，而不是去追一个更快的请求
每请求的住宅延迟有一个下限，所以挪动吞吐量的办法是并行，而不是从单次调用里抠毫秒。异步带来的收益远大于微优化：
import asyncio, httpx
async def fetch(client, url): r = await client.get(url, timeout=30) return r.status_code
async def main(urls): async with httpx.AsyncClient(proxy=proxy_url) as client: # 复用的连接 return await asyncio.gather(*(fetch(client, u) for u in urls))但别盲目地把并发拉满。对着一个目标发太多并行请求，会触发速率限制和行为检测，而封锁（通过重试）花掉你的延迟，远超并发所省下的。找到目标能容忍的水平，并待在那之下。
4. 别把地理过滤条件收得过紧
每一个定位标志都会收窄合格出口 IP 的池子。把 country + city + asn 叠在一起，你可能是在从一个很小的集合里挑，这意味着更少、可能更慢的设备，更多失败，以及更多重试。把你数据其实并不需要的过滤条件放宽。
需要注意的是：如果你的用例确实需要一个特定位置才能让数据正确，那就留着它。准确性胜过速度，一个快速的、来自错误市场的答案一文不值（何时城市级定位很重要）。只是别为你并没在用的精度去缴税。
5. 更小的负载就是更快的负载
在这里，延迟优化和带宽优化是同一件事：更少的字节穿过线路，传输时间就更短。当 HTML 或一个 JSON 端点里就有你的数据时，跳过浏览器渲染；必须渲染时，拦掉图片/媒体/字体；并保持压缩开启。完整清单见如何削减代理带宽成本，那里的每一条在缩短你账单的同时，也缩短了你的请求。
6. 设置超时并快速失败
一个卡住的请求会钉住一个 worker，并把你的尾部延迟拖长。设置明确的连接和读取超时；当有东西挂住时，放弃它、换一个新鲜 IP 重试，而不是干等一个 60 秒的默认值。在一个坏出口上快速失败，几乎总是比指望它恢复更快。
7. 靠不被封来削减重试
这是那个容易被忽视的。一个被封并被重试的请求，花掉的是两三个来回而不是一个，所以你的有效延迟，远比你测到的每请求延迟糟糕。降低封锁率就是一项延迟优化：用高质量的 IP、发送真实的头部和相匹配的指纹，并保持明智的节奏。见为什么爬虫会被封和如何避免被封。
8. 测量百分位，并把目标隔离出来
优化你能看见的东西。追踪 p50 和 p95 而不是平均值，是尾部在拖住并发的 worker；并通过在你的真实目标旁边同时给一个快速中性端点计时，来把代理开销与目标的慢分开。方法见如何测试住宅代理的速度、成功率与位置准确度。没有这一步拆分，你会花一周去调代理，而慢的其实是目标。
你修不了的，以及该拿它怎么办
住宅那一跳是一个下限。即便调到完美，住宅也不会追平数据中心的 p50，因为按设计就有一台真实的消费者设备在路径中。这就是那个交换：用延迟换来在受防护目标上拿到真实页面的信任（住宅 vs 数据中心）。
如果你的工作负载确实需要更低、更稳定的延迟并且需要一个稳定的 IP，又不需要一个轮换的住宅池，那就是一个信号：你也许想要的是一个不同的产品，而不是一份更快的住宅配置。ISP 代理正好在中间：数据中心级的速度，配上注册为住宅的地址（中间地带）。选对工具，胜过把错的那个调过头。
常见问题
为什么住宅代理比数据中心代理慢？ 因为流量经由家庭网络上一台真实的消费者设备路由，按设计就多了一跳。正是那一跳，让你在会封数据中心 IP 的站点上看起来像一个真实用户。这是一个刻意的交换，不是缺陷。
降低住宅代理延迟最快的办法是什么？ 复用连接。一个带池化、且配粘性 IP 的 session，把 TCP/TLS 握手只付一次而不是每个请求都付，而在一份粗放的配置里，那通常就是最大的一块可避免延迟。
轮换 IP 会让请求变慢吗？ 会，有一些：一个新 IP 意味着一条新连接和一次新握手，所以每请求轮换放弃了连接复用。当你的用例允许时，在逻辑工作单元之间轮换，而不是每个请求都换。
更紧的地理过滤会让速度变慢吗？ 可能会。每个过滤条件都会收窄合格的池子，所以国家 + 城市 + ASN 叠在一起，可能只剩很少的出口，这意味着更慢的设备和更多失败。留住你数据真正需要的精度，其余的放掉。
我怎么知道慢的是代理还是目标？ 经由同一个代理，对一个快速、中性的端点和你的真实目标各跑同一个测试并计时。两者之差大致就是目标自身的响应时间。测 p50 和 p95，别测平均值。
底线
住宅代理有一个你调不掉的延迟下限，但那个下限之上的几乎一切，都在你的掌控之中。复用连接、在工作允许的地方用粘性会话、用并发来扩展而不是去追单请求的速度、别把地理收得过紧、缩小负载、在卡住时快速失败，以及最重要的，别再被封了，因为重试主宰着有效延迟。然后测量百分位，好让你优化的是那条真正让你痛的尾巴。
做到这些，一份住宅代理配置就会跑在接近它现实上限的水平。如果你仍然需要更低的延迟外加一个静态 IP，那就去看看 ISP 代理，而不是去跟物理规律较劲。定价页面有按 GB 计费的套餐，可以拿任一种对着你自己的工作负载测试。