Тестирование сайтов за Cloudflare
Cloudflare стоит перед миллионами сайтов как CDN, WAF и anti-DDoS слой. Для QA это означает: один и тот же URL ведёт себя по-разному в зависимости от IP, TLS-fingerprint, JavaScript-challenge и включённого Bot Fight Mode. Тестировать production только с офисного адреса — значит не видеть опыт пользователя из другой страны и не воспроизводить блокировки автomation-трафика. Прокси дают набор «входов» с разных подсетей и гео.
Сценарии тестирования
Geo-правила. Cloudflare Workers и Page Rules отдают разный контент по стране — проверьте с IP DE, US, RU. WAF custom rules. Блокировка по ASN или country — убедитесь, что легитимные пользователи не попадают под rule. Rate limiting. Порог 100 req/min с одного IP — load test должен распределять нагрузку через пул прокси.
Challenge и Turnstile. Headless-браузер без прокси часто получает 403 или бесконечный challenge. Residential-подобный IPv4 + корректный UA снижают friction; см. также bot detection.
Staging vs production
Staging за Cloudflare Access или IP whitelist — добавьте IP прокси в allowlist или используйте отдельный subdomain без challenge. Не гоняйте агрессивный краулинг по production: даже «своему» сайту Cloudflare может включить Under Attack Mode при аномалии.
Для Playwright и Cypress прокси задаётся на уровне launch options — детали в гайде Playwright и QA-тестировании.
Распределённый load test
k6, Locust или JMeter с одного IP упираются в Cloudflare rate limit раньше, чем origin. Сгенерируйте список прокси NEONPROXY, передайте в executor — каждый virtual user берёт случайный адрес. Следите за кодами 429 и 503; экспоненциальный backoff обязателен. Подробнее — load testing и ошибка 429.
TLS и HTTP/2
Cloudflare анализирует JA3/JA4 fingerprint. Прокси HTTPS терминирует TLS на своей стороне — fingerprint будет прокси-клиента, не вашего curl. Для проверки именно browser fingerprint используйте real browser через прокси, не raw HTTP-клиент. CONNECT-туннель описан в статьях про HTTP CONNECT и HTTPS CONNECT.
Workers и edge cases
Cloudflare Workers выполняют код на edge — A/B тест может отдавать variant B только для EU. QA через прокси из US и DE подтверждает, что experiment bucket работает. Cache Rules и Tiered Cache меняют HIT/MISS — заголовок CF-Cache-Status логируйте в автотестах для каждого geo.
Bot Fight Mode «Definitely automated» иногда блокирует CI runner даже с browser-like UA. Whitelist IP прокси в Cloudflare dashboard → Security → WAF → custom rule skip для известных QA-адресов — документируйте список в runbook команды.
Чеклист перед релизом
Проверить главную и checkout с 3+ гео. Убедиться, что API routes не блокируются OWASP rules. Прогнать smoke E2E через прокси из чекера с чистым blacklist. Задокументировать, какие IP добавлены в Cloudflare allowlist для CI. Сравнить response headers до и после включения нового WAF rule — regression часто видна только из «чужого» ASN.
Zero Trust и Access
Cloudflare Access перед internal tools требует JWT; E2E тест login flow через прокси + service token для CI bypass на staging. Не отключайте Access на prod ради «удобства QA» — заведите parallel staging subdomain.
Logpush в S3 для анализа blocked requests по country — validate WAF rules post-deploy. JA3 hash в CF logs помогает отличить ваш Playwright от curl при отладке false positive.
Zero Trust и Access
Cloudflare Access перед internal tools требует JWT; E2E тест login flow через прокси + service token для CI bypass на staging. Не отключайте Access на prod ради «удобства QA» — заведите parallel staging subdomain.
Logpush в S3 для анализа blocked requests по country — validate WAF rules post-deploy. JA3 hash в CF logs помогает отличить ваш Playwright от curl при отладке false positive.
Cache purge и тестирование
После purge everything — первый request с каждого geo должен быть MISS; повторный HIT. Тестируйте через прокси из 5 стран параллельно в CI matrix job. Purge by tag безопаснее global purge на production.