You hit an Arkose challenge and you know it on sight: a small interactive puzzle asking you to rotate an animal until it is upright, or pick the image that matches a prompt, usually on a signup or a suspicious login. It is the wall widely reported behind account creation on platforms like X (formerly Twitter) and Roblox. The automation that ran clean an hour ago now meets that puzzle on every attempt, and swapping proxies changes how often it appears but never makes it go away. That is the tell. Arkose did not throw that puzzle at random. It scored your session first, decided you were probably automated, and only then served the challenge. And the puzzle itself is not designed to be unsolvable, it is designed to be expensive, so that a cheap mass attack turns into a costly one. Once you know what feeds the score, you can bring it down until the puzzle is rare, which is a far better position than solving one on every request. One thing honest up front, the same as with reCAPTCHA and hCaptcha: no proxy solves the puzzle for you. What a good proxy setup does is keep Arkose from asking.
Can proxies get past Arkose?
No, and it is worth being blunt about it. A proxy changes the IP your request comes from, nothing more. A clean residential IP lowers your risk score, which lowers how often Arkose challenges you and how hard those challenges are, but it never reads the puzzle and never returns a solved token. Proxies reduce challenge frequency. Real browsers and solvers handle the challenges that still get through.
What Arkose actually does
Arkose is a two-layer system, and the split matters for how you approach it: a detection layer that scores you invisibly, and an enforcement layer that challenges you when the score is poor.
It scores you first. Arkose describes leveraging 225+ risk signals and the Arkose Global Intelligence Network to spot even the most evasive threats, and it aims to differentiate good users from malicious bots without friction. Its own developer docs describe the client-side step as collecting the data needed to classify client traffic, display an Enforcement Challenge if applicable, and provide a one-time use token. So the first thing that happens is a risk assessment, not a puzzle.
It enforces with an interactive challenge. When the score is poor, Arkose serves what it calls an Enforcement Challenge: the interactive puzzle it is best known for, long called FunCaptcha and now branded Arkose MatchKey. As the solving community describes it, FunCaptcha uses interactive puzzles and games to distinguish between humans and bots, where instead of reading text you pass a logical or gaming task, which is exactly why plain OCR bots cannot cope with it. The puzzles are dynamic and, in Arkose's words, evolve in real time to counter emerging attack vectors.
It makes attacks pay. The design goal is economic, not just technical. By escalating challenge difficulty for risky sessions and rotating the puzzles, Arkose makes automated solving slow and costly enough that a large-scale attack stops being profitable. That is the whole philosophy, and it is why it shows up on high-value account flows.
It runs one session fabric. Arkose ties detection and enforcement together on what it calls the Arkose Titan session infrastructure, so the risk signals and the challenge outcome belong to the same scored session rather than being independent checks you can pick apart.
The token, and why you cannot farm it
When a challenge is completed, the client produces a one-time-use token, and that token is verified on the server, not trusted on the client. Arkose's docs describe the server-side step as taking the client-provided token and verifying it with the Arkose Verify API, authenticated with a private key that, in Arkose's words, must not be published on a client-facing website and must only be used server-side. Because the token is single-use, you cannot solve one challenge and replay it across a batch, you cannot cache tokens ahead of time, and you cannot share one between sessions. This is the same reason token farming fails against hCaptcha: the durable strategy is to avoid the challenge, not to stockpile answers to it.
Why a raw HTTP client is dead on arrival
Point a plain requests or axios script at an Arkose-protected flow and it fails before scoring even matters. The challenge and the client-side script have to run in a browser, and a plain HTTP client has no JavaScript engine to run them, so it never produces a token. Separately, its TLS and HTTP/2 fingerprint matches no real browser, so it looks automated the moment the connection opens. Rotating a proxy pool changes none of that, because rotation fixes the IP and the IP was never the thing that would earn a token.
Where residential proxies fit
Residential proxies still earn their place, because the IP is one of the many signals feeding Arkose's risk score. Route through a real consumer connection and you present as an ordinary visitor rather than a datacenter range that reads as automation on sight, which nudges the score toward the quiet pass and away from an Enforcement Challenge. What a proxy cannot do is solve the puzzle or fix a headless browser's tells. The proxy forwards your bytes untouched, so a clean IP behind a stock automation build still fingerprints as automation and still gets challenged. As with every captcha-class defense, the proxy makes your IP believable and the browser makes the rest of you believable, and Arkose reads them together as one session. The same mental model runs through how websites detect proxies.
Prevention keeps the puzzle rare
Everything above lowers your risk score. Do all of it and the interactive challenge becomes the exception:
- Start with clean residential or ISP IPs, verified before use and held per session rather than swapped on every request, so the scored session stays consistent.
- Drive a real, fortified browser, a hardened Playwright or Puppeteer or an anti-detect browser, with the automation tells patched out, so the detection layer scores you as a genuine device.
- Pace and enter like a person, through a natural path rather than a cold deep-link, with randomized delays and modest per-IP volume.
- Warm the session, carrying a cookie jar and a small trail of history, so you arrive looking like a returning visitor rather than one that teleported in.
Get those right and most of your traffic clears the risk layer without ever seeing FunCaptcha.
When the puzzle still appears
Prevention lowers frequency, it does not hit zero, and Arkose is built so the leftovers are deliberately expensive. For the challenges that get through you have two honest options, and both cost something. A captcha-solving service takes the interactive puzzle and returns a solved token, which is fine for the occasional interruption but adds real latency per solve and turns into a meaningful bill at volume, exactly the cost Arkose is engineering for. Or you keep leaning on a real browser with a genuinely good risk score, so the challenges that appear are rare and the easier ones. If the target is a flow you are authorized to use at scale, the official route almost always beats both: many services behind Arkose expose an API or an account-based path that skips the challenge entirely.
Test before you scale
Prove one identity before you commit a batch. Confirm your exit is alive and residential with the proxy checker, then run one real request through your browser and IP and see what Arkose does: a quiet pass, or an Enforcement Challenge. If a fortified browser on a clean residential IP still gets challenged hard on the first hit, your fingerprint or behavior is dragging the score down, and no solver subscription fixes that root cause. Testing one full identity tells you which input is failing before you scale the mistake to thousands of requests.
The honest bottom line
Arkose scores you before it shows you anything, from your IP, your device, and your behavior across 225-plus signals, and it only serves the interactive FunCaptcha puzzle when that invisible score goes against you. The puzzle is engineered to be economically unfeasible to solve in bulk, and the token it produces is single-use and verified server-side, so there is nothing to farm. Residential proxies fix the IP input and are the foundation, but they are one input of several, and a clean address behind a headless browser still scores like a bot. Raise the score by pairing residential IPs with a real browser and human pacing, take the official API path when a site offers one, and keep a solver on standby only for the rare, costly leftovers. Anyone selling a proxy as an Arkose bypass is selling the wrong story: proxies make the puzzle rare, and a clean setup is what makes it rare enough to live with.
Sources
- Arkose Labs: Arkose Protect: the 225+ risk signals and Arkose Global Intelligence Network, dynamic challenges that evolve in real time, differentiating good users from bots without friction, and the Arkose Titan session infrastructure.
- Arkose Labs developer docs: standard setup: the two-step model of client-side classification that displays an Enforcement Challenge and provides a one-time-use token, and server-side verification of that token via the Arkose Verify API using a private key kept off the client.
- 2Captcha: FunCaptcha: the interactive-puzzle mechanics (logical and gaming tasks rather than text), and why OCR bots cannot cope with them, described from the solving community. Arkose does not publish every internal detail, so the FunCaptcha name and the puzzle specifics here are drawn from community documentation alongside Arkose's own pages.