Tất cả bài viết

Giới thiệu Auto: Một endpoint cho mọi mục tiêu

Endpoint Auto chọn Single, Proxy Finder hoặc Browser cho mỗi request, xử lý các thử thách anti-bot và trả về một session mà lệnh gọi tiếp theo của bạn có thể tái sử dụng.

Tính năng mới

endpoint /api/auto hiện là đường dẫn ngắn nhất để có một response hoạt động cho bất kỳ URL nào. Trỏ nó vào một mục tiêu. Auto tự động chọn xem nên chạy request thông qua Single, Proxy Finder hay Browser, xử lý các thử thách chống bot khi gặp phải và trả về một phiên mà lệnh gọi tiếp theo của bạn có thể tái sử dụng.

Một endpoint. Bất kỳ mục tiêu nào. Không cần chuyển đổi chế độ từ phía bạn.

Đó là toàn bộ ý tưởng. Phần còn lại của bài viết này trình bày cách nó hoạt động, chi phí là bao nhiêu và những điểm hạn chế nằm ở đâu.

Cách hoạt động

Bên dưới Auto là một thang bậc (rẻ trước, đắt sau). Trên mỗi request, Auto đi dần lên thang cho đến khi một bậc trả về một response mà các quy tắc validate của bạn chấp nhận.

Thứ tự các bậc:

  1. Cached session. Nếu Auto có một phiên ấm cho host này từ lệnh gọi trước đó, nó sẽ thực hiện lại qua đó trước. Đường dẫn rẻ nhất.
  2. Proxy Finder. Một proxy request được xoay vòng. Tốt cho các trang web được bảo vệ chủ yếu bằng uy tín IP.
  3. Browser. Một bản render đầy đủ thực thi JavaScript, giải quyết các thử thách chống bot và thu thập các cookie mà trang web cấp phát.

Khi một bậc thành công, Auto lưu trữ phiên mà nó tìm thấy: proxy id nó đã sử dụng, các cookie trang web đã cấp phát và User-Agent. Trong lệnh gọi tiếp theo đến cùng một host, Auto sẽ thử phiên đó trước. Nếu nó vẫn hoạt động, bạn sẽ trả phí cho bậc rẻ thay vì bậc đắt.

Một lệnh gọi tối giản:

curl -X POST "https://api.foura.ai/api/auto" \
  -H "Authorization: Bearer pk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/data",
    "validate": { "status": { "accept": [200] } }
  }'

Một response được rút gọn:

{
  "status": 200,
  "data": "...",
  "headers": [...],
  "meta": {
    "rung": "cache",
    "solved": false,
    "attempts": 1,
    "credits": 2
  },
  "session": {
    "proxy": "CLN1B8",
    "cookies": [{ "name": "cf_clearance", "value": "..." }],
    "userAgent": "..."
  }
}

Có hai trường quan trọng cho những gì bạn xây dựng tiếp theo. meta.rung cho bạn biết đường dẫn nào đã chiến thắng. session là bộ ba mà bạn có thể mang vào một lời gọi /api/single để tự replay cùng một exit. Trường proxy là một base36 id mờ (không có raw IPs), an toàn để ghi log và an toàn để truyền giữa các hệ thống.

Tác động

Có hai con số quan trọng ở đây.

Lời gọi đầu tiên tới một trang web được bảo vệ sẽ chạy Browser rung: render, giải quyết, thu thập cookies, và trả về trang cho bạn. Thao tác đó tốn khoảng 10 credit. Khi Auto đã cache một phiên làm việc (session) thành công cho host đó, các lời gọi tiếp theo sẽ chạy qua Single với giá 2 credit. Do đó, lời gọi thứ hai rẻ hơn 5 lần so với lời gọi đầu tiên, và mỗi lời gọi sau đó tiếp tục trả mức giá rẻ miễn là session còn hiệu lực. Chúng tôi đã đo lường điều này trên prod trong quá trình triển khai: các no-cookie exit (sau khi được tìm thấy) sẽ replay chính xác với giá 2 credit mỗi lời gọi, so với 10 credit như trước đây khi mọi request đều đi qua Proxy Finder.

Con số thứ hai: các rung thất bại sẽ không tính phí. Nếu Auto thử ba proxy và mỗi proxy đều trả về lỗi 403 trước khi proxy thứ tư phân phối thành công, thì chỉ credit của proxy thứ tư mới được tính. Bạn trả tiền cho nội dung được phân phối, chứ không phải cho quá trình tìm kiếm.

Đó là giá trị cốt lõi. Rung đắt tiền chạy một lần, rung rẻ tiền chạy mãi mãi sau đó, và bạn không cần tự viết logic caching.

Có hai hành vi khác đáng chú ý vì chúng giải quyết các vấn đề đau đầu thực tế trên production:

Các mục tiêu giới hạn địa lý ngừng lãng phí exit. Khi một trang web trả về lỗi 451 (hoặc một interstitial chặn vì lý do pháp lý) cho hầu hết các exit, Auto sẽ học được những quốc gia nào thực sự đã phân phối nội dung. Ở lời gọi tiếp theo, nó sẽ ưu tiên lấy các exit mới từ những quốc gia đó trước và phân bổ tải đồng thời (concurrent load) trên chúng. Nhờ vậy, một exit may mắn duy nhất sẽ không bị dồn nén và bị rate limit.

Validate chạy trên mọi rung. Một trang sai nội dung (chặn địa lý trả về status 200 với nội dung là thông báo pháp lý) không bao giờ được tính là một hit. Nếu validate.data.fail của bạn nói "legal reasons", Auto sẽ tiếp tục xử lý cho đến khi có một rung vượt qua được. Không phải rung đã cache. Không phải bất kỳ rung nào. Nếu không có gì vượt qua, bạn sẽ nhận được một lỗi fail trung thực kèm lý do thực sự.

Dành cho Power Users

Một vài thiết lập quan trọng khi bạn đẩy một volume lớn qua Auto.

timeout_ms là ngân sách cho toàn bộ operation, không phải cho từng rung. Mặc định là 120 giây. Auto sẽ chia nhỏ nó: mỗi sub-call nhận được mức tối thiểu giữa timeout tự nhiên của nó và ngân sách còn lại, và thang (ladder) sẽ ngừng khởi chạy các rung mới khi thời gian còn lại quá ít. Đặt ở mức 20,000 đối với các công việc yêu cầu độ trễ tương tác. Giữ nguyên mặc định đối với các đợt crawl số lượng lớn có thể chấp nhận thời gian kéo dài.

forceProxy được bật theo mặc định. Auto không bao giờ chạm vào mục tiêu từ IP origin của FourA trừ khi bạn thiết lập forceProxy: false. Một cảnh báo: một số trang web (Cloudflare tương tác với cổng IP-trust) thực sự hoạt động tốt hơn từ một IP data-center sạch so với một exit dân cư có độ tin cậy thấp. Vì vậy, forceProxy: false có thể làm cho một số mục tiêu nhất định trở nên dễ dàng hơn, thay vì khó hơn. Nếu bạn thấy các challenge lặp lại trên một host cụ thể, việc tắt tính năng này là đáng thử.

ignoreProxies là một danh sách tránh ở phía client. Truyền các proxy id mà bạn biết là đã bị hỏng (từ một session.proxy trước đó bị rate limit ở phía bạn) và Auto sẽ bỏ qua chúng ở mọi nơi: tái sử dụng warm session, tìm kiếm exit, và lệnh gọi phụ đến Proxy Finder. Vì vậy Auto sẽ không chọn lại exit mà bạn vừa yêu cầu tránh.

meta cũng cho phép bạn tự xây dựng các dashboard của riêng mình: host nào đã chạm đến cấp độ browser hôm nay, số lần thử trung bình cho mỗi đợt phân phối, tỷ lệ fetch giải quyết thử thách so với fetch sạch. Nếu một host cụ thể đột ngột tăng từ 2 credit lên 10, đó là một tín hiệu suy giảm session mà bạn có thể xử lý trước khi hóa đơn của bạn tăng lên.

Một ví dụ kết hợp cả bốn thành phần:

import requests

r = requests.post(
    "https://api.foura.ai/api/auto",
    headers={"Authorization": "Bearer pk_live_..."},
    json={
        "url": "https://example.com/product/9876",
        "timeout_ms": 30000,
        "forceProxy": True,
        "ignoreProxies": ["CLN1B8", "K7X9AB"],
        "validate": {
            "status": {"accept": [200]},
            "data":   {"accept": ['"price":'], "fail": ["captcha", "legal reasons"]}
        }
    }
).json()

# If Auto delivered, keep the session for the next call to this host
if r.get("status") == 200 and "session" in r:
    session = r["session"]                              # {proxy, cookies, userAgent}
    print(r["meta"]["rung"], r["meta"]["credits"], r["meta"]["attempts"])

Để xem chi tiết về bản thân validate schema, hãy đọc bài hướng dẫn trước trong phần Validate Rules Now Decide What Counts as Success.

Bước tiếp theo

Có hai điều đang nằm trong lộ trình cho Auto ngay lúc này.

Tính năng kiểm tra session sẽ sớm có mặt trên Dashboard. Hiện tại, các session mà Auto giữ cho mỗi host nằm bên trong service và bạn không có gì để xem khi đang debug lỗi tiêu tốn tài nguyên từ phía mình. Chúng tôi đang xây dựng giao diện xem session theo từng host để bạn có thể thấy các session được cache, độ tuổi của chúng, thời gian tồn tại còn lại và lịch sử rung phía sau mỗi session. Cùng với một nút để xóa session thủ công khi target của bạn thay đổi và bạn biết cache đã sai.

Sau đó là các biện pháp kiểm soát chi phí chặt chẽ hơn. Giới hạn credit cứng cho mỗi request (không bao giờ chi nhiều hơn X cho lần gọi này, sẵn sàng báo lỗi nếu vượt quá) và chế độ "single-only" cho các team có target không bao giờ cần đến browser rung. Cả hai tính năng này hiện đang được ẩn sau các flag.

Điểm mấu chốt của Auto là bạn không cần suy nghĩ xem nên gọi product nào. Điều đó không có nghĩa là bạn không thể kiểm tra những gì đã xảy ra. Mỗi response đều đi kèm với rung mà nó sử dụng và session mà nó tạo ra. Đọc hai trường đó và bạn sẽ biết chính xác lý do tại sao các lần gọi của bạn lại có mức chi phí như vậy.