새로운 기능
출구 노드 순환은 누구나 자동화하는 부분입니다. 하지만 그 밑에 있는 브라우저 시그니처는 대개 변경되지 않습니다.
Single 및 Proxy Finder는 이제 request가 어떤 브라우저로 표시될지 결정하는 네 가지 선택 필드를 지원합니다: browser, os, version, profile. 이에 대응하는 카탈로그는 GET /api/profiles에 공개되어 있으며 API key 없이 접근할 수 있습니다. 현재 Windows, macOS, Android, iOS 환경의 Chrome, Edge, Safari, Firefox, Tor에 걸쳐 79개의 프로필을 제공합니다.
프로필을 직접 지정하지 않으면 Proxy Finder가 이를 대신 변경합니다. 단, 대상 사이트가 기존 프로필을 거부한다는 점이 두 번 확인된 경우에만 변경이 이루어집니다.
동작 원리
필드 중 세 개는 사람이 직접 읽기 위한 것이며 하나는 머신용입니다.
browser, os, version을 사용해 카탈로그 범위를 좁힐 수 있으며, 이 중 일부만 전송해도 됩니다. os은 패밀리 단위로 일치하므로 macOS을 요청하면 목록의 모든 macOS 릴리스를 허용하며, 정확한 릴리스 라벨을 요청하면 해당 릴리스로만 한정됩니다. 조건에 맞는 프로필이 여러 개 남아 있다면 최신 버전이 우선 적용됩니다. 최신 상태를 유지하는 것이 핵심이기 때문입니다. 차단 목록은 주로 오래된 메이저 버전을 기준으로 필터링합니다.
curl -X POST https://eu.api.foura.ai/api/single/ \
-H "X-API-Key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"method": "GET",
"url": "https://example.com/listing/42",
"browser": "Safari",
"os": "iOS"
}'
이는 카탈로그 내 최신 Safari on iOS로 매핑되며, 이에 해당하는 User-Agent, client hints, header 순서를 그대로 전송합니다. Header 순서 자체도 주요 식별 신호이므로 전송 과정에서 임의로 재정렬되지 않습니다.
profile는 네 번째 필드입니다. 최신 버전이 출시된 후에도 동일한 클라이언트를 계속 유지해야 하는 코드를 위한 카탈로그의 고유 ID입니다. Proxy Finder는 request 객체 내에서 이 네 가지 필드를 모두 지원합니다. 전체 매개변수 목록은 API reference에 있으며, Playground 역시 동일한 카탈로그를 참조하므로 드롭다운 메뉴에는 코드로 요청할 수 있는 항목만 표시됩니다. 동일한 네 개 필드가 MCP server의 foura_single 및 foura_proxy 내부에도 포함되어 있어, 에이전트가 단순 403 오류를 반환하는 대신 다른 브라우저로 재시도할 수 있습니다.
이 설계에서 의도적으로 배제한 두 가지 동작이 있습니다.
카탈로그에 없는 조합을 요청하면 해당 브라우저에서 사용 가능한 항목을 안내하는 오류를 반환합니다. 기본값으로 자동 대체하면 사용자가 지정하지 않았고 응답에서도 확인할 수 없는 클라이언트를 전송하게 됩니다. unblocker: false가 포함된 프로필 선택 또한 거부됩니다. 해당 플래그가 실제 header를 전송하는 역할을 하기 때문입니다 (해당 플래그의 실제 동작 원리). 불완전한 프로필은 적용하지 않는 것보다 위험합니다.
카탈로그 자체는 수작업으로 작성하지 않고 직접 측정하여 구성합니다. 스크립트가 실제 request 경로를 통해 모든 프로필을 실행하고 네트워크로 전송된 실제 데이터를 기록합니다. 이는 생각보다 매우 중요합니다. 한 브라우저의 최근 두 개 메이저 버전 사이에서 placeholder brand 문자열이 변경되고 brand 순서가 뒤바뀌었는데, 탐지 시스템은 바로 이러한 세부 정보를 식별하기 때문입니다.
Impact
예상치 못했던 분석 결과는 다음과 같습니다.
기본값은 모든 사용자가 공유하는 기본값입니다. 별도 설정을 지정하지 않았을 때 request가 사용하는 클라이언트는 설정을 지정하지 않은 다른 모든 request의 클라이언트와 동일합니다. 리소스를 적게 소모하는 차단 기준을 찾는 방어 시스템은 바로 이 공통 기본값을 타겟팅합니다. 이로 인한 실패 패턴도 독특합니다. 특정 브라우저를 차단하는 사이트는 보유한 모든 출구 노드에서 해당 브라우저를 거부합니다. 결국 허용되지 않는 동일한 클라이언트로 전체 재시도 예산만 낭비하게 됩니다.
서로 다른 세 개 공급업체를 대상으로 세 차례 측정을 진행했으며, 결과 패턴은 매번 동일했습니다.
PerimeterX 기반 부동산 포털은 기본값 설정을 사용한 9번의 시도를 모두 차단했습니다. 다른 조건과 IP pool은 그대로 둔 채 request가 명시하는 platform만 변경하자 6번의 시도 모두 페이지를 정상 반환했습니다. Akamai 기반 영양제 쇼핑몰은 기본값을 거부했으나 다른 두 개 브라우저 패밀리 요청은 정상 처리했습니다. DataDome 기반 금융 뉴스 사이트는 기본값 요청에 401 오류와 774바이트 인터스티셜 페이지로 응답한 반면, 다른 세 개 프로필은 약 760KB의 실제 페이지를 각각 12회씩 정상 로드했습니다. 요청 순서로 인한 편향이 없는지 확인하기 위해 순서를 바꾸어 역방향으로도 검증했습니다.
이제 Proxy Finder는 출구 IP뿐만 아니라 브라우저 제품군도 순환합니다. 단일 거부는 특정 출구의 문제일 수 있으므로 서로 독립적인 두 개의 출구에서 거부되어야 다음 단계로 넘어갑니다. 이후 가장 작은 변화인 플랫폼부터 시작하여 다른 제품군을 시도하는 사다리 구조를 따릅니다.
비용은 추가되지 않습니다. 순환은 재시도 발생 여부가 아니라 재시도 시 전송되는 내용만 변경하므로, 작업당 request 수와 크레딧 소모는 기존과 정확히 동일합니다.
고급 사용자를 위한 안내
순환 기능은 기본 설정을 방해하지 않으며, 동작 규칙은 숙지할 가치가 있습니다.
프로필을 직접 지정한 경우에는 작동하지 않습니다. 또한 직접 user-agent 또는 cookie header를 전송한 경우에도 작동하지 않습니다. 이 부분이 중요합니다. 통과 인증 cookie는 이를 획득한 클라이언트에 종속되므로, 정상 작동 중인 세션 재생 중에 서명을 바꾸면 성공하던 request가 실패하게 됩니다. 고정한 값은 그대로 유지됩니다.
모든 실패가 프로필 전환의 근거가 되는 것은 아닙니다. 확인된 보안 솔루션의 차단은 근거로 인정됩니다. 특정 솔루션이 명시되지 않은 단순 거부 상태 코드(401, 403, 429, 503)도 인정되며, 이 기준은 실제로 중요하게 작용했습니다. 한 작업에서 8번의 상태 코드 거부가 발생했으나 탐지된 보안 솔루션이 없었던 사례가 있었습니다. 탐지기만 신뢰했다면 순환 로직이 무시했을 실제 거부 사례였습니다. 존재하지 않는 페이지나 국가 차단은 근거로 계산되지 않습니다. 이는 클라이언트가 아닌 URL 및 지리적 위치에 기인한 응답이기 때문입니다.
모든 동작 과정은 직접 확인할 수 있습니다. 성공한 Proxy Finder response에는 시스템이 직접 선택한 경우에만 profile가 포함되며 사용자가 지정한 경우에는 포함되지 않습니다. 실패한 작업에는 attemptReport.profilesTried이 포함됩니다. 이는 최초 사용 순서대로 시도한 제품군 목록이며, 변경 없이 전송된 request는 default로 표기됩니다. 이 필드가 없다면 외부에서는 "4개 브라우저를 시도했으나 모두 거부됨"과 "브라우저를 전혀 변경하지 않음"을 구분할 수 없습니다.
참고할 만한 방법 하나는 프로필의 효과를 테스트할 때 다른 모든 조건을 고정하는 것입니다. Scrapfly의 2026 핑거프린트 테스트 도구 정리에서 잘 설명하듯, 실행 간에 세 가지 변수를 동시에 변경하면 무언가 작동했음을 알 수는 있어도 어떤 변경이 주효했는지는 알 수 없습니다. 동일한 대상, 동일한 출구에서 단 하나의 필드만 변경해야 합니다. 본문의 모든 수치 역시 이 방식으로 도출되었습니다.
향후 계획
후보 사다리는 단지 추측에 기반하지 않고 각 대상을 직접 측정하여 확장됩니다. 기본 설정으로 열 수 없었던 대상을 여는 것이 확인된 제품군만 추가되며, 카탈로그는 기존 데이터를 그대로 유지하지 않고 엔진 업데이트마다 재측정됩니다.
이것이 이 문제의 까다로운 본질입니다. 최적의 클라이언트 서명은 계속 변하며, 이를 추적하는 일은 한 번 배포하고 끝나는 것이 아닌 지속적인 작업입니다. 지난 분기에 성공했던 설정은 이미 누군가의 차단 목록에 올라가 있습니다. 이것이 임의의 고정값을 제공하는 대신, 사용자가 직접 설정할 수 있는 필드와 확인할 수 있는 카탈로그를 제공하는 이유입니다.