用 Python 写一个带健康分代理池的 360 搜索 site: 查询计数脚本的设计思路

在做站点收录巡检时，经常需要批量统计 site:域名 加关键词在 360 搜索中的结果数。手工查一次不难，但几十个域名、上百个关键词一到，就需要一个稳定、可复跑的小脚本。本文只讲设计思路，不提供任何真实代理地址，也不涉及账号与密钥。

一、先把问题拆成三层

输入层是任务清单：关键词、目标域名、期望的查询组合；执行层负责发请求、换代理、解析结果数；存储层记录每一次查询的原始结果，便于事后对账。三层解耦后，换解析规则或存储方式都不会牵一发而动全身。

二、代理池为什么要用健康分

代理的可用性是波动的：有的快但偶尔超时，有的平时可用、突发限流后连续失败。如果只用轮询，坏代理会拖慢整个任务；如果直接剔除，又可能错杀只是临时抖动的节点。健康分的做法是给每个代理一个 0 到 100 的分数，初始给 60 分。请求成功加分，超时、连接失败、返回异常状态码扣分，连续失败额外扣分并进入冷却；分数低于阈值暂停使用，高于阈值且冷却到期后以低权重恢复试探。这样池子会自己把流量导向更可靠的节点。

三、抽取策略要带一点随机性

不要永远只用最高分代理，否则它会最先被限流。常见做法是按分数加权随机抽取，再加少量随机探索：例如 80% 按权重选，20% 从健康分中等的节点里抽。这样既保证成功率，又能及时发现恢复的节点。同一代理连续使用后也要强制换手，避免把压力集中在个别出口上。

四、请求与解析要分开写

请求层统一处理超时、重试、退避和请求头。超时建议分连接超时和读取超时；重试只针对超时与临时性错误，遇到明确的拒绝或验证页面不要无脑重试。退避用指数退避加随机抖动，节奏上模拟正常间隔。解析层只做一件事：从返回页面中稳健地提取结果数量文本，并把“万”“约”等中文数量单位统一换算；解析失败时保存状态码与失败原因，而不是猜一个数字。

五、节流与并发是底线

批量查询最容易犯的错是贪快。建议用线程池或 asyncio 控制并发数，同一站点加全局令牌桶限速，任务之间加随机延迟；把一天的任务拆成多批跑，中间留出休息窗口。脚本的目标是可长期复用，而不是一次把配额打爆。

六、结果怎么存才可复查

每条记录至少包含查询时间、关键词、site: 限定域名、解析到的结果数、使用的代理标识、状态与耗时；失败也要入库，标明失败类型。输出先写 SQLite 或 CSV，跑完再做聚合：按域名统计中位数、按小时统计失败率、按代理统计成功率。这些指标比单次数字更能说明问题。

七、一个最小骨架

可以用 Proxy 表示代理与分数、ProxyPool 负责抽取、反馈与冷却、Searcher 负责构造查询与解析、Runner 负责调度与落库。主流程是：取任务、取代理、发请求、反馈分数、写记录；任何一步异常都不要让整个任务中断。

八、合规提醒

只统计公开搜索结果，不绕过登录与验证，不抓取非公开内容；代理来源要合法合规，配置里只放占位符，不写真实地址、账号与密钥。把脚本当成巡检工具，而不是对抗工具，长期可用性才有保障。