Skip to main content
Only enable Cloudflare bypass when the site explicitly requires it. Always test WITHOUT --browser first.

Detection Indicators

Your site needs Cloudflare bypass if you see:
  • “Checking your browser” or “Just a moment” messages
  • 403/503 HTTP errors with Cloudflare branding
  • Challenge pages before content loads
VPS/Cloud Server IP Reputation Issue:If running on AWS, DigitalOcean, Hetzner, or any cloud provider, Cloudflare may block your server’s IP even with browser bypass enabled. Cloud/datacenter IPs are often flagged as high-risk.Solution: Combine --browser with residential proxies:
See Proxy Configuration for details.

Display Requirements

Cloudflare bypass requires a visible browser (not headless). Cloudflare detects and blocks headless browsers.
Platform support:
  • Windows: Uses native display automatically ✓
  • macOS: Uses native display automatically ✓
  • Linux desktop: Uses native display automatically ✓
  • Linux servers (VPS without GUI): Auto-detects missing display and uses Xvfb (virtual display) ✓
Installing Xvfb on Linux servers:
The crawler automatically detects your environment and uses Xvfb when no display is available on Linux.

Inspector Usage

1

Start with default HTTP (fast)

Works for most sites:
2

Try browser mode if JS-rendered

For JavaScript-heavy sites:
3

Use Cloudflare bypass only when blocked

For Cloudflare-protected sites:

Strategies

Verify the Cloudflare challenge once, then serve everything else over fast HTTP with the cached cookie. 20-100x faster than browser-only mode. How verification works (reactive hold-and-verify — no timer):
  1. The first request to a host has no cookie, so it verifies once. All other requests for that host hold at a single gate while ONE verification runs — the browser is never driven by concurrent requests at the same time.
  2. Once a cookie exists, requests go out over HTTP with it (via curl_cffi TLS impersonation).
  3. If an HTTP response comes back blocked, requests hold again, ONE request re-verifies, and everyone retries with the fresh cookie. There is no time-based refresh — cookies are re-fetched only when missing or when a response is actually blocked. If a response is still blocked immediately after a fresh verify, that’s treated as a real block (IP/rate limit) and surfaced, not retried forever.
Cookies are cached per spider + host. Each hostname (www., hemeroteca., an API subdomain, …) verifies and caches independently — a cookie for one subdomain is never reused for another.
Cloudflare verification always routes through the shared browser service — one warm browser shared across all crawls, so the challenge is solved once and reused instead of every crawl spawning its own Chrome. If the service isn’t running it is started automatically; if it can’t be reached the request fails and Scrapy retries it. See the Browser Service guide.
Do NOT set CONCURRENT_REQUESTS - uses Scrapy default of 16 for optimal performance.
spider.json

Browser-Only Mode (Legacy)

Much slower - uses browser for every request. Requires CONCURRENT_REQUESTS: 1 to prevent browser conflicts.
spider.json

Settings Reference

Complete Spider Example

spider.json

Timeouts & Hang Prevention

Browser operation timeout: 300 seconds (5 minutes) per operation to prevent infinite hangs.
Typical operation times:
  • CF verification: 10-60 seconds
  • Page load: 5-30 seconds
  • Re-verify after a blocked response: 10-30 seconds
If you consistently hit the 300s timeout, investigate:
  • Network connectivity issues
  • Site blocking your IP/region
  • Browser/Chrome subprocess problems
  • System resource constraints (CPU/memory)

Troubleshooting

Crawl Hangs at “Getting/refreshing CF cookies”

Symptoms: Browser opens but never navigates. Solutions:
1

Update to latest version

Ensure you’re on latest version with timeout fix
2

Verify browser opens

Check browser actually opens (not headless failing)
3

Check display (Linux servers)

Verify Xvfb is installed: sudo apt-get install xvfb
4

Test with inspector

Test with --browser flag on inspector first:
5

Check system resources

Verify CPU, memory, and disk space availability

Works on One Machine But Not Another

Debugging steps:
1

Test inspector on both machines

2

Check Chrome installation

3

Verify display (Linux)

4

Review logs for errors

Check logs for specific error messages
5

Try different strategy

Switch between hybrid and browser_only modes

Diagnosing via Logs

Hybrid mode indicators:
Browser-only mode indicators:

Title Contamination

If extracted titles show wrong text, set CF_WAIT_SELECTOR to the main title element to capture HTML before related content loads.

Browser Service

Shared warm browser that solves CF once per site

Proxy Escalation

Combine with smart proxy usage

Checkpoint Resume

Pause and resume long crawls