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

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

Cloudflare полезен перед API-шлюзом, но только если вы контролируете поведение кэша, TLS и заголовков. Для публичных GET-методов можно включать кэширование точечно; для POST, PATCH и auth-эндпоинтов кэш должен быть выключен. Иначе вы рискуете не ускорить систему, а раздать устаревшие ответы клиентам.

Критичные проверки:
— передавайте реальный IP клиента через CF-Connecting-IP или X-Forwarded-For и настраивайте доверенные прокси на стороне шлюза;
— не завязывайте авторизацию только на IP, если часть трафика идет через edge;
— исключите из кэша токены, персональные данные и ответы с разными cookies или Authorization;
— проверьте, не ломают ли WAF и rate limiting внутренние сервисные вызовы. ⚙️

Отдельно смотрите на заголовки Cache-Control, Vary и Origin. Если шлюз отдает разные ответы для одного URL в зависимости от токена, языка или device hints, Cloudflare должен учитывать это явно. Иначе получите редкие, но очень дорогие инциденты: данные смешиваются между пользователями, а проблема выглядит как «плавающая» ошибка приложения.

Безопасная схема проста: edge фильтрует шум, API-шлюз принимает только ожидаемый трафик, кэшируется лишь то, что действительно одинаково для всех. Стабильность инфраструктуры — залог масштабируемости.