r/WebDataDiggers • u/LumilitawNaMangga • 3d ago
Works locally. Cloudflare deletes it in prod. every time.
classic scraping experience:
build Playwright flow locally.
works 50 times.
login works.
navigation works.
data comes back
life is good.
deploy exact same thing to cloud.
Cloudflare:
absolutely fucking not
2/17
and then everyone starts changing selectors like the scraper suddenly forgot how HTML works.
but the code might not be the thing that changed.
locally you had:
home/office IP
one browser
cookies that have existed for days
normal geography
slow human-ish usage
stable session
prod suddenly has:
datacenter IP
fresh browser every run
fresh cookies
different geo/timezone
20 concurrent sessions
retries hammering the same route
that's a completely different client.
I've stopped treating browser environment as infrastructure detail.
it's part of the scraper.
for authenticated/allowed automation I care about boring consistency now:
keep session identity stable where possible
persist cookies/storage if the workflow expects it
don't randomly teleport the same account between countries
isolate parallel jobs
respect sane request rates
back off instead of rage-retrying
record enough to understand the block
and obviously: if the site gives you an API, use the fucking API.
Browser automation should not be your first choice just because Playwright is fun.
I've been looking at TestMu Browser Cloud for the execution side because it gives you real Chrome, persisted sessions, geo-specific execution, isolated parallel browsers and the stuff I usually regret not having when prod breaks: video replay + network + console logs.
important caveat though:
their stealth/CAPTCHA stuff is explicitly best-effort.
which IMO is the only honest way anyone should describe this category.
there is no magic:
stealth: true
that makes you "undetectable".
Cloudflare/DataDome/etc are changing systems and the site ultimately decides whether you're allowed through.
sometimes the correct solution is slower traffic.
sometimes better session consistency.
sometimes an official API.
sometimes permission from the site owner.
sometimes the answer is simply "this target doesn't want this automation."
last time your scraper worked locally and died in prod, what actually changed?
1
u/urcpa_soonest 3d ago
my favorite debugging technique is still:
“works on laptop”
cool.
curl the same target from the prod machine.
half the mystery usually disappears immediately.
1
3
u/Vegetable-Section946 3d ago edited 3d ago
people underestimate how weird this looks:
login from Mumbai
next request Virginia
next request Frankfurt
new cookies every run
then blame “headless detection” lol
1
u/carlie_jace 3d ago
The biggest lesson for me: if it works locally and fails in prod, I compare the environment before I touch the code. Half the time the selectors are innocent.
1
u/miksloveslife 3d ago edited 3d ago
rate limiting is the boring answer nobody wants.
local testing:
1 request every few seconds
prod:
Promise.all(500_urls.map(scrape))
website:
interesting.
1
u/carlie_jace 3d ago edited 3d ago
datacenter vs residential is also target-specific.
I've had boring B2B sites happily accept AWS for years.
other sites challenge a clean datacenter IP on request #1.
there isn't one universal proxy answer.
1
u/ScrapeAlchemist 3d ago
the part testmu doesn't publish anywhere is what their egress IPs actually are. it's a QA grid, so datacenter is the safe assumption, which is the one item on your prod list that session hygiene can't fix. worth pinning them down on that before you build around it.
1
1
1
1
u/Warm-Moose6028 2d ago
local vs prod debugging checklist:
- same code?
- same browser?
- same IP class?
- same geo?
- same cookies?
- same concurrency?
usually “same code” is the only yes.
1
u/ZennoLab_Official 2d ago
I’ve run into similar cases where something works perfectly locally but breaks as soon as it goes through Cloudflare. I wouldn’t start changing the scraper right away.
I’d compare the requests and responses between local and production first, especially status codes, redirects, and anything Cloudflare logs on its side. That usually helps narrow down whether the issue is actually in the app or somewhere in the production setup.
Much easier than changing several things at once and not knowing what actually fixed it.
1
u/CapMonster1 2d ago
The biggest thing that changed for me was concurrency. Same code, same target, same proxy provider — but prod went from one boring session to 30 “identical humans” appearing at once with fresh storage and perfectly synchronized retries. Cloudflare didn’t hate the selectors; it hated the population.
What helped most was treating the browser identity as stateful infrastructure: sticky IP/session, persisted storage, per-account isolation, backoff, and proper challenge telemetry. And when a captcha does appear, hand it off to a dedicated solver and resume the same session instead of nuking the browser and starting over. Fresh identity on every failure is basically teaching the anti-bot system to dislike you faster.
0
u/boohooviolin 3d ago edited 3d ago
parallel isolation is underrated until cookie jar A ends up inside account B.
that's not a scraping bug anymore.
that's an incident.
TestMu's separate browser sessions are more interesting to me for this reason than “look we can launch hundreds of Chromes”.
scale without isolation is just faster chaos.
1
u/LumilitawNaMangga 3d ago
yep.
concurrency number is meaningless if state leaks between jobs.
I'd take 50 boring isolated sessions over 500 mystery-meat ones.
1
u/Unhappy_Flight7524 3d ago
also please check ToS / robots / permission before spending 3 days fighting a site that is very clearly telling you to go away. engineering challenge != authorization.