论文摘要是对全文的高度概括，必须包含目的、方法、结果和结论四要素，突出创新点，语言简明客观，字数通常不超过300字，具有独立性和自明性。
为什么直接用固定代理池很快被封
固定代理池里那几十个IP，一旦被目标网站标记为“爬虫高频来源”，整批都会进黑名单。Redis本身不解决代理质量衰减问题，它只负责存和取——如果塞进去的proxy_list全是过期或低匿代理，再快的读写也救不了请求失败率。
- 真实场景中，
requests.get(url, proxies={"http": "http://user:pass@ip:port"})返回503或直接超时，大概率是代理已失效，不是你代码写错了 - 免费代理源（如
kuaidaili.com、89ip.cn）的存活时间普遍低于15分钟，手动更新根本跟不上节奏 - 目标站若启用
Cloudflare或Imperva，还会校验User-Agent、Accept-Language、TLS指纹等，单靠换IP没用
用Redis存代理时必须带验证状态和响应延迟
别只存http://1.2.3.4:8080这种裸字符串。Redis里每个代理键至少得包含三项：status（alive/dead）、latency_ms（最近一次验证耗时）、last_check_ts（时间戳）。否则你永远不知道手里的代理是不是“僵尸”。
- 验证逻辑必须走真实请求：用
requests.head("https://httpbin.org", timeout=3)测连通性，不能只socket.connect() - 把
latency_ms当权重排序，优先取latency_ms < 800的代理，高延迟代理即使“活着”也容易触发服务端超时熔断 - 用
zset结构存代理，score设为last_check_ts，方便用ZRANGEBYSCORE批量清理2小时未验证的节点
代理获取、验证、入库要拆成独立进程，且加随机间隔
所有代理抓取脚本如果都在整点启动，目标站日志里会看到一批相同User-Agent+相同IP段的请求扎堆出现——这比频率高更致命。Redis只是管道，上游喂什么，下游就吐什么。
- 每个代理源爬虫进程启动时，先
time.sleep(random.uniform(10, 60))，错开采集时间点 - 验证代理时，对每个IP单独设置
timeout=2.5，并强制使用http://协议（避免HTTPS握手暴露更多指纹） - 入库前检查
redis.hexists("proxy:valid", ip_port)，避免重复写入导致ZCARD统计失真
请求层必须配合轮询策略和异常降级
从Redis取代理不是spop完事。一个代理连续失败3次，就得立刻标为dead并踢出zset；如果当前池子里alive代理少于5个，要触发备用策略——比如切到tor链路或暂停10秒再试。
立即学习“Python免费学习笔记（深入）”；
- 用
redis.eval()执行Lua脚本原子化取+标+删，防止并发时多个worker抢同一个坏代理 - 在
requests.Session里挂Retry时，status_forcelist必须包含429（限流）和503（服务不可用），但重试次数严格限制为1次——多试几次等于主动送封 - 记录每次请求的
proxy_used和response.status_code到本地access.log，后续可按IP段分析哪些ASN被重点盯防
proxyapi.io的免费key）看似能拿100个IP，但其中70%根本无法完成TLS握手——这种细节，只有在curl -v https://httpbin.org --proxy http://x.x.x.x:yy实测时才会暴露。 
