Cloudflare Workers: как не превратить serverless-логику в скрытую точку отказа

Workers удобны, когда нужно сдвинуть логику ближе к пользователю: редиректы, A/B-ветвления, авторизация, тонкая маршрутизация запросов. Но serverless на edge легко перегрузить лишними задачами. Если в одном скрипте смешаны кэш, API-агрегация и тяжёлая обработка, вы получаете не ускорение, а дорогую задержку и сложную отладку.

Правило первое: держите Worker коротким и детерминированным. Он должен быстро принять решение, а не выполнять бизнес-логику целиком. Вынесите долгие операции во внешние сервисы или очереди. Если запрос требует сетевых походов к нескольким API, проверьте, нельзя ли отдать часть ответа из кэша или precompute-слоя.

Правило второе: фиксируйте границы ответственности. Один Worker — одна задача: нормализация URL, защита от ботов, подмена заголовков, проксирование по правилам. Когда скрипт начинает «уметь всё», растут риски: сложнее ревью, выше шанс случайно сломать безопасность, труднее понять, где именно возникла ошибка ⚙️

Не забывайте про наблюдаемость. Логи должны показывать входные параметры, ветку решения и причину отказа, но без утечки секретов. Для критичных сценариев полезно отдельно тестировать поведение при таймаутах, пустых ответах и отказе внешнего API. Без этого serverless выглядит стабильным только на бумаге.

Стабильность инфраструктуры — залог масштабируемости: держите Workers простыми, измеряйте задержки и не переносите на edge то, что не обязано жить на edge.

TTL нельзя выбирать «на глаз»: сначала смотрим на профиль трафика и частоту изменений

Если кэш обновляется редко, а контент живёт долго, короткий TTL только увеличивает нагрузку на origin без заметной пользы. Если же на сайте часто меняются цены, остатки, персонализация или API-ответы, слишком длинный TTL быстро превращает CDN в источник устаревших данных.

Полезно разложить трафик по типам:
— статические ассеты: высокий TTL, агрессивный кэш;
— HTML-страницы: умеренный TTL и аккуратная инвалидация;
— API и динамика: либо минимальный TTL, либо bypass;
— редкие, но тяжёлые объекты: отдельные правила кэширования.
Смотрите не только на объём запросов, но и на churn: сколько объектов реально меняется за интервал. Это лучший индикатор того, где TTL надо сокращать, а где — наоборот увеличивать.

В метриках важны три сигнала: hit ratio, доля revalidate-запросов и время до устаревания данных на клиенте. Высокий hit ratio сам по себе не гарантирует качество: если пользователи получают старые ответы, бизнес-ошибка дороже экономии на origin.

Базовая стратегия проста: повышайте TTL там, где контент предсказуем, и снижайте там, где цена устаревания выше цены лишнего запроса. Оптимизация — это непрерывный процесс, а не разовая настройка.

Brotli и Minification ускоряют сайт только при правильной настройке, а не «по умолчанию»

Brotli даёт заметный выигрыш на текстовых ресурсах: HTML, CSS, JS, SVG, JSON. Но сжатие не должно ломать кэш и увеличивать CPU-нагрузку на origin. Если сервер уже отдаёт тяжёлый динамический ответ, агрессивное сжатие может съесть больше ресурсов, чем сэкономит на трафике.

Minification полезен там, где есть повторяющиеся символы и лишние пробелы. Но она не заменяет нормальную сборку фронтенда. Для продакшена важнее:
— не минифицировать уже сжатые или собранные файлы повторно;
— исключить бинарные и служебные форматы;
— проверить, что source map не уехали в публичную выдачу;
— не менять контент на лету так, чтобы ломались ETag и cache key.

В Cloudflare и на origin важно разделять задачи: сжатие — на уровне доставки, минификация — на уровне сборки или edge, но только для предсказуемых типов контента. Для API и часто меняющихся страниц выигрыш от minification обычно минимален, а риск побочных эффектов выше.

Проверяйте результат через размер ответа, время на origin и поведение кэша. Если после включения Brotli и Minification TTFB вырос или cache hit упал, значит оптимизация стала дороже самого трафика. Разбираем логи, оптимизируем кэширование, минимизируем задержки.

Anthropic обвинила DeepSeek, Moonlight и Alibaba в дистиляции

Статья о том, как китайские компании массово выкачивают ответы западных нейросеток, чтобы дообучать свои модели. Anthropic говорит о 24 000 фейковых аккаунтов и 16 млн запросов к Claude. Вывод простой: рынок ИИ входит в фазу жёсткого копирования, а китайские модели Qwen, Kimi и DeepSeek могут быстро догонять лидеров дешевле.

➡️ Читайте на сайте: https://aff.top/blog/anthropic-obvinila-deepseek-moonlight-i-alibaba-v-distiliacii

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

SSL/TLS режимы Cloudflare: где ломается доверие и как не открыть дыру

Выбор режима SSL/TLS — это не «галочка в панели», а решение о том, как Cloudflare будет доверять вашему origin и что увидит клиент на каждом участке цепочки.

— Flexible шифрует только до edge. До origin трафик идёт по HTTP, поэтому редиректы, cookies с Secure и логика приложений часто ведут себя непредсказуемо.
— Full включает HTTPS до origin, но не проверяет сертификат. Работает, пока на сервере нет самоподписанного сертификата или ошибки в имени хоста.
— Full (strict) требует валидный сертификат и совпадение имени. Это единственный режим, который одновременно снижает риск MITM и дисциплинирует конфигурацию.

Типовая ошибка — включить режим, не соответствующий реальной схеме. После этого появляются бесконечные редиректы, смешанный контент, проблемы с авторизацией и ложные срабатывания WAF. Для проверки достаточно пройти цепочку: клиент → Cloudflare → origin, отдельно смотреть схему, сертификат, SNI и правила перенаправления 🔒

Если нужен стабильный прод, цель одна: Full (strict) плюс корректный сертификат на origin и единая политика редиректов. Стабильность инфраструктуры — залог масштабируемости.

Page Rules и Cache Rules: как не сломать кэш и не открыть лишний доступ

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

Рабочая схема такая:
— сначала фиксируете, что должно кешироваться, а что нет;
— затем отдельно задаёте редиректы, bypass и исключения;
— не смешивайте политику безопасности и политику кэша в одном правиле.

Page Rules лучше оставлять для редких, узких сценариев: отдельный путь, старый URL, точечный redirect. Cache Rules подходят для массовой логики: тип контента, параметры строки, cookies, заголовки. Если одно и то же можно выразить в Cache Rules, не тащите это в Page Rules.

Проверяйте приоритеты и пересечения. Один неверный wildcard может перебить более точное правило, а «Cache Everything» без явного bypass для приватных страниц создаёт риск утечки контента через кэш. Безопасность и скорость: находим баланс в каждой конфигурации.

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

Тем временем подстилка коричневых Кардиналов и лично Кустова главред Максим Огненный завёл собственный канал, где, наверное, опять будет писать стихи и анонсировать вьюхи с ме**дроновыми наркоманами.🤡🤡

Чем вообще известен этот персонаж? Собсна, только порцией отборного кринжа, например, не так давно он выебывался на Иванова в "Письмах кардинала", но недожал и тема осталась нераскрытой. ЕЮ заслужил даже высокоинтеллектуальные выпады, которые тот не понял в силу врождённого аутизма:

Высокохудожественная лексика героя, демонстрируемая им не только на своем канале, но и на любой публичной площадке, настолько пленит любого слушателя, что мало кто может стать собеседником жертвы во второй раз.

Нихуя не разбираясь в аффилке, он на серьёзных щах брал интервью у Мефмедова и пытался построить серьёзный диалог с объёбанной ракетой. Из остальных достижений только нытье в чатиках: персонаж настолько невзрачный, что даже хуесосить его не так интересно.¯\_(ツ)_/¯

А теперь Огненный завёл собственный канал, где собрался выебать всех, но, походу, ебать будет лишь подписоту своей графоманией. Похожей хуйнёй занимался и оунер ФБ Киллы, который так любит рассуждать про экономику и политику. Оно и понятно: что у коричневых, что у киллы, что у партнёркина — один инвестор и одна крыша, поэтому подопечные синхронно занимаются бестолковой хуйнёй. Кому не похуй, подписывайтесь, будет интересно (нет): https://t.me/+dr240TeLtPc2Nzdk

В арбитраже деньги есть, но только у тех, кто с LuckyCards 💵

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

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

Проверьте три базовые вещи:
• Не кэшируйте ответы с персональными данными, токенами и зависимыми от сессии payload.
• Передавайте исходные заголовки авторизации без их переписывания на edge.
• Отдельно настройте правила для методов GET, POST, PUT и DELETE: для API они не равны по риску и поведению.

Отдельное внимание — rate limiting и WAF. Если шлюз уже считает квоты, не дублируйте логику на Cloudflare без понимания порядка срабатывания. Иначе получите ложные блокировки, сложную отладку и лишнюю нагрузку на поддержку. Для критичных маршрутов полезно включать логирование request ID на обеих сторонах, чтобы связать запрос на edge и в origin.

Хорошая схема здесь не «ускорить любой ценой», а чётко разделить статический контент, публичные методы и защищённые вызовы. Стабильность инфраструктуры — залог масштабируемости.

TTFB не лечат «ускорением CDN»: сначала находят, где теряется первая миллисекунда

TTFB — это не только скорость ответа origin. В цепочке участвуют DNS, TLS, кэш на edge, прокси-слой и сам бэкенд. Если мерить только среднее значение, вы пропустите деградацию на отдельных PoP, на конкретных маршрутах или под нагрузкой. Для бизнеса это прямой риск: страница «в целом открывается», но отдельные пользователи получают медленный первый байт и уходят раньше загрузки контента.

Что стоит мониторить постоянно:
• TTFB по географиям и ASN, а не одной цифрой по всему трафику.
• Разделение edge hit / miss: кэш может выглядеть здоровым, пока miss-цепочка уже тормозит.
• P95 и P99 вместо среднего: именно хвосты ломают UX и конверсию.
• Разницу между origin time, TLS handshake и waiting time в логах.

Если TTFB растёт только на miss, ищите узкое место в origin, БД или сетевом пути до backend. Если растёт и на hit, проверяйте edge-логи, правила Worker/Transform, лимиты на стороне приложений и лишние запросы к сторонним сервисам. Нельзя лечить задержку без разложения по этапам — это почти всегда приводит к ложным выводам и лишним изменениям в конфигурации.

Хорошая практика — собрать алерт не по абсолютному TTFB, а по отклонению от базовой линии для конкретного маршрута и типа контента. Так вы ловите регрессии раньше, чем их замечает пользователь. Стабильность инфраструктуры — залог масштабируемости.

Antropic раскрыла ферму с нейронными дейтинг-моделями

Anthropic раскрыла кейс китайской студии, которая запустила 20 дейтинг-приложений с нейропрофилями для удержания пользователей. Вместо стандартного слива дейтинг-трафика на чужие смартлинки, вебмастерам стоит присмотреться к разработке собственных LLM-сервисов. Затраты на токены и подключение платежных решений окупаются за счет прямого контроля над монетизацией и забора всей маржи рекламодателя.

➡️ Читайте на сайте: https://aff.top/blog/antropic-raskryla-fermu-s-neironnymi-deiting-modeliami

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