---
title: "CAPTCHA"
url: https://proxy.wiki/glossary/captcha/
type: Glossary Term
author: "proxy.wiki editorial"
published: 2026-08-19
updated: 2026-08-29
site: proxy.wiki
topics: ["Anti-bot systems"]
license: CC BY 4.0 — quote freely with attribution to https://proxy.wiki/
---

# CAPTCHA

> A challenge intended to separate humans from automation, and usually a symptom rather than the problem itself.

**A CAPTCHA is a test presented when a system is uncertain whether a visitor is human.** Modern implementations mostly score behaviour silently and only show a visible puzzle when the score is poor.

## Treat it as a symptom

By the time a challenge appears, something earlier already looked wrong: the [network](/glossary/asn/), the [TLS fingerprint](/glossary/tls-fingerprinting/), the request rate, or the [browser fingerprint](/glossary/browser-fingerprinting/). Solving the challenge without addressing the cause means solving one on every request, which is slow and expensive.

## The order that actually works

- Find out which signal is triggering suspicion.

- Fix that — often the client stack rather than the proxy.

- Reduce request rate and make timing less mechanical.

- Only then consider solving services, and only for the residual cases.

## Note on legality

Automated circumvention of access controls is restricted in some jurisdictions and prohibited by many sites’ terms. Whether you may do it is a separate question from whether you can.

## What triggered it, and in what order to look

A challenge is the output of a decision, so treat it as a symptom. Work through the causes in order of how cheaply you can test them.

| Check | How to test it |
| --- | --- |
| Address class | Repeat from a different category of address |
| [TLS handshake](/glossary/tls-fingerprinting/) | Repeat with a real browser on the same connection |
| Header set | Compare your headers with a browser’s, in order |
| Rate | Slow down and reduce [concurrency](/glossary/concurrency/) |
| Missing cookies | Fetch the entry page first, then the target |

If a real browser on your own connection is also challenged, the address is not the problem and no proxy will fix it.

## Why solving is the wrong first move

Paying to solve challenges treats the output rather than the cause. It costs per request, it fails at scale, and it leaves the underlying signal untouched, so the challenge rate usually rises. Fixing the signal removes the challenge instead of paying for it repeatedly.

There is also a boundary worth naming. Systems that solve challenges on your behalf sit in a contested legal and contractual area. Read the target’s terms before adopting one, and treat the question as a real one rather than a formality.

## Frequently asked questions

### Why am I getting CAPTCHAs on every request?

Something about the connection is being scored as automated. Address class, TLS handshake, header set, request rate and missing cookies are the usual causes. Test the cheapest first by repeating the request from a different address, then with a real browser.

### Will better proxies remove the CAPTCHAs?

Only if the address was the trigger. Confirm it by loading the same page in a real browser on your own connection. If that is challenged too, the address is not the cause and changing it will not help.

### Is using a CAPTCHA-solving service legal?

It depends on the jurisdiction and on the target's terms, and it is genuinely contested rather than settled. Read the terms of the site you are accessing and take the question seriously before adopting one.

## Sources

1. [RFC 9110: HTTP Semantics, the 403 status code](https://www.rfc-editor.org/rfc/rfc9110.html)