How to Bypass GeeTest CAPTCHA: Avoidance Over Solvers

In this article, bypass means one thing: not triggering the challenge. It does not mean solving the slider, and it does not mean getting past something you were not allowed through.

Circumventing an access control can breach a site's terms of service, and in some jurisdictions it can engage computer-misuse law, including the Computer Fraud and Abuse Act in the United States and the Computer Misuse Act 1990 in the United Kingdom. The US position narrowed in Van Buren v. United States (2021) and again in the Ninth Circuit's hiQ Labs v. LinkedIn decision (April 2022), but neither made access controls irrelevant, and terms of service still bind you contractually whatever the criminal analysis says. This guide is written for people collecting data they are permitted to access. It is not legal advice, and a commercial project deserves counsel.

Three things are deliberately absent below: a solver for the slide or icon-selection puzzle, any token harvesting or replay technique, and any recommendation of a human-farm solving service. The reason is engineering, not squeamishness. Those are the parts that break. GeeTest changes challenge types, payload encoding, and scoring weights on a schedule you do not control, so every solver in circulation is a maintenance liability with a countdown attached. The signal-hygiene work below does not expire, because it makes your traffic genuinely ordinary rather than convincingly fake.

GeeTest (Chinese name 极验) is a bot-management vendor founded in 2012 and headquartered in Wuhan. Its flagship product is a behaviour-verification CAPTCHA, sold alongside device fingerprinting and bot-detection services. You meet it constantly on Chinese-market properties, including e-commerce, travel and ticketing, telecom self-service portals, and financial services, and increasingly on global sites that picked it over reCAPTCHA or hCaptcha.

The design difference matters more than the branding. reCAPTCHA v2 puts a checkbox in front of you as the default path. GeeTest treats the interactive puzzle as the fallback path. It scores the session first, and a session that scores well can pass with no interaction at all. That is why two engineers scraping the same site report completely different experiences: one sees a slider on every request and the other has never seen one.

Those field names are worth knowing for exactly one reason: so you can tell from the network tab which version you are facing and stop guessing. The verification itself is server-side, on the site's backend, against GeeTest's API. A response that looks accepted in your browser proves nothing about what the origin will do with it, which is the structural reason token replay is a dead end rather than a clever shortcut. GeeTest publishes the integration flow in its official developer documentation, and reading the server-side verification page is more instructive than any bypass write-up.

A challenge is an output, not an event. Something in your session pushed a risk score past a threshold, and the widget is the receipt. These are the inputs, roughly in order of how much score they move per unit of effort to fix.

The single most useful thing to internalise is the ordering of events. The score is assembled from the first bytes of the connection onward, and the widget renders only after the decision has effectively been made. By the time you see a slider, the network layer, the TLS layer, the fingerprint layer and your request history have already been read. That is why "the mouse movement wasn't human enough" is almost never the real diagnosis. The mouse is the last row of the table, and the first six rows decided the outcome before the mouse existed.

It also means the widget is a lagging indicator. If you only instrument challenges, you are measuring the alarm rather than the fire. The next section fixes that.

Start by distinguishing three states that most scrapers collapse into one. GeeTest's script being present on a page is not the same as being challenged, and being challenged is not the same as being blocked.

import re

GEETEST_HOSTS = ("geetest.com", "geevisit.com", "gcaptcha4", "gt4.js")

def geetest_state(html: str, status_code: int) -> str:
    """Classify a response into one of four states. Read-only, no interaction."""
    script_present = any(h in html for h in GEETEST_HOSTS)
    v4 = "captchaId" in html or "gt4.js" in html
    v3 = bool(re.search(r"\bgt\s*[:=]\s*['\"][0-9a-f]{32}", html))
    challenged = script_present and (
        "geetest_widget" in html
        or "geetest_holder" in html
        or "geetest_box" in html
    )

    if status_code in (403, 429):
        return "blocked"
    if challenged:
        return "challenged_v4" if v4 else ("challenged_v3" if v3 else "challenged")
    if script_present:
        return "passed_with_widget_loaded"   # GeeTest scored you and let you through
    return "clean"                            # no GeeTest on this path at all

passed_with_widget_loaded is the state worth celebrating. It means the site runs GeeTest, it evaluated your session, and it decided not to interrupt you. That is what a successful bypass looks like in production, and it looks like nothing happening.

Now turn it into a number you can defend in a review. Challenge rate is the share of sessions that got interrupted, and it should be tagged by segment so you can attribute a regression to a cause rather than to bad luck.

from collections import defaultdict

class ChallengeMeter:
    """Rolling challenge-rate SLI, sliced by whatever segment you care about."""

    def __init__(self):
        self.total = defaultdict(int)
        self.challenged = defaultdict(int)

    def record(self, segment: str, state: str) -> None:
        self.total[segment] += 1
        if state.startswith("challenged") or state == "blocked":
            self.challenged[segment] += 1

    def rate(self, segment: str) -> float:
        n = self.total[segment]
        return 0.0 if n == 0 else self.challenged[segment] / n

    def worst(self, min_samples: int = 30):
        """The segment to fix first: highest rate with enough samples to trust."""
        eligible = [s for s in self.total if self.total[s] >= min_samples]
        return max(eligible, key=self.rate, default=None)

Segment on the things you can change: exit country, proxy pool, browser profile version, concurrency level, time of day. A single global number tells you that something is wrong. A segmented number tells you which change caused it, which is the difference between a fix and a week of guessing.

Measuring this costs a counter and a dictionary. Not measuring it is why teams spend a month tuning mouse curves when their exit ASN was the whole problem.

Before you engineer around a CAPTCHA, work down this list. Each row is cheaper to run and far more stable than the row below it, and the last two are where most people start.

The negotiated route fails for a boring reason: people send a vague email. Send a specific one. Name the user agent string your crawler will send, the source IP range, the paths you want, requests per minute, the purpose, how long you retain the data, and a contact address that a human monitors. A message with those six facts gets answered. "Can I scrape your site?" does not.

While you are there, read the site's robots.txt yourself and honour it for your own user agent. The Robots Exclusion Protocol was standardised as RFC 9309 in September 2022, which means Disallow and Crawl-delay are a published interface rather than folklore. Our guide to ethical scraping and rate limiting covers turning those directives into concurrency settings you can defend in writing.

Exit selection moves the score more than anything else you can change in an afternoon. GeeTest sees the connection before it sees your headers, and a hosting-provider ASN is a strong prior all on its own. Almost nobody books a flight or checks a telecom bill from an OVH range, so a session that starts there begins in a hole your fingerprint work then has to climb out of.

Three properties matter, and only the first usually gets attention:

• ASN class. Consumer ISP and mobile carrier ranges carry ordinary reputation. Hosting ranges carry hosting reputation, which is worse before you have done anything at all.
• Subnet neighbours. A clean IP inside a /24 that other crawlers are hammering inherits the neighbourhood. This is the failure mode behind "I rotated and it got worse", and it is covered in depth in how to avoid getting your proxy blocked.
• Geography relative to the audience. GeeTest's heaviest deployments serve mainland-China audiences. A German exit hitting a domestic Chinese ticketing flow is anomalous no matter how clean the IP is, and a Chinese exit hitting a US-only retail site is equally odd in reverse.

Geography brings a trap that costs more sessions than bad IPs do, because it stays invisible until you check for it. The exit country has to agree with everything else the browser announces.

COUNTRY_PROFILE = {
    "cn": ("Asia/Shanghai",    "zh-CN,zh;q=0.9,en;q=0.8"),
    "hk": ("Asia/Hong_Kong",   "zh-HK,zh;q=0.9,en;q=0.8"),
    "us": ("America/New_York", "en-US,en;q=0.9"),
    "de": ("Europe/Berlin",    "de-DE,de;q=0.9,en;q=0.8"),
}

def assert_coherent(country: str, timezone: str, accept_language: str) -> None:
    """Fail loudly at startup instead of quietly at a 30% challenge rate."""
    want_tz, want_lang = COUNTRY_PROFILE[country.lower()]
    if timezone != want_tz:
        raise ValueError(f"exit {country} but timezone {timezone}, expected {want_tz}")
    if not accept_language.startswith(want_lang.split(",")[0]):
        raise ValueError(f"exit {country} but Accept-Language {accept_language}")

Run that assertion when the worker boots. A UTC clock behind a Shanghai exit is not a small inconsistency, it is a contradiction, and contradictions are precisely what a behaviour-verification product exists to find.

GeeTest does not score any individual value as good or bad. It scores whether your layers agree with each other. An honest Python client that announces itself as Python is less interesting than a client claiming to be Chrome 131 over a TLS handshake no Chrome build has ever produced. The lie is the signal.

Python's requests rides on urllib3, whose Client Hello produces a JA3 hash that maps to no browser. The fix is to impersonate a real stack rather than to patch headers:

from curl_cffi import requests as cffi

session = cffi.Session(impersonate="chrome131")  # real Chrome TLS + HTTP/2 profile
session.proxies = {
    "http":  "http://user:pass@gate.sparkproxy.io:10000",
    "https": "http://user:pass@gate.sparkproxy.io:10000",
}
resp = session.get("https://example.com/catalog")
print(resp.status_code)

impersonate="chrome131" sends Chrome 131's cipher suites, extension order, and HTTP/2 SETTINGS, so the JA3 and JA4 hashes finally tell the same story as the User-Agent. curl_cffi maintains those profiles as browsers ship, which is the part you do not want to own yourself. The mechanics of what gets hashed are in what is TLS fingerprinting, and JA4 is the successor scheme you will increasingly see referenced instead of JA3.

Where a real browser is required, keep the whole profile coherent:

PROFILE = {
    "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 "
                  "(KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36",
    "viewport": {"width": 1440, "height": 900},   # not the 800x600 headless default
    "locale": "zh-CN",
    "timezone_id": "Asia/Shanghai",
    "country": "cn",
    "impersonate": "chrome131",
}

def profile_is_coherent(p: dict) -> bool:
    ua_major = int(p["user_agent"].split("Chrome/")[1].split(".")[0])
    imp_major = int(p["impersonate"].replace("chrome", ""))
    same_engine = abs(ua_major - imp_major) <= 1
    real_viewport = p["viewport"]["width"] >= 1024 and p["viewport"]["height"] >= 720
    assert_coherent(p["country"], p["timezone_id"], p["locale"])
    return same_engine and real_viewport

The abs(ua_major - imp_major) <= 1 check catches the most common regression in a long-running scraper: somebody bumps the User-Agent string to look current and forgets the TLS profile, so the claimed browser and the actual handshake drift apart by six versions. That drift is silent, it never throws, and it surfaces weeks later as a challenge rate nobody can explain. Canvas, WebGL vendor strings and font enumeration behave the same way: consistency beats cleverness.

Here is the rule missing from most GeeTest write-ups, and it explains a lot of otherwise baffling results. Two clocks run at once, and they have to be retired together.

The exit clock tracks how much a given IP has been used: total requests, how recently, and against which hosts. The session clock tracks how old a browser session is: cookie age, pages visited, and whether it has a plausible history. Rotate the exit while keeping the session and you have a user whose IP teleported mid-visit. Keep the exit and rotate the session and you have a machine where a brand-new visitor appears every ninety seconds from one address. Both are contradictions, and both are more suspicious than the wear you were trying to avoid.

import time
from dataclasses import dataclass, field

@dataclass
class Session:
    exit_id: str                       # sticky proxy session or session_id label
    created_at: float = field(default_factory=time.time)
    requests: int = 0
    warmed: bool = False

    MAX_AGE = 20 * 60                  # retire after 20 minutes of wall clock
    MAX_REQUESTS = 60                  # or 60 requests, whichever lands first

    def age(self) -> float:
        return time.time() - self.created_at

    def should_retire(self) -> bool:
        return self.age() > self.MAX_AGE or self.requests >= self.MAX_REQUESTS

    def retire(self) -> "Session":
        """Never reuse half a session. Both clocks reset together."""
        return Session(exit_id=new_exit())   # new exit, new cookie jar, new age

Warming is the other half. A session whose first request is a deep listing page has no history, and no history is itself a signal. Load the entry point, let the page settle, then walk a plausible path: entry, category, listing, detail. It costs two cheap requests to make the expensive one look ordinary. Binding a session to one exit for its whole life is what a sticky session is for, and what a sticky session proxy is covers how that binding is implemented on the proxy side.

The numbers above are starting points, not constants. Derive your own from the challenge meter: raise MAX_REQUESTS until the rate moves, then step back one notch.

Standard retry logic does the wrong thing here, and it does it confidently. A generic backoff sleeps and then retries the same request on the same session over the same exit, which re-presents the exact fingerprint that just scored badly. You added a delay and changed nothing else. The score does not improve because you waited.

A challenge means the session is spent. Quarantine it.

import random, time

class Quarantine:
    """Back-off that retires the identity, not just the clock."""

    def __init__(self, meter, target_rate=0.02):
        self.meter = meter
        self.target = target_rate
        self.concurrency = 4
        self.strikes = 0

    def on_challenge(self, session) -> "Session":
        self.strikes += 1
        session.retire()                                  # both clocks reset
        delay = min(2 ** self.strikes, 120) + random.uniform(0, 5)
        time.sleep(delay)                                 # jitter, never a fixed step
        self.concurrency = max(1, self.concurrency // 2)  # multiplicative decrease
        return new_warmed_session()

    def on_success(self, segment: str) -> None:
        self.strikes = 0
        if self.meter.rate(segment) < self.target and self.meter.total[segment] > 50:
            self.concurrency += 1                         # additive increase

That is additive-increase, multiplicative-decrease, the same control law TCP congestion control uses, applied to challenge rate instead of packet loss. It converges on the highest request volume the target tolerates without you having to guess a number, and it hands throughput back automatically when conditions improve. Pair it with the general patterns in retry and backoff strategies for web scraping, with one amendment specific to GeeTest: the retry unit is the identity, not the request.

Volume is the lever nobody wants to pull and the one that works most reliably. If your challenge rate sits at 15% and you halve requests per hour, the rate usually falls by more than half, because velocity feeds the score that produces the challenges in the first place. Ask whether you need every page daily, or whether the top 20% of pages daily and the rest weekly answers the same business question. Most of the time it does.

Running clean exits, current TLS profiles, coherent browser profiles, and session lifecycle management is a standing job. A scraping API collapses those into request parameters and keeps them current on the provider's side, which is a straight build-versus-buy call turning on how many targets you run and how fast they change.

The endpoint is https://scrape.sparkproxy.io/api/v1 and auth is a single X-API-Key header:

curl -G "https://scrape.sparkproxy.io/api/v1" \
  -H "X-API-Key: YOUR_API_KEY" \
  --data-urlencode "url=https://example.com/catalog" \
  --data-urlencode "render_js=true" \
  --data-urlencode "premium_proxy=true" \
  --data-urlencode "country_code=CN" \
  --data-urlencode "stealth=true" \
  --data-urlencode "human=true" \
  --data-urlencode "wait=3" \
  --data-urlencode "wait_for=.product-grid" \
  --data-urlencode "session_id=warm-pool-07" \
  --data-urlencode "tag=geetest-cn-residential" \
  --data-urlencode "json_response=true"

Each parameter maps onto a row of the signals table:

• premium_proxy=true puts the exit on a residential ISP range instead of a hosting ASN.
• country_code=CN matches the exit to the site's expected audience.
• stealth=true patches the automation leaks a fingerprint pass reads, and it requires render_js=true.
• human=true and wait=3 give the page ordinary interaction and settling time rather than an instant read.
• wait_for holds until your real content exists, so you never archive a challenge page as if it were data.
• session_id labels the browser profile, which is how a warmed session stays coherent across calls.
• tag is the one people skip, and it is what makes the challenge meter useful: tag by pool and country and you can attribute a rate regression to a single change.

Pricing follows from the flags. A premium-proxy request with JS rendering is 25 credits, stealth adds 5, and country_code adds 5, so the configuration above costs 35 credits per request. That is real money at volume, which is another argument for a low challenge rate: every retry you avoid is 35 credits you keep.

import requests

API = "https://scrape.sparkproxy.io/api/v1"
KEY = "YOUR_API_KEY"

def fetch(url: str, segment: str, meter: ChallengeMeter, **extra):
    params = {
        "url": url,
        "render_js": "true",
        "premium_proxy": "true",
        "country_code": "CN",
        "stealth": "true",
        "human": "true",
        "wait": "3",
        "session_id": segment,
        "tag": segment,
        "json_response": "true",
    }
    params.update(extra)
    env = requests.get(API, headers={"X-API-Key": KEY},
                       params=params, timeout=120).json()
    body = requests.get(env["result_url"], timeout=60).text
    state = geetest_state(body, env.get("status_code", 0))
    meter.record(segment, state)
    return state, body

With json_response=true the reply is an envelope carrying job_id, status_code, duration_ms, credits_used and a result_url holding the content, so you can classify the outcome and bill it to a segment in one pass. Full parameter and response details are in the SparkProxy Scraping API documentation.

Assemble the pieces. The loop classifies every response, feeds the meter, adjusts concurrency by the control law, quarantines identities on a challenge, and stops on its own when the target is telling you no.

def crawl(urls, segment="cn-residential-a", target=0.02, hard_stop=0.35):
    meter = ChallengeMeter()
    guard = Quarantine(meter, target_rate=target)
    session = new_warmed_session()
    collected, deferred = [], []

    for url in urls:
        if session.should_retire():
            session = session.retire()

        state, body = fetch(url, segment, meter)
        session.requests += 1

        if state in ("clean", "passed_with_widget_loaded"):
            collected.append((url, body))
            guard.on_success(segment)
            continue

        deferred.append(url)                   # re-queue, do not discard
        session = guard.on_challenge(session)  # retire, back off, re-warm

        if meter.total[segment] > 100 and meter.rate(segment) > hard_stop:
            raise RuntimeError(
                f"challenge rate {meter.rate(segment):.0%} on {segment}: "
                "stop and fix the profile, or negotiate access"
            )

    return collected, deferred

Two design choices carry the whole thing. Challenged URLs go to deferred rather than being retried in place, so a bad patch never turns into a hot loop against someone's origin. And hard_stop raises instead of degrading, because a sustained rate above roughly a third means the answer is not a tuning change. It means this route is wrong and section 5 is where you should be.

Persist the counters between runs. Challenge rate over a week, sliced by pool and country, tells you when an exit range is decaying long before your throughput graph does, and it turns the whole question from an argument about mouse curves into a number you can watch. That is what a working GeeTest strategy looks like: not a solver you maintain, but a rate you keep low. For the vendor-agnostic version of the same discipline, how to avoid CAPTCHAs when web scraping applies it across reCAPTCHA, hCaptcha and Turnstile too.