求爬虫大佬解答，关于 Cloudflare 的反爬的

[l1ve]

目标是用了 CF 的付费计划，有缓存，目标是每次请求都让 CF 回源,最终目标是将请求间隔降到 50-100ms

尝试用 censys 找源站 IP 没找到，所以只能从 CF 的入口着手

直接 curl 会触发 CF 的 403,这里用 tls 指纹解决了

然后用 URL 混淆突破了缓存，但是只要请求的频率稍稍快一点，就会触发 429 error code: 1015

这里查了官方文档说是请求超过回源限制了，但是返回的 Retry-After 是 0

已经使用了代理，但是是同一个 C 段内的 64 个 IP ，机房 IP

---

目前尝试了几种情况 结果是这样

1.TLS 验证，代理轮询，间隔 5 秒，模拟 IOS => 可以正常访问

2.TLS 验证，代理轮询，间隔 5 秒，随机模拟 IOS/SAFARI/CHROME => 偶尔报 429-1015 错误

3.TLS 验证，不使用代理，间隔 5 秒 随机模拟 => 成功 8 次后 返回 2 次 429-1015 ，成功 13 次，失败 1 ，成功 3 ，后面几分钟成功率基本在 90%以上，20 分钟后成功率 50%左右

4.TLS 验证，代理轮询，间隔 500 毫秒，随机模拟 IOS/SAFARI/CHROME => 偶尔报 429-1015 错误，成功率 40%左右

---

如果用那种住宅 IP 代理服务的话延迟达不到要求，尝试过几个都是 500ms 左右才会返回结果

有大佬做过相关的东西吗，求思路，孩子没招了

[AkinoKaedeChan]

IPv4 的空间不大，可以扫一遍看看能不能找到源站

[CC11001100]

> 目标是每次请求都让 CF 回源

老哥你这看上去像是灰产要 DDOS 啊。。。

[l1ve]

@CC11001100 不至于... 就一个要求实时性高的爬虫而已
已经有一个其他的目标用了 cloudfront 这样搞定了

[l1ve]

@AkinoKaedeChan 考虑过，但目标安全方面做的很到位，严重怀疑就算打到源站了，也没法直接带着 HOST 访问

[NewYear]

等等，你是想要 100 毫秒内的实施页面信息？甚至还要穿透缓存？

这信息的及时性重要性这么高吗？

那如果全天候都要扫描实时信息，那就是 86400*(1/0.1)=86.4 万访问量。

也就是说光你一个人就达到了可怕的 86 万每天的访问量。

恐怖如斯，恐怖如斯啊！！！

[NewYear]

一般的话扫描整个 ipv4 是有可能得到源站 IP ，如果无法得到，只有三种可能。

1 、人家用的不是 80/443 ，在 CDN 上做了重定向，那么你需要扫描整个 tcp 范围 65535 个端口。

2 、人家开了白名单。

3 、人家 cdn 访问的 host 不是你用的这个 host ，又或者加了其他 http 请求参数。

[cnrting]

老哥哥可太狠了

[duzhuo]

就算是找到了源站的的 IP 和端口大概也没有办法，肯定有白名单的 只允许 Cloudflare 的 IP 地址段访问

[zencitta]

看起来像是是抓取菠菜网站

[AkinoKaedeChan]

@NewYear 我在我自己的站点上基本上都配了 mTLS ，扫描器 TLS 握手都完不成（

[xwayway]

也许有个办法可以解决代理 ip 问题😂

[l1ve]

@zencitta 不是哈哈哈

[l1ve]

@duzhuo @NewYear 是的，考虑过扫段，可以确定源站服务器在哪个国家，但是大概率开了 CF 的白名单，所以这条路也行不通
对于这种轮询类的来说其实这个访问量不可怕，为了及时性什么事都干的出来，正在跑的另一个服务是开了十几台和目标同区域的 aws 实例在爬

[l1ve]

@xwayway 老哥细说

[julyclyde]

@NewYear 还有可能根本没在公网上呢

[NewYear]

@julyclyde #15

内网穿透，堪称无敌。

[lisxour]

一看就是炒币抓上新的