Решите, что должен доставлять CDN
Начните с инвентаризации. Разделите версионированные ресурсы — изображения, стили, скрипты, шрифты и загрузки — от HTML, API, страниц аккаунтов, оформления заказа и администрирования. CDN часто наполняют кэш по запросу: первый запрос может дойти до origin, а последующие совпадающие запросы будут обслуживаться на edge. Близость edge и попадание в кэш — разные преимущества.
Зафиксируйте хост, приложение, бакет хранения или балансировщик нагрузки, который отвечает за каждый путь; он должен отвечать при кэш-миссе.
Начните с ресурсов, одинаковых для всех посетителей, которые безопасно доступны до истечения их заявленного срока жизни.
Не шарьте персонализированные панели управления, страницы, привязанные к сессии, или данные клиентов, если только квалифицированный инженер не спроектировал и не протестировал разделение.
Установите политику кэша по поведению контента
HTTP-ответы выражают поведение кэша. Cache-Control определяет, можно ли хранить ответ и как долго он остаётся «свежим»; время жизни (TTL) — это период свежести. Браузер — это приватный кэш, тогда как CDN обычно является общим. Используйте явные заголовки. HTTP-стандарт позволяет задавать s-maxage для отдельного срока жизни для общих кэшей отдельно от max-age.
Публикуйте новый URL при изменении контента, например имя файла с хешем содержимого, и дайте неизменяемой версии долгий документированный срок жизни.
Выбирайте короткий срок жизни или поведение валидации, исходя из стоимости устаревшего контента; не применяйте правило для ресурсов к ценам, запасам или состоянию аккаунта.
Используйте private для ответов, предназначенных для одного пользователя. Сам по себе cookie не делает ответ безопасным для общего кэша.
Сделайте инвалидацию исключением, а не планом релиза
Инвалидация, или очистка (purge), инструктирует управляемый CDN удалить выбранные объекты из хранения до нормального истечения. Используйте её для исправлений, а не для каждого деплоя. Подтвердите, что origin уже возвращает замену перед очисткой; иначе refill может снова заполнить кэш плохим ответом. Браузерные кэши находятся вне контроля очистки CDN, поэтому версионирование URL остаётся надежным для изменяющихся файлов.
Предпочитайте конкретный путь, группу релизов или поддерживаемый провайдером тег кэша вместо очистки всего сайта; широкая очистка может внезапно нагрузить origin.
Распределённая очистка может достигать не всех edge одновременно. Проверьте семантику завершения у провайдера и протестируйте представительный URL.
Записывайте старый и новый URL, правило кэша, область очистки, ожидаемый результат и шаги отката.
Держите origin за слоем доставки
Прямой доступ к origin может обходить кэш CDN и элементы контроля на edge. Ограничьте его так, чтобы только CDN и преднамеренные пути могли до него добраться. В зависимости от стека используйте доступ к origin через облачный контролируемый доступ, правила файрвола с задокументированными диапазонами исходящего трафика CDN, частные сети, подписанные запросы к origin или взаимную TLS-аутентификацию (mTLS), где обе стороны аутентифицируют друг друга сертификатами.
Из авторизованного тестового местоположения подтвердите, что origin отвергает публичные запросы, в то время как CDN-хостнейм работает.
Ограничьте health checks, инструменты деплоя и внутренний доступ по идентификации и сети, а не широким публичным правилам.
Аутентификация origin различается у CDN и у origin-платформ. Используйте актуальные инструкции провайдера и проведите обзор безопасности.
Рассматривайте TLS как два соединения
HTTPS на edge защищает соединение посетитель→CDN, но соединение CDN→origin тоже нуждается в защите. Требуйте шифрования на обоих участках, валидируйте сертификат origin в выбранном режиме CDN и назначьте ответственность за hostname и продление сертификатов. OWASP рекомендует TLS 1.3 по умолчанию и допускает TLS 1.2 для совместимости; TLS 1.0 и 1.1 следует отключить. Для регламентированных данных, платежей или необычной совместимости клиентов получите квалифицированный обзор.
Перечислите владельцев сертификатов edge и origin, пути продления и поведение при сбое.
Протестируйте HTTP→HTTPS, канонический хост и глубокие редиректы на предмет циклов или потери путей.
Шифрование не делает ответ безопасным для кэширования; задавайте правила кэша отдельно для аутентифицированных, персональных и связанных с оплатой страниц.
Тестируйте реальный путь доставки до изменения трафика
Начните с hostname в staging или с узкого производственного пути, затем тестируйте CDN-хостнейм, а не только origin. Chrome DevTools Network показывает статус запроса, домен, тайминги, размер и заголовки. Выполните жёсткую перезагрузку с пустым кэшем, чтобы приблизить первый визит, затем повторный визит, чтобы проверить повторное использование. Сравнивайте ожидаемые заголовки и содержимое, а не только визуально более быструю страницу. Повторяйте тесты из репрезентативных регионов, если аудитория распределена географически.
Инспектируйте Cache-Control и провайдерские заголовки cache-status. Подтвердите повторное использование публичных ресурсов и отсутствие неожиданного шаринга для чувствительных страниц.
Пропустите сценарии miss, исправления устаревшего контента, ошибки origin и откат одного ресурса или маршрута до широкого запуска.
Сохраняйте протестированные URL, снимки заголовков, версию правил маршрута и метрики до и после вместе с записью изменения.
Выбирайте CDN по операционным потребностям, затем докажите это
Не выбирайте CDN только по числу точек присутствия или общей заявке о скорости. Производительность зависит от географии, времени, распределения трафика, маршрутизации и доли попаданий в кэш. Сравнивайте кандидатов по репрезентативным маршрутам, ресурсам и регионам. Спросите, поддерживает ли каждый нужные вам контролы кэша, целевую инвалидацию, ограничение origin, рабочий процесс сертификатов, логи, роли доступа, ценообразование, поддержку и процесс изменений.
Используйте идентичные заголовки кэша, поведение origin и страницы для кандидатов; фиксируйте результаты для первого визита и повторного визита отдельно.
Просмотрите расходы на запросы, передачу, инвалидацию, логирование и поддержку, плюс всплеск из-за кэш-миссов. Цены и контролы различаются по тарифам.
Требуйте экспортируемой конфигурации, принципа наименьших привилегий, протестированного отката и чёткой ответственности до покрытия критических маршрутов.