--browser first.
Detection Indicators
Your site needs Cloudflare bypass if you see:Display Requirements
Cloudflare bypass requires a visible browser (not headless). Cloudflare detects and blocks headless browsers.
- 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) ✓
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
Hybrid Mode (Recommended)
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):- 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.
- Once a cookie exists, requests go out over HTTP with it (via
curl_cffiTLS impersonation). - 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)
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.
- CF verification: 10-60 seconds
- Page load: 5-30 seconds
- Re-verify after a blocked response: 10-30 seconds
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 xvfb4
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:Title Contamination
Related Guides
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