Azure Front Door часто задаваемые вопросы (вопросы и ответы)

В этой статье приведены ответы на наиболее часто задаваемые вопросы о возможностях и функциях Azure Front Door. Если вы не видите ответ на ваш вопрос, вы можете связаться с нами по следующим каналам (в порядке эскалации):

1. Раздел отзывов этой статьи.

2. Azure Front Door Отзывы.

3. служба поддержки Майкрософт: Чтобы создать новый запрос на поддержку, на портале Azure на вкладке Help нажмите кнопку Help + support и выберите запрос на поддержку .

Общая информация

Что такое Azure Front Door?

Azure Front Door — это облачная служба, которая обеспечивает более быструю и надежную работу приложений. Он использует балансировку нагрузки уровня 7 для распределения трафика между несколькими регионами и конечными точками. Он также предлагает динамическое ускорение сайта (DSA) для оптимизации производительности веба и почти в реальном времени аварийного переключения, чтобы обеспечить высокую доступность. Azure Front Door — это полностью управляемая служба, поэтому вам не нужно беспокоиться о масштабировании или обслуживании.

Какова разница между Azure Front Door и Шлюз приложений Azure?

Azure Front Door и Шлюз приложений Azure — это подсистемы балансировки нагрузки для трафика HTTP/HTTPS, но они имеют разные области. Front Door — это глобальная служба, которая может распределять запросы между регионами, а шлюз приложений — это региональная служба, которая может балансировать запросы в пределах региона. Azure Front Door работает с единицами масштабирования, кластерами или штампами, а Шлюз приложений Azure — с виртуальными машинами, контейнерами или другими ресурсами в той же единице масштабирования.

Какой тип ресурсов в настоящее время совместим с источником?

Для Azure Front Door можно использовать различные типы источников, например:

• Хранение (Azure Blob, классические, статические веб-сайты)
• Облачная служба
• Служба приложений
• Статическое веб-приложение
• Управление API
• Шлюз приложений
• Общедоступный IP-адрес
• Приложения Azure Spring
• Экземпляры контейнеров
• Приложения в контейнерах
• Любое пользовательское имя узла с общедоступным доступом.

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

В каких регионах можно развернуть службы Azure Front Door?

Azure Front Door не ограничивается ни одним регионом Azure, но работает глобально. Единственное место, которое вы выбираете при создании Парадной Двери, — это местоположение группы ресурсов, которая определяет, где хранятся метаданные группы ресурсов. Профиль Front Door — это глобальный ресурс, и его конфигурация распространяется на все пограничные узлы во всех регионах мира.

Каковы местоположения точек присутствия Azure Front Door?

Полный список точек присутствия (POP), обеспечивающих глобальную балансировку нагрузки и доставку содержимого для Azure Front Door, смотрите в разделе расположения POP Azure Front Door. Этот список регулярно обновляется по мере добавления или удаления новых узлов доступа. Api Azure Resource Manager можно также использовать для программного запроса текущего списка POP.

Как Azure Front Door выделяет свои ресурсы среди разных клиентов?

Azure Front Door — это служба, которая распределяет приложение глобально между несколькими регионами. Он использует общую инфраструктуру, которую используют все её клиенты, но вы можете настраивать свой профиль Front Door под конкретные требования приложения. Конфигурации других клиентов не могут повлиять на конфигурацию Front Door, которая изолирована от их.

Как Azure Front Door определяет порядок правил маршрутизации?

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

Какие шаги необходимо предпринять, чтобы ограничить доступ к серверной части только для Azure Front Door?

Чтобы обеспечить оптимальную работу функций Front Door, позволяйте только трафику, поступающему с Azure Front Door, достигать вашего исходного адреса. В результате несанкционированные или вредоносные запросы сталкиваются с политиками безопасности и маршрутизации Front Door, и доступ им запрещается. Чтобы узнать, как защитить источник, см. Защита трафика к источникам Azure Front Door.

Какое предполагаемое время развертывания Azure Front Door? Остается ли моя система Front Door работоспособной в процессе обновления?

Время распространения конфигурации после одной операции создания, обновления, удаления или WAF для профилей Azure Front Door и CDN может составлять до 15 минут в целях дополнительной безопасности. Одна операция очистки кэша завершается в течение 10 минут. Последовательные изменения могут увеличить общее время развертывания примерно до 30 минут. Каждое обновление конфигурации, включая корректировки набора правил, изменения маршрутизации, обновления исходной или доменной системы, а также модификации WAF, рассматривается как глобальная операция. Если вы выполняете дополнительные операции, пока первая операция продолжается (в течение ~15 минут), система ставит их в очередь и начинает только после завершения предыдущей операции. В этом случае первая операция завершается в течение первых 15 минут, а последующие изменения обрабатываются в следующем окне. Текущие улучшения платформы продолжаются, что приведет к дальнейшему сокращению этого времени.

Замечание

Обновления пользовательского TLS/SSL сертификата могут занять больше времени для глобального внедрения, до одного часа.

Отправка нескольких запросов на очистку

Каждый запрос очистки может содержать до 100 URL-адресов (сочетание домена и пути). Первая партия обрабатывается и вступает в действие примерно в течение 10 минут.

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

Пример: очистка 256 URL-адресов

1. Отправьте первые 100 URL-адресов в первоначальном запросе на очистку.
2. Подождите примерно 10 минут и убедитесь, что первая партия успешно выполнена.
3. Отправьте следующие 101-200 URL-адреса во втором запросе.
4. Подождите примерно 10 минут, чтобы завершить вторую партию.
5. Отправьте оставшиеся URL-адреса 201-256 в третьем запросе.

Обновления маршрутов или групп источников или внутренних пулов являются простыми и не вызывают простоя (если новая конфигурация правильна). Обновления сертификатов также выполняются атомарно, поэтому не возникает простоя.

Можно ли перемещать профили Front Door и CDN между группами ресурсов или подписками без простоя?

• Вы можете перемещать профили Front Door Standard/Premium и Azure CDN между группами ресурсов или подписками без простоев. Чтобы выполнить перемещение, следуйте этим инструкциям.
• Azure Front Door (classic) не поддерживает перемещение между группами ресурсов или подписками. Вместо этого вы можете перенести профиль Azure Front Door (классический) в Standard/Premium и затем выполнить переезд.
• Если вы связываете полис WAF с Azure Front Door Standard или Premium, операция по переезду проваливается. Сначала нужно отключить политику WAF, завершить переезд, а затем восстановить её.

Функции и протоколы

Какие функции поддерживаются Azure Front Door?

Azure Front Door предлагает множество преимуществ для ваших веб-приложений, таких как динамическое ускорение сайта (DSA), что повышает производительность и пользовательский опыт ваших сайтов. Azure Front Door также обеспечивает разгрузку TLS/SSL и сквозное TLS-шифрование, что повышает уровень безопасности и обеспечивает шифрование вашего веб-трафика. Кроме того, Azure Front Door предоставляет межсетевой экран веб-приложений, учет сессий на основе cookie, маршрутизацию по путям URL, бесплатные сертификаты, управление несколькими доменами и многое другое. Дополнительные сведения о функциях и возможностях Azure Front Door см. в статье tier comparison.

Какие протоколы поддерживаются Azure Front Door?

Azure Front Door поддерживает HTTP, HTTPS и HTTP/2.

Как Azure Front Door поддерживает HTTP/2?

Azure Front Door поддерживает протокол HTTP/2 для клиентских подключений. Однако связь пула бэкэнда использует протокол HTTP/1.1. Поддержка HTTP/2 включена по умолчанию.

Поддерживает ли Azure Front Door gRPC?

Нет. В настоящее время Azure Front Door поддерживает только HTTP/1.1 из края в источник. Для работы gRPC требуется HTTP/2.

Поддерживает ли Azure Front Door перенаправление HTTP в HTTPS?

Вы можете перенаправить компоненты хоста, путь и строку запроса URL-адреса с помощью Azure Front Door. Чтобы узнать, как настроить перенаправление URL, см. раздел URL redirect.

Предоставляет ли Front Door данные телеметрии, чтобы показать, какие правила обработчика правил обрабатываются для каждого запроса?

Да. Смотрите свойство MatchedRulesSetName в разделе Журналы доступа.

Может ли Front Door обеспечить защиту от атак DDoS «HTTP/2 Rapid Reset»?

Да. Дополнительные сведения см. в статье ответ компании Microsoft на атаки DDoS на HTTP/2.

Можно ли заставить трафик из одной страны или региона использовать определенную Azure Front Door POP в другой стране или регионе?

Нет. Azure Front Door не удается принудительно заставить трафик клиента к определенному протоколу POP. Запросы направляются в ближайшее доступное пограничное расположение для повышения производительности и надежности. Если вам нужно ограничить доступ по географическому региону, используйте настраиваемые правила Брандмауэр веб-приложений Azure (WAF) с условиями GeoMatch. Этот подход позволяет или блокирует запросы на основе страны или региона клиента, но он не перенаправляет этих клиентов в другую точку присутствия в другой стране или регионе. Например, если вы блокируете страну или регион А, запросы от клиентов в стране или регионе A блокируются независимо от того, какой pop-адрес служил бы им. Дополнительные сведения см. в разделе Geo-filtering in Azure WAF for Azure Front Door.

Сохраняет ли Azure Front Door заголовки X-Forwarded-For?

Azure Front Door поддерживает заголовки X-Forwarded-For, X-Forwarded-Host и X-Forwarded-Proto. Эти заголовки помогают Front Door определить исходный IP-адрес клиента и протокол. Если X-Forwarded-For уже присутствует, Front Door добавляет IP-адрес сокета клиента в конец списка IP-адресов. В противном случае он создает заголовок, указывая IP-адрес сокета клиента в качестве значения. Для X-Forwarded-Host и X-Forwarded-Proto Front Door заменяет существующие значения собственными.

Для получения дополнительной информации см. поддерживаемые заголовки HTTP для Front Door.

Есть ли Azure Front Door возможность балансировки нагрузки или маршрутизации трафика в виртуальной сети?

Чтобы использовать Azure Front Door Standard или Azure Front Door (классика), вам нужен публичный IP-адрес или общедоступное DNS-имя. Это требование позволяет Azure Front Door направлять трафик на ваши бэкенд-ресурсы. Вы можете использовать Azure ресурсы, такие как шлюзы приложений или Azure Load Balancers, для маршрутизации трафика к ресурсам в виртуальной сети. Если вы используете Azure Front Door Premium, вы можете использовать Приватный канал для подключения к источникам за внутренним балансировщиком нагрузки через частную конечную точку. Дополнительные сведения см. в разделе Secure origins with Приватный канал.

Можно ли использовать Приватный канал для подключения Azure Front Door к Azure Key Vault?

Нет. Для безопасности Azure Front Door поддерживает только проверку подлинности на основе управляемых удостоверений при доступе к сертификатам в Key Vault. Дополнительные сведения см. в разделе Использование управляемых удостоверений в Azure Front Door.

Поддерживает ли Azure Front Door управляемое удостоверение с Центры событий Azure?

Нет. Azure Front Door в настоящее время не поддерживает интеграцию управляемых удостоверений с Центры событий Azure.

Поддерживает ли Azure Front Door настраиваемые страницы ошибок?

Нет. Azure Front Door в настоящее время не поддерживает пользовательские страницы ошибок.

Развертывание "Front Door" с другими службами

Когда следует развернуть шлюз приложений за «Front Door»?

Шлюз приложений за Front Door полезен в следующих ситуациях:

• Вы хотите сбалансировать трафик не только глобально, но и в виртуальной сети. Front Door может выполнять балансировку нагрузки только на основе путей на глобальном уровне, но Application Gateway может делать это в вашей виртуальной сети.
• Требуется дренаж подключений, которую не поддерживает Front Door. Шлюз приложений может включить очистку подключений для виртуальных машин или контейнеров.
• Вы хотите выгрузить всю обработку TLS/SSL и использовать только HTTP-запросы в виртуальной сети. Шлюз приложений за Front Door может обеспечить эту настройку.
• Вы хотите использовать сходство сеансов как на региональном, так и на уровне сервера. Front Door может направлять трафик из сеанса пользователя к той же серверной части в регионе, но шлюз приложений может направлять его непосредственно на тот же сервер в этой серверной части.

Можно ли развернуть другую сеть CDN от стороннего поставщика перед Front Door или за ним?

Использование двух CDN в цепочке обычно не рекомендуется. Хотя это может работать, у него есть следующие недостатки:

1. Ускорение последней мили в CDN работает за счёт поддержания соединения с сервером-источником и выбора оптимального пути к источнику для достижения наилучших результатов. Соединение двух CDN обычно сводит на нет некоторые преимущества ускорения последней мили.
2. Контроль безопасности менее эффективен на втором CDN. Контроль доступа по IP-адресу клиента там не работает, потому что второй CDN идентифицирует выходной узел первого CDN как клиентский IP. Полезная нагрузка содержимого всё ещё проверяется.
3. Цепочка двух CDN усложняет диагностику. Когда возникает проблема, бывает сложно определить, какой именно CDN её вызывает.

Можно ли развернуть Azure Load Balancer за Front Door?

Чтобы использовать Azure Front Door, необходимо иметь публичный виртуальный IP-адрес или общедоступное DNS-имя. Azure Front Door использует общедоступный IP-адрес для маршрутизации трафика в источник. Распространенный сценарий — развертывание Azure Load Balancer за Front Door. Вы также можете использовать Приватный канал с Azure Front Door Premium для подключения к внутренней подсистеме балансировки нагрузки. Для получения дополнительной информации см. раздел включение Приватный канал с внутренней подсистемой балансировки нагрузки.

Можно ли настроить Azure CDN через профиль или конечную точку Front Door, или наоборот?

Azure Front Door и Azure CDN — это две службы, обеспечивающие быструю и надежную веб-доставку для приложений. Однако они не совместимы друг с другом, так как они используют ту же сеть граничных узлов Azure для доставки содержимого пользователям. Эта общая сеть приводит к конфликтам между политиками маршрутизации и кэширования. Поэтому необходимо выбрать Azure Front Door или Azure CDN для приложения в зависимости от требований к производительности и безопасности.

Можно ли настроить профиль или конечную точку Azure Front Door за другим профилем или конечной точкой Front Door или наоборот?

Тот факт, что оба профиля и конечные точки используют один и тот же пограничный POP-узел Azure для обработки входящих запросов, приводит к ограничению, из-за которого невозможно разместить один профиль или конечную точку Azure Front Door за другим(-ой). Эта настройка приведет к возникновению конфликтов маршрутизации и проблем с производительностью. Поэтому, если вам нужно использовать несколько профилей/конечных точек для ваших приложений, убедитесь, что ваши профили/эндпоинты Azure Front Door не связаны между собой.

IP-адреса Front Door и служебные теги

Какой метод разрешения имен и маршрутизации используется Azure Front Door?

Azure Front Door использует уникаст-маршрутизацию для разрешения имён и направляет запросы в оптимальную точку присутствия (POP). Unicast заменил метод маршрутизации Anycast, который ранее использовал Azure Front Door.

Как Azure Front Door использует маршрутизацию одноадресной рассылки?

Запрос разрешения имен для источника, находящегося за Azure Front Door, попадает на конечную точку диспетчера трафика Azure Front Door. Профили диспетчера трафика Front Door используют множество сигналов о работоспособности и доступности от поставщиков по всему миру. На основе этих сигналов возвращается юникаст IP-адрес оптимального узла Front Door PoP. Затем запрос отправляется непосредственно на возвращаемый IP-адрес, который следует архитектуре маршрутизации Front Door, чтобы затем ответ вернулся пользователю или приложению.

Каковы теги сетевой службы, поддерживаемые Front Door?

Azure Front Door использует три тега службы для управления трафиком между клиентами и источниками:

• Тег службы AzureFrontDoor.Backend содержит IP-адреса, которые Front Door использует для доступа к вашим оригин. Этот тег службы можно применить при настройке безопасности для источников.
• Тег службы AzureFrontDoor.Frontend содержит IP-адреса, используемые клиентами для доступа к Front Door. Вы можете применить тег службы AzureFrontDoor.Frontend, если вы хотите контролировать исходящий трафик, который может подключаться к службам за Azure Front Door.
• Тег службы AzureFrontDoor.FirstParty зарезервирован для группы службы Майкрософт, размещенной на Azure Front Door.

Дополнительные сведения о сценариях тегов служб Azure Front Door см. в разделе доступные теги служб. Чтобы оставаться в курсе и принимать соответствующие меры во время любых изменений в IP-адресах, разработайте автоматизацию, чтобы регулярно получать последние IP-адреса с помощью API обнаружения тегов службы или JSON-файла.

Конфигурация

Каковы рекомендации по созданию источников и групп источников для Azure Front Door?

Группа источников — это коллекция источников, которые могут обрабатывать аналогичные типы запросов. Вам нужна другая группа источников для каждого приложения или рабочей нагрузки, которая отличается.

В группе источников создается источник для каждого сервера или службы, которые могут обслуживать запросы. Если у источника есть подсистема балансировки нагрузки, например Шлюз приложений Azure, или размещена в PaaS с подсистемой балансировки нагрузки, то группа источников имеет только один источник. Источник управляет обработкой отказа и балансировкой нагрузки между источниками, которые не видит Front Door.

Например, если вы размещаете приложение в Служба приложений Azure, настройка Front Door зависит от количества экземпляров приложения:

• Развертывание в одном регионе: создайте одну группу источников. В этой группе источников создайте один источник для приложения App Service. Приложение службы приложений может масштабироваться между рабочими ролей, но Front Door видит один источник.
• Многорегионное активное/пассивное развертывание: создайте одну группу источников. В этой группе источников сделайте источник для каждого приложения службы приложений. Задайте приоритет каждого источника таким образом, чтобы основное приложение имеет более высокий приоритет, чем приложение резервного копирования.
• Многорегионное активное/активное развертывание: создайте одну группу источников. В этой группе источников сделайте источник для каждого приложения службы приложений. Задайте приоритет каждого источника таким же. Задайте вес каждого источника, чтобы контролировать количество запросов, которые отправляются в этот источник.

Дополнительные сведения см. в разделе Origins и группы источников в Azure Front Door.

Каковы значения по умолчанию и максимальные значения времени ожидания и ограничений Azure Front Door?

Azure Front Door — это служба, которая обеспечивает быструю и надежную веб-доставку для приложений. Она предлагает такие функции, как кэширование, балансировка нагрузки, безопасность и маршрутизация. Однако необходимо учитывать некоторые ограничения времени ожидания и ограничения, которые применяются к Azure Front Door. Эти интервалы времени ожидания и ограничения включают максимальный размер запроса, максимальный размер ответа, максимальный размер заголовка, максимальное число заголовков, максимальное число правил и максимальное число групп источников. Подробные сведения об этих тайм-аутах и ограничениях см. в документации Azure Front Door.

Сколько времени требуется Azure Front Door, чтобы применить новое правило, добавленное в механизм правил Front Door?

Большинство наборов правил обновляют свои конфигурации менее чем за 15 минут. Правило вступает в силу сразу после завершения обновления.

Каково значение тайм-аута для заголовка от клиента к Azure Front Door?

Azure Front Door имеет 5-секундный тайм-аут для получения заголовков от клиента. Если клиент не отправляет заголовки в течение 5 секунд после установления TCP/TLS-соединения с Azure Front Door, соединение прекращается. Вы не можете настроить этот тайм-аут.

Каково значение таймаута HTTP keep-alive для Azure Front Door?

Azure Front Door имеет 90-секундное время ожидания HTTP в режиме поддержания соединения. Подключение завершается, если клиент не отправляет данные в течение 90 секунд, что является временем ожидания по протоколу HTTP для Azure Front Door. Вы не можете настроить это значение времени ожидания.

Можно ли использовать один и тот же домен для двух разных конечных точек Front Door?

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

Можно ли перенести домен из одной конечной точки Front Door в другую конечную точку Front Door без простоя?

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

Интеграция Azure Front Door с Приватный канал не поддерживается в регионе, в котором расположен мой источник. Что мне делать?

Azure Front Door Приватный канал не зависит от региона. Чтобы обеспечить минимальную задержку, при включении конечной точки Приватный канал для Azure Front Door выберите поддерживаемый регион Azure, ближайший к источнику. Если регион вашего источника не поддерживается в списке регионов, которые поддерживает Front Door Приватный канал, выберите следующий ближайший регион. Трафик передается от клиента к конечной точке Azure Front Door Приватный канал в поддерживаемом регионе, а затем проходит через магистральную сеть Microsoft к вашему источнику, поддерживая частное подключение. Эта конфигурация добавляет дополнительную задержку из-за дополнительного перехода между регионами. Вы можете использовать статистику задержки туда и обратно в сети Azure, чтобы определить дополнительную задержку при выборе ближайшего региона. Когда поддерживается новый регион, вы можете следовать этим инструкциям , чтобы постепенно перенаправлять трафик в новый регион.

Производительность

Как Azure Front Door обеспечивает высокую доступность и масштабируемость для своих служб?

Azure Front Door — это платформа, которая распределяет трафик по всему миру и может масштабироваться в соответствии с требованиями вашего приложения. Он использует глобальную edge-сеть Microsoft для обеспечения глобального балансировки нагрузки, что позволяет переместить всё приложение или конкретные микросервисы в другие регионы или облака в случае сбоя.

Каковы условия кэширования диапазонных ответов из моего источника?

Чтобы избежать ошибок при доставке больших файлов, убедитесь, что исходный сервер включает заголовок Content-Range в ответ, а значение заголовка соответствует фактическому размеру тела ответа.

Дополнительные сведения о настройке источника и Front Door для доставки больших файлов можно найти в доставке больших файлов.

Конфигурация протокола TLS

Как Azure Front Door блокирует маскировку домена?

Маскировка домена — это сетевой метод, позволяющий злоумышленнику скрыть фактическое назначение вредоносного запроса с помощью другого доменного имени в рукопожатии TLS и заголовке host HTTP.

Azure Front Door (стандартный, премиум и классический уровень) или Azure CDN Standard от ресурсов Microsoft (classic), созданные после 8 ноября 2022 года, имеют включённую блокировку доменного фронтинга. Вместо того чтобы блокировать запрос с несовпадающими заголовками SNI и хоста, мы допускаем такое несоответствие, если оба домена принадлежат одной подписке и включены в маршруты или правила маршрутизации. Применение блокировки подмены домена началось 22 января 2024 года.

Если Front Door блокирует запрос из-за несоответствия:

• Клиент получает ответ кода ошибки HTTP 421 Misdirected Request .
• Azure Front Door записывает блок в журналы диагностики в Error Info со значением SSLMismatchedSNI.

Для получения дополнительной информации о доменной подмене см. раздел Обеспечение безопасности нашего подхода к доменной подмене в Azure и Запрет на доменную подмену в Azure Front Door и Azure CDN Standard от Microsoft (классической).

Какие версии TLS поддерживаются с Azure Front Door?

Front Door использует TLS 1.2 в качестве минимальной версии для всех профилей, созданных после сентября 2019 года.

Вы можете использовать TLS 1.2 или 1.3 с Azure Front Door. Для получения дополнительной информации прочитайте статью Конечное шифрование TLS в Azure Front Door.

Управление сертификатами и устаревание процесса DCV от DigiCert

Что происходит с рабочим процессом CNAME Делегирования DCV в DigiCert?

С 15 августа 2025 г. DigiCert перешли на новую платформу проверки контроля домена с открытым исходным кодом (OSS), предназначенную для повышения прозрачности и подотчетности в процессах проверки домена. DigiCert больше не поддерживает устаревший рабочий процесс CNAME Delegation DCV для проверки контроля домена в указанных сервисах Azure. Подробнее

Какие уровни Azure Front Door будут затронуты этим изменением?

Устаревание влияет на службы, использующие проверку на основе CNAME для автоматической выдачи и продления сертификатов, в том числе:

• Azure Front Door (классическая версия)
• Azure CDN из Microsoft (классическая версия)

Каково текущее состояние?

Azure Front Door (классическая) и Azure CDN из Microsoft (классическая):

• С 15 августа 2025 года больше не поддерживается новый онбординг доменов, создание новых профилей или управляемые сертификаты Azure.
• С 14 апреля 2026 г. существующие управляемые сертификаты удаляются. Все существующие управляемые сертификаты либо мигрируются клиентом или командой AFD на стандарт Azure Front Door или премиум. Используйте Azure Front Door уровня "Стандартный" или "Премиум" для управляемого сертификата.

Нужно ли выполнить какие-либо действия, чтобы обновить управляемый сертификат после миграции?

В большинстве случаев никаких действий не требуется. После миграции вашего профиля Azure Front Door автоматически пытается обновить управляемый сертификат, если до истечения срока его действия остается менее 45 дней.

• Если ваш домен сопоставлен с CNAME на Azure Front Door и соответствует требованиям CAA к записям и состоянию домена, сертификат автоматически вращается. Автоматическая ротация выполняется каждые 6–8 часов и занимает примерно 24–48 часов. Если автоматическое вращение не удаётся, состояние валидации домена меняется на «Ожидает валидации», и вы можете повторно проверить владение доменом, чтобы вручную запустить проверку.
• Если ваш домен не соответствует этим требованиям или HTTPS отключён, состояние сертификата меняется на ожидающее повторное подтверждение, и вам необходимо повторно проверить право собственности на домен.

Чтобы продлить сертификат без ожидания автоматического вращения, вручную перепроверьте право собственности на домен, используя один из следующих методов:

• Добавление требуемой записи проверки DNS на шаге 3 для доменов, ожидающих проверки
• Запуск проверки вручную с помощью PowerShell или Azure CLI (RefreshValidation).

Выставление счетов

Взимается ли плата за отключенные ресурсы Azure Front Door?

Вы не можете отключить ресурсы Azure Front Door. Вы можете только их удалить. Плата за переменные тарифные показатели, такие как исходящая передача данных, входящая передача данных и запросы, не взимается при отсутствии трафика, однако базовая плата взимается даже при его отсутствии. Базовая плата взимается до удаления профиля. Для Azure Front Door (классический) плата за политики и правила WAF взимается независимо от их статуса. Даже если вы отключите политику или правило WAF, это все равно будет стоить вам денег.

Кэширование

Можно ли использовать заголовок HTTP-запроса в качестве ключа кэша?

Нет.

Поддерживает ли Front Door ETag?

Нет.

Можно ли поддерживать сжатие для размеров файлов выше 8 МБ?

Front Door не поддерживает динамическое сжатие для контента объемом более 8 МБ. Однако если источник уже сжимает контент, Front Door поддерживает отдачу статического сжатого контента размером свыше 8 МБ, если поддерживаются диапазонные запросы и не включена передача с использованием chunked encoding.

Поддерживает ли Front Door установку заголовка авторизации в HTTP-запросе, если включено кэширование?

Нет.

Диагностика и ведение журнала

Какие метрики и журналы предоставляет Azure Front Door?

Сведения о журналах и других возможностях диагностики см. в разделе "Метрики мониторинга" и журналы для Front Door.

Как долго я могу хранить диагностические журналы?

Журналы диагностики можно хранить в собственной учетной записи хранения и выбрать срок их хранения. В качестве альтернативы можно отправлять диагностические журналы в Event Hubs или в журналы Azure Monitor. Дополнительные сведения см. в разделе диагностика Azure Front Door.

Какие шаги по доступу к журналам аудита для Azure Front Door?

Чтобы получить доступ к журналам аудита Azure Front Door, необходимо посетить портал. Выберите пункт «Входная дверь» на странице меню и выберите Журнал активности. Журнал активности предоставляет вам записи операций вашего Azure Front Door.

Как настроить оповещения для Azure Front Door?

Оповещения можно настроить для Azure Front Door на основе метрик или журналов. Таким образом, вы можете отслеживать производительность и работоспособность фронтальных хостов.

Сведения о создании оповещений для Azure Front Door категории "Стандартный" и "Премиум", см. в статье настройка оповещений.

Связанный контент

• Создание профиля Azure Front Door
• Архитектура маршрутизации Azure Front Door

В этой статье приведены ответы на наиболее часто задаваемые вопросы о возможностях и функциях Azure Front Door. Если вы не видите ответ на ваш вопрос, вы можете связаться с нами по следующим каналам (в порядке эскалации):

1. Раздел отзывов этой статьи.

2. Azure Front Door Отзывы.

3. служба поддержки Майкрософт: Чтобы создать новый запрос на поддержку, на портале Azure на вкладке Help нажмите кнопку Help + support и выберите запрос на поддержку .

Azure Front Door — это облачная служба, которая обеспечивает более быструю и надежную работу приложений. Он использует балансировку нагрузки уровня 7 для распределения трафика между несколькими регионами и конечными точками. Он также предлагает динамическое ускорение сайта (DSA) для оптимизации производительности веба и почти в реальном времени аварийного переключения, чтобы обеспечить высокую доступность. Azure Front Door — это полностью управляемая служба, поэтому вам не нужно беспокоиться о масштабировании или обслуживании.

Azure Front Door и Шлюз приложений Azure — это подсистемы балансировки нагрузки для трафика HTTP/HTTPS, но они имеют разные области. Front Door — это глобальная служба, которая может распределять запросы между регионами, а шлюз приложений — это региональная служба, которая может балансировать запросы в пределах региона. Azure Front Door работает с единицами масштабирования, кластерами или штампами, а Шлюз приложений Azure — с виртуальными машинами, контейнерами или другими ресурсами в той же единице масштабирования.

Для Azure Front Door можно использовать различные типы источников, например:

• Хранение (Azure Blob, классические, статические веб-сайты)
• Облачная служба
• Служба приложений
• Статическое веб-приложение
• Управление API
• Шлюз приложений
• Общедоступный IP-адрес
• Приложения Azure Spring
• Экземпляры контейнеров
• Приложения в контейнерах
• Любое пользовательское имя узла с общедоступным доступом.

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

Azure Front Door не ограничивается ни одним регионом Azure, но работает глобально. Единственное место, которое вы выбираете при создании Парадной Двери, — это местоположение группы ресурсов, которая определяет, где хранятся метаданные группы ресурсов. Профиль Front Door — это глобальный ресурс, и его конфигурация распространяется на все пограничные узлы во всех регионах мира.

Полный список точек присутствия (POP), обеспечивающих глобальную балансировку нагрузки и доставку содержимого для Azure Front Door, смотрите в разделе расположения POP Azure Front Door. Этот список регулярно обновляется по мере добавления или удаления новых узлов доступа. Api Azure Resource Manager можно также использовать для программного запроса текущего списка POP.

Azure Front Door — это служба, которая распределяет приложение глобально между несколькими регионами. Он использует общую инфраструктуру, которую используют все её клиенты, но вы можете настраивать свой профиль Front Door под конкретные требования приложения. Конфигурации других клиентов не могут повлиять на конфигурацию Front Door, которая изолирована от их.

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

Чтобы обеспечить оптимальную работу функций Front Door, позволяйте только трафику, поступающему с Azure Front Door, достигать вашего исходного адреса. В результате несанкционированные или вредоносные запросы сталкиваются с политиками безопасности и маршрутизации Front Door, и доступ им запрещается. Чтобы узнать, как защитить источник, см. Защита трафика к источникам Azure Front Door.

Время распространения конфигурации после одной операции создания, обновления, удаления или WAF для профилей Azure Front Door и CDN может составлять до 15 минут в целях дополнительной безопасности. Одна операция очистки кэша завершается в течение 10 минут. Последовательные изменения могут увеличить общее время развертывания примерно до 30 минут. Каждое обновление конфигурации, включая корректировки набора правил, изменения маршрутизации, обновления исходной или доменной системы, а также модификации WAF, рассматривается как глобальная операция. Если вы выполняете дополнительные операции, пока первая операция продолжается (в течение ~15 минут), система ставит их в очередь и начинает только после завершения предыдущей операции. В этом случае первая операция завершается в течение первых 15 минут, а последующие изменения обрабатываются в следующем окне. Текущие улучшения платформы продолжаются, что приведет к дальнейшему сокращению этого времени.

Замечание

Обновления пользовательского TLS/SSL сертификата могут занять больше времени для глобального внедрения, до одного часа.

Отправка нескольких запросов на очистку

Каждый запрос очистки может содержать до 100 URL-адресов (сочетание домена и пути). Первая партия обрабатывается и вступает в действие примерно в течение 10 минут.

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

Пример: очистка 256 URL-адресов

1. Отправьте первые 100 URL-адресов в первоначальном запросе на очистку.
2. Подождите примерно 10 минут и убедитесь, что первая партия успешно выполнена.
3. Отправьте следующие 101-200 URL-адреса во втором запросе.
4. Подождите примерно 10 минут, чтобы завершить вторую партию.
5. Отправьте оставшиеся URL-адреса 201-256 в третьем запросе.

Обновления маршрутов или групп источников или внутренних пулов являются простыми и не вызывают простоя (если новая конфигурация правильна). Обновления сертификатов также выполняются атомарно, поэтому не возникает простоя.

• Вы можете перемещать профили Front Door Standard/Premium и Azure CDN между группами ресурсов или подписками без простоев. Чтобы выполнить перемещение, следуйте этим инструкциям.
• Azure Front Door (classic) не поддерживает перемещение между группами ресурсов или подписками. Вместо этого вы можете перенести профиль Azure Front Door (классический) в Standard/Premium и затем выполнить переезд.
• Если вы связываете полис WAF с Azure Front Door Standard или Premium, операция по переезду проваливается. Сначала нужно отключить политику WAF, завершить переезд, а затем восстановить её.

Azure Front Door предлагает множество преимуществ для ваших веб-приложений, таких как динамическое ускорение сайта (DSA), что повышает производительность и пользовательский опыт ваших сайтов. Azure Front Door также обеспечивает разгрузку TLS/SSL и сквозное TLS-шифрование, что повышает уровень безопасности и обеспечивает шифрование вашего веб-трафика. Кроме того, Azure Front Door предоставляет межсетевой экран веб-приложений, учет сессий на основе cookie, маршрутизацию по путям URL, бесплатные сертификаты, управление несколькими доменами и многое другое. Дополнительные сведения о функциях и возможностях Azure Front Door см. в статье tier comparison.

Azure Front Door поддерживает HTTP, HTTPS и HTTP/2.

Azure Front Door поддерживает протокол HTTP/2 для клиентских подключений. Однако связь пула бэкэнда использует протокол HTTP/1.1. Поддержка HTTP/2 включена по умолчанию.

Нет. В настоящее время Azure Front Door поддерживает только HTTP/1.1 из края в источник. Для работы gRPC требуется HTTP/2.

Вы можете перенаправить компоненты хоста, путь и строку запроса URL-адреса с помощью Azure Front Door. Чтобы узнать, как настроить перенаправление URL, см. раздел URL redirect.

Да. Смотрите свойство MatchedRulesSetName в разделе Журналы доступа.

Да. Дополнительные сведения см. в статье ответ компании Microsoft на атаки DDoS на HTTP/2.

Нет. Azure Front Door не удается принудительно заставить трафик клиента к определенному протоколу POP. Запросы направляются в ближайшее доступное пограничное расположение для повышения производительности и надежности. Если вам нужно ограничить доступ по географическому региону, используйте настраиваемые правила Брандмауэр веб-приложений Azure (WAF) с условиями GeoMatch. Этот подход позволяет или блокирует запросы на основе страны или региона клиента, но он не перенаправляет этих клиентов в другую точку присутствия в другой стране или регионе. Например, если вы блокируете страну или регион А, запросы от клиентов в стране или регионе A блокируются независимо от того, какой pop-адрес служил бы им. Дополнительные сведения см. в разделе Geo-filtering in Azure WAF for Azure Front Door.

Azure Front Door поддерживает заголовки X-Forwarded-For, X-Forwarded-Host и X-Forwarded-Proto. Эти заголовки помогают Front Door определить исходный IP-адрес клиента и протокол. Если X-Forwarded-For уже присутствует, Front Door добавляет IP-адрес сокета клиента в конец списка IP-адресов. В противном случае он создает заголовок, указывая IP-адрес сокета клиента в качестве значения. Для X-Forwarded-Host и X-Forwarded-Proto Front Door заменяет существующие значения собственными.

Для получения дополнительной информации см. поддерживаемые заголовки HTTP для Front Door.

Чтобы использовать Azure Front Door Standard или Azure Front Door (классика), вам нужен публичный IP-адрес или общедоступное DNS-имя. Это требование позволяет Azure Front Door направлять трафик на ваши бэкенд-ресурсы. Вы можете использовать Azure ресурсы, такие как шлюзы приложений или Azure Load Balancers, для маршрутизации трафика к ресурсам в виртуальной сети. Если вы используете Azure Front Door Premium, вы можете использовать Приватный канал для подключения к источникам за внутренним балансировщиком нагрузки через частную конечную точку. Дополнительные сведения см. в разделе Secure origins with Приватный канал.

Нет. Для безопасности Azure Front Door поддерживает только проверку подлинности на основе управляемых удостоверений при доступе к сертификатам в Key Vault. Дополнительные сведения см. в разделе Использование управляемых удостоверений в Azure Front Door.

Нет. Azure Front Door в настоящее время не поддерживает интеграцию управляемых удостоверений с Центры событий Azure.

Нет. Azure Front Door в настоящее время не поддерживает пользовательские страницы ошибок.

Шлюз приложений за Front Door полезен в следующих ситуациях:

• Вы хотите сбалансировать трафик не только глобально, но и в виртуальной сети. Front Door может выполнять балансировку нагрузки только на основе путей на глобальном уровне, но Application Gateway может делать это в вашей виртуальной сети.
• Требуется дренаж подключений, которую не поддерживает Front Door. Шлюз приложений может включить очистку подключений для виртуальных машин или контейнеров.
• Вы хотите выгрузить всю обработку TLS/SSL и использовать только HTTP-запросы в виртуальной сети. Шлюз приложений за Front Door может обеспечить эту настройку.
• Вы хотите использовать сходство сеансов как на региональном, так и на уровне сервера. Front Door может направлять трафик из сеанса пользователя к той же серверной части в регионе, но шлюз приложений может направлять его непосредственно на тот же сервер в этой серверной части.

Использование двух CDN в цепочке обычно не рекомендуется. Хотя это может работать, у него есть следующие недостатки:

1. Ускорение последней мили в CDN работает за счёт поддержания соединения с сервером-источником и выбора оптимального пути к источнику для достижения наилучших результатов. Соединение двух CDN обычно сводит на нет некоторые преимущества ускорения последней мили.
2. Контроль безопасности менее эффективен на втором CDN. Контроль доступа по IP-адресу клиента там не работает, потому что второй CDN идентифицирует выходной узел первого CDN как клиентский IP. Полезная нагрузка содержимого всё ещё проверяется.
3. Цепочка двух CDN усложняет диагностику. Когда возникает проблема, бывает сложно определить, какой именно CDN её вызывает.

Чтобы использовать Azure Front Door, необходимо иметь публичный виртуальный IP-адрес или общедоступное DNS-имя. Azure Front Door использует общедоступный IP-адрес для маршрутизации трафика в источник. Распространенный сценарий — развертывание Azure Load Balancer за Front Door. Вы также можете использовать Приватный канал с Azure Front Door Premium для подключения к внутренней подсистеме балансировки нагрузки. Для получения дополнительной информации см. раздел включение Приватный канал с внутренней подсистемой балансировки нагрузки.

Azure Front Door и Azure CDN — это две службы, обеспечивающие быструю и надежную веб-доставку для приложений. Однако они не совместимы друг с другом, так как они используют ту же сеть граничных узлов Azure для доставки содержимого пользователям. Эта общая сеть приводит к конфликтам между политиками маршрутизации и кэширования. Поэтому необходимо выбрать Azure Front Door или Azure CDN для приложения в зависимости от требований к производительности и безопасности.

Тот факт, что оба профиля и конечные точки используют один и тот же пограничный POP-узел Azure для обработки входящих запросов, приводит к ограничению, из-за которого невозможно разместить один профиль или конечную точку Azure Front Door за другим(-ой). Эта настройка приведет к возникновению конфликтов маршрутизации и проблем с производительностью. Поэтому, если вам нужно использовать несколько профилей/конечных точек для ваших приложений, убедитесь, что ваши профили/эндпоинты Azure Front Door не связаны между собой.

Azure Front Door использует уникаст-маршрутизацию для разрешения имён и направляет запросы в оптимальную точку присутствия (POP). Unicast заменил метод маршрутизации Anycast, который ранее использовал Azure Front Door.

Запрос разрешения имен для источника, находящегося за Azure Front Door, попадает на конечную точку диспетчера трафика Azure Front Door. Профили диспетчера трафика Front Door используют множество сигналов о работоспособности и доступности от поставщиков по всему миру. На основе этих сигналов возвращается юникаст IP-адрес оптимального узла Front Door PoP. Затем запрос отправляется непосредственно на возвращаемый IP-адрес, который следует архитектуре маршрутизации Front Door, чтобы затем ответ вернулся пользователю или приложению.

Azure Front Door использует три тега службы для управления трафиком между клиентами и источниками:

• Тег службы AzureFrontDoor.Backend содержит IP-адреса, которые Front Door использует для доступа к вашим оригин. Этот тег службы можно применить при настройке безопасности для источников.
• Тег службы AzureFrontDoor.Frontend содержит IP-адреса, используемые клиентами для доступа к Front Door. Вы можете применить тег службы AzureFrontDoor.Frontend, если вы хотите контролировать исходящий трафик, который может подключаться к службам за Azure Front Door.
• Тег службы AzureFrontDoor.FirstParty зарезервирован для группы службы Майкрософт, размещенной на Azure Front Door.

Дополнительные сведения о сценариях тегов служб Azure Front Door см. в разделе доступные теги служб. Чтобы оставаться в курсе и принимать соответствующие меры во время любых изменений в IP-адресах, разработайте автоматизацию, чтобы регулярно получать последние IP-адреса с помощью API обнаружения тегов службы или JSON-файла.

Группа источников — это коллекция источников, которые могут обрабатывать аналогичные типы запросов. Вам нужна другая группа источников для каждого приложения или рабочей нагрузки, которая отличается.

В группе источников создается источник для каждого сервера или службы, которые могут обслуживать запросы. Если у источника есть подсистема балансировки нагрузки, например Шлюз приложений Azure, или размещена в PaaS с подсистемой балансировки нагрузки, то группа источников имеет только один источник. Источник управляет обработкой отказа и балансировкой нагрузки между источниками, которые не видит Front Door.

Например, если вы размещаете приложение в Служба приложений Azure, настройка Front Door зависит от количества экземпляров приложения:

• Развертывание в одном регионе: создайте одну группу источников. В этой группе источников создайте один источник для приложения App Service. Приложение службы приложений может масштабироваться между рабочими ролей, но Front Door видит один источник.
• Многорегионное активное/пассивное развертывание: создайте одну группу источников. В этой группе источников сделайте источник для каждого приложения службы приложений. Задайте приоритет каждого источника таким образом, чтобы основное приложение имеет более высокий приоритет, чем приложение резервного копирования.
• Многорегионное активное/активное развертывание: создайте одну группу источников. В этой группе источников сделайте источник для каждого приложения службы приложений. Задайте приоритет каждого источника таким же. Задайте вес каждого источника, чтобы контролировать количество запросов, которые отправляются в этот источник.

Дополнительные сведения см. в разделе Origins и группы источников в Azure Front Door.

Azure Front Door — это служба, которая обеспечивает быструю и надежную веб-доставку для приложений. Она предлагает такие функции, как кэширование, балансировка нагрузки, безопасность и маршрутизация. Однако необходимо учитывать некоторые ограничения времени ожидания и ограничения, которые применяются к Azure Front Door. Эти интервалы времени ожидания и ограничения включают максимальный размер запроса, максимальный размер ответа, максимальный размер заголовка, максимальное число заголовков, максимальное число правил и максимальное число групп источников. Подробные сведения об этих тайм-аутах и ограничениях см. в документации Azure Front Door.

Большинство наборов правил обновляют свои конфигурации менее чем за 15 минут. Правило вступает в силу сразу после завершения обновления.

Azure Front Door имеет 5-секундный тайм-аут для получения заголовков от клиента. Если клиент не отправляет заголовки в течение 5 секунд после установления TCP/TLS-соединения с Azure Front Door, соединение прекращается. Вы не можете настроить этот тайм-аут.

Azure Front Door имеет 90-секундное время ожидания HTTP в режиме поддержания соединения. Подключение завершается, если клиент не отправляет данные в течение 90 секунд, что является временем ожидания по протоколу HTTP для Azure Front Door. Вы не можете настроить это значение времени ожидания.

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

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

Azure Front Door Приватный канал не зависит от региона. Чтобы обеспечить минимальную задержку, при включении конечной точки Приватный канал для Azure Front Door выберите поддерживаемый регион Azure, ближайший к источнику. Если регион вашего источника не поддерживается в списке регионов, которые поддерживает Front Door Приватный канал, выберите следующий ближайший регион. Трафик передается от клиента к конечной точке Azure Front Door Приватный канал в поддерживаемом регионе, а затем проходит через магистральную сеть Microsoft к вашему источнику, поддерживая частное подключение. Эта конфигурация добавляет дополнительную задержку из-за дополнительного перехода между регионами. Вы можете использовать статистику задержки туда и обратно в сети Azure, чтобы определить дополнительную задержку при выборе ближайшего региона. Когда поддерживается новый регион, вы можете следовать этим инструкциям , чтобы постепенно перенаправлять трафик в новый регион.

Azure Front Door — это платформа, которая распределяет трафик по всему миру и может масштабироваться в соответствии с требованиями вашего приложения. Он использует глобальную edge-сеть Microsoft для обеспечения глобального балансировки нагрузки, что позволяет переместить всё приложение или конкретные микросервисы в другие регионы или облака в случае сбоя.

Чтобы избежать ошибок при доставке больших файлов, убедитесь, что исходный сервер включает заголовок Content-Range в ответ, а значение заголовка соответствует фактическому размеру тела ответа.

Дополнительные сведения о настройке источника и Front Door для доставки больших файлов можно найти в доставке больших файлов.

Маскировка домена — это сетевой метод, позволяющий злоумышленнику скрыть фактическое назначение вредоносного запроса с помощью другого доменного имени в рукопожатии TLS и заголовке host HTTP.

Azure Front Door (стандартный, премиум и классический уровень) или Azure CDN Standard от ресурсов Microsoft (classic), созданные после 8 ноября 2022 года, имеют включённую блокировку доменного фронтинга. Вместо того чтобы блокировать запрос с несовпадающими заголовками SNI и хоста, мы допускаем такое несоответствие, если оба домена принадлежат одной подписке и включены в маршруты или правила маршрутизации. Применение блокировки подмены домена началось 22 января 2024 года.

Если Front Door блокирует запрос из-за несоответствия:

• Клиент получает ответ кода ошибки HTTP 421 Misdirected Request .
• Azure Front Door записывает блок в журналы диагностики в Error Info со значением SSLMismatchedSNI.

Для получения дополнительной информации о доменной подмене см. раздел Обеспечение безопасности нашего подхода к доменной подмене в Azure и Запрет на доменную подмену в Azure Front Door и Azure CDN Standard от Microsoft (классической).

Front Door использует TLS 1.2 в качестве минимальной версии для всех профилей, созданных после сентября 2019 года.

Вы можете использовать TLS 1.2 или 1.3 с Azure Front Door. Для получения дополнительной информации прочитайте статью Конечное шифрование TLS в Azure Front Door.

С 15 августа 2025 г. DigiCert перешли на новую платформу проверки контроля домена с открытым исходным кодом (OSS), предназначенную для повышения прозрачности и подотчетности в процессах проверки домена. DigiCert больше не поддерживает устаревший рабочий процесс CNAME Delegation DCV для проверки контроля домена в указанных сервисах Azure. Подробнее

Устаревание влияет на службы, использующие проверку на основе CNAME для автоматической выдачи и продления сертификатов, в том числе:

• Azure Front Door (классическая версия)
• Azure CDN из Microsoft (классическая версия)

Azure Front Door (классическая) и Azure CDN из Microsoft (классическая):

• С 15 августа 2025 года больше не поддерживается новый онбординг доменов, создание новых профилей или управляемые сертификаты Azure.
• С 14 апреля 2026 г. существующие управляемые сертификаты удаляются. Все существующие управляемые сертификаты либо мигрируются клиентом или командой AFD на стандарт Azure Front Door или премиум. Используйте Azure Front Door уровня "Стандартный" или "Премиум" для управляемого сертификата.

В большинстве случаев никаких действий не требуется. После миграции вашего профиля Azure Front Door автоматически пытается обновить управляемый сертификат, если до истечения срока его действия остается менее 45 дней.

• Если ваш домен сопоставлен с CNAME на Azure Front Door и соответствует требованиям CAA к записям и состоянию домена, сертификат автоматически вращается. Автоматическая ротация выполняется каждые 6–8 часов и занимает примерно 24–48 часов. Если автоматическое вращение не удаётся, состояние валидации домена меняется на «Ожидает валидации», и вы можете повторно проверить владение доменом, чтобы вручную запустить проверку.
• Если ваш домен не соответствует этим требованиям или HTTPS отключён, состояние сертификата меняется на ожидающее повторное подтверждение, и вам необходимо повторно проверить право собственности на домен.

Чтобы продлить сертификат без ожидания автоматического вращения, вручную перепроверьте право собственности на домен, используя один из следующих методов:

• Добавление требуемой записи проверки DNS на шаге 3 для доменов, ожидающих проверки
• Запуск проверки вручную с помощью PowerShell или Azure CLI (RefreshValidation).

Вы не можете отключить ресурсы Azure Front Door. Вы можете только их удалить. Плата за переменные тарифные показатели, такие как исходящая передача данных, входящая передача данных и запросы, не взимается при отсутствии трафика, однако базовая плата взимается даже при его отсутствии. Базовая плата взимается до удаления профиля. Для Azure Front Door (классический) плата за политики и правила WAF взимается независимо от их статуса. Даже если вы отключите политику или правило WAF, это все равно будет стоить вам денег.

Нет.

Нет.

Front Door не поддерживает динамическое сжатие для контента объемом более 8 МБ. Однако если источник уже сжимает контент, Front Door поддерживает отдачу статического сжатого контента размером свыше 8 МБ, если поддерживаются диапазонные запросы и не включена передача с использованием chunked encoding.

Нет.

Сведения о журналах и других возможностях диагностики см. в разделе "Метрики мониторинга" и журналы для Front Door.

Журналы диагностики можно хранить в собственной учетной записи хранения и выбрать срок их хранения. В качестве альтернативы можно отправлять диагностические журналы в Event Hubs или в журналы Azure Monitor. Дополнительные сведения см. в разделе диагностика Azure Front Door.

Чтобы получить доступ к журналам аудита Azure Front Door, необходимо посетить портал. Выберите пункт «Входная дверь» на странице меню и выберите Журнал активности. Журнал активности предоставляет вам записи операций вашего Azure Front Door.

Оповещения можно настроить для Azure Front Door на основе метрик или журналов. Таким образом, вы можете отслеживать производительность и работоспособность фронтальных хостов.

Сведения о создании оповещений для Azure Front Door категории "Стандартный" и "Премиум", см. в статье настройка оповещений.

Связанный контент

• Создание профиля Azure Front Door
• Архитектура маршрутизации Azure Front Door