Có gì mới
Xoay vòng IP đầu ra là phần ai cũng tự động hóa. Chữ ký trình duyệt bên dưới chúng thường không bao giờ thay đổi.
Single và Proxy Finder hiện nhận bốn trường tùy chọn để quyết định trình duyệt mà request của bạn hiển thị: browser, os, version, và profile. Danh mục phía sau chúng được công khai tại GET /api/profiles và không cần API key. Hiện tại danh mục chứa 79 profile trên Chrome, Edge, Safari, Firefox và Tor, trên Windows, macOS, Android và iOS.
Khi bạn không chỉ định profile cụ thể, Proxy Finder sẽ tự động đổi profile cho bạn. Nhưng chỉ sau khi một trang web đã từ chối profile bạn gửi hai lần.
Cách thức hoạt động
Ba trong số các trường dành cho người dùng và một trường dành cho máy.
browser, os và version giúp thu hẹp danh mục, và bạn có thể gửi bất kỳ tập hợp con nào trong số chúng. os khớp theo họ hệ điều hành, vì vậy yêu cầu macOS sẽ chấp nhận mọi bản phát hành macOS trong danh sách, trong khi yêu cầu nhãn bản phát hành chính xác sẽ thu hẹp về bản đó. Khi nhiều profile vẫn phù hợp, phiên bản mới nhất sẽ được chọn, vì việc duy trì tính cập nhật là mục tiêu cốt lõi. Các phiên bản chính cũ là yếu tố mà danh sách chặn nhắm vào.
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"
}'
Cấu hình này phân giải thành Safari mới nhất trên iOS trong danh mục, đồng thời gửi User-Agent, client hints và thứ tự header đi kèm theo đúng trình tự đó. Thứ tự header bản thân nó là một tín hiệu nhận diện, vì vậy không có gì bị sắp xếp lại trên đường truyền đi.
profile là trường thứ tư: một id chính xác từ danh mục, dành cho mã nguồn cần duy trì việc gửi cùng một client sau khi có phiên bản mới hơn ra mắt. Proxy Finder nhận cả bốn trường này bên trong đối tượng request của nó. Danh sách tham số đầy đủ có trong tài liệu tham khảo API, và Playground đọc cùng một danh mục đó, nên các menu thả xuống chỉ cung cấp những gì mã nguồn của bạn có thể yêu cầu. Bốn trường tương tự cũng nằm bên trong foura_single và foura_proxy trên máy chủ MCP, cho phép agent thử lại dưới dạng một trình duyệt khác thay vì chỉ trả về mã lỗi 403 đơn thuần.
Có hai điều hệ thống chủ động từ chối thực hiện.
Một tổ hợp mà danh mục không thể cung cấp sẽ trả về một lỗi nêu rõ những gì hiện có cho trình duyệt đó. Việc tự động chuyển về cấu hình mặc định sẽ gửi đi một client mà bạn không chọn và không thể thấy trong response. Lựa chọn cấu hình với unblocker: false cũng bị từ chối, vì cờ đó là thứ mang các header (cờ đó thực sự làm gì). Một nửa cấu hình còn tệ hơn là không có gì.
Bản thân danh mục được đo lường thực tế chứ không phải do nhập tay. Một script sẽ kích hoạt từng cấu hình qua luồng request thực tế và ghi lại những gì thực sự được gửi trên đường truyền. Điều này quan trọng hơn vẻ ngoài của nó: giữa hai phiên bản chính gần đây của một trình duyệt, chuỗi thương hiệu giữ chỗ đã thay đổi và thứ tự thương hiệu bị đảo ngược, và đó chính xác là loại chi tiết mà một dịch vụ phát hiện bot sẽ phân tích.
Tác động
Đây là phần chúng tôi không ngờ tới.
Một giá trị mặc định là giá trị mặc định dùng chung. Client mà request của bạn hiển thị khi bạn không yêu cầu gì chính là client mà mọi request không yêu cầu gì khác đều hiển thị, và một hệ thống phòng thủ muốn dựa vào một tiêu chí đơn giản sẽ nhắm chính xác vào điều đó. Lỗi xảy ra theo cách không giống bất kỳ điều gì khác: một trang web từ chối một trình duyệt sẽ từ chối nó ở mọi điểm exit mà bạn sở hữu. Bạn tiêu hết toàn bộ hạn mức thử lại chỉ để chứng minh rằng cùng một client đó không được chào đón.
Chúng tôi đã đo lường ba lần trên ba nhà cung cấp khác nhau, và kết quả đều có cùng một quy luật.
Một cổng thông tin bất động sản phía sau PerimeterX đã từ chối chín lần thử với cấu hình mặc định. Chỉ cần thay đổi nền tảng mà request khai báo (mọi thứ khác giữ nguyên, cùng một pool) đã trả về trang web sáu trên sáu lần. Một nhà bán lẻ thực phẩm bổ sung phía sau Akamai đã từ chối cấu hình mặc định nhưng phân phối nội dung bình thường cho hai dòng trình duyệt khác. Một trang tin tài chính phía sau DataDome đã phản hồi cấu hình mặc định bằng mã 401 và một trang trung gian 774 byte, trong khi ba cấu hình khác đã tải trang thực tế, dung lượng khoảng 760 KB, mười hai lần mỗi cấu hình. Chúng tôi đã chạy thử nghiệm đó theo cả chiều xuôi và ngược để đảm bảo thứ tự thực hiện không ảnh hưởng đến kết quả.
Vì vậy, Proxy Finder hiện tự động luân chuyển browser family, không chỉ riêng exit. Cần có hai exit độc lập từ chối trước khi nó chuyển đổi, bởi vì một lần từ chối chỉ là ý kiến của một exit. Sau đó, nó tiến dần qua từng bậc thang bắt đầu từ thay đổi nhỏ nhất có thể, là platform, rồi mới thử nghiệm các family khác.
Tính năng này không tốn thêm chi phí. Quá trình luân chuyển thay đổi nội dung gửi đi khi retry, chứ không thay đổi việc có retry hay không, do đó số lượng request và credit cho mỗi task vẫn giữ nguyên chính xác như trước.
Dành cho Power User
Cơ chế luân chuyển hoạt động ngầm và không gây cản trở, nhưng bạn nên nắm rõ các quy tắc sau.
Nó không bao giờ kích hoạt khi bạn tự chỉ định một profile. Nó cũng không kích hoạt khi bạn tự gửi header user-agent hoặc cookie, và đây là điểm quan trọng: một clearance cookie được liên kết trực tiếp với client đã tạo ra nó, vì vậy việc thay đổi signature bên dưới một session replay đang hoạt động sẽ làm hỏng một request vốn đang thành công. Khi bạn ghim giá trị mong muốn, nó sẽ được giữ nguyên.
Không phải mọi lỗi đều được tính là bằng chứng để chuyển đổi profile. Một nhà cung cấp giải pháp phòng thủ (defense vendor) được nhận diện sẽ được tính. Một status code từ chối thuần túy (401, 403, 429, 503) không kèm tên vendor cũng được tính, và trường hợp này thực tế rất quan trọng. Một task trả về tám lần từ chối status code mà không nhận diện được vendor nào: đó là những lần từ chối thực sự mà cơ chế luân chuyển từng bỏ qua, vì trước đây nó chỉ tin vào bộ detector. Trang không tồn tại (404) hoặc chặn theo quốc gia sẽ không được tính. Đó là kết quả liên quan đến URL và vị trí địa lý của bạn, không phải do client.
Bạn có thể quan sát toàn bộ quá trình. Một response Proxy Finder thành công chỉ chứa profile khi do hệ thống tự chọn, không bao giờ xuất hiện khi bạn tự cấu hình. Một task thất bại sẽ chứa attemptReport.profilesTried: danh sách các family đã gửi theo thứ tự sử dụng đầu tiên, với default cho request không bị chỉnh sửa. Nếu không có trường đó, thông điệp "chúng tôi đã thử bốn browser và tất cả đều bị từ chối" và "chúng tôi chưa từng đổi browser" nhìn từ bên ngoài sẽ hoàn toàn giống nhau.
Một thói quen rất nên áp dụng: khi bạn kiểm tra xem một profile có hiệu quả hay không, hãy giữ nguyên mọi yếu tố khác. Bản tổng hợp năm 2026 về các công cụ kiểm tra fingerprint của Scrapfly đã nêu rất rõ, việc thay đổi ba biến số giữa các lần chạy có thể cho bạn biết có gì đó hiệu quả nhưng không rõ thay đổi nào tạo ra sự khác biệt. Cùng mục tiêu, cùng exit, chỉ thay đổi một trường duy nhất. Đó cũng là cách mọi số liệu ở trên được tạo ra.
Kế hoạch tiếp theo
Danh sách ứng viên chỉ mở rộng dựa trên đo lường thực tế, từng mục tiêu một. Một family chỉ được thêm vào sau khi chúng tôi xác nhận nó mở được một target mà cấu hình mặc định không làm được, chứ không phải dựa trên phỏng đoán, và toàn bộ danh mục sẽ được đo lường lại sau mỗi lần nâng cấp engine thay vì giữ nguyên số liệu cũ.
Đó là bản chất phức tạp của bài toán này. Client signature tối ưu luôn thay đổi liên tục, việc theo dõi nó là công việc liên tục chứ không phải giải pháp làm một lần là xong, và bất kỳ phương án nào hiệu quả ở quý trước thì nay đã nằm trong danh sách chặn của ai đó. Đó là lý do tại sao đây là một trường bạn có thể cấu hình và là một danh mục bạn có thể tra cứu, thay vì một con số cố định do chúng tôi chọn sẵn cho bạn.