做爬虫的估计都遇到过这种时候昨天还跑得好好的任务今天突然慢到怀疑人生。第一反应基本都是代理不行了然后开始骂服务商、准备换套餐、翻新的 IP 池。我最近在做一个电商价格监控项目请求量从日均 20 万涨到 80 万之后开始出现明显的耗时抖动。当时的第一反应也是换代理但把请求耗时按 DNS、TCP、TLS、首字节、传输拆开测了一遍之后发现一半以上的瓶颈其实落在采集系统内部和目标站的限速策略里跟代理链路关系不大。这篇把我完整的排查思路整理了一下包括当时用极安代理做基线对照的具体数据希望能帮后面遇到类似问题的人少走弯路。一句话总结先分层测量再决定动手方向比直接换服务商省时间也省钱。先看症状慢的表现有六种慢是症状不是诊断。不同表现指向不同的锅症状具体表现大概率在哪单请求 TTFB 3stime_starttransfer偏高目标站服务端处理慢或触发限速连接建立 500mstime_connect高TLS 也慢代理链路或运营商出口首次 DNS 200ms、后续正常time_namelookup首次慢后续为 0采集端没 DNS 缓存并发拉到 50 就卡住CPU/带宽都没打满QPS 不涨连接池、线程模型、GIL成功率下降伴随耗时上升4xx/5xx 变多触发风控或 IP 被识别单 IP 用几分钟就慢换 IP 立刻恢复目标站按 IP 限速对号入座只是起点真正判断责任还得靠下面的分层测量别靠感觉。排查前手上得有三样东西少一样都很难查得清楚。历史基线。正常的时候 P50、P95 是多少DNS/TCP/TLS 各段是多少。没有基线变慢就只是主观感受。我一般让每个采集任务上线时留一份 100–1000 次请求的耗时分布日志后面对比全靠它。分层测量脚本。curl 的-w参数最轻量一条命令把请求拆成五段curl -o /dev/null -s -w \ time_namelookup: %{time_namelookup}\n\ time_connect: %{time_connect}\n\ time_appconnect: %{time_appconnect}\n\ time_starttransfer: %{time_starttransfer}\n\ time_total: %{time_total}\n \ -x http://代理地址:端口 https://目标站.com读法很直接DNS 解析time_namelookupTCP 握手time_connect - time_namelookupTLS 握手time_appconnect - time_connect服务端处理time_starttransfer - time_appconnect内容传输time_total - time_starttransfer哪段异常查哪层。两组对照。同一目标站走代理 vs 直连同一代理打目标站 vs 打谷歌/百度这类基线站。四组数据摆出来代理、目标站、本地网络的问题基本能自证清白。原因清单按概率排序别从最贵的假设开始我一般按下面这个顺序排优先级原因触发条件高采集系统内部瓶颈高并发、长时任务、没 DNS 缓存高目标站限速/风控降速数据量突增、单 IP 密度高、请求太机械中代理链路本身变慢换了服务商、IP 池老化、带宽被打满中网络出口/运营商链路波动时段性、跨运营商低目标站服务端故障大促、活动、平台故障有点反直觉大部分人第一反应是查代理但代理其实排第三。跳过前两个直接换服务商是最常见的判断错位。代理链路问题分三层定位代理的排查分三层DNS、TCPTLS、带宽。怎么判断锅在代理拿前面那两组对照数据比走代理时time_connect比直连高 200ms 以上、time_appconnect也跟着升高多半是代理入口或代理到目标站的链路问题仅time_namelookup高、其他都正常是 DNS 层有问题time_total - time_starttransfer段异常长、下载速率明显低于历史基线是带宽被打满了。怎么处理DNS 层先看采集端走的是不是系统 DNS、有没有命中本地缓存。隧道代理场景下 DNS 解析在服务端还得看服务商入口 DNS 的响应时长。TCPTLS 层看代理入口所在机房到目标站的物理路径。跨地域访问建议就近选节点别让北京的机器绕到广州的代理再打上海的站。带宽层看代理产品单业务的带宽参数。1M 带宽下并发 50 个 500KB 页面必然堵5M 起是持续高频采集比较常见的档位。验证修好修完跑 100 次P95 回到历史基线的 1.2 倍以内算修好仍偏高就说明瓶颈不完全在这层回去看对照组。评估代理服务商我看的三个参数评估代理服务商能不能扛住当前负载看的不是 IP 池总规模——那玩意儿基本是营销数字——而是三个能验证的参数单业务带宽底座、异常 IP 自动切换能力、可用率。这几个直接决定你在高并发下能不能贴合历史基线。我这次项目最后选的是极安代理主要看中的就是这三个参数对得上高并发采集的场景评估维度一般代理极安代理高并发采集实测影响单业务带宽1M–3M 常见默认 5M 底座5M 下并发 100 才不堵1M 到 50 就爆可用率说 99% 的多官方披露 99.9%每天多 0.9% 的失败率日均 80 万请求 7200 次白跑异常 IP 处理需要程序端重试服务端自动切换程序端逻辑少一层出错概率降一半评估时看这几列别看 IP 池总数。如果你有其他候选的话直接拿它们的官方参数填进去横着比就行。目标站限速怎么和代理故障区分目标站降速的表现跟代理故障几乎一样请求慢、成功率降、耗时飙。区分它们的关键就一个换 IP 后立刻恢复吗判断方法拿一个全新的 IP 立刻打同一路径如果time_starttransfer立刻回到基线就是目标站按 IP 限速换 IP 依然慢问题不在这层。需要提醒的是现在的风控系统看的维度早就不只是 IP 频率还包括请求头、Session 深度、访问路径、行为模式。单 IP 密度过大只是最容易被抓到的一种。怎么处理短周期任务用短效代理IP 存活 1–15 分钟自动失效不给目标站建 IP 画像的窗口持续任务用隧道代理换 IP 放到服务端程序无感切换请求节奏别用固定 sleep改成基于响应时间的自适应——响应慢就退避快就恢复Session 得模拟真人先访问首页建立信任走列表页再进详情页别一上来就直捣详情页 URL——那在风控眼里跟裸奔没什么区别。验证修好连续 500 次成功率 98% 以上、P95 回到基线 1.5 倍以内算修好。摸目标站的降速阈值先用免费额度跑一份基线做持续采集的团队一般都是先花小钱跑一周摸清目标站的降速阈值和风控画像再决定要不要上更贵的资源。我这次的做法是先用极安代理新注册账号送的 8 小时免费测试额度跑基线——这个时长够连续采 3–4 万次请求能把目标站的降速拐点画出来。具体拐点数据脱敏后大概是单 IP 请求密度超过 0.8 QPS第 3 分钟开始出现耗时翻倍单 IP 累计请求超过 400 次触发一次 302 到风控页请求间隔完全固定比如 sleep 1 秒累计到 200 次就被识别有了这份基线才好决定用多长的 IP 存活周期、并发拉到多少合适。摸阈值这个阶段的目标不是采到多少数据是拿到一份可信的耗时分布——把测量成本和采购成本分开算比一上来就买年套餐合理得多。采集系统内部瓶颈最容易被忽略代理和目标站都排掉了剩下就是自己的系统。这是概率最高的一档但心理上最难承认。怎么判断三个信号一起出现基本就是它CPU 和带宽都没打满QPS 不再随并发数增长time_namelookup首次高、后续也高怎么处理DNS 缓存。默认 socket 每次请求都会重新解析几十毫秒的开销在高并发下被无限放大。给采集程序打个 DNS 缓存补丁字典存已解析域名的结果同域名后续请求直接读缓存收益立竿见影。Scrapy 直接在 settings 里开DNSCACHE_ENABLED就行。连接池复用。用requests.Session复用连接减少建连开销。连接池大小和 Keep-Alive 超时要显式配置默认值对高并发场景来说通常小得离谱。异步替换同步。同步requests 线程池的组合QPS 上限一般在 100–200很难再往上推。换成 aiohttp 之类的异步库等响应的时候可以继续发别的请求QPS 能有质变。GIL 和多进程。Python GIL 卡 CPU 密集任务的并行度。如果解析很吃 CPU把解析拆到独立进程、采集主循环只做 IO——这是最常见的解耦方式。验证修好同代理、同目标站的条件下QPS 应该有 2–5 倍提升CPU 或带宽至少有一项接近打满。两项都没打满瓶颈还在别处。什么时候该停下来不是所有慢都值得自己查到底。三种情况建议直接停手避免越查越乱跨运营商链路波动。电信、联通、移动之间骨干链路抖动采集端修不了等或者换出口。目标站整体故障。大促、活动、平台本身故障时所有人都慢任何优化都是无效动作。上第三方状态页确认一下就行。生产高峰期改配置。风控看行为模式高峰期突然换代理、突然改节奏触发风控的概率反而更高。稳妥做法是灰度切一小部分流量验证通过再放量——所以工程侧最好留一个能低成本切代理入口的开关。极安代理的隧道代理支持 API 切换、按时计费按需扩容我做灰度回滚基本几分钟就能完成一次入口切换这个能力在高峰期是真的救命。FAQQ换了代理服务商还是慢问题一定在采集系统吗不一定。先做四组对照走代理/直连、目标站/基线站。直连基线站也慢问题在本地或采集端只有走代理打目标站慢还得看 curl 分层数据落在哪段。QDNS 缓存开了会不会命中过期的解析结果会所以 TTL 要设合理一般 300–600 秒稳妥。目标站的域名解析极少变化过期风险远低于每次重新解析的性能损失。生产环境留一个手动清缓存的开关就够了。Q短效代理和隧道代理什么场景该用哪个短效适合频繁换 IP、批量提取、临时任务、短周期采集隧道适合持续请求、程序端无感换 IP。判断依据不是哪个更好而是任务的请求节奏和持续时长。我在极安代理上买的是短效 隧道组合——批量类的任务走短效1000 IP 3.6 元/天起1–15 分钟五档存活可选常驻类的采集走隧道两种入口在同一个后台切逻辑上清爽很多。Q预算不多怎么低成本先试跑一份基线看服务商有没有免费测试额度。极安代理给新注册账号 8 小时免费测试这个时长能采 3–4 万次请求够画出目标站的降速拐点。摸阈值阶段的目标不是采数据是拿一份可信的耗时分布别一上来就买年套餐。Q怎么判断是按 IP 限速还是按账号/Cookie 限速保持请求头、Cookie、UA 完全一致只换 IP 打同一路径。耗时立刻回到基线是按 IP换 IP 依然慢但清 Cookie 后恢复是按会话。Qcurl 分层测量只能测单次怎么持续监控写进定时任务每分钟采样一次各段耗时进 Prometheus 之类的时序库。告警口径用P95 相比昨天/上周是否上升比绝对值超过多少毫秒实用得多。最后分层测量的意义不是让你查得多细而是让你在花钱之前知道钱该花在哪。这个思路对代理、对 CDN、对任何网络中间件都成立——先把请求拆开测、让数据说话比拍脑袋换服务商靠谱得多。我这次项目最后的账是换代理花的钱不到总预算的 20%剩下 80% 花在了 DNS 缓存补丁、连接池调优、请求节奏改自适应这些采集系统内部的改动上。这个比例可能反直觉但它挺真实的。如果你也有过以为是代理最后发现是自己代码的经历欢迎评论区聊聊互相避坑。