选住宅类代理IP的理由，通常被说成「更像真实用户」，这句话太笼统，落到具体任务上才知道该不该用。先把这一条理清楚。判断这一条的标准是：这个任务的对端会不会在意请求从哪一类地址来。会在意的，用住宅；不在意的，用机房更省钱。
会出现在意的场景，一般是内容分发、区域限定的服务和需要长期保持同一身份的任务。不在意的场景，是接口调用、文件同步、数据拉取这类只看结果不看来源的任务。
把这两类分清，采购预算的分配就清楚了：把住宅类代理IP留给真正在意的任务，剩下的用机房类兜住，总成本能降一截，效果不受影响。
三类任务的具体对照
第一类是身份敏感型，比如需要长期保持账号与地址对应关系的任务。第二类是区域敏感型，某些服务只对特定地区的地址开放。第三类是普通请求型，只要网络通、速度够就行。
- 身份敏感型
- 对地址的稳定性要求高于速度，住宅类的优势在这里最明显。
- 区域敏感型
- 对地址所属地区有要求，选之前先确认地区覆盖，再谈别的。
- 普通请求型
- 只在意通不通、快不快，机房类足够，价格还低。
别把场景混在一个池子里
最常见的浪费是把三类任务全放在住宅代理IP池里跑。普通请求型占了大部分用量，却承担了住宅的价格。把这类任务分出去，能省下来的钱通常比谈价格更多。
场景会变吗
会。任务扩量、目标站点调整、账号用途变化，都可能让一个原本不敏感的任务变得敏感。所以场景分类要定期回看，不用很频繁，一季度过一遍就够。
怎么判断任务属于哪一类
看它在被拒绝时给出的信号。只说网络错误的，多半是链路问题；提示来源受限的，说明对端在意来源；直接封禁的，说明对端更在意行为特征。三种信号对应三种处理方向，别都用换地址去解决。最后一种最难处理，因为它指向的是行为，换地址解决不了。
场景分对了，预算不会错配，也不会把住宅类的价格用在普通请求上。