ScalebrowserDOCS

Test your setup

Four ways to measure what a page really sees: the account-free check pages, the built-in detector audit against a running profile, the proxy check, and the metrics endpoint.

Everything on this site is a claim until you measure it. Four instruments, from cheapest to most thorough.

The check pages

Two public pages, no account and no key on either.

scalebrowser.net/check measures the browser you open it with, across five layers from the TCP handshake to what JavaScript can read. It does not only report what it measured; it reports how rare each reading is, which is the question that actually matters. A value nobody else has is worse than an unusual one many people share.

scalebrowser.net/ai-agent-check measures the tool, not the browser. Whether a click arrived with a real pointer path, whether a keystroke carried pressure, whether the page was reached the way a person reaches it. Most automation passes the first page and fails this one.

Open either one from inside a profile to see what a real site sees.

The cheapest control you have is the same engine with no persona. Launch it without a profile configuration and it answers what your host really is, in one launch. Every judgement about a fingerprint is a difference between two readings, and without a control there is no difference to read.

The built-in audit

Drive a running profile through the external detector pages from the daemon itself, and keep the verdict against the launch it was measured on:

bash
$ curl -X POST http://127.0.0.1:8787/v1/profiles/pr_9c21e4/audit \
    -H "Authorization: Bearer $SCALEBROWSER_BEARER_TOKEN"
$ curl http://127.0.0.1:8787/v1/profiles/pr_9c21e4/audit \
    -H "Authorization: Bearer $SCALEBROWSER_BEARER_TOKEN"

Fifteen detector pages are driven: eight readings from BrowserLeaks (canvas, WebGL, fonts, WebRTC, TLS, client hints, client rects, WebGPU), plus CreepJS, iphey, BrowserScan, Pixelscan, FingerprintJS, Sannysoft and AmIUnique.

It is two calls rather than one because it is minutes of real network traffic. POST starts the run and answers immediately; GET reports idle, running or finished plus the last report.

The report lands on the profile's newest launch log, so it can never outlive the browser it describes. That is the point: a fingerprint verdict from a previous launch is a verdict about a browser that no longer exists.

The proxy check

The single most important measurement, because the exit is judged before any JavaScript runs:

bash
$ curl -X POST http://127.0.0.1:8787/v1/proxies/px_7f3a/check \
    -H "Authorization: Bearer $SCALEBROWSER_BEARER_TOKEN"

Reachability, exit address, exit country and the fingerprint verdict. POST /v1/proxies/check runs the same thing on an unsaved configuration, so you can test before you store anything. See Proxies & exits.

The metrics endpoint

GET /v1/metrics answers with the resource picture: how many browsers are running, the configured capacity and budgets, host memory, CPU and GPU figures, and a per-profile breakdown.

Each measured value is paired with a probe state of measured, unsupported or unavailable, so "zero" and "we could not read this" never look alike. See Monitoring & metrics.

How to read a result

Three rules, each of which has cost somebody a wrong conclusion.

Measure differentially. A single reading tells you almost nothing. Run the same page in the same engine with no persona, and compare. What you are looking for is the pair that cannot both be true.

A green detector is not a green site. These pages are built to be measured. A real target combines their signals with an address reputation, a rate history and an account graph, and it weights the address far above anything the browser says.

An unreachable page is not a failure. curl cannot tell a wrong address from a bot wall; both answer 403. If a check page will not load, drive a profile at it rather than concluding anything from the transport.

Next