← 전체 글
제품 업데이트 5분 읽기

Auto 소개: 모든 타겟을 위한 단일 endpoint

Auto endpoint는 각 request에 맞춰 Single, Proxy Finder 또는 Browser를 선택하고 안티봇 방어를 처리하며, 다음 호출에 재사용할 수 있는 세션을 반환합니다.

autoapiorchestrationsessionsanti-bot

새로운 소식

이제 /api/auto endpoint는 모든 URL에 대해 유효한 response를 얻을 수 있는 가장 짧은 경로입니다. 타겟을 지정하기만 하면 됩니다. Auto는 request를 Single, Proxy Finder, Browser 중 어디로 라우팅할지 선택하고, 안티봇 챌린지가 발생하면 이를 처리하며, 다음 호출에 재사용할 수 있는 세션을 반환합니다.

하나의 endpoint. 모든 타겟. 사용자가 직접 모드를 전환할 필요가 없습니다.

이것이 핵심입니다. 이 글의 나머지 부분에서는 작동 방식, 비용, 그리고 주의할 점을 설명합니다.

작동 방식

Auto 내부에는 단계별 계단이 있습니다 (저렴한 것부터 비싼 것 순). 매 request마다 Auto는 validate 규칙이 허용하는 response를 반환하는 단계를 찾을 때까지 계단을 올라갑니다.

순서대로 나열한 단계는 다음과 같습니다:

  1. Cached session. 이전 호출에서 해당 호스트에 대한 활성 세션이 Auto에 있는 경우, 이를 먼저 재사용합니다. 가장 저렴한 경로입니다.
  2. Proxy Finder. 로테이션 proxy request입니다. 주로 IP 평판에 의해 보호되는 사이트에 적합합니다.
  3. Browser. JavaScript를 실행하고, 안티봇 챌린지를 해결하며, 사이트에서 발급하는 cookie를 수집하는 전체 렌더링 방식입니다.

특정 단계가 성공하면 Auto는 찾은 세션을 저장합니다. 사용된 proxy id, 사이트에서 발급한 cookie, 그리고 User-Agent가 포함됩니다. 동일한 호스트에 대한 다음 호출 시 Auto는 해당 세션을 먼저 시도합니다. 여전히 작동한다면, 비싼 단계가 아닌 저렴한 단계의 비용만 지불하게 됩니다.

최소 호출 예시:

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] } }
  }'

축소된 응답:

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

다음에 빌드할 항목에서 두 필드가 중요합니다. meta.rung은 어떤 경로가 성공했는지 알려줍니다. session는 /api/single 호출에 전달하여 동일한 exit을 직접 다시 실행할 수 있는 트리플(triple)입니다. proxy 필드는 불투명한 base36 id이며(원시 IP 없음), 시스템 간에 안전하게 기록하고 전달할 수 있습니다.

영향

여기서는 두 가지 숫자가 중요합니다.

보호된 사이트에 대한 첫 번째 호출은 Browser 단계를 실행합니다. 즉 렌더링하고, 해결하고, cookie를 수집하고, 페이지를 전달합니다. 여기에는 약 10크레딧이 소요됩니다. Auto가 해당 호스트에 대해 작동하는 세션을 캐시하면, 후속 호출은 2크레딧으로 Single을 통해 실행됩니다. 따라서 두 번째 호출은 첫 번째 호출보다 5배 저렴하며, 세션이 유지되는 한 이후 모든 호출은 저렴한 요금으로 처리됩니다. 우리는 롤아웃 중에 프로덕션 환경에서 이를 측정했습니다. 모든 request가 Proxy Finder를 통과할 때마다 10크레딧이 들었던 것과 비교하여, cookie가 없는 exit(한 번 찾은 경우)은 호출당 정확히 2크레딧으로 다시 실행됩니다.

두 번째 숫자입니다. 실패한 단계에는 비용이 청구되지 않습니다. Auto가 세 개의 proxy를 시도하고 네 번째에서 성공하기 전에 각각 403을 반환하는 경우, 네 번째의 크레딧만 계산됩니다. 검색이 아닌 전달된 콘텐츠에 대해서만 비용을 지불합니다.

이것이 핵심 가치입니다. 비용이 많이 드는 단계는 한 번만 실행되고, 비용이 적게 드는 단계는 그 이후로 계속 실행되며, 캐싱 로직을 직접 작성할 필요가 없습니다.

실제 프로덕션 환경의 문제를 해결하므로, 다음의 두 가지 다른 동작도 주목할 만합니다.

지역 제한 타겟이 exit 낭비를 방지합니다. 대부분의 exit에 대해 사이트가 451(또는 법적 차단 전면 광고)을 반환하면, Auto는 실제로 콘텐츠를 전달한 국가를 학습합니다. 다음 호출에서는 해당 국가에서 먼저 새로운 exit을 가져오고 동시 로드를 여러 exit에 분산시킵니다. 따라서 운 좋게 성공한 단일 exit에 요청이 몰려 rate limit이 발생하는 것을 방지합니다.

모든 단계에서 유효성 검사가 실행됩니다. 잘못된 콘텐츠 페이지(본문에 법적 고지가 포함된 상태로 상태 코드 200을 반환하는 지역 차단)는 절대로 성공으로 간주되지 않습니다. validate.data.fail에 "legal reasons"이 명시된 경우, Auto는 특정 단계가 이를 통과할 때까지 계속 시도합니다. 캐시된 단계나 다른 단계가 아닌 실제 성공하는 단계가 필요합니다. 어느 것도 통과하지 못하면, 실제 이유와 함께 실패 결과가 반환됩니다.

파워 유저를 위한 기능

Auto를 통해 대량의 트래픽을 처리할 때 중요한 몇 가지 설정입니다.

timeout_ms은 단계별 예산이 아닌 전체 작업 예산입니다. 기본값은 120초입니다. Auto는 이를 분할합니다. 모든 하위 호출은 (자체 시간 제한, 남은 예산) 중 최소값을 가지며, 남은 시간이 너무 적으면 새 단계 실행을 중지합니다. 인터랙티브 대기 시간 작업의 경우 20,000으로 설정하십시오. 긴 지연을 허용하는 대규모 크롤링의 경우 기본값을 유지하십시오.

forceProxy은 기본적으로 켜져 있습니다. forceProxy: false을 설정하지 않으면 Auto는 FourA의 원본 IP에서 타겟에 절대 접근하지 않습니다. 한 가지 주의할 점이 있습니다. 일부 사이트(IP 신뢰도 게이팅이 있는 인터랙티브 Cloudflare)는 신뢰도가 낮은 주거용 exit보다 깨끗한 데이터 센터 IP에서 실제로 더 잘 작동합니다. 따라서 forceProxy: false는 특정 타겟을 더 어렵게 만드는 것이 아니라 더 쉽게 만들 수 있습니다. 특정 호스트에서 반복적인 챌린지가 발생하는 경우, 이 기능을 끄는 것이 좋습니다.

ignoreProxies은 클라이언트 회피 목록입니다. (rate limit에 걸린 이전 session.proxy에서) 이미 차단된 proxy ID를 전달하면 Auto가 웜 세션 재사용, 종료점 검색, Proxy Finder 하위 호출 등 모든 곳에서 해당 proxy를 건너뜁니다. 따라서 Auto는 사용자가 피하라고 지정한 종료점을 다시 선택하지 않습니다.

meta을 사용하면 자체 대시보드도 구축할 수 있습니다. 오늘 브라우저 단계에 도달한 호스트, 전송당 평균 시도 횟수, 챌린지 해결 요청 대 정상 요청의 비율 등을 확인할 수 있습니다. 특정 호스트가 갑자기 2크레딧에서 10크레딧으로 급증하는 경우, 이는 청구액이 증가하기 전에 대응할 수 있는 세션 저하 신호입니다.

이 4가지를 모두 구성한 예시입니다.

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"])

validate 스키마 자체에 대해서는 Validate Rules Now Decide What Counts as Success의 이전 가이드를 참조하십시오.

다음 단계

현재 Auto 로드맵에는 두 가지 항목이 있습니다.

다음으로 Dashboard에 세션 검사 기능이 추가됩니다. 현재 Auto가 호스트별로 유지하는 세션은 서비스 내부에 있으며, 사용자 측에서 문제를 디버깅할 때 확인할 수 있는 정보가 없습니다. 캐시된 세션, 생성 후 경과 시간, 유지 기간 및 각 세션 이면의 rung 기록을 볼 수 있도록 호스트별 세션 보기를 구성하고 있습니다. 또한 대상이 변경되고 캐시가 잘못되었음을 알 때 수동으로 세션을 삭제하는 버튼도 추가됩니다.

그 후에는 더 엄격한 비용 제어가 도입됩니다. 엄격한 요청당 크레딧 한도(이 호출에 X 이상을 사용하지 않고, 초과 시 정직하게 실패 처리)와 브라우저 rung이 필요하지 않은 대상을 위한 "single-only" 모드가 제공됩니다. 현재 이 두 기능은 플래그 설정으로 제공됩니다.

Auto의 핵심은 어떤 제품을 호출할지 고민할 필요가 없다는 것입니다. 그렇다고 해서 발생한 작업을 검사할 수 없는 것은 아닙니다. 모든 응답에는 사용된 rung과 생성된 세션이 포함됩니다. 이 두 필드를 확인하면 호출 비용이 청구된 이유를 정확히 알 수 있습니다.