SSL/TLS режимы Cloudflare: где теряется безопасность и ломается origin-связь

Cloudflare часто воспринимают как «включил и забыл», но у SSL/TLS режимов разная цена ошибки:
— Flexible шифрует только до edge, а до origin идёт HTTP. Для админок, корзин и авторизации это слабое место.
— Full шифрует до origin, но не проверяет сертификат. Подходит лишь если вы уверены в валидности цепочки и контролируете сеть.
— Full (strict) проверяет сертификат и имя хоста. Это режим, который реально защищает от подмены и случайных misconfig.

Главная ловушка — неправильный выбор режима маскирует проблемы на origin. Сайт «работает», но:
• редиректы могут зациклиться;
• часть запросов уходит в mixed content;
• интеграции начинают падать на уровне TLS-рукопожатия;
• логика доверия между edge и сервером становится неявной. 🔐

Правильная схема простая: ставьте Full (strict), выпускайте валидный сертификат на origin и проверьте, что SNI совпадает с именем в сертификате. Для health-check и служебных доменов используйте отдельные правила, а не ослабляйте режим для всего трафика.

Если нужен баланс, сначала исправляйте origin, а не снижайте требования CDN. Безопасность и скорость: находим баланс в каждой конфигурации.

Защита от DDoS и WAF: где заканчивается фильтрация и начинается блокировка бизнеса

DDoS и WAF часто смешивают в одну «кнопку защиты», но задачи у них разные. DDoS-сценарий режет объемный шум на уровне сети и HTTP-потока. WAF работает точнее: ищет признаки атак в запросах, заголовках, payload и поведении клиента.

При настройке WAF не начинайте с блока всего подряд. Сначала включите режим наблюдения, соберите ложные срабатывания и отметьте легитимные паттерны: API-методы, формы, боты, нестандартные query string. Затем переводите только повторяющиеся угрозы в блок или challenge. Это снижает риск сломать авторизацию, поиск и checkout.

Для DDoS важнее не «максимальная жесткость», а устойчивость. Ограничивайте запросы на узких точках, используйте rate limiting для дорогих эндпоинтов и следите, чтобы origin не принимал трафик в обход CDN. Если origin доступен напрямую, любая edge-защита теряет смысл. 🔒

Отдельно проверьте порядок правил: исключения для внутренних сервисов, allowlist для мониторинга и приоритеты для критичных URL должны быть зафиксированы до включения агрессивных политик. Иначе одна новая сигнатура способна перекрыть и атаку, и нормальный трафик.

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

Meta ограничивает расходы на токены для сотрудников

Meta ввела внутренние лимиты на использование ИИ из-за резкого роста расходов: в 2026 году только на сотрудников заложены миллиарды долларов, а общий бюджет на ИИ-инфраструктуру оценивается в 130–145 млрд. Вывод простой: даже у Big Tech ИИ перестал быть бесплатной игрушкой и требует жёсткого контроля затрат.

➡️ Читайте на сайте: https://aff.top/blog/meta-ogranichivaet-raskhody-na-tokeny-dlia-sotrudnikov

🧠 Ещё больше инсайтов → в канале AFF.top

Claude Cowork, Claude Design объединили в один Claude

➡️ Читайте на сайте: https://aff.top/blog/claude-cowork-claude-design-obedinili-v-odin-claude

🧠 Ещё больше инсайтов → в канале AFF.top

Microsoft планирует вставлять рекламу в игры

➡️ Читайте на сайте: https://aff.top/blog/microsoft-planiruet-vstavliat-reklamu-v-igry

🧠 Ещё больше инсайтов → в канале AFF.top

Page Rules и Cache Rules: где чаще всего ломают кэш и ускорение сайта

Page Rules и Cache Rules решают разные задачи. Первая удобна для простых глобальных исключений, вторая — для точной логики по пути, заголовкам и типу ответа. Ошибка начинается, когда их смешивают без приоритета: правило «Cache Everything» может быть перебито более общим исключением, а ожидание «всё закэшируется» не совпадает с реальным матчингом.

Проверяйте три вещи:
• порядок срабатывания и область действия
• наличие конфликтующих правил для одного URL
• что именно кэшируется: HTML, статические файлы, ответы API, редиректы

Для динамики лучше задавать явные исключения через Cache Rules, а Page Rules оставлять для редких, грубых сценариев. Если нужно управлять TTL, режимом кэша и условием по параметрам запроса, точечное правило надёжнее. Если нужно быстро отключить кэш для целого раздела — Page Rules всё ещё полезны, но как инструмент последнего ряда, а не основа архитектуры.

Отдельно контролируйте bypass для авторизованных пользователей, корзины, личных кабинетов и POST-запросов. Иначе можно получить «ускорение» ценой утечки чужого контента или странных артефактов в браузере.

Разбираем логи, оптимизируем кэширование, минимизируем задержки. Стабильность инфраструктуры — залог масштабируемости.

Почему DDoS и WAF нельзя настраивать как два отдельных “щитка”

Защита от DDoS и управление WAF-политиками должны работать как одна система. Если рассматривать их отдельно, легко получить типичную ошибку: трафик уже отфильтрован на L3/L4, а на уровне приложений остаются дорогие запросы, бьющие по базе, логике авторизации и API.

Проверяйте три слоя:
• зона действия правила: весь домен, конкретный path или только API;
• режим срабатывания: блокировка, challenge, log-only;
• исключения для доверенных ботов, внутренних сервисов и health-check.

WAF не должен превращаться в “чёрный список по ощущениям”. Сначала включайте наблюдение и анализ false positive, затем ужесточайте правила точечно. Иначе вы начнёте терять легитимных пользователей раньше, чем увидите реальную атаку. Безопасность и скорость: находим баланс в каждой конфигурации.

Отдельно следите за корреляцией с кэшем: если защищённый endpoint не кэшируется, каждый промах WAF увеличивает нагрузку на origin. В таких точках полезны rate limiting, отдельные правила для авторизации и более жёсткая фильтрация по методам POST, PUT, DELETE.

Разбираем логи, оптимизируем кэширование, минимизируем задержки. Настраивайте DDoS и WAF не “на максимум”, а по критичности путей и профилю трафика — тогда защита не будет мешать бизнесу.