하이라이트
이제 대시보드에서 직접 본인의 API key를 사용하여 request를 작성, 전송 및 재실행할 수 있습니다. 새로운 playground는 세 가지 제품을 모두 지원하며, 실행 간에 cookie, preset, history를 유지합니다. 이와 함께 두 가지 안정성 패치가 적용되었는데, 몇 주 동안 감지되지 않고 기능이 저하되었던 unblocker: true가 다시 end-to-end로 정상 작동하며, Browser가 Cloudflare의 passive-challenge cf_clearance cookie를 안정적으로 캡처합니다.
업데이트 사항
대시보드 Playground
이제 /dashboard/#playground는 실제 작업대(workbench) 역할을 합니다. 세 가지 제품 탭(Single, Proxy Finder, Browser), URL 바, header, body 등 제품별 모든 flag가 노출되어 각 제품의 실제 schema와 매칭됩니다. request를 전송하고 JSON, HTML, 텍스트 뷰 모드로 렌더링되는 response를 확인해 보세요. Ctrl/Cmd+K를 사용하여 response 창 전체를 검색할 수 있습니다. 방대한 HTML 코드를 읽어야 할 때는 response 창을 전체 화면으로 확장할 수 있습니다.
우리가 직접 사용하고 싶은 방식으로 개발하면서 추가된 몇 가지 기능은 다음과 같습니다.
- 수신된 cookie는 호스트별 jar에 저장됩니다. 동일한 호스트로 보내는 다음 request에 자동으로 첨부되며, 전송 전에 모든 cookie를 검사, 수정 또는 삭제할 수 있습니다.
- working-proxies 레일은 성공적인 Proxy Finder 실행에서 반환된 모든 proxy id를 수집하므로, 다시 입력할 필요 없이 "use"를 클릭하여 Single 또는 Browser request에서 해당 proxy를 재사용할 수 있습니다.
- request를 preset으로 저장할 수 있습니다. history 대화 상자에서 최근 20번의 실행 기록 중 하나를 다시 실행해 보세요.
- curl reproducer는 터미널에서 동일한 request를 전송하기 위해 실행할 정확한 명령어(
x-api-key포함)를 보여줍니다.
playground는 수명이 짧은 내부 token에 서명하므로, 평문 key가 대시보드를 벗어나지 않습니다. 할당량, 메트릭 및 last_used_at은 자체 코드에서 request를 보낸 것과 동일하게 선택한 key에 반영됩니다.
unblocker: true 기능의 end-to-end 재작동
지난 몇 주 동안 unblocker: true가 설정된 Single 및 Proxy Finder request의 기능이 감지되지 않고 저하되던 빌드 문제를 발견했습니다. 우회 기능이 실제로 연결되지 않은 채 빌드가 배포되어, 핸드셰이크 수준의 안티봇 장벽을 통과해야 했던 request가 대신 일반 request 서명을 받고 있었습니다. 통과시켜 주어야 했던 사이트들이 당사 요청을 차단하고 있었습니다.
수정 사항이 배포되었습니다. 이전에는 통과하기 위해 Browser가 필요했던 3개의 Cloudflare 인터스티셜(interstitial)을 포함하여, 11개의 실제 대상을 상대로 end-to-end 검증을 완료했습니다. 이제 Single 단독으로도 이를 통과합니다. 체인으로 연결된 Proxy Finder + Browser + Single 흐름(proxy 찾기, Browser에서 cf_clearance cookie 가져오기, Single에 해당 cookie와 동일한 proxy를 추가하여 페이지 request 전송)은 단 한 번의 왕복(round trip)으로 전체 HTML을 반환합니다.
이번 오류는 저희의 과실입니다. unblocker: true는 배포 당일에는 정상 작동했으나, 정기 재빌드 과정에서 조용히 손상되었습니다. 지난 몇 주 동안 보호된 사이트를 대상으로 unblocker: true를 적용하여 request를 실행했을 때 200 대신 403 오류가 발생했다면 바로 이 때문입니다. 다시 시도해 보시기 바랍니다.
Browser의 Cloudflare passive JavaScript challenge 처리
Cloudflare에는 두 가지 challenge 모드가 있습니다. 액티브(active) 모드(HTTP 403 및 인터스티셜)는 이미 처리하고 있었습니다. 패시브(passive) 모드는 더 까다롭습니다. 페이지가 즉시 200을 반환하지만, Cloudflare가 클라이언트를 핑거프린팅하는 비동기 JavaScript probe를 주입한 후에야 cf_clearance cookie를 발급합니다. 이번 수정 전에는 probe가 완료되기 전에 Browser가 response를 완료해 버려 clearance cookie가 jar에 저장되지 않았습니다.
이제 Browser는 Set-Cookie 이벤트를 명시적으로 감지하며, body에서 passive-challenge 마커를 발견하면 cf_clearance를 대기합니다. 폴링이나 고정된 유예 기간이 없으며, Cloudflare가 아닌 사이트에 대해 불필요하게 대기하지도 않습니다. 테스트 제품군에 포함된 12개의 실제 도메인(이 중 3개는 패시브 경로 사용)에서 이제 clearance cookie가 안정적으로 반환됩니다.
API edge의 SSRF 취약점 차단
유효한 pk_live_... API key가 있다고 해서 당사의 사설 네트워크에 접근할 수 있는 것은 아닙니다. 이제 API는 호스트 이름 리터럴 또는 DNS 확인 결과가 RFC 5735, 6598 또는 IPv6 예약 블록에 해당하는 모든 대상을 거부합니다. 2차 방어선으로서 모든 백엔드 제품에서도 동일한 검사가 실행됩니다.
겉으로 보기에는 달라진 점이 없을 것입니다. 당사는 내부 네트워크 탐색 시도가 TCP 핸드셰이크를 완료하기 전에 이를 차단합니다.
블로그 개별 소셜 프리뷰 적용 및 페이지네이션 오류 수정
이제 모든 블로그 포스트는 브랜드 카드에 포스트 제목과 요약이 렌더링된 자체 Open Graph 이미지를 생성합니다. Discord, LinkedIn, Slack 또는 Twitter에 foura.ai/blog/... 링크를 붙여넣으면 일반적인 기본 이미지 대신 해당 포스트 전용 프리뷰가 표시됩니다.
블로그 인덱스의 페이지네이션이 제대로 작동하지 않고 있었습니다. "Older" 버튼을 누르면 다시 1페이지로 이동하는 문제가 있었습니다. 당사는 이를 경로 기반 URL(/blog/page/N/)로 재구축하고, 스마트 윈도우가 적용된 숫자 탐색 기능을 추가했으며, 페이지가 구분된 시리즈에 대해 적절한 rel=prev/next 링크 태그를 추가했습니다. 기존 ?page=N URL은 새로운 형식으로 301 리다이렉트되므로, 이전에 크롤링된 데이터가 손실되지 않습니다.
내부 동작
Model Context Protocol을 지원하는 모든 LLM 도구를 위해 당사의 MCP 서버가 mcp.foura.ai에서 운영 중입니다. 인증은 REST API에 사용하는 것과 동일한 pk_live_... Bearer token을 사용합니다. 이 서버는 세 가지 제품을 도구(Single, Proxy Finder, Browser) 및 몇 가지 프롬프트로 노출합니다. FourA를 Claude Code나 기타 MCP 지원 에이전트에 연결하는 경우, 더 이상 로컬 브리지를 실행할 필요가 없습니다.
이전 playground가 미흡하여 대시보드 사용을 미뤄두셨다면, 이번 주에 꼭 확인해 보시기 바랍니다. 이는 이제 API 대상을 상대로 문제가 발생했을 때 저희가 직접 사용하는 도구이기도 합니다.