You can usually tell you have hit Fastly by the way the block reads. A request that pulled a clean 200 an hour ago now comes back as a 403, or the 406 Not Acceptable that Signal Sciences deployments often return, and swapping in a fresh proxy changes nothing. That last part is the tell: if a new IP does not move the block, the IP was never the only thing Fastly was reading. Fastly's Next-Gen WAF grew out of Signal Sciences, and it is not counting your requests the way a plain rate limiter does. It scores who you are from several angles, an IP and cross-customer reputation, the request signals and rate you generate at the edge, and, where Bot Management is enabled, a client-side challenge that fingerprints your browser, and your IP is one input out of several.
Can residential proxies get past Fastly?
Partly, and only for one of the things Fastly checks. Residential proxies fix the IP-reputation signal, which gets you off the datacenter ranges and the Network Learning Exchange lists that Fastly shares across its customer base. They do nothing for the request-shape signals Signal Sciences attaches to your traffic, and nothing for the client-side challenge that Bot Management uses to catch headless browsers. A clean IP behind a bare HTTP client still gets caught. You need all of it to line up.
What Fastly actually checks
Fastly is a CDN and edge platform, so its Next-Gen WAF sits inline in front of the origin. Detection comes in two layers, and the split matters for how you approach it.
IP and NLX reputation. Fastly reads the network that owns your address and its history, and its Network Learning Exchange shares confirmed-malicious source reputation across customers, so an IP burned scraping one Fastly site can arrive pre-flagged at the next. Fastly's own bot guidance notes that inventory-scraping bots can be identified through pre-identified bad IP ranges from sources like SANS. Datacenter ranges accumulate this reputation fast. This is the gate a proxy actually moves.
Request signals and rate. This is the Signal Sciences heritage, and it is what makes Fastly feel different from a signature WAF. Instead of matching a static payload list, it attaches named signals to requests, an anomalous header order, a scraper pattern, an abuse attempt, and rate-limits or alerts when a source crosses a threshold on those signals. Fastly's writing on telling good bot traffic from bad is about exactly this: reading suggestive signals rather than a single fingerprint. A scraper can trip this layer on behavior and rate before any JavaScript runs.
The client challenge and headless detection. Where Bot Management is enabled, Fastly adds a client-side layer. Client challenges require a visitor to prove they are a full browser rather than a script, and advanced client-side detection uses a JavaScript snippet you embed in the page to detect bots leveraging headless browsers such as headless Chrome. Passing sets a challenge-complete cookie (_fs_ch_cp), with a companion _fs_cd_cp cookie issued from your own domain. A client that never runs the challenge JavaScript never earns these, so it stays unproven.
Client fingerprint. Underneath both layers Fastly fingerprints the connection, including JA3 and JA4 TLS signatures, so a client whose handshake contradicts its User-Agent is flagged before the signals are even totted up.
Why a raw HTTP client trips Fastly
Point a plain requests or axios script at a Fastly-protected site and you lose on more than one layer at once. Its TLS fingerprint and header order feed the request signals as anomalous the moment the connection opens, and it has no JavaScript engine, so where Bot Management is on it never runs the challenge and never receives the _fs_ch_cp cookie. On top of that the rate and shape of a tight scraping loop is precisely the pattern Signal Sciences signals are built to catch. This is why rotating a datacenter pool against Fastly rarely helps: you keep changing the IP, which NLX reputation and signal-based rate limiting were designed to see through, while the request-shape signals and the missing challenge do the blocking.
Where residential proxies fit, and where they do not
Residential proxies route your traffic through real home connections on consumer ISPs, so the reputation signal flips from a flagged, NLX-listed hosting range to a neutral home line. Datacenter IPs lose at this gate first, which is why every serious attempt against Fastly starts with residential or mobile IPs. This is real, and it is the non-negotiable foundation.
What a proxy cannot do is change your request signals or answer the client challenge. The proxy forwards your bytes untouched. If those bytes carry a scraper's header order and a tight request rhythm, a residential IP just means Fastly signals a residential IP as a scraper. The mental model is the one behind all web scraping with proxies: the proxy makes your IP believable, and your request shape, your browser, and your pacing make the rest of you believable. Fastly scores them together.
Sticky sessions, not blind rotation
There is a rotation trap here too, the same shape as on Cloudflare and DataDome. Signal Sciences can rate-limit on identifiers beyond the raw IP, and NLX reputation follows the address, so blind per-request rotation mostly spreads your pattern across more IPs that can each pick up reputation. Once Bot Management is on, rotating also throws away the _fs_ch_cp cookie that vouches for your session. The winning pattern is the opposite of machine-gun rotation:
- Sticky sessions per flow. Hold one residential or ISP IP for a whole browsing session so the challenge cookie, the IP, and the fingerprint stay consistent.
- Rotate between flows, not inside them. New session, new identity, new IP.
A setup that actually gets through
The honest version has no single trick in it. Getting past a real Fastly deployment means lining up every signal, and proxies are one of them:
- Route through rotating residential or mobile IPs, with sticky sessions per flow. This clears the reputation and NLX gate that stops datacenter ranges first.
- Run a real browser where Bot Management is on. A hardened Playwright or Puppeteer, or an anti-detect browser, runs the client challenge and hides the headless tells the client-side detection looks for. A bare HTTP client cannot earn the
_fs_ch_cpcookie. - Send a full, correctly ordered header set and a TLS fingerprint that matches your User-Agent, so you stop feeding the anomalous-request signals that Signal Sciences keys on.
- Pace like a person, with randomized delays and modest per-IP volume, because the signal thresholds are watching rate and rhythm, not just the raw count.
- Persist cookies and session on the same sticky IP, so once you pass the challenge you stay passed.
Test before you scale
Before you point a real job at a defended target, prove one identity end to end. Confirm your exit is alive and residential with the proxy checker, then hit a fingerprint test endpoint and confirm your JA3 matches the browser you claim to be. If the IP is clean but the request still gets a 406, your header order, your rate, or your missing challenge is the problem, not the address. Testing one full identity tells you which signal is failing, which is the only way to fix the right thing instead of buying more proxies you did not need.
The honest bottom line
Fastly's Next-Gen WAF scores several things and reads them together: your IP and NLX reputation, the request signals and rate you generate at the edge, and, where Bot Management is on, a client-side challenge that fingerprints headless browsers. Residential proxies fix the reputation layer completely and are the foundation, since datacenter ranges never make it past the NLX and IP gate. But they do nothing for the request signals or the challenge. A clean rotating residential pool with sticky sessions gets you to the table; a real browser, a clean request shape, and human pacing are what let you stay. Our residential IPs start at $0.65/GB pay-as-you-go with no KYC and a balance that does not expire, which fits a job that runs in bursts. Anyone selling residential proxies as a one-click Fastly bypass is skipping most of the problem. Get all of it right and Fastly stops being a wall and becomes a checklist.
Sources
- Fastly: Bot Management: client challenges, advanced client-side detection of headless browsers via an embedded JavaScript snippet, the
_fs_ch_cpchallenge-complete and_fs_cd_cpcookies, and verified bots. - Fastly: Next-Gen WAF: the Signal Sciences heritage, signal-based detection, and the Network Learning Exchange cross-customer reputation.
- Fastly: Suggestive signals, how to tell good bot traffic from bad: reading request signals rather than a single static fingerprint.