Why Your Proxies Get Flagged (and How to Fix It in 2026)

Your bot gets flagged before the ATC. Cookie challenge, hCaptcha, or straight-up 403. You blame the proxies. Sometimes it is the proxies — but usually the proxy is one of three signals that combine to flag the request. Here's how to diagnose which of the three is broken.

The three flagging surfaces

1. IP reputation — is your IP known-bad
2. TLS fingerprint — does your bot's TLS handshake match a real browser
3. Behavior — does your request timing / mouse curves / typing rhythm match a human

All three feed into the fraud engine. A borderline IP + a perfect TLS fingerprint might pass. A perfect residential IP + a Python requests library TLS fingerprint gets flagged instantly.

Diagnose which one is broken

Test 1: IP reputation

Take one of your proxy IPs and check it against a public reputation database:

• ipinfo.io/[IP] — shows ASN, city, org. If ASN says "AMAZON-02" or similar, you're on a datacenter IP.
• ipqualityscore.com — proprietary fraud score. Anything over 75/100 is flagged.
• fraudguard.io — behavioral scoring.

If your IP scores >75 or shows a datacenter ASN, that's why you're getting flagged. Switch to a legit residential provider.

Test 2: TLS fingerprint

Head to ja3er.com or tls.peet.ws through your bot's HTTP client. It returns your TLS fingerprint (JA3 hash). Compare it to what a real Chrome/Firefox produces from the same OS.

Common giveaways:

• Python requests → distinctive JA3, easy to detect
• Go net/http → distinctive JA3, easy to detect
• Node axios → same
• curl_cffi or httpx with impersonate="chrome110" → matches Chrome, hard to detect

Fix: use a TLS-impersonating HTTP library. curl_cffi for Python, utls for Go. If you're using a bot (NSB, Wrath, etc.), the bot handles this — check that TLS impersonation is enabled in settings.

Test 3: Behavior

This is what most proxy problems actually are. Common behavior red flags:

• Request timing too regular. A human doesn't ATC every product exactly 300 ms after the PDP loads. Add jitter — 300–2000 ms random delay.
• Request order too aggressive. Home → PDP → ATC in 500 ms combined = bot. Warm up: home → wait 15 s → category → wait 10 s → PDP → wait 5 s → ATC.
• No mouse movement (browser bots). Puppeteer/Playwright that goes straight to page.click() without simulated mouse curves = bot. Use ghost-cursor or similar.
• Instant form fill. Real humans type. Simulate keystroke timing.
• User agent mismatch with TLS. Sending "Chrome 122" in your UA but a Firefox JA3 = bot. Match them.

The order to fix things

If you're getting flagged, work through in this order:

1. Are the proxies actually residential? (Test 1) — if no, buy real residential proxies.
2. Is TLS fingerprint browser-like? (Test 2) — if no, switch HTTP client.
3. Is behavior human-like? (Test 3) — if no, add jitter + warm-up + slow down.

Do them in that order because each one is progressively harder to test and fix. Wasting a week tuning behavior when your proxies are actually datacenter is common.

Site-specific flag patterns

Cloudflare-protected sites (Nike, Shopify, Ticketmaster): heavy JA3 checking, moderate IP checking, light behavior scoring. TLS fingerprint is your biggest risk.

Akamai-protected sites (Yeezy Supply, Adidas): aggressive behavior scoring, moderate IP reputation, TLS check that's slightly forgiving. Behavior is your biggest risk.

PerimeterX / HUMAN-protected (Foot Locker, Ticketmaster): full sensor stack — mouse + touch + accelerometer + fingerprint. Nearly impossible without a real browser + solver network.

DataDome-protected (Reddit ATO, some smaller sites): device fingerprint focus. IP matters less, browser fingerprint matters more.

When it really is the proxies

Signs your proxies specifically (not TLS, not behavior) are the problem:

• Same bot + same account works on residential proxies from a different provider, fails on yours
• Public reputation lookups show your IPs as flagged
• Requests fail before any application-level response — TCP resets, TLS aborts
• Your provider's ASN is a known-bad datacenter (check ipinfo.io)

Signs it's not the proxies:

• You get the site's HTML back but with a hCaptcha or Cloudflare challenge — the site is talking to you, it just doesn't trust you (TLS or behavior issue, not IP)
• Different bots on the same proxies work — one bot is fingerprint-broken
• Some sites work, others don't — the "others" have stronger detection stacks, not different IP requirements

Test your proxies before drop day

Never buy proxies and immediately deploy them on drop day. Run a soft test the night before:

1. Fire a monitoring task on the target site through the new proxies
2. Check that GET requests return 200 with expected HTML
3. Run one full checkout to test PDP through cart
4. If any step gets a challenge or 403, the proxies aren't ready

SMT residential — free to test with 2 GB for $2. If the proxies don't work for you, refund on the spot.