Cloudflare перед API-шлюзом: где ускорение помогает, а где ломает авторизацию

Cloudflare перед API-шлюзом: где ускорение помогает, а где ломает авторизацию

Интеграция CDN с API-шлюзом кажется простой: ставим Cloudflare перед gateway и получаем меньше латентность. На практике ошибка часто в другом — кешируют всё подряд, не учитывают заголовки авторизации и случайно раздают ответ, который должен быть персональным.

Рабочая схема обычно такая:
— публичные GET-эндпоинты можно кешировать, но только если ответ не зависит от Cookie и Authorization;
— для POST, PUT, DELETE кеш должен быть выключен;
— лимиты и WAF лучше применять на уровне edge, а не внутри самого шлюза;
— исходный IP клиента надо передавать явно, иначе логика rate limit и аудит искажаются.

Для API критичны заголовки. Если шлюз строит ответ по Accept, Origin, Authorization или пользовательскому tenant-id, эти значения должны попадать в cache key или исключать кеширование. Иначе одна организация увидит данные другой. Это не гипотеза, а типовая причина инцидентов после «безобидного» включения Cache Everything.

Отдельно проверьте TLS и проксирование: шлюз должен доверять CF-Connecting-IP и X-Forwarded-For только из списка IP Cloudflare, а не от любого клиента. Иначе защита от злоупотреблений превращается в дыру.

Стабильная интеграция строится на простом правиле: кешируем только то, что одинаково для всех, а безопасность и идентификацию пользователя не переносим в предположения. Разбираем логи, оптимизируем кэширование, минимизируем задержки.