亿牛云 Logo亿牛云

FAQ

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

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

优先检查这几件事：

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

建议处理方式：

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

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

DOWNLOAD_DELAY = 1
RANDOMIZE_DOWNLOAD_DELAY = True
CONCURRENT_REQUESTS = 16
CONCURRENT_REQUESTS_PER_DOMAIN = 8

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

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

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

建议按这个顺序排查：

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

先测试域名解析：

nslookup example.com
dig example.com

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

cat /etc/resolv.conf

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

nameserver 223.5.5.5
nameserver 223.6.6.6

然后测试基础连通性：

ping 223.5.5.5
curl -I https://example.com

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

sudo systemd-resolve --flush-caches

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

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

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

建议先确认三件事：

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

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

import urllib3

urllib3.disable_warnings()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

排查顺序建议如下：

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

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

netstat -s | egrep -i 'listen|SYNs to LISTEN'
dmesg | grep -i 'possible SYN flooding'

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

cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

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

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. 如果错误已经明确落在产品状态码，再回对应产品手册处理

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

相关入口