亞馬遜是如何反爬蟲的？

01-18

自己寫了一個程序用來從亞馬遜上下載圖書的信息，單線程，每0.5秒請求一次頁面。單純對圖書頁面的html進行下載，下載了一個多星期都很正常，今天發現下載的頁面是亞馬遜返回的讓用戶輸入驗證碼的頁面。現在十分好奇，它可能或是有哪些方法來阻止機器請求其頁面。

題主握手

我也一直在做對亞馬遜的爬蟲，也飽受這個反爬蟲的困擾。

在經過一段時間的爬蟲之後，亞馬遜會返回一個RobotCheck的頁面。但是如果這個時候暫停爬蟲，快的話個把小時，慢的話半天，基本就又可以繼續爬了。

所以判斷的規則無非是根據IP，訪問行為來判斷。

不過事實上可能還有其他規則。因為在我的開發過程中，還碰到了其他現象。

現象1：頁面直接返回500，然後HTML頂部有一段注釋的問題，提示如何使用介面訪問數據云雲。

現象2：頁面正常返回，但是價格全部為0.（我做的是抓取價格）

因為還在分析解決中，所以暫時不能給題主一個準確的答案。先佔坑吧。

PS：如果是抓取信息，亞馬遜是有API SERVICE的，題主可以看一下：Welcome - Product Advertising API，不用抓HTML那麼辛苦。

做了幾個小實驗，以試圖逼近亞馬遜的防爬蟲機制的邊界。

因為各種原因，做得比較簡陋，結論都是估計出來的，沒有很大依據，漏洞很多，歡迎指出，大家湊合著看

首先大前提是：觸發Robot Check的原因是亞馬遜覺得你在短時間內大量發出請求，有可能是機器。那反防爬蟲的思路就是，通過header裡面的信息讓你的請求看起來不那麼機器。

以下是實驗記錄：

實驗1：

headers：只有user-agent

過程：單線程3個請求

結果：成功 x 3

實驗2：

headers：只有user-agent

過程：單線程20個請求

結果：成功 x 20

實驗3：

headers：只有user-agent

過程：9個線程各20個請求

結果：成功 x 9 x 20

實驗4：

headers：只有user-agent

過程：16個線程各20個請求

結果： 3個Connection aborted，剩餘13個完成，平均每個有6個左右的失敗，均不連續集中在後面的請求

實驗5：

headers：只有user-agent

過程：在實驗4後，繼續重複實驗4：16個線程各20個請求

結果： 1個Connection aborted，15個完成，平均每個有3個左右的成功，不連續。

小結論：

請求的block的一個必要條件是在短時間內產生多個請求（大概至少在一秒內出現3個或以上）
amazon端有多台伺服器，所以不會一下子完全訪問不了，會漸漸地block住

實驗6：

header：user-agent, accept, accept-encoding, accept-language

過程：在實驗5後，單線程3個請求

結果：成功

實驗7：

header：user-agent, accept, accept-encoding, accept-language

過程：在實驗5後，16個線程各20個請求

結果：16個完成，平均每個有7個左右的失敗，均不連續集中在後面的請求

小結論：

加了accept的一些信息能夠讓請求更加安全一些
在block住之後，加了accept等header信息立刻就解鎖了

實驗8：

header：user-agent, cookie

過程：在實驗7後，單線程3個請求

結果：成功

實驗9：

header：user-agent, cookie

過程：13個線程各20個請求

結果：成功

實驗10：

header：user-agent, cookie

過程：在實驗9後，16個線程各20個請求

結果：1個Connection aborted，15個完成，平均每個有1,2個左右的失敗。

實驗11：

header：user-agent, cookie

過程：在實驗10後，16個線程各20個請求

結果：16個完成，平均每個有1,2個左右的成功，其他均失敗。

小結論：

當header裡面有cookie的時候會穩健很多
但是即使有cookie短時間內多次請求也還是會被防，而一旦有一兩個伺服器防了，很快會蔓延到幾乎所有伺服器都防住

實驗12：

header：user-agent, accept, accept-encoding, accept-language, cookie

過程：在實驗11後，使用實驗11的cookie，單線程3個請求

結果：失敗

實驗13：

header：user-agent, accept, accept-encoding, accept-language, cookie

過程：在實驗12後，使用與12不同的user-agent和cookie，單線程3個請求

結果：成功

實驗14：

header：user-agent, accept, accept-encoding, accept-language, cookie

過程：使用13的user-agent和cookie，16個線程各20個請求

結果：成功

小總結：

amazon的防爬蟲機制在只有ip (沒有cookie) 的時候防ip，在有cookie的時候，是防ip+cookie，也即對於一個ip，一個cookie被防了可以換一個cookie。
有cookie的時候觸發防爬蟲robotcheck的可能性小很多
觸發的機制個人猜測是有疊加效應的，即一次使用同一個ip+header短時間內訪問多次(1秒內訪問至少3次以上)是不會觸發robotecheck的，大概在積累了8到9次的短時間多訪問（理由是上面很多實驗都是在第9個請求後開始出現block），才會激發。而這個忍耐度在有cookie的時候會放得更寬。

反防爬蟲的建議：

使用cookie，建立一個cookie-useragent的list，每次訪問隨機使用一組 (要注意cookie過期的問題)
避免短時間內多次訪問(粗略估計在1秒內3，4次以上的訪問量)

亞馬遜反爬蟲很嚴的，有多年寫爬蟲經驗的我也是研究很久才有一些體悟：

IP 信譽監控，基本上亞馬遜能識別你的代理的IP是雲的IP還是住家IP，畢竟亞馬遜是雲計算的龍頭。假如一個IP被識別是雲的IP，或經常被捉到，亞馬遜就會記錄下來，出驗證碼的幾率高好多。
機器人驗證碼(captcha)，如果一個IP（不管有沒有換Cookie）在幾個小時內的下載次數太多，就會跳出驗證碼頁。難度還算中下。用普通的OCR程式可以破解，準確率約四分一左右。但破解驗證碼後，看你的IP 信譽高不高，如果夠高，亞馬遜好長一段時間不來煩你，如果不夠高，每兩個小時又再出驗證碼。（秘：畢竟驗證碼是很傷用戶體驗的，美國時間白天時，亞馬遜網站的流量很大，亞馬遜不敢捉得太嚴，這個時候可以下載快一點，晚上捉得很嚴，這個時候要龜速，或者乾脆休息。）
PhantomJS：全封。畢竟PhantomJS和普通瀏覽器不同，http/css/js請求和執行方式都有細微的差別，亞馬遜能100%識別PhantomJS的請求，由於沒有傷用戶體驗的風險，基本上全面封殺。

奉勸各位，假如只要單純商品的詳情，報價和Sales Rank，用MWS API 就好。假如用爬蟲，切記不要暴力的捉，破解驗證碼是有風險的，假如破解後還暴力的捉，那下次亞馬遜惱羞成怒，可能就換另一種更強的反爬蟲機制了。大家無非是混口飯吃，給自己一條活路，也給哥們一條活路，行?

想解反爬蟲前，先反思，有沒有必要下這麼多商品的數據？假如只是研究一兩個大類的商品的趨勢，是用不著分散式的。再來就是有沒有必要每天更新，有時每星期更新的數據也管用。

P/S：亞馬遜要斷所有爬蟲的後路幾乎易如反掌，只要看你有沒有請求AJAX即可。一般爬蟲只是下HTML而已。他們還沒怎麼做，有他的理由。。。。。。

https://github.com/dynamohuang/amazon-scrapy

python scrapy寫的，抓取各類目Best seller 前100 ，一級類目5000 二級類目5W asin。

功能開發完善中，歡迎提issue和需求交流

15秒發送100+請求成功抓取5000asin並未被封，順滑使用

反爬case待更新

現有反反爬策略：

ip代理池，header池，禁止cookie

http://www.amazon.cn自帶反爬蟲，網頁載入速度比國內電商慢一倍

有沒有嘗試過動態ip

請問如何爬哈請教哈我直接調用的亞馬遜api 但是因為美國亞馬遜有限制只能調用5頁每頁調用10條，所以想用爬蟲看看能爬不求教題主啊，非常感謝~！

我也遇到了，樓主解決了沒？可否共享下解決方案。

保守亞馬遜反爬蟲的折磨介面限制太大了一秒鐘一個介面只能一個請求啊完全達不到需求

沒爬過。會不會是cookie過期了，重新登錄一下就好了？

這裡有寫好的

亞馬遜商品採集爬蟲