一、爬虫VPS 和普通建站 VPS 的需求到底差在哪
爬虫 VPS 的第一需求是 IP 而不是算力。一台普通建站 VPS 给到 8 核 16G 内存，跑静态站可以扛住几百 QPS，但那台机器往往只带一个 IPv4 出口。你开五十个线程同时抓取，在目标站那边看到的全是同一个 IP 在高频访问，几分钟内就会被降速或直接封禁。反过来，一台只有 2 核 2G 的小机器，只要挂上三十个干净且分散的 IP，采集效率可能是前者的好几倍。
延伸对照：cloudcone 的公开机型与线路说明，可结合本节的判断标准自行核对。
三个维度决定了你该买什么机器。第一是 IP 数量与类型，数据中心 IP、静态 ISP IP、住宅 IP 在目标站的信任度上完全不同，住宅 IP 通常最贵也最不容易被识别成机房流量。第二是速率与并发上限，商家是否对单个 IP 的出站连接数、每秒新建连接数设置限制，这个限制往往比你的带宽数值更早触发。第三是计费方式，有些商家按月给固定流量额度，超出后限速而不是断供，有些按峰值带宽计费，前者适合稳定抓取，后者适合突发式下载。
| 项目 | 建站 VPS | 爬虫 VPS |
|---|---|---|
| 首要指标 | 单核性能、带宽峰值 | 出口 IP 数量与信誉 |
| 并发瓶颈 | CPU 与数据库 | 单 IP 速率与封禁阈值 |
| 流量计费 | 带宽峰值为主 | 月流量额度为主 |
| 存储需求 | 数据库与附件 | 原始数据落盘与去重 |
| 典型故障 | 内存不足进程被杀 | IP 被封导致成功率下滑 |
先算 IP 数量，再算 CPU，这个顺序反过来就会买错机器。算力不足表现为处理队列堆积、任务卡住不动，IP 不足表现为任务能跑但成功率低、同一时间有效返回的比例越来越小。两种故障的表现完全不同，混在一起判断就会买一台核多但只有一个 IP 的机器，钱花了却什么都没解决。
还有一个进阶维度是连接层的指纹。同一台机器上的所有 IP 共享同一个 TLS 指纹和 HTTP 客户端特征，目标站的风控系统可以据此判断多个 IP 来自同一个客户端。要打散这一层，就得让请求经过不同的中间层，或者在客户端侧调整握手特征。这属于进阶操作，投入产出比要结合实际规模评估，抓几十个页面时完全不必考虑。
另一个现实约束是地域分布。目标站如果对不同地区的请求给出不同结果，或者需要按地区抓取不同内容，就必须准备对应地区的 IP。广告库里能拿到结构化套餐的商家覆盖范围很广：justg 的节点在东京、首尔和莫斯科，sixtynet 在洛杉矶和尔湾，goodlyclouds 同时覆盖美国双 ISP 与英国原生 IP，恒创科技的节点分布在香港、美国、日本和韩国。选机器时把目标站点和出口地区的对应关系先列出来，比事后换机器便宜得多。
二、需要几个 IP：按目标站容忍度倒推
单个 IP 能承载的稳定并发并不取决于你的机器有多少核，而取决于出口带宽除以平均响应体大小。算式很朴素：单 IP 理论 QPS 等于出口带宽除以单次请求的总流量，包括请求头和响应体。一个 10Mbps 的出口，如果每次请求平均传输 200KB，理论上限就是每秒 5 次左右。实际能跑到七成已经算不错，因为重传、连接建立开销和突发抖动都会吃掉一部分余量。
延伸对照：digitalocean 的公开机型与线路说明，可结合本节的判断标准自行核对。
# 用 curl 量化一次请求的真实传输量，包含请求头与响应头
curl -o /dev/null -s -w "size_download=%{size_download} time_total=%{time_total}\n" \
https://目标站点/示例页面
# 换算成单 IP 的理论 QPS：带宽 Mbps * 1024 * 1024 / 8 / 单次传输字节数
# 例：10Mbps、单次 200KB → 10*1024*1024/8/204800 ≈ 6.4 次/秒目标站的容忍度决定了除数。普通内容站做了基础防护，一分钟五到十次请求通常无感，但把请求分散到多个 IP 之后，实际可以跑到的并发数会被 IP 数量放大。假设你测出单 IP 每分钟能容忍十次请求，想要每分钟一千次，就需要一百个 IP 的轮换池，或者把速率压到目标站能接受的范围。
| 目标站类型 | 单 IP 可接受频率 | 一个 IP 一天理论请求数 | 备注 |
|---|---|---|---|
| 无防护内容站 | 每分钟 30 次以上 | 四万次以上 | 常因并发而非频率被限 |
| 基础防护站 | 每分钟 5 到 10 次 | 七千到一万五千次 | 常见 429 限速 |
| 有验证码与风控站 | 每分钟 1 到 3 次 | 一千到四千次 | 单 IP 价值最高 |
| 接口型站点 | 看文档配额 | 视配额而定 | 超配额直接封禁 |
另一个容易被忽略的口径是并发连接数而不是请求数。商家侧的出站连接数限制通常比带宽更紧，很多商家对单台机器的并发 TCP 连接设有上限，超出直接丢包或者 RST。压测时应该同时观察建立连接的成功率。
还有一个反直觉的结论是：慢速持续比高速突发更安全。目标站的滑动窗口限流通常统计的是单位时间内的请求数，无论你是每秒五十次持续三分钟，还是每分钟一百次突发两次，前者累计命中窗口的次数是后者的数倍。真正稳妥的节奏是把速率压到目标站阈值的百分之三十以下，用更长的时间窗去换成功率。
# 用 constant 速率发压，观察长时间运行下的成功率是否衰减
curl -s -o /dev/null --limit-rate 50k -Z \
--parallel-immediate --parallel-max 4 \
https://目标站点/示例路径三、请求频率怎么控制：令牌桶与退避
限速不能靠 sleep 硬编码，固定间隔在不同响应延迟下会形成流量尖峰。正确的做法是令牌桶：桶按固定速率补充令牌，每个请求消耗一个令牌，桶有容量上限以允许短时突发。桶容量决定你最多能一次打出去多少请求，补充速率决定长期平均速率。这两个参数分别对应目标的突发容忍度和稳态容忍度。
延伸对照：hostwinds 的公开机型与线路说明，可结合本节的判断标准自行核对。
import time, threading
class TokenBucket:
def __init__(self, rate_per_sec, capacity):
self.rate = rate_per_sec
self.capacity = capacity
self.tokens = capacity
self.lock = threading.Lock()
self.last = time.monotonic()
def take(self):
while True:
with self.lock:
now = time.monotonic()
self.tokens = min(self.capacity,
self.tokens + (now - self.last) * self.rate)
self.last = now
if self.tokens >= 1:
self.tokens -= 1
return True
time.sleep(0.05)
bucket = TokenBucket(rate_per_sec=1.5, capacity=5) # 稳态 1.5 次/秒，允许 5 次突发判读方式不是看代码跑没报错，而是看目标站返回的状态码分布。持续 200 说明速率在阈值内；间歇性 429 说明请求间隔太短，需要把速率下调三成以上再观察；200 之后突然大面积 403 或者返回验证页面，说明已经不是速率问题而是 IP 信誉问题，调速没有用，要换 IP。
退避策略要分层。收到 429 是明确的信号，按指数退避加随机抖动处理，退避上限设在一分钟左右；收到 403 或者验证码页面属于 IP 已经不可用，直接标记下线不要重试，因为重试只会让封禁时间更长；遇到连接超时和连接重置这类网络层错误，可以原 IP 原速率重试三次。
# 用 curl 观察状态码序列，配合上面的令牌桶抓一段真实访问日志
curl -s -o /dev/null -w "%{http_code} %{time_total}\n" \
-H "User-Agent: Mozilla/5.0 (compatible; ResearchBot/1.0)" \
https://目标站点/示例路径
# 统计一段日志里各状态码占比，429 超过 5% 就该降速
awk '{print $1}' access.log | sort | uniq -c | sort -rn四、代理池怎么搭：数据中心 IP 与住宅 IP 的取舍
代理池的价值在于把请求分散到多个独立 IP 上，让目标站看到的是分散的访问行为而不是集中流量。但不同类型的 IP 池效果差别很大，买错类型等于白花钱。数据中心 IP 便宜、量大、带宽足，缺点是目标站的 IP 库对机房段有明确标记，一旦这个段被拉黑，池子里所有 IP 同时失效。
延伸对照：interserver 的公开机型与线路说明，可结合本节的判断标准自行核对。
住宅 IP 贵、量少，但目标站很难把它归类为机房行为。广告库里能查到的结构化套餐里，sixtynet 提供洛杉矶与尔湾节点的住宅 IP 与双 ISP 方案，起步款 LAX-STARTER 为 2 核 2G、2000Mbps 端口、每月 5000GB 流量，标价 200 美元年付，同系列还有 PRO 和 MICRO 两档配置向上；这个商家的产品说明里明确把住宅 IP 用于网络爬虫类场景，属于典型的用途对位商品。具体报价与库存以官网当日报价为准。
干杯cloud 主打美西 AT&T 原生住宅宽带独立 IP，付款后分钟级自动开通，支持支付宝与微信支付。这类原生 IP 接在真实住宅地址上，由运营商原生分配，不经过代理池，对追求住宅属性的场景更合适。
| IP 类型 | 单价区间（估算） | 数量规模 | 抗封能力 | 适合场景 |
|---|---|---|---|---|
| 数据中心 IP | 最低 | 成百上千 | 弱，整段易被拉黑 | 接口型、对公开页抓取 |
| 静态 ISP IP | 中等 | 数十到数百 | 中 | 常规内容采集 |
| 双 ISP IP | 中高 | 数十 | 中高 | 需要跨 ISP 属性稳定 |
| 住宅原生 IP | 最高 | 个位数到数十 | 高 | 有风控、有验证码的站点 |
goodlyclouds 提供美国双 ISP 与英国原生 IP 云服务器，属于静态 ISP 这一档的常见选择；zorocloud 的产品线里同时覆盖原生 IP、住宅 IP 和家宽 VPS，并接驳 CN2 GIA、9929、CMIN2 等线路，节点覆盖美国、新加坡、香港、台湾、英国等地，选型时可以按站点分布决定买哪个地区的段。
代理池的软件实现上，池子要做成带健康度评分的队列，而不是简单的列表。每个 IP 记录成功次数、失败次数、最近响应码和最后使用时间，连续失败自动降权并进入隔离队列，隔离期满再试探性放回。
IP_POOL = [
{"ip": "1.2.3.4", "ok": 30, "fail": 2, "cooldown_until": 0},
{"ip": "5.6.7.8", "ok": 12, "fail": 9, "cooldown_until": 0},
]
def pick_ip(pool, now):
alive = [x for x in pool if now >= x["cooldown_until"]]
if not alive:
raise RuntimeError("代理池无可用 IP")
return max(alive, key=lambda x: x["ok"] / (x["ok"] + x["fail"] + 1))
def report(ip, code):
if code in (200, 301, 302):
ip["ok"] += 1
elif code == 429:
ip["fail"] += 1
elif code in (403, 401) or code == 407:
ip["fail"] += 3
ip["cooldown_until"] = now() + 900 # 403 直接隔离 15 分钟注意池子里 IP 数量和单 IP 请求量要一起看。三百个 IP 每个每天只请求五次，和三十个 IP 每个每天请求五十次，在目标站那边看起来是两种完全不同的行为模式，前者更像正常用户的零散访问。
五、IP 被封了怎么发现：特征识别与自愈
IP 被封很少给你一个干净的错误码。最常见的四种信号是持续返回 403、返回 429 限速页面、返回带验证码的 HTML、或者连接层面直接被重置。区分这四种信号很重要，因为它们对应完全不同的处置：403 和验证码意味着换 IP，429 意味着降速，重置意味着网络层面被墙或者被限连接数。
延伸对照：itldc 的公开机型与线路说明，可结合本节的判断标准自行核对。
# 判定单个 IP 是否已不可用：区分 403/429/验证码/连接重置四种情况
probe() {
code=$(curl -s -m 15 -o /tmp/probe.html -w "%{http_code}" \
-A "Mozilla/5.0 (compatible; ResearchBot/1.0)" "$1")
if [ "$code" = "000" ]; then echo "RESET-OR-TIMEOUT";
elif grep -qi "captcha\|验证码\|滑动验证\|cf-chl" /tmp/probe.html; then echo "CAPTCHA";
elif [ "$code" = "429" ]; then echo "RATE-LIMITED";
elif [ "$code" = "403" ]; then echo "BLOCKED";
else echo "OK-$code"; fi
}自愈机制要包含三个环节。第一是探测，由一个独立于采集队列的低频探测任务定期验证池中 IP 的可用性，探测频率控制在每 IP 每十分钟一次以内，探测本身用不同 User-Agent 和更保守的路径。第二是隔离，被判定不可用的 IP 进入冷却，冷却时长随失败次数递增，比如十分钟、三十分钟、两小时，而不是一次失败就永久弃用。第三是补充，池子低于阈值时自动触发补货或切到备用供应商。
# 统计当前池子的健康分布
awk -F',' '{print $3}' ip_pool.csv | sort | uniq -c | sort -rn
# 只把健康的 IP 投进采集队列，隔离区单独存放
awk -F',' '$4 < 900 && $5 < 5 {print $1}' ip_pool.csv > healthy.txt一个真实的判读经验是看成功率曲线而不是单点。正常情况下你的整体成功率应该在百分之九十以上并保持平稳。一旦出现台阶式下跌，比如从百分之九十五直接掉到百分之六十且不再回升，基本可以确定是池子里的某个 IP 段被整体拉黑，而不是代码改错了。如果是缓慢下滑且伴随 429 变多，那多半是速率超了，把令牌桶的速率往下调。
六、硬件怎么配：CPU、内存、磁盘 IO 与带宽
爬虫的算力消耗和建站完全不同。建站的 CPU 消耗集中在渲染和查询，爬虫的 CPU 消耗集中在解析、序列化和去重。真正吃 CPU 的是解析环节，一个用正则逐行匹配大文件的爬虫，跑一百万行可能吃掉五个 CPU 核；而一个只用 BeautifulSoup 解析结构化页面的爬虫，一个核足够。
延伸对照：iwebfusion 的公开机型与线路说明，可结合本节的判断标准自行核对。
内存消耗取决于并发队列深度和单页缓存。如果你在内存里维护一个已访问 URL 的集合做去重，一千万条 URL 按平均六十字节算，光这个集合就是六百 MB，再算上 Python 对象的额外开销会翻倍。
| 配置项 | 低端配置够用的场景 | 需要加配的场景 |
|---|---|---|
| CPU 核数 | 静态页、接口 JSON、并发 20 以内 | 大文件解析、JS 渲染、并发百级以上 |
| 内存 | 队列深度 1000 以内 | 需要大集合去重或本地模型 |
| 磁盘 | 临时数据、日志留存几天 | 本地数据库、多份原始数据留存 |
| 带宽 | 纯文本抓取 | 下载图片、视频、二进制文件 |
磁盘 IO 在爬虫里被严重低估。大量小文件写入时，随机 IO 会成为瓶颈，机械盘上写二十万个小文件可能比顺序写一个二十 GB 的文件慢得多。买机器时确认是 SSD 还是 NVMe，社区里常见的技术栈是 Python 加 Scrapy 加 Redis 去重加 PostgreSQL 存数据，这套组合在两核四 G 的机器上就能跑得不错。
还有一个细节是内存与磁盘的配合关系。Redis 做去重集合时，如果放不下会触发交换文件，机器会瞬间从流畅变成卡顿，表现为所有任务延迟同时上升。监控时要单独盯 swap 使用量，swap 一旦被写满，抓取任务的吞吐会断崖式下跌，而这跟 CPU 和网络都没有关系。
# 观察 swap 与内存压力，swapon 显示非零且持续增长就说明内存不足
free -m && swapon --show
# 找出占用内存最多的进程，确认是不是去重集合撑爆了
ps -eo pid,rss,%mem,cmd --sort=-rss | head -8带宽方面，端口标称值和实际可用值是两件事。标称千兆的端口在跨洲链路上实测可能只有几百 Mbps，在共享交换架构的机房晚高峰还可能进一步下降。爬虫如果主要抓取国内或亚洲站点，线路质量比绝对带宽更影响吞吐。
判断实际带宽的办法是找一台同线路的参照机做对比下载，而不是看商家给的端口数字。单线程下载速度通常只能跑到标称值的三分之一左右，因为 TCP 单流受窗口限制，用多线程并发下载才能逼近端口上限。
# 多线程并发下载测实际吞吐，别用单线程的数字做判断
for i in 1 2 3 4 5 6 7 8; do
curl -s -o /dev/null -w "%{speed_download}\n" \
https://speedtest.example.com/100MB.zip &
done; wait七、存储与带宽：原始数据落在哪，流量账单怎么估
原始数据的存储位置直接决定流量账单。爬虫抓下来的东西有三个去处：直接丢弃、抓完立即解析后丢弃、或者长期留存做二次分析。如果只是抓完就解析，最省钱的做法是在内存里解析完立刻释放，磁盘只做临时缓冲，机器的流量账单和存储账单都会很低。如果要长期留存，就得考虑数据量增速和备份副本。
延伸对照：justg 的公开机型与线路说明，可结合本节的判断标准自行核对。
流量账单的估算公式是：日请求数乘以单次平均传输量乘以三十天，再乘以失败重试系数。举例来说每天一百万次请求、单次平均 50KB、失败重试按三成算，月流量大约是 100 万乘以 50KB 乘以 1.3 乘以 30，约等于 1950GB。这个数字远超很多新手对月流量的直觉估计。
# 从真实访问日志统计单次请求的平均传输量
awk '{sum+=$10; n++} END {printf "avg_bytes=%.0f total=%.2f GB\n", sum/n, sum/1024/1024/1024}' access.log
# 按日请求量折算月流量，把结果和商家给的额度对比
awk -v req=1000000 -v avg=51200 'BEGIN{
printf "月流量 ≈ %.0f GB\n", req*avg*1.3*30/1024/1024/1024
}'广告库里能查到的套餐里，流量额度差异很大。justg 的 RosCloud 系列从 19.99 美元每月的 1 核 2G 起，配 1TB 月流量、500Mbps 端口，往上每档递增 CPU、内存和磁盘，月流量最高一档到 6144GB。云途的香港与欧洲节点系列则是 1000Mbps 端口配 10000GB 月流量起步的高内存大流量型规格。这些具体数值以官网当日报价为准，下单前务必自己核对当前口径。
存储侧还要算上磁盘写入和日志轮转。爬虫日志如果每天写几个 GB，不做轮转会慢慢吃满磁盘导致服务异常退出。
# 用 logrotate 按天切割并压缩爬虫日志
cat > /etc/logrotate.d/crawler <<'EOF'
/var/log/crawler/*.log {
daily
rotate 14
compress
missingok
notifempty
copytruncate
}
EOF数据长期留存时，更稳妥的做法是把原始数据分层：热数据留在本机 NVMe 供快速回溯，冷数据同步到对象存储或另一台便宜的大容量机器上，原始包再定期做一份离线备份。这样既避免了单台机器磁盘成为瓶颈，也把长期存储成本压到了最低。
八、爬虫的合规边界：哪些能做哪些不能做
技术手段解决不了法律问题。爬虫最容易被忽略的风险点有三个：抓取数据的用途是否侵犯知识产权、抓取行为是否违反目标站的服务条款、以及是否触及个人信息的合规要求。技术选型时把这些边界先想清楚，比事后补救便宜得多。
延伸对照：racknerd 的公开机型与线路说明，可结合本节的判断标准自行核对。
robots.txt 是目标站给出的机器可读规则，标准做法是读取并遵守。判断依据很简单：协议里 Disallow 的路径就不去，Allow 优先，Crawl-delay 决定两次请求的最小间隔。需要注意 robots.txt 本身不是法律授权，它代表的是站点方的意愿声明，技术上可以绕过但不代表可以绕。
# 读取目标站 robots.txt 并检查指定路径是否被禁止
curl -s https://目标站点/robots.txt | grep -i "disallow\|crawl-delay"
# 用 curl 模拟遵循 Crawl-delay 的访问节奏
curl -s -o /dev/null -w "%{http_code}\n" --limit-rate 100k \
-A "MyResearchBot/1.0 (contact: your@example.com)" \
https://目标站点/允许的路径服务条款是第二道线。多数网站的用户协议里都有一段禁止自动化访问和批量抓取的条款，即使 robots.txt 允许访问也不代表条款允许。把爬虫用于个人信息收集、绕过登录墙、或者抓取后再分发，都可能触及法律风险。商业项目中，涉及用户数据的采集必须做脱敏和最小化，只采业务必需字段，并保留数据来源和处理流程的记录。
工程上可控的部分是给爬虫留出身份标识。用带联系方式的 User-Agent，把 Crawl-delay 设为不低于目标站声明的值，遇到 403 和验证码时退避而不是硬冲，这些既是礼貌也是降低被封概率的实操手段。
HEADERS = {
"User-Agent": "MyResearchBot/1.0 (+https://example.com/bot; contact@example.com)",
"Accept": "text/html,application/xhtml+xml",
"Accept-Language": "zh-CN,zh;q=0.9",
}
# 遵守目标站声明的 Crawl-delay，没有声明时用保守默认值
CRAWL_DELAY = 3.0如果需求本身是采集公开数据用于竞品分析或价格监测，通常风险可控；如果涉及个人身份信息、付费内容的绕过、或把数据用于二次分发，那就应该走正式的数据合作或授权采购路径，而不是靠技术手段硬来。
九、成本核算：单 IP 月成本与规模化后的账
爬虫的成本模型跟建站完全不同，建站是服务器加域名加证书的固定支出，爬虫的成本随抓取规模近似线性增长，而且集中在两个变量上：IP 数量和流量额度。这两个变量的乘积决定月度账单。
延伸对照：spinservers 的公开机型与线路说明，可结合本节的判断标准自行核对。
单 IP 月成本的估算方式是把商家套餐价格除以该套餐能稳定提供的可用 IP 数量，再乘以计划使用的 IP 数量。有些商家的套餐按台售卖一台机器只给一个 IP，有些允许附加 IP，附加 IP 通常比整机便宜。
| 成本项 | 计算方式 | 影响因素 |
|---|---|---|
| 基础机器 | 月租 | 核数、内存、SSD 容量 |
| IP 附加 | 附加 IP 单价乘数量 | 是否原生、是否住宅 |
| 流量超额 | 超出额度部分单价或降速 | 抓取资源体积、失败重试 |
| 带宽升级 | 端口升级差价 | 大文件下载、突发并发 |
| 代理服务 | 按 IP 数或按流量 | 池子规模、周转速度 |
规模化的账要算周转变速。池子里的 IP 不是永久资产，被封之后要补货、隔离、重新验证，这部分损耗必须计入。行业常见的情况是住宅 IP 的月损耗率在百分之十到三十之间，这部分完全是运营成本，不能当成意外支出。
# 估算池子的月损耗与补货成本
awk -F',' 'BEGIN{used=0; cost_per=0}
{if($3=="BLOCKED"||$3=="CAPTCHA"){used++; cost_per=$6} }
END{printf "月封禁约 %d 个 IP，补货成本约 $%.2f\n", used, used*cost_per}' ip_pool.csv还有一个省钱的结构性思路是分层池。容易抓的站点用便宜的数据中心 IP 覆盖，把高质量住宅 IP 留给真正需要它的少数目标站点，两者分开统计健康度。这样住宅 IP 的周转压力能降下来，整月账单也会更可控。
还有一个反直觉的账，是不要把机器和 IP 绑死买。有些商家按台卖机器，一台机器只给一个 IP；如果你需要十个 IP，十台机器的 CPU 和内存全是浪费。反过来如果商家允许附加 IP，那么一台内存够用的机器加十个 IP，比十台小机器更省内存也更好管理。选型前先确认附加 IP 的价格与是否允许，这一条往往比对比机器单价更影响总账单。
另外带宽和 IP 数在爬虫里常常需要分开决策。抓纯文本的站点，带宽消耗低，IP 数量是瓶颈，你可能需要一台小机器加大量附加 IP。抓图片和视频的站点，带宽消耗大，IP 数量反而不是问题，一台大流量机器加少量 IP 就够。这两种业务的选型结论完全相反，混在一起算就会两头都不够。
十、常见问题
爬虫VPS 买多少核合适？ 抓普通网页两核起步就够，瓶颈通常在网络和目标站限速而不是 CPU。只有在解析超大文件、执行 JS 渲染或者队列深度过百时，才需要往四核以上加。加核之前先用任务管理器确认进程到底是不是 CPU 满载。
一台服务器能挂多少个 IP？ 取决于商家给多少个 IPv4 以及是否允许附加 IP。很多套餐默认一个 IPv4，附加要单独收费。具体数量以商家控制台和官网当日报价为准，选购前务必确认，不要按宣传页的数量估算。
住宅 IP VPS 和数据中心 VPS 抓取效果差多少？ 在有风控和验证码的站点上差距明显，住宅 IP 的有效返回率通常显著高于数据中心 IP。在完全公开的接口站上两者差别不大，没必要为住宅 IP 多付钱。
被抓了怎么快速恢复？ 先确认是速率问题还是 IP 问题。看返回码，429 就要降速，403 和验证码就换 IP。池子里有备用段就直接切走，同时降速恢复的策略要常备，否则每次都要临时处理。
流量额度不够用怎么办？ 先算清楚到底缺多少，别直接升级带宽端口。爬虫常见的浪费是失败重试带来的重复传输，把重试策略和幂等性做扎实，能省下相当一部分流量。确实不够再考虑升级端口或换套餐。
多个 IP 会不会因为来自同一台机器而被识别？ 会，目标站能通过请求指纹、连接特征发现同源机器上的多 IP 共用行为。缓解办法是让请求特征接近真实浏览器、保持不同 IP 的请求时间分布有差异、并且避免所有 IP 在同一秒集中发请求。
夜间跑爬虫是不是更不容易被封？ 目标站的流量低谷时段风控阈值可能放宽，但机器资源竞争会明显上升，共享型机器在深夜反而更卡。是否错峰要结合目标站和商家两个方向判断，不能只听一边。
需要备案或者申请白名单吗？ 如果是访问境内网站，通常需要用境内 IP 并按对方要求提交用途说明。多数内容站对陌生 IP 的自动化访问都会要求提供来源说明，提前准备好联系邮箱和用途描述比被封后再解释高效得多。
抓下来的数据怎么存才不超磁盘？ 分层加轮转。原始包按天压缩，解析结果入数据库，日志单独切割，历史原始包定期同步到便宜的大容量存储。磁盘使用率超过八成就要告警，不要等写满才发现。
值得自己搭代理池还是买现成的代理服务？ 目标集中、IP 数量需求在几百以内、且对稳定性有要求时，自建更可控也更便宜。需求分散、要覆盖多国、需要秒级切换时，买现成的更省运维。这条线的划分点主要在运维人力成本，不在技术难度。
怎么验证买回来的机器真能跑爬虫？ 下单后第一小时做四件事：测路由与丢包、测单 IP 在不同并发下的状态码分布、测连续抓取两万次后的成功率曲线、测磁盘在大量小文件写入下的表现。这四项跑完就能判断这台机器能不能用。
喜欢 
高兴
鬼脸
呵呵
无聊
伤心
