Skip to content

Stealth Proxies Cannot Buy a Captcha That Measures the Browser

Adityo Guni Waluyo

Stealth proxies beat WAF walls and die at browser-measuring captcha gates.

TL;DR

Stealth proxies hit captcha walls, not WAFs: Jakarta Selatan hid Cloudflare Turnstile, Jakarta Pusat ran reCAPTCHA v2. Real browsers cleared both—Chromium passed Turnstile untouched; a Firefox anti-detect profile solved reCAPTCHA with Tab plus Space, no solver service. Detail pages need live sessions, so the build now tiers access: proxies for WAFs, browsers for captchas, supervised runs for Jakarta Pusat.

I pointed a stealth proxy at a court portal for the DemandScope project. The response came back HTTP 200, but the body was a captcha page waiting for a human to tick a box. The tool that was supposed to slip past identity walls stopped dead at a gate that cannot be bought with clean IPs. My first guess: a plain Web Application Firewall (WAF) block, the kind a User-Agent or IP rotation would shake. That sort of layer only reads your identity from the outside. Follow-up probes through real interactive browsers flipped the verdict. Jakarta Selatan, which phase 0 had labeled WAF 403, turned out to sit behind Cloudflare Turnstile[3]. In Chromium with a real profile fingerprint the challenge cleared itself, without a single click. 1,209,232 cases opened up across 60,462 pages. Jakarta Pusat leaned on reCAPTCHA v2[1]. Bare fetches only ever saw a 769-byte shell. In a real-Firefox anti-detect browser, focusing the widget with Tab followed by Space produced an answer token instantly[4]. No solver service, no captcha farm. The clearance cookie stayed in the profile. This makes sense because these captcha gates measure the browser, not the network. Cloudflare actively evaluates client-side signals gathered from the visitor's browser environment, and most visitors pass automatically without any puzzle[7]. reCAPTCHA v2 was designed to make sure a human completed the challenge, through single-use tokens that expire in two minutes[2].

Sessions Bind the Data

Passing the front gate is only step one. Case detail pages turned out to be bound to the PHP session[6]. Requests to show_detil/<token> bounce or 404 without an active session. Inside a live session the page renders fully: case header plus five tabs of information. The live sample I harvested was registered 05 October 2026: a listed-company petitioner against its respondent, first hearing scheduled. Exactly the signal the product wants, from the court phase 0 had called unscrapeable. The list holds 1,277,296 cases across 63,865 pages, 20 detail links per page.

The Updated Access Ladder

These findings reshaped the collection architecture. Stealth proxies still earn their keep against User-Agent and IP walls; they do nothing at captcha gates. Access now splits into three tiers:
  1. A real-Chromium pane clears Cloudflare challenges with no interaction at all.
  2. A real-Firefox anti-detect browser: one keyboard focus and Space solves reCAPTCHA, and the clearance cookie persists in the profile, exactly how RFC 6265 describes cookies carrying session state[5].
  3. Stealth proxies for plain WAF walls, never for captcha gates.

What Changed in the Build

Courts behind strict gates are off the daily robot cron. Jakarta Pusat becomes a phase-two source through periodic supervised interactive sessions. Detail parsing needs a session-aware client, flagged session_required in the court config. Jakarta Selatan stays a general-civil source now that it clears itself. Sometimes the most advanced tool fails at the plainest door. Forcing full automation against an environment built to detect automation is a dead end. Respecting session boundaries and keeping interactions measured beats trying to fool the system with a see-through proxy.

Sources

  1. Google reCAPTCHA v2 docs
  2. Google reCAPTCHA siteverify docs
  3. Cloudflare Turnstile docs
  4. Playwright docs
  5. RFC 6265
  6. PHP manual: Sessions
  7. Cloudflare Challenges docs

Related articles