CAPTCHAが見ているもの
CAPTCHAはchallenge-responseのレイヤーです。画像を選ぶ、チェックボックスを押す、パズルを解く、hidden risk scoreを通過する、ブラウザ検証を完了するなど、基本的なbotより人間にとって容易な操作を求めます。 代表的な種類:- 画像選択型
- チェックボックス型
- 目に見えないrisk scoring
- Turnstileのようなブラウザ検証型
Cloudflareが追加するもの
CloudflareはCAPTCHAより広い防御レイヤーです。- 実ブラウザ環境を期待するJavaScript/browser integrity check
- リスクが高い時だけ出るmanaged challenge
- IP、path、頻度、アカウント行動に基づくrate limit
- Turnstile verification
- 地域、IP reputation、ASN、header、自動化パターンに基づくaccess rule
なぜスクレイパーが引っかかるか
- 1つのIPから短時間に大量リクエストする
- データセンターIPのreputationが低い
- headless browser特有の信号が漏れる
- IP地域、timezone、language、user-agentが矛盾する
- クリック位置や待機時間が機械的すぎる
- ログイン中にIPやfingerprintが変わる
レイヤーごとの対策
サイトが期待するなら実ブラウザを使う
JavaScript、ブラウザAPI、Cloudflareのbrowser checkに依存するページでは、raw HTTP requestは不向きです。スクリプトを実行し、Cookieを維持し、セッション状態を保てるブラウザruntimeを使います。指紋の整合性を保つ
指紋管理はランダム化ではありません。IP地域、timezone、language、user-agent、viewport、font、操作が1つの自然な人物像として整合している必要があります。詳しくはブラウザフィンガープリントを参照してください。行動を自然にする
一定間隔、正確すぎるクリック、スクロールなし、最短経路だけの遷移は検知されやすい信号です。待機時間に揺らぎを持たせ、スクロールや滞在時間を入れ、クリック位置も自然にします。詳しくは人間らしいスクレイピングを参照してください。ネットワークを整える
プロキシローテーションは1つのIPへの負荷を下げますが、低品質プロキシは逆にCAPTCHAを増やします。住宅IPやISP proxyは自然に見えやすい一方、コストと調達倫理に注意が必要です。詳しくはローテーティングプロキシを参照してください。必要な時だけ解く
チャレンジが出た場合の選択肢は、人間による手動対応、自動CAPTCHA solver、ツール側のmanaged handling、失敗subtaskの保留/再実行などです。すべてをsolverで解くのは遅く高コストです。頻発するなら、そもそものtraffic pattern、fingerprint、behavior、IP reputation、rateを見直します。スクレイピングでの例
- ECカテゴリページ: 1IPで高速にページ送りするとrate limitやCAPTCHAが出やすい
- 検索結果ページ: 同一指紋と同一IPで大量queryを投げると検知されやすい
- チケット/旅行サイト: browser check、fingerprint、行動監視が組み合わさる
- ログイン後ダッシュボード: セッション中のIP変更はaccount takeoverに見えやすい