Поделиться через

Устранение неполадок конечных точек Azure сеть доставки содержимого, возвращающих код состояния 404

  • Статья

Внимание

Azure CDN standard от Корпорации Майкрософт (классическая версия) будет прекращена 30 сентября 2027 г. Чтобы избежать нарушений работы службы, важно перенести профили Azure CDN уровня "Стандартный" от Майкрософт (классический) на уровень Azure Front Door standard или Premium к 30 сентября 2027 года. Дополнительные сведения см. в статье Azure CDN Standard от майкрософт (классическая версия).

Azure CDN из Эдгио будет прекращено 4 ноября 2025 г. Перед этой датой необходимо перенести рабочую нагрузку в Azure Front Door. Дополнительные сведения см. в статье Azure CDN из Edgio для выхода на пенсию.

Эта статья позволяет устранять проблемы с конечными точками Azure сеть доставки содержимого, возвращающими коды состояния HTTP-ответа 404.

Если вам потребуется дополнительная помощь по любому из вопросов, рассматриваемых в статье, вы можете обратиться к экспертам по Azure на форумах MSDN Azure и Stack Overflow. Кроме того, можно подать инцидент в службу поддержки Azure. Перейдите на сайт поддержки Azure и выберите Получить поддержку.

Симптом

Вы создали профиль сети доставки содержимого и конечную точку, но содержимое, как представляется, не доступно в сети доставки содержимого. Пользователи, пытающиеся получить доступ к содержимому через URL-адрес сети доставки содержимого, получают код состояния HTTP 404.

Причина

Возможно несколько причин, включая указанные ниже.

  • Источник файла не отображается в сети доставки содержимого.
  • Конечная точка неправильно настроена, что приводит к тому, что сеть доставки содержимого будет выглядеть неправильно.
  • Узел отклоняет заголовок узла из сети доставки содержимого.
  • Конечная точка не имела времени распространяться по сети доставки содержимого.

Действия по устранению неполадок

Внимание

После создания конечной точки сети доставки содержимого она не сразу будет доступна для использования, так как требуется время для распространения регистрации через сеть доставки содержимого:

  • Для профилей Azure CDN уровня "Стандартный" от Майкрософт распространение обычно выполняется в течение десяти минут.
  • Для Azure CDN standard из Edgio и Azure CDN Premium из профилей Edgio распространение обычно завершается в течение 90 минут.

Если вы по-прежнему получаете ответы 404 после выполнения процедур, описанных в этом документе, подождите еще несколько часов, чтобы повторить проверку, прежде чем открыть запрос в службу поддержки.

Проверка исходного файла

Во-первых, убедитесь, что файл для кэширования доступен в сервере-источнике и в Интернете в режиме общего доступа. Самый быстрый способ — открыть браузер в анонимном режиме или режиме InPrivate и перейти к файлу напрямую. Введите или вставьте URL-адрес в поле адреса и убедитесь, что выведен нужный вам файл. Предположим, например, что у вас есть файл в учетной записи службы хранилища Azure, доступный по адресу HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt. Если содержимое этого файла загружено успешно, он прошел проверку.

Готово!

Предупреждение

Хотя это и самый быстрый и простой способ проверки общего доступа к файлу, некоторые конфигурации сети в организации могут определить, что этот файл является общедоступным, тогда как на самом деле он доступен только для пользователей вашей корпоративной сети (даже если размещен в Azure). Чтобы убедиться, что это не так, проверьте файл с помощью внешнего браузера, например на мобильном устройстве, не подключенном к сети вашей организации, или на виртуальной машине в Azure.

Проверка параметров источника

Убедившись, что файл находится в открытом доступе в Интернете, проверьте параметры источника. В портал Azure перейдите к профилю сети доставки содержимого и выберите конечную точку, которую вы устраняете. На открывшейся странице Конечная точка выберите источник.

Страница

Откроется страница Источник.

Страница

Тип и имя узла источника

Убедитесь, что тип источника и имя узла источника указаны правильно. В этом примере в URL-адресе HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt именем узла является cdndocdemo.blob.core.windows.net, что является правильным значением. Так как служба хранилища Azure, веб-приложение и источники облачной службы используют раскрывающееся значение списка для поля имени узла Источника, неправильные орфографии не являются проблемой. Однако если вы используете настраиваемый источник, очень важно правильно указать имя вашего узла.

Порты HTTP и HTTPS

Проверьте порты HTTP и HTTPS. В большинстве случаев 80 и 443 являются правильными, и вам не требуется никаких изменений. Однако если сервер-источник прослушивает другой порт, он должен быть представлен здесь. Если вам это неизвестно, взгляните на URL-адрес для исходного файла. Спецификации HTTP и HTTPS используют порты 80 и 443 по умолчанию. В примере URL-адреса HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txtпорт не указан, поэтому предполагается значение по умолчанию 443 и правильные параметры.

Тем не менее рассмотрим такой URL-адрес для ранее тестируемого исходного файла: HTTP://www.contoso.com:8080/file.txt.. Обратите внимание на часть : 8080 в конце сегмента имени узла. Это число указывает браузеру использовать порт 8080 для подключения к веб-серверу в www.contoso.com, поэтому необходимо ввести 8080 в поле ПОРТА HTTP. Важно отметить, что эти параметры портов влияют только на определение порта, используемого конечной точкой для получения сведений из источника.

Проверка параметров конечной точки

На странице Конечная точка нажмите кнопку Настройка.

Страница

Откроется страница настройки конечной точки сети доставки содержимого.

Страница

Протоколы

В разделе Протоколы убедитесь, что выбран протокол, используемый клиентами. Протокол клиента также используется для доступа к источнику, поэтому важно, чтобы порты источника были настроены правильно (см. предыдущий раздел). Конечная точка сети доставки содержимого прослушивает только порты HTTP и HTTPS по умолчанию (80 и 443), независимо от портов источника.

Давайте вернемся к нашему гипотетическому примеру с HTTP://www.contoso.com:8080/file.txt. Как вы помните, Contoso указала 8080 в качестве порта HTTP, но предположим, что они указали 44300 в качестве порта HTTPS. Если они создали конечную точку с именем contoso, имя узла конечной точки доставки содержимого будет contoso.azureedge.net. Запрос файла HTTP://Contoso.azureedge.net/file.txt является HTTP-запросом, поэтому конечная точка будет использовать HTTP на порту 8080, чтобы получить его из источника. При использовании безопасного запроса по протоколу HTTPS по адресу HTTPS://Contoso.azureedge.net/file.txt конечная точка будет использовать HTTPS на порту 44300 во время получения файла из источника.

Заголовок узла источника

Заголовок узла источника — это значение заголовка узла, отправляемое в источник с каждым запросом. В большинстве случаев это значение должно совпадать с именем узла Источника, которое мы проверили ранее. Неправильное значение в этом поле не приводит к состоянию 404, но, скорее всего, приведет к другим состояниям 4xx в зависимости от того, что ожидает источник.

Путь к источнику

Наконец, следует проверить путь к источнику. По умолчанию этот путь пуст. Это поле следует использовать только в том случае, если вы хотите сузить область ресурсов, размещенных в источнике, которые необходимо сделать доступными в сети доставки содержимого.

В этом примере конечной точки необходимо, чтобы все ресурсы в учетной записи хранения были доступными, поэтому поле Путь к источнику осталось пустым. Таким образом, запрос на HTTPS://cdndocdemo.azureedge.net/publicblob/lorem.txt подключение от конечной точки к cdndocdemo.core.windows.net, который запрашивает /publicblob/lorem.txt. Аналогичным образом, запрос файла HTTPS://cdndocdemo.azureedge.net/donotcache/status.png приведет к запросу конечной точкой файла /donotcache/status.png из источника.

Но что делать, если вы не хотите использовать сеть доставки содержимого для каждого пути в источнике? Предположим, что вы только хотите предоставить общедоступный путь к BLOB-объектам . Если мы введем /publicblob в поле пути источника, это приведет к тому, что конечная точка будет вставлять /publicblob перед каждым запросом, сделанным в источник. Поэтому запрос HTTPS://cdndocdemo.azureedge.net/publicblob/lorem.txt теперь принимает часть запроса URL-адреса, /publicblob/lorem.txt и добавляет /publicblob в начало. В результате запроса на /publicblob/publicblob/lorem.txt из источника. Если этот путь не разрешается в фактический файл, источник возвращает состояние 404. Правильный URL-адрес для получения файла lorem.txt в этом примере: HTTPS://cdndocdemo.azureedge.net/lorem.txt. Мы не добавляем путь /publicblob вообще, так как часть запроса URL-адреса имеет значение /lorem.txt, а конечная точка добавляет /publicblob, что приводит к тому, что /publicblob/lorem.txt передается в источник.