Chào các bạn, nếu bạn từng tốn hàng tuần để viết một bộ scraper bằng Python, để rồi chứng kiến nó "bay màu" chỉ sau 100 request vì bị Google chặn, thì bài viết này dành cho bạn. Năm 2026, cuộc chiến giữa bot và hệ thống bảo mật của Google đã trở nên cực kỳ gay gắt với các rào cản từ TLS fingerprinting, CAPTCHA đến việc thay đổi cấu trúc HTML liên tục.
Dưới đây là kinh nghiệm xương máu của tôi để xây dựng một bộ scraper bền bỉ hoặc biết khi nào nên "về đội" của các dịch vụ API quản lý (Managed API).
Tại sao các thư viện HTTP tiêu chuẩn lại thất bại?
Phần lớn các scraper "gà mờ" sử dụng requests hoặc node-fetch. Vấn đề là chúng mặc định dùng HTTP/1.1 và các dấu vân tay TLS (TLS fingerprints) không trùng khớp với trình duyệt thật.
- Giao thức lạc hậu: Chrome/Firefox dùng HTTP/2 hoặc HTTP/3. Khi Google thấy hàng loạt request qua HTTP/1.1, hệ thống firewall của họ sẽ gắn cờ "bot" ngay lập tức và trả về mã 429 hoặc yêu cầu CAPTCHA.
- JA3 Fingerprinting: Đây là kỹ thuật Google dùng để kiểm tra "chữ ký" của request trong quá trình TLS Handshake. Nếu bạn dùng cấu hình SSL mặc định của Python, JA3 hash của bạn sẽ tố cáo bạn là một script tự động, không phải trình duyệt Chrome.
Giải pháp kỹ thuật để "ẩn mình"
Nếu vẫn muốn tự build, bạn cần tối ưu hóa ở tầng transport:
- Sử dụng HTTPX: Thư viện này hỗ trợ HTTP/2. Hãy khởi tạo client với
http2=True. Điều này giúp bắt chước cách trình duyệt đàm phán giao thức. - Spoofing TLS Fingerprint: Đừng dùng cấu hình SSL mặc định. Bạn cần tùy chỉnh
SSLContextđể re-order các cipher suites khớp với trình duyệt thật (như Chrome), đặt TLS 1.3 làm mặc định và ưu tiên các thuật toán nhưCHACHA20. - Parsel thay vì BeautifulSoup: Google thường xuyên thay đổi class CSS (ví dụ
.g,.rđổi thành chuỗi ngẫu nhiên). Thay vì target class, hãy dùng XPath để truy xuất theo cấu trúc DOM (ví dụ://div[@id="search"]//a), cách này bền vững hơn nhiều.
Khi nào nên tự build vs. dùng API (SerpApi)?
| Yếu tố | Tự build (DIY) | Managed API (ví dụ: SerpApi) |
|---|---|---|
| Độ phức tạp | Rất cao (cần Proxy, TLS) | Rất thấp (chỉ 1 API call) |
| Bảo trì | Hàng tuần (fix parser/proxy) | Không cần |
| Định dạng dữ liệu | Raw HTML (cần parser) | JSON sạch sẽ |
| Chi phí ẩn | Lương engineer & Proxy cost | Phí đăng ký dự đoán trước |
Lời khuyên: Nếu nhu cầu của bạn dưới 10,000 query/tháng, tự build với một pool proxy dân cư (residential proxy) là hợp lý. Nhưng nếu bạn cần quy mô lớn, việc dành 5-10 tiếng mỗi tuần chỉ để "chữa cháy" parser sẽ đắt đỏ hơn nhiều so với việc trả phí cho một dịch vụ API chuyên nghiệp.
Scaling với kiến trúc phân tán
Khi đạt tới hàng triệu query, bạn cần:
- Celery + Redis: Đẩy tác vụ vào hàng đợi để quản lý retry và điều tiết tốc độ (rate limiting).
- Proxy dân cư: Đừng bao giờ dùng proxy datacenter (AWS/DigitalOcean) vì Google đã blacklist hầu hết các dải IP này. Proxy dân cư từ ISP địa phương là chìa khóa để có "trust score" cao.
Lời kết
Dù việc scraping dữ liệu công khai trên Google là hợp pháp theo các tiền lệ tại tòa án, nhưng hãy luôn làm việc có đạo đức: tôn trọng robots.txt và không spam server của họ tới mức gây ra tấn công từ chối dịch vụ (DoS).
Nếu bạn muốn tập trung vào việc xử lý dữ liệu thay vì tốn thời gian đối phó với bot protection, việc sử dụng các API như SerpApi sẽ giúp bạn có ngay dữ liệu JSON cấu trúc chuẩn, tiết kiệm hàng trăm giờ công bảo trì mỗi năm.
Happy coding!
Bài viết gốc được đăng tải tại How to scrape google search results without getting blocked
Top comments (0)