免费试用提供的是一小笔固定的带宽，而你如何使用它决定了你能学到什么。常见的做法是把它指向一个回显 IP 地址的测试端点，确认地址发生了变化，然后得出代理有效的结论。这几乎不能告诉你任何真正需要知道的事情，也正是人们最终购买的套餐在他们真正在意的网站上令人失望的原因。
试用的存在只是为了回答一个问题：这在我的目标网站上、在我的量级下、在我的市场中，能否奏效？下面的内容按价值从高到低排列，以防你在好奇心耗尽之前先耗尽了带宽。
开始之前：做好准备，不要浪费它
两分钟的准备就能改变一次试用的价值。
写下你真正的目标，也就是你的项目实际依赖的站点或端点，并且要包含其中最难的那一个，而不只是简单的那些。写下你真正的市场，具体到需要的国家，如果相关的话，还有城市。并且提前决定什么样算是通过，例如在两个国家的主要目标上有百分之九十的有效响应，因为事先设定好的门槛能阻止你事后为一个平庸的结果找理由。
然后在发出第一个请求之前设置好响应验证。这是最重要的准备步骤，因为验证挑战页面、空结果、被截断的列表，或者跳转到通用页面的重定向，往往会带着 200 状态码到达，而只统计状态码的测试会在什么都没收集到的情况下报告成功。要检查一个只出现在真正正常页面上的标记：一个预期的元素、一个合理的内容长度、JSON 中的一个已知字段。这些失败模式在检测被屏蔽或伪造的内容中有详细记录。
import requests
PROXY = "http://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443"
PROXIES = {"http": PROXY, "https": PROXY}
def is_valid(html):
return "product-price" in html and len(html) > 20_000 # your own marker
ok = 0
for i in range(100): # a small, honest sample
r = requests.get("https://your-real-target.example/item/123",
proxies=PROXIES, timeout=20)
if r.status_code == 200 and is_valid(r.text):
ok += 1
print(f"validated success rate: {ok}%") # not "did it return 200"测试一：在你自己的目标上的成功率
这是比其他所有测试加起来都更重要的测试，它应该占用你大部分的试用带宽。
针对每一个真实目标运行一个有意义的样本量，大约一百个请求，并测量经过验证的成功率而不是 HTTP 层面的成功率。要包含你防护最严的目标，因为一个能应付简单站点却在难的站点上败下阵来的代理池，并不能解决你的问题。如果你有现有的方案，让相同的样本通过它运行一遍作为对照，这样你就是在做比较而不是在猜测。
要留意这样一种模式：成功率开始很高，随着运行推进逐渐下降，因为这通常意味着你的请求节奏对目标来说过于激进，而不是代理池本身有问题，这是一个值得在试用期间学习的节奏教训，而不是等到生产环境中才学到。
测试二：地理位置准确性
如果你的项目依赖于位置，而大多数项目确实如此，那就验证你请求的国家是否就是你得到的国家，并且要检查你实际需要的每一个市场，而不是只检查一个方便的例子。一个代理池可能在某个地区表现出色，在另一个地区却很薄弱，而宣传页面上的全球数字并不能告诉你在你实际采集的那个具体地方情况如何。
有两个层面值得检查。第一，出口地址的地理定位是否指向所请求的国家，要在足够多的请求中采样以发现不一致性。第二，也是更有意义的一点，目标站点的表现是否像你确实身处那里：正确的货币、本地定价、区域商品目录、本地搜索结果。第二点才是真正的测试，因为 IP 地理位置数据库和目标站点自己的判断并不总是一致，而你花钱买的正是目标站点的判断。如果你需要城市级别的定位，就要在城市粒度上验证，而不是假设国家层面的准确性就意味着城市层面也准确。
测试三：这个代理池是否名副其实
花一点带宽来采样出口地址，并按其所属组织进行分组。消费级互联网服务商正是你想看到的结果；如果托管或云服务组织占据了相当比例，那说明这个代理池掺杂了数据中心地址，这一点很重要，因为这些地址正是你的目标网站会当作机器流量对待的地址。完整的方法在识别被伪装成住宅代理出售的数据中心 IP中，其背后的区别原理在住宅 IP 的解剖中。
顺便说一句，要注意地址质量和地址类型是两个独立的维度：一个真正的住宅代理池，如果被滥用导致信誉不佳，仍然会招致验证挑战，而这正是测试一从外部所衡量到的东西。
测试四：会话行为
如果你的项目中有任何部分涉及多步骤流程，比如翻页搜索、登录，或者一个你设置后又要读取的位置上下文，那就在试用期间确认两件事。
确认在你不指定会话时轮换确实会发生，并确认粘性会话在你需要的时长内确实能保持同一个地址。然后在一个保持不变的会话上端到端地运行你的一个真实多步骤流程，因为一个代理池在单个请求上可能看起来没问题，但如果地址在流程进行中悄悄改变，仍然可能破坏整个流程。如果你的工作需要同时保持许多个身份，要检查并发会话是否相互独立地运作。
测试五：性能与消耗
有两个数字值得记录下来，它们都会影响你最终购买的套餐。
如果你的工作对时间敏感，延迟和吞吐量就很重要，所以要在你的真实目标上测量通过代理的响应时间，而不是在测速端点上测量，并且要预期住宅代理会比直连慢，因为流量走的路径更长。重要的是它是否足够快以满足你的工作需要，而不是它是否达到数据中心代理的基准水平。测量方法在测试速度、成功率和位置准确性中。
然后测量每个请求的字节数，这是把套餐估算变成套餐决策的那个数字。用你测得的平均值乘以你预期的月请求量，你就得到了一个真实的带宽数字，而不是一个猜测，这正是估算月度带宽所需的输入。如果结果让人不太舒服，这也正是发现获取数据端点而不是渲染完整页面能让你降到更低套餐档位的时刻，这一点在削减代理带宽成本中有讨论。
不该在试用中花费带宽的地方
有几件事会消耗带宽却教不会你任何东西。
针对一个 IP 回显端点进行测试只能证明代理连上了，这是一个三十秒的健全性检查，而不是一次评估。只测试简单的目标会美化代理池的表现，掩盖你真正需要的答案。在一个目标上跑巨大的流量并不能衡量质量，反而可能导致该地址被封禁，从而让代理池看起来比实际情况更差。而仅凭少量请求就下判断只会得到噪音，因为一个五次请求的样本无法区分百分之九十五的池子和百分之七十的池子。
还有一点：不要根据代理池规模的宣传数字来评估供应商。一个宣传性的数字不是试用能够验证的东西，也不是决定你结果的因素。你所在国家的密度和你目标站点上的成功率才是。
试用检查清单
- 准备工作：包含最难目标在内的真实目标、真实市场、通过门槛，以及在第一个请求之前就写好的响应验证。
- 测量经过验证的成功率，每个目标大约一百个请求，如果有现有方案则加上对照组。
- 对每一个你需要的市场核实地理位置，既包括出口位置也包括目标站点的表现。
- 采样出口组织，确认代理池确实是住宅性质的。
- 在一个粘性会话上执行一个真实的多步骤流程，并确认没有粘性设置时轮换正常发生。
- 记录延迟和每请求字节数，然后根据测得的数字来确定套餐规模。
如果一次试用在你自己的目标上通过了以上全部六项，套餐决策就变成了算术题，而不是一次盲目的信任跳跃。全部套餐层面的选择在如何选择合适的住宅代理套餐中有详细说明。
结论
试用就是带宽，而花在 IP 回显端点上的带宽回答的是一个你本来就不需要问的问题。把它花在你真实的目标上，配合真正的响应验证，核实你实际需要的市场，检查代理池是否真正是住宅性质的，如果你的工作涉及会话流程就实际测试一遍，并记录每请求字节数，让你的套餐规模基于测量而不是猜测。在开始之前设定好通过门槛。做到这些，你在试用结束时就会知道这个产品能否解决你的问题，而这正是试用存在的唯一目的。
如果你想运行这份检查清单，可以在 Shifter 住宅代理的免费试用中进行，它提供国家和城市级别的定位、默认轮换，以及针对需要它的流程的粘性会话。等数字出来后，按 GB 计费意味着你选择的套餐将根据你测得的带宽而定，而不是靠猜测。