亿牛云 Logo亿牛云

FAQ

阅读模式

请求频率不高，为什么还是容易被封或返回 429？

很多网站不只看总请求量，还会看请求节奏、会话行为和请求头模式。你的总量不高，不代表访问特征正常。固定间隔、固定并发、固定头部，通常比“稍快一点但更像真实访问”的流量更容易被识别。

优先检查这几件事：

  1. 你是不是按固定周期发请求
  2. 你是不是把并发全压在同一个域名上
  3. 你是不是频繁重复拉取相同页面或相同代理
  4. 你的请求头、Cookie、Referer 是否长期保持完全一致

建议处理方式：

  • 给请求加随机延迟，不要让每次请求都卡在固定节奏
  • 控制单域名并发，不要只看全局并发
  • 复用本地缓存、已提取代理和已验证结果，减少重复请求
  • 把“提取代理”和“实际访问目标站”拆开统计，分别限速

如果你在用 Scrapy，先看下面几个配置：

1
DOWNLOAD_DELAY = 1

2
RANDOMIZE_DOWNLOAD_DELAY = True

3
CONCURRENT_REQUESTS = 16

4
CONCURRENT_REQUESTS_PER_DOMAIN = 8

这些值不是固定答案，但它们决定了你的请求节奏是否过于整齐。排查时先降低并发，再增加延迟，再观察目标站是否恢复正常。

报 Temporary failure in name resolution，先查什么？

先查 DNS。这个报错说明机器在发请求前就没有把域名解析成 IP，问题通常出在 DNS 配置、缓存、网络连通性，或者代理地址本身无法解析。

建议按这个顺序排查：

  1. 先确认目标域名能不能解析
  2. 再确认当前机器的 DNS 配置是否可用
  3. 再确认机器到 DNS 服务器、代理服务器和目标站的网络是否连通
  4. 最后再看程序里的重试逻辑

先测试域名解析：

1
nslookup example.com

2
dig example.com

如果这里已经失败，先看当前机器的 DNS 配置：

1
cat /etc/resolv.conf

如果 DNS 服务器本身不稳定，可以临时改成公共 DNS 再重试：

1
nameserver 223.5.5.5

2
nameserver 223.6.6.6

然后测试基础连通性：

1
ping 223.5.5.5

2
curl -I https://example.com

如果你怀疑是缓存问题，可以刷新本机 DNS 缓存。不同系统命令不同，Linux 常见环境可以先尝试：

1
sudo systemd-resolve --flush-caches

只有在 DNS、网络和代理都正常以后，程序重试才有意义。域名解析本身不通时，继续加重试只会放大失败量。

HTTPS 请求报 SSL 证书错误，该怎么判断？

先把它当成证书校验问题，不要先把锅甩给代理。常见情况是目标站证书链不完整、本地 CA 证书缺失、TLS 握手版本不兼容，或者你关闭证书校验后只是把错误换成了警告。

建议先确认三件事：

  1. 目标站在浏览器里是否能正常打开
  2. 当前运行环境的 CA 证书是否完整
  3. 你的请求库有没有显式关闭证书校验

urllib3 常见警告之一是 InsecureRequestWarning。这通常表示你在访问 HTTPS 站点时关闭了证书校验。临时定位问题可以这样关掉警告：

1
import urllib3

2


3
urllib3.disable_warnings()

但这不是长期方案。长期运行的爬虫应该优先修复证书环境，而不是默认跳过校验。

如果你已经确认目标站证书正常，但仍然频繁出现 SSL/TLS 问题，还要继续检查：

  • 运行环境的 OpenSSL 和依赖库是否过旧
  • 代理链路是否篡改或拦截了证书
  • 目标站是否对 TLS 指纹有额外校验

结论很简单：排查阶段可以短暂关闭告警，正式环境应当恢复证书校验。

客户端看到很多 ESTABLISHED，服务端连接却少很多，怎么排查？

先统一统计口径，再判断是不是真的有“幽灵连接”。大多数“客户端三万，服务端三千”的问题，第一步不是调参数，而是先确认两边是不是在数同一类连接。

客户端和服务端的 ss 过滤方向不同。客户端看的是远端地址和远端端口，服务端看的是本地监听端口。

假设服务端 IP 是 111.200.212.155，监听端口是 6449，建议这样统计。

客户端统计到服务端的已建立连接：

1
ss -tan 'state established and dst 111.200.212.155 and dport = :6449' | wc -l

2
ss -tanp 'state established and dst 111.200.212.155 and dport = :6449'

服务端统计本地 6449 端口上的已建立连接：

1
ss -tan 'state established and sport = :6449' | wc -l

如果只想看某个客户端 IP：

1
ss -tan 'state established and src 10.0.0.123 and sport = :6449' | wc -l

排查顺序建议如下：

  1. 在客户端挑一条具体连接，记下四元组
  2. 到服务端按同样四元组查这条连接是否存在
  3. 如果服务端查不到，再检查监听队列、SYN flood 和中间 NAT/conntrack

先检查服务端是否被连接洪峰压垮：

1
netstat -s | egrep -i 'listen|SYNs to LISTEN'

2
dmesg | grep -i 'possible SYN flooding'

再检查中间层是否把连接“多记账”了：

1
cat /proc/sys/net/netfilter/nf_conntrack_count

2
cat /proc/sys/net/netfilter/nf_conntrack_max

如果需要确认一条连接到底是谁丢了状态，直接抓包最有效：

1
tcpdump -i eth0 "host client_ip and host 111.200.212.155 and port 6449" -vv

重点看三件事：

  • 三次握手最后那个 ACK 是否真的到了服务端
  • 服务端是否立刻回了 RST 或 FIN
  • 中间设备是否吞掉了握手或后续数据包

如果你确认客户端长期保留了大量无效连接，就要继续补这几类治理：

  • 应用层超时
  • 心跳保活
  • 连接池上限
  • 合理的 keepalive 参数

什么时候先查通用问题，什么时候再回产品文档？

可以按这个顺序判断：

  1. 先查 DNS、SSL、请求频率和 TCP 连接状态
  2. 这些都正常，再去查白名单、套餐、提取参数或认证信息
  3. 如果错误已经明确落在产品状态码，再回对应产品手册处理

这样排查更快，也能避免把基础网络问题误判成产品故障。

相关入口

浏览器配置错误码说明