전체신규개선해결
해결

Auto no longer accepts challenge pages as success

If you passed a negative validate to /api/auto (like {data: {fail: ['"Due to legal reasons"']}}), a Cloudflare 'Just a moment' interstitial could slip through as a cached success because the fail-list didn't happen to match its text. Auto now rejects challenge pages before applying your validate rules, and it swaps the bad exit and re-solves instead of scoring it.

해결

Long foura_auto calls now complete through the hosted MCP

If you set a long timeout on foura_auto through the hosted MCP server, the request could time out at the edge before your call finished. That's fixed. Full-budget auto calls now run their 180-second budget end to end.

해결

Auto spreads concurrent load across multiple exits

If you've been hitting 429s when firing many concurrent Auto calls at one target, those calls used to funnel onto a single cached exit because the warm path picked the score-favourite and replayed once. Auto now opens additional sessions on demand and routes each call to the least-loaded exit, so a burst fans out across multiple proxy IDs instead of hammering one. Measured locally: a 100-call burst on a no-cookie portable host now spreads across the grown pool within seconds.

해결

Clean Cloudflare pages skip the browser solve

Cloudflare injects a passive script even on pages that pass cleanly, and Auto used to treat any reference to it as an active challenge and run a full browser solve anyway. Now only true interstitial markers (the 'just a moment' page and friends) trigger the browser path; a clean 200 comes back from the cheaper proxy rung. Auto also follows up to 5 redirects by default (configurable via followRedirects).

해결

Browser captures the real status after Cloudflare clears

When a Cloudflare-protected target served a real geo-block page (451) after the challenge passed, the Browser product was reporting it as a 200 because the watcher hardcoded the cleared status. The watcher now reads the actual post-clearance Document, so a 200 stays 200, a 451 surfaces as 451, and Auto rejects the wrong content and keeps searching for an exit that genuinely matches your validate rules.

해결

Cmd+K opens on non-Latin keyboards

The Cmd+K (Ctrl+K) shortcut now opens the command palette and search modal regardless of keyboard layout. We were matching the typed character (к on a Cyrillic layout), so anyone on a non-Latin layout got nothing. Now we match the physical key. Fixed across the main site, the blog, and the docs.

해결

Auto requests stop 504-ing on cold solves

A cold Auto solve can run several minutes (proxy grind plus a browser solve). Our HTTP edge was capping requests at 2 minutes and returning a plain HTML 504, so the longest solves looked like a gateway failure even when the orchestrator was still working. We extended the edge timeout past Auto's worst-case run and switched /api/ error pages to JSON, so any error from any layer reads as JSON your client can parse.

해결

Auto amortizes to 2 credits on repeat requests

Cookie-reusable sites (bet365 was the canary) were sticking on the expensive browser solve at 15 credits per request instead of dropping to the cheap 2-credit replay after the first solve. Two bugs: the latch fired on any transient transport error, and a successful browser replay never refreshed the session cookies. Fixed both. Repeat requests on a cookie-reusable site now cost 2 credits after the first solve, exactly as the pricing implies.

해결

API의 cross-origin 액세스 제한

foura.ai만 credentials를 사용하여 API를 호출할 수 있도록 cross-origin 액세스를 강화했습니다. 또한 metrics endpoint의 입력 필터를 강화하고 개발 전용 fallback secret을 제거했습니다. 기존 integration은 변경되지 않습니다.

해결

커스텀 validate 규칙이 성공으로 집계됩니다

requestvalidate.status.accept를 설정한 경우, 엔진은 허용된 non-200 응답을 정상적인 성공으로 처리합니다. 하지만 Activity에서는 여전히 이를 실패로 분류하여 사용량 통계에 혼선이 있었습니다. 이제 처리 결과가 사용자의 validate 판정을 따르므로, 허용된 403App Fail이 아닌 성공으로 표시됩니다.

해결

Non-UTF-8 페이지가 이제 정상적으로 디코딩됩니다

Single을 통해 키릴 문자, 중국어, 일본어 또는 기타 non-UTF-8 페이지를 스크래핑할 때 body가 깨진 글자로 반환되곤 했습니다. 이전에는 사용자가 raw bytes를 확인하기 전에 모든 response를 UTF-8로 강제 디코딩했습니다. 이제는 response에서 charset을 읽어와(Content-Type, 그 다음 <meta charset>, 마지막으로 UTF-8 fallback 적용) 올바르게 디코딩합니다. 이 문제를 제보해 주신 Alexandar Kanchev (Sensika) 님께 감사드립니다.

해결

request를 그대로 에코하는 가짜 proxies 감지

실제 환경의 일부 proxies는 실제로 request를 전달하지 않습니다. 이들은 request를 plaintext server dump 형태로 에코하여 내부 데이터를 탈취하려고 시도합니다. 이제 response가 코드에 도달하기 전에 이 패턴을 감지하므로, Single, Browser, Proxy Finder는 가비지 데이터 대신 명확한 실패(또는 retry)를 반환합니다.

해결

새로 발견된 proxy가 pool에 더 빠르게 진입합니다

새로 발견된 proxy가 검증을 받기 전에 대기해야 했던 지연 문제를 해결했습니다. 이제 Proxy Finder가 이를 즉시 확인하므로, 더 많은 활성 상태의 작동 중인 proxy가 순환에 투입되어 pool이 더 최신 상태로 유지됩니다.

해결

Playground 쿠키, RFC 6265 host-only 규칙 준수

Host-only 쿠키가 서브도메인으로 유출되고 있었습니다. 이제 Domain 속성을 올바르게 추적하며, (흔치 않은) host-only 케이스를 위해 Parsed 뷰에 HO 배지를 추가했습니다. Raw 뷰는 업스트림이 전송한 내용과 일치합니다: 도메인 쿠키의 경우 Domain=.example.com, host-only의 경우 Domain= 라인이 없습니다.

해결

플레이그라운드 폼 필드가 실제 API 스키마와 일치합니다

Browser endpoint는 8개의 입력(url, userAgent, headers, cookies, proxy, timeout_ms, checkStatus, checkText)만 허용합니다. 기존 플레이그라운드에서는 wait_selector 및 viewport와 같은 추가 필드가 표시되었으나, 이들은 전송 과정에서 아무런 경고 없이 무시되었습니다. 이제 모든 필드가 스키마와 일치합니다. Browser는 GET 방식을 강제하고 body textarea를 숨기며, Raw 탭에는 API에 전송되는 정확한 JSON과 curl 재현 코드가 표시됩니다.