Điểm nổi bật
Hiện bạn có thể tạo, gửi và phát lại các request bằng API key của chính mình ngay trên dashboard. Playground mới hỗ trợ cả ba sản phẩm, đồng thời lưu giữ cookie, preset và lịch sử qua các lần chạy. Hai bản sửa lỗi độ tin cậy cũng được phát hành kèm theo: unblocker: true bị suy giảm hiệu năng âm thầm trong vài tuần (hiện đã hoạt động trở lại, end-to-end), và Browser hiện thu thập cookie cf_clearance từ passive challenge của Cloudflare một cách ổn định.
Có gì mới
Dashboard Playground
/dashboard/#playground hiện là một không gian làm việc thực thụ. Ba tab sản phẩm (Single, Proxy Finder, Browser), thanh URL, header, body, cùng toàn bộ cờ tùy chọn riêng cho từng sản phẩm đều được hiển thị và khớp chính xác với schema thực tế của từng sản phẩm. Gửi request, theo dõi response hiển thị với các chế độ xem JSON, HTML và văn bản thô. Tìm kiếm trên các khung response bằng Ctrl/Cmd+K. Mở rộng response ra toàn màn hình khi bạn cần đọc một khối HTML lớn.
Một vài điểm nổi bật có được từ việc xây dựng công cụ theo đúng cách chúng tôi muốn sử dụng:
- Cookie nhận được sẽ được lưu vào jar riêng cho từng host. Request tiếp theo tới cùng host đó sẽ tự động đính kèm chúng, bạn có thể kiểm tra, chỉnh sửa hoặc xóa bất kỳ cookie nào trước khi gửi.
- Thanh danh sách proxy hoạt động sẽ thu thập mọi proxy id trả về từ lượt chạy Proxy Finder thành công, cho phép bạn nhấn "sử dụng" để tái sử dụng proxy đó trong request Single hoặc Browser mà không cần nhập lại.
- Lưu request dưới dạng preset. Phát lại bất kỳ request nào trong số 20 lần chạy gần nhất từ hộp thoại lịch sử.
- Trình tạo lệnh cURL hiển thị chính xác câu lệnh (kèm
x-api-key) bạn có thể chạy từ terminal để gửi cùng một request.
Playground ký một token nội bộ ngắn hạn, vì vậy key dạng plaintext không bao giờ rời khỏi dashboard. Hạn ngạch, chỉ số và last_used_at được tính vào key bạn đã chọn, tương tự như khi bạn gửi request từ mã nguồn của chính mình.
unblocker: true hoạt động trở lại, end-to-end
Chúng tôi đã phát hiện một sự cố bản build khiến các request Single và Proxy Finder sử dụng unblocker: true bị hạ cấp âm thầm trong vài tuần qua. Bản build được phát hành mà không thực sự liên kết browser profile, do đó các request đáng lẽ mang chữ ký trình duyệt lại nhận chữ ký request thông thường. Các trang web đáng lẽ cho phép truy cập đã chặn chúng tôi.
Bản vá đã được triển khai. Chúng tôi đã xác minh end-to-end trên mười một mục tiêu thực tế, bao gồm ba trang đằng sau các trang kiểm tra trước đây cần đến Browser. Single hiện tự vượt qua được. Luồng kết hợp Proxy Finder + Browser + Single (tìm proxy, lấy cookie cf_clearance từ Browser, gửi request trang bằng Single kèm cookie và chính proxy đó) trả về đầy đủ HTML chỉ trong một lượt khứ hồi.
Đây là sơ suất của chúng tôi. unblocker: true hoạt động bình thường vào ngày phát hành, nhưng đã bị hỏng âm thầm trong một lần rebuild định kỳ. Nếu bạn đã gửi request với unblocker: true tới một trang được bảo vệ trong vài tuần qua và nhận mã 403 thay vì 200, thì đó chính là nguyên nhân. Hãy thử lại.
Browser xử lý passive JavaScript challenge của Cloudflare
Cloudflare có hai chế độ challenge. Chế độ chủ động (HTTP 403 kèm trang trung gian) đã được chúng tôi xử lý từ trước. Chế độ thụ động khó nhận biết hơn: trang trả về mã 200 ngay lập tức, nhưng Cloudflare chèn một đoạn probe JavaScript bất đồng bộ để thu thập fingerprint của client và chỉ sau đó mới cấp cookie cf_clearance. Trước bản sửa lỗi này, Browser đã hoàn tất response trước khi probe kịp chạy xong, dẫn đến việc clearance cookie không bao giờ được lưu vào jar.
Browser hiện lắng nghe sự kiện Set-Cookie một cách rõ ràng và đợi cf_clearance nếu phát hiện dấu hiệu passive-challenge trong body. Không dùng cơ chế polling, không có khoảng thời gian ân hạn cố định, không phải chờ thêm đối với các trang không dùng Cloudflare. Mười hai domain thực tế trong bộ test suite, trong đó có ba domain dùng đường dẫn thụ động, hiện đã trả về clearance cookie ổn định.
Vá lỗ hổng SSRF tại tầng API edge
Một API key pk_live_... hợp lệ không đồng nghĩa với việc được phép truy cập vào mạng nội bộ của chúng tôi. API hiện từ chối mọi target có hostname dạng chuỗi hoặc kết quả phân giải DNS rơi vào dải mạng dành riêng theo RFC 5735, 6598 hoặc IPv6. Quy trình kiểm tra tương tự cũng chạy trên từng sản phẩm backend như một lớp phòng thủ thứ hai.
Bạn sẽ không nhận thấy thay đổi nào ở bề ngoài. Chúng tôi chặn đứng một nhóm probe dò quét mạng nội bộ trước khi chúng kịp hoàn tất bắt tay TCP.
Blog có bản xem trước mạng xã hội riêng, sửa lỗi phân trang
Mỗi bài viết blog hiện tự động tạo hình ảnh Open Graph riêng với tiêu đề bài viết và đoạn trích được hiển thị trên thẻ thương hiệu. Khi dán link foura.ai/blog/... vào Discord, LinkedIn, Slack hoặc Twitter, bạn sẽ thấy bản xem trước riêng của bài viết thay vì hình mặc định chung chung.
Tính năng phân trang trên trang danh mục blog từng gặp lỗi ngầm. Nút "Older" chuyển hướng người dùng quay lại trang 1. Chúng tôi đã xây dựng lại hệ thống dựa trên URL theo đường dẫn (/blog/page/N/), bổ sung điều hướng đánh số kèm cửa sổ hiển thị thông minh, đồng thời thêm các thẻ liên kết rel=prev/next chuẩn cho chuỗi phân trang. Các URL cũ dạng ?page=N sẽ trả về 301 chuyển hướng sang định dạng mới, đảm bảo dữ liệu đã được thu thập trước đó không bị mất.
Bên dưới hệ thống
Máy chủ MCP của chúng tôi hiện hoạt động tại mcp.foura.ai dành cho bất kỳ công cụ LLM nào hỗ trợ Model Context Protocol. Quá trình xác thực sử dụng cùng Bearer token pk_live_... mà bạn dùng với REST API. Hệ thống cung cấp ba sản phẩm dưới dạng công cụ (Single, Proxy Finder, Browser) cùng một số prompt. Nếu bạn đang tích hợp FourA vào Claude Code hoặc bất kỳ agent nào hỗ trợ MCP, bạn không cần phải chạy bridge cục bộ nữa.
Nếu trước đây bạn chưa dùng dashboard vì playground cũ còn đơn sơ, hãy thử mở lại trong tuần này. Đây chính là giao diện chúng tôi hiện tự dùng khi cần kiểm tra những điểm bất thường trên một API target.