Tình huống cổ điển: kịch bản theo dõi giá trên Wildberries hoặc Ozon hoạt động tuyệt vời trên máy tính xách tay tại nhà, nhưng sau khi chuyển sang VPS lại bắt đầu nhận được 403, captcha hoặc bị cấm ngay lập tức theo IP. Nhà phát triển thay đổi tiêu đề, thêm độ trễ - nhưng kết quả không thay đổi. Vấn đề hầu như không bao giờ nằm ở mã của trình phân tích mà ở môi trường mà nó thực hiện các yêu cầu. Chúng ta sẽ phân tích 7 lý do cụ thể và những gì cần thay đổi để trình phân tích hoạt động ổn định trên máy chủ.
Tại sao mọi thứ hoạt động cục bộ, nhưng trên máy chủ lại bị cấm
Khi bạn khởi động trình phân tích từ máy tính tại nhà, trang web thấy yêu cầu từ một địa chỉ IP người dùng bình thường của nhà cung cấp của bạn, từ khu vực quen thuộc, với môi trường trình duyệt thực tế, nếu bạn sử dụng Selenium hoặc Playwright với hồ sơ thực. Ngay khi cùng một kịch bản chuyển sang VPS ở Đức, Hà Lan hoặc Mỹ, bức tranh hoàn toàn thay đổi: IP thuộc về trung tâm dữ liệu, dấu vân tay TLS có thể khác do phiên bản thư viện khác nhau, múi giờ của máy chủ không trùng khớp với địa lý của IP, và tần suất yêu cầu tăng vọt, vì máy chủ hoạt động 24/7 mà không có thời gian nghỉ.
Hệ thống chống bot của Wildberries, Ozon, Avito và hầu hết các thị trường lớn từ lâu đã không chỉ xem xét User-Agent. Họ phân tích tổng hợp hàng chục tín hiệu: loại IP, tốc độ và tính thường xuyên của các yêu cầu, hành vi trên trang, sự phù hợp của các tiêu đề và tham số TLS, sự tồn tại của cookies và lịch sử phiên. Máy tính cục bộ tình cờ vượt qua kiểm tra ở hầu hết các điểm, máy chủ - gần như thất bại ở tất cả. Dưới đây là phân tích chi tiết về từng lý do.
Lý do 1: IP của trung tâm dữ liệu thay vì IP của người dùng
Đây là lý do số 1 trong 80% trường hợp. Địa chỉ IP của VPS và máy chủ đám mây (AWS, DigitalOcean, Hetzner, các dịch vụ VDS thông thường) nằm trong cơ sở dữ liệu của các trung tâm dữ liệu - ASN của các nhà cung cấp này được công khai biết đến và được các hệ thống chống bot sử dụng để lọc lưu lượng ngay lập tức. Các thị trường sử dụng những danh sách này trước tiên, vì 95% việc phân tích tự động đến từ IP của máy chủ.
Giải pháp - sử dụng IP mà về mặt hình thức không khác gì so với người dùng bình thường trên internet. Để phân tích Wildberries, Ozon và Avito, proxy cư trú là lựa chọn tốt nhất: đây là các địa chỉ IP thực tế của các nhà cung cấp tại nhà, được cấp cho các thuê bao bình thường. Các hệ thống chống bot nhìn nhận yêu cầu như lưu lượng từ người dùng thực, chứ không phải từ máy chủ trong trung tâm dữ liệu, điều này loại bỏ phần lớn các khối ngay lập tức.
Lý do 2: Không có xoay vòng IP và giới hạn tần suất yêu cầu
Trên máy tính cục bộ, bạn thực hiện 20-50 yêu cầu thủ công trong quá trình thử nghiệm, và trang web không nhận thấy điều đó. Trên máy chủ, kịch bản được khởi động theo cron mỗi 5 phút và xử lý hàng ngàn thẻ sản phẩm liên tiếp từ một IP. Mẫu này - là tín hiệu trực tiếp cho hệ thống chống bot: một người thực không thể mở 3000 trang danh mục trong một giờ mà không có một khoảng dừng nào.
Cần phải đưa vào xoay vòng IP trên nhóm proxy và giới hạn số lượng yêu cầu đến một địa chỉ trong một khoảng thời gian. Quy tắc thực tiễn: không quá 30-60 yêu cầu từ một IP trong một phút cho các thẻ sản phẩm, với việc tự động thay đổi địa chỉ sau mỗi nhóm yêu cầu. Ví dụ về cấu hình xoay vòng trong Python thông qua nhóm proxy:
import requests
proxies_pool = [
"http://user:[email protected]:9000",
"http://user:[email protected]:9001",
"http://user:[email protected]:9002",
]
def get_page(url, session_id):
proxy = proxies_pool[session_id % len(proxies_pool)]
resp = requests.get(
url,
proxies={"http": proxy, "https": proxy},
headers={"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"},
timeout=10
)
return resp.text
Khi thu thập một khối lượng lớn thẻ trong một ngày, tốt hơn là sử dụng proxy với việc tự động xoay vòng IP theo yêu cầu hoặc theo thời gian - điều này loại bỏ sự cần thiết phải giữ danh sách địa chỉ một cách thủ công.
Lý do 3: Tiêu đề và User-Agent không giống như trình duyệt
Nhiều trình phân tích trên requests hoặc aiohttp gửi yêu cầu với một tập hợp tiêu đề tối thiểu hoặc với User-Agent chuẩn của thư viện, điều này ngay lập tức tiết lộ kịch bản (ví dụ python-requests/2.31.0). Trên máy tính cục bộ qua trình duyệt, tập hợp tiêu đề đầy đủ: Accept, Accept-Language, Accept-Encoding, Sec-Ch-Ua, Referer và các tiêu đề khác - tổng hợp của chúng trông tự nhiên.
Cần phải sao chép đầy đủ tập hợp tiêu đề của trình duyệt thực, bao gồm cả thứ tự gửi - một số hệ thống chống bot kiểm tra ngay cả điều này. Thêm vào đó, việc xoay vòng User-Agent đồng bộ với phiên bản dấu vân tay TLS (xem mục tiếp theo) là rất quan trọng, nếu không sự không phù hợp giữa tiêu đề của trình duyệt và khách hàng TLS thực sẽ trở thành tín hiệu mới của bot.
Lý do 4: Dấu vân tay TLS/JA3 tiết lộ kịch bản
Đây là lý do ít được biết đến nhưng cực kỳ phổ biến dẫn đến việc bị cấm trên máy chủ. Các thư viện requests, urllib, aiohttp sử dụng triển khai TLS handshake của riêng mình, khác với triển khai trong Chrome hoặc Firefox. Các hệ thống chống bot tính toán dấu vân tay JA3/JA4 của kết nối TLS - và nó không giống như dấu vân tay của trình duyệt thực, ngay cả khi các tiêu đề đã được sao chép hoàn hảo.
Giải pháp - sử dụng các thư viện mô phỏng dấu vân tay TLS của trình duyệt (ví dụ curl_cffi, tls-client trong Python, hoặc trình duyệt headless hoàn chỉnh dựa trên Chromium thông qua Playwright/Puppeteer). Tùy chọn thứ hai - làm việc không thông qua khách hàng HTTP thuần túy, mà thông qua một động cơ trình duyệt được quản lý kết hợp với công cụ chống phát hiện, nơi TLS và tiêu đề được hình thành bởi lõi trình duyệt thực, chứ không phải là mô phỏng của thư viện.
Lý do 5: Múi giờ, ngôn ngữ và máy chủ DNS
Nếu kịch bản mô phỏng trình duyệt thông qua Selenium hoặc Playwright, hệ thống chống bot có thể kiểm tra múi giờ hệ thống, ngôn ngữ giao diện, DNS resolver và thậm chí là rò rỉ WebRTC của IP thực của máy chủ. VPS trong trung tâm dữ liệu Frankfurt với múi giờ hệ thống UTC và nhà cung cấp DNS của nhà lưu trữ, trong khi sử dụng proxy với IP từ Moscow, tạo ra sự không phù hợp rõ ràng về dữ liệu địa lý - đây là một trong những tín hiệu đáng tin cậy nhất để phát hiện.
Tất cả các tham số môi trường - múi giờ, ngôn ngữ trình duyệt, DNS, địa lý qua WebRTC - phải phù hợp với khu vực của địa chỉ IP được sử dụng để yêu cầu. Chính để giải quyết vấn đề này mà các trình duyệt chống phát hiện được tạo ra: Dolphin Anty, AdsPower, Multilogin, Octo Browser và GoLogin cho phép cấu hình một "hồ sơ trình duyệt" riêng cho mỗi proxy, nơi tự động điều chỉnh múi giờ, ngôn ngữ, độ phân giải màn hình và WebRTC theo địa lý của IP.
Lý do 6: Mẫu yêu cầu quá "robot hóa"
Con người lướt qua danh mục với các khoảng dừng khác nhau, nhấp vào các sản phẩm ngẫu nhiên, đôi khi quay lại, cuộn trang không đồng đều. Kịch bản trên máy chủ thường thực hiện các yêu cầu qua các khoảng thời gian đều đặn (ví dụ chính xác mỗi 2 giây) và chỉ truy cập vào các URL cần thiết mà không có "tiếng ồn" xung quanh - không tải hình ảnh, kịch bản, không truy cập vào trang chính trước khi vào thẻ sản phẩm.
Những gì cần thay đổi: thêm độ trễ ngẫu nhiên (không phải 2 giây cố định, mà là ngẫu nhiên từ 1.5 đến 6 giây), thỉnh thoảng truy cập vào các trang trung gian (danh mục → thẻ sản phẩm, thay vì yêu cầu trực tiếp đến API), mô phỏng cuộn và chuyển động chuột khi làm việc qua trình duyệt headless. Điều này làm tăng thời gian thu thập dữ liệu, nhưng giảm đáng kể số lượng bị cấm.
Lý do 7: Phiên và cookies không được lưu giữa các yêu cầu
Thường thì trình phân tích trên máy chủ tạo ra một phiên requests mới cho mỗi yêu cầu - không có cookies, không có token xác thực đã lưu, không có lịch sử truy cập. Các thị trường như Wildberries và Ozon phát hành cookies tạm thời và token khi lần đầu truy cập, và các yêu cầu tiếp theo mà không có chúng trông đáng ngờ, như thể mỗi yêu cầu được thực hiện bởi một người dùng ẩn danh mới.
Sơ đồ đúng: một phiên (requests.Session() hoặc ngữ cảnh trình duyệt) - cho một IP từ nhóm proxy, với việc lưu cookies trong suốt chuỗi yêu cầu đến IP đó. Khi thay đổi proxy, cần bắt đầu một phiên mới với cookies sạch, mô phỏng một người dùng mới, chứ không tiếp tục sử dụng cookies cũ với IP mới - điều này cũng tạo ra sự không phù hợp và kích hoạt việc bị cấm.
Danh sách kiểm tra: những gì cần thay đổi theo thứ tự
Nếu trình phân tích bị cấm ổn định trên máy chủ nhưng hoạt động cục bộ, hãy kiểm tra các thay đổi theo thứ tự này - như vậy bạn sẽ tìm ra lý do nhanh hơn:
| Bước | Điều gì cần kiểm tra | Điều gì cần thay đổi |
|---|---|---|
| 1 | Loại IP của máy chủ | Chuyển sang proxy cư trú thay vì IP trực tiếp từ dịch vụ lưu trữ |
| 2 | Tần suất yêu cầu | Thiết lập xoay vòng IP và giới hạn yêu cầu đến địa chỉ |
| 3 | Tiêu đề yêu cầu | Sao chép đầy đủ tập hợp tiêu đề của trình duyệt thực |
| 4 | Dấu vân tay TLS | Sử dụng curl_cffi / trình duyệt headless thay vì requests thuần túy |
| 5 | Múi giờ và ngôn ngữ | Cấu hình hồ sơ trong Dolphin Anty / AdsPower cho khu vực IP |
| 6 | Mẫu hành vi | Ngẫu nhiên hóa độ trễ, thêm các trang trung gian |
| 7 | Phiên và cookies | Gắn một phiên với một IP cho toàn bộ chu trình yêu cầu |
Đối với việc phân tích tần suất cao các danh mục Wildberries và Ozon, nơi tốc độ duyệt hàng ngàn trang là quan trọng, thường kết hợp hai loại proxy: proxy trung tâm dữ liệu cho các yêu cầu kỹ thuật thô (kiểm tra khả năng truy cập, mã trạng thái) và proxy cư trú - cho việc thu thập dữ liệu cuối cùng từ các thẻ, nơi việc ngụy trang thành người dùng thực là quan trọng. Đối với các ứng dụng di động của các thị trường và Avito, đôi khi hiệu quả hơn là sử dụng proxy di động, vì chúng ít bị đưa vào danh sách tự động cấm theo ASN.
Kết luận
Việc bị cấm trình phân tích trên máy chủ khi phiên bản cục bộ hoạt động gần như luôn liên quan đến môi trường: loại IP, dấu vân tay TLS, tiêu đề, múi giờ, mẫu yêu cầu và quản lý phiên. Kiểm tra từng lý do trong 7 lý do theo thứ tự - từ lý do phổ biến nhất (IP của trung tâm dữ liệu) đến lý do ít rõ ràng nhất (sự không phù hợp giữa múi giờ và khu vực IP) - có thể khôi phục hoạt động ổn định của trình phân tích mà không cần thay đổi logic kinh doanh chính của việc thu thập dữ liệu.
Nếu bạn thu thập giá cả và tồn kho trên Wildberries, Ozon hoặc Avito với khối lượng lớn, hãy bắt đầu bằng cách thay đổi IP: thử proxy cư trú thay vì địa chỉ VPS tiêu chuẩn - trong hầu hết các trường hợp, điều này loại bỏ đến 70% các khối ngay cả trước khi bạn bắt đầu cấu hình tiêu đề và dấu vân tay TLS.