这是一个创建于 1770 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
googlefans 2019-06-19 14:57:04 +08:00
收费项目吗
|
 |
2
RiESA 2019-06-19 15:05:32 +08:00
同问,是收费项目
|
|
3
RiESA 2019-06-19 15:05:44 +08:00
吗? 手滑按快了
|
 |
4
botsonar OP 免费的
|
|
5
botsonar OP |
 |
6
wbrobot 2019-06-19 15:24:20 +08:00
js 不解析，可以统计爬虫？？
|
 |
8
Sornets 2019-06-19 16:18:35 +08:00
啥原理？
|
|
10
botsonar OP |
 |
11
opengps 2019-06-19 18:06:50 +08:00
有那么几个奇葩爬虫就是不停的爬，甚至有集中爬取的情况。
刚才一下子发太多爬虫 UA 信息，结果因为 ua 包含大量 url 被屏蔽了一会才打开 贴个我自己的博客： https://www.opengps.cn/Blog/View.aspx?id=322 使用判断方法：使用“ Crawler ”作为关键字识别到的文明爬虫 |
 |
12
uqf0663 2019-06-19 18:23:19 +08:00
确实是有反爬虫的需求，我的站点甚至加了一些验证手段，例如随机出现 qq 的 007 验证等，但是每天还是有大量爬虫（他们还是分布式的）来搞。以至于我只要重启 web 服务器后马上服务器的带宽就会被瞬间占满几分钟（估计是他们的失败重试机制不完善导致访问失败后大量重试的请求）着实很头疼
|
1 |
15
uqf0663 2019-06-19 21:40:08 +08:00
@botsonar 某个小众行业的数据查询的网站，数据都是我独家整理的，多年前我是这个小众行业第一个做的，在我没有做任何 SEO 手段没有任何外链的前提下搜索引擎搜这个行业名词我的站一直稳在第一位，以至于后来的模仿者全都是扒我的页面爬我的数据。他们要是友好一点我倒也懒得管他们，主要是他们搞得太狠，页面没有图片就三个简单页面，晚上高峰期都能经常占到 20M 的带宽，真实用户估计都用不到 2M 带宽。所以我有很迫切的需求怎么干掉这些家伙，一直没有找到合适的办法。看起来他们应该是用了类似 Puppeteer 之类的东西来爬，而且大规模的分布式机器，每个 IP 请求的量都跟正常用户差不多，真是不容易识别。
|
|
17
opengps 2019-06-20 08:57:37 +08:00
@botsonar 我的博客板块专门写了几篇关于 UA 的，针对伪造 UA 防御难度很大，你可以参考下，从博客板块搜 UA 关键字能看到全部相关文章
|
 |
19
encro 2019-06-20 10:00:38 +08:00
1，前端 JS 渲染加 COOKIE 验证；
2，nginx 配置单 IP 访问频率； 3，各大搜索引擎 IP 是公开的，可以反向解析，将怀疑 IP 检查一遍，非几大搜索引擎的仿冒爬虫都 ban 掉。 做到以上几条基本可以清净了。 @uqf0663 |
|
20
uqf0663 2019-06-20 10:47:53 +08:00
@encro 注意看我 15 楼的描述，顺便了解下 Puppeteer 先（什么 JS 渲染 cookie 验证完全没有难度），对于我的情况，你说的这些全部没有用（你顺便了解下 qq 的 007 验证，这个他们都能轻松过）。而且现在各大运营商都在进行大内网 NAT 策略（也就是一个城市可能就几个 IP 出口），ban 掉各大 idc 的 ip 还可以，面对大规模家宽 ip 的分布式爬虫，你 ban IP 的同时也会 ban 掉该城市的正常的用户（因为他们的公网 IP 是同一个啊）。
|
|
21
botsonar OP @uqf0663 试一试另一个策略，看看同一个用户在不通 IP 和 UA 下的频率，如果没有登录，你可以通过服务端下发 cookie 的形式标记用户，由于 pupeteer 这种工具其模拟效果是很好，但是效率比较低下，那些大规模占用带宽的可能是那些脚本爬虫；即使是 pupeteer 也是使用 chrome 的 cdp 协议，可以通过协议检测识别这种工具
|
|
23
botsonar OP @opengps 关于 UA 中的 IMEI 写的很好，另外一篇知乎的写的也不错，然后我发现很多 UA parser 没法解析像 appname 和 organization 这些信息
|
|
24
uqf0663 2019-06-20 12:11:58 +08:00
@botsonar 我当前的做法是首次进来就弹 qq 的 007 验证出来，验证通过后下发一个 cookie （这个 cookie 的值是利用 ip 跟 ua 还有其他一些因素组合 md5 后的结果），这个 cookie 请求 10~30 次（随机）以后失效，需要重新走 007 验证重新下发。多次请求以后那个 007 验证的难度会自动变大（例如从拼图验证变成点选倾斜物体验证），我自信拦住一般的非模拟浏览器的脚本爬虫没问题，但是他们貌似很轻松就突破了。
而且我的关键数据是页面留着一串加密信息，然后页面中有几个 ajax 请求，用于解密的随机种子通过这些请求的随机其中一个下发并执行解密还原到页面上，我认为突破这些的最方便做法就只有 pupeteer 类的工具了（就是等我的页面完全渲染完再取内容）。 |
|
25
uqf0663 2019-06-20 12:16:14 +08:00
@botsonar 又由于运营商们的大内网策略，导致我在 ban ip 这件事上很被动，webrtc 我之前没有了解过，我先去了解下，晚一点来此回复。希望本贴公开交流也能给其他爬虫的跟反爬虫的人仕提供些参考
|
 |
26
locoz 2019-06-20 16:56:43 +08:00
@uqf0663 #24 从你的评论中可以看出你的网站是有一定的圈内知名度和信息唯一性的，所以那些针对你网站爬的人肯定会想尽办法破掉你加的反爬，然后你现在用的这个腾讯防水墙的验证码其实好几个打码平台都是有的了，所以...“我自信拦住一般的非模拟浏览器的脚本爬虫没问题，但是他们貌似很轻松就突破了”这是很正常的事情，即使别人自己破不了验证，也还是可以花钱接打码平台来破，只不过增加了点成本而已。
所以其实这方面你真没有什么办法的，你还能尝试做的就是多换换反爬措施，让对方感到厌烦，或许就不想搞你的网站了；或者就跟各大互联网企业一样，用法律手段解决问题，直接把爬你数据的对手网站全都告死。 |
|
27
uqf0663 2019-06-20 17:58:19 +08:00
@locoz 我不认为他们会用到打码平台，因为打码平台是需要成本的，我这是一个极其小众的行业，那些数据虽然我是独家的，但是不值钱，而且在我已知的直接竞争对手中，我是行业第一，我仍无盈利，因为太过小众，所以用户不多，愿意为此付费的更少，竞争对手中虽然有利用信息不对等忽悠用户付费的，但是付费的量并不能覆盖到打码成本。此处可能有疑问，既然连打码成本都覆盖不起，为什么会有大规模的分布式爬虫呢，此我猜测他们某个客户端是有用户基础的，他们利用这个客户端的用户电脑当肉鸡来做的爬虫。
|
|
28
uqf0663 2019-06-20 18:07:01 +08:00
@locoz 另外做为个人开发者（或是小公司）根本无法去告对手，连第一步的取证都是困难重重，也许你不知道律师的成本多贵，也不了解初级法院有多少划水的法官，如果你不小心遇到个坑比律师，那情况就更糟，折腾一趟下来至少几个月时间跟几万块没有了，而且这种技术相关的，初级法院一般解决不了，你得一审二审然后上诉去中级法院甚至去到省院才有可能解决，一般几年几十万就搭进去了，你能获得赔偿是多少呢？未知的，甚至是没有的，某些划水法官会在证据明确的情况下选择驳回双方诉求，你就只能接着上诉，直到遇到一个干实事的法官为止，总之对于个人开发者（或是小公司）而言走法律途径是一场豪赌。
|
|
29
uqf0663 2019-06-20 20:00:40 +08:00
@botsonar google 上翻了几篇 webrtc 的内容以后，还是搞不太懂 webrtc 具体是什么东西，看起来有点像 websocket 之类的东西，而且并不是所有浏览器都能够支持，有一篇说 safari 不支持（又有说支持的），搞不清楚，但是基于可能存在的不兼容，初步估计可能不太合适（因为我的网站用户群体不是 IT 人士，电脑小白更多一点，他们的浏览器可能都比较老旧，难以让他们升级）
|
|
30
botsonar OP 这边大家有空多关注下 github 部分新功能和改动会在 github 进行跟踪，如果有特别的需求或者规划，也可以在 issue 中提出来，因为有很多用户接入了，这个版本会持续开发
|
Select Language