Solução de problemas de pontos de extremidade da Rede de Distribuição de Conteúdo do Azure que retornam um código de status 404

Importante

A CDN do Azure Standard (clássica) será desativada em 30 de setembro de 2027. Para evitar qualquer interrupção de serviço, é importante migrar seus perfis da CDN do Azure Standard (clássica) para a camada Azure Front Door Standard ou Premium até 30 de setembro de 2027. Para obter mais informações, confira CDN do Azure Standard (clássica).

O CDN do Azure da Edgio será desativado em 15 de janeiro de 2025. Você deve migrar sua carga de trabalho para o Azure Front Door antes desta data para evitar interrupção do serviço.. Para obter mais informações, veja Perguntas frequentes sobre a aposentadoria do CDN do Azure da Edgeo.

Este artigo permite que você solucione problemas com pontos de extremidade de Rede de Distribuição de Conteúdo do Azure que retornam códigos de status de resposta HTTP 404.

Se você precisar de mais ajuda em qualquer momento neste artigo, você pode contatar os especialistas do Azure nos fóruns do Azure MSDN e Excedente de Pilha. Como alternativa, você também pode registrar um incidente do Suporte do Azure. Vá para o Site de suporte do Azure e selecione Obter suporte.

Sintoma

Você criou um perfil de rede de distribuição de conteúdo e um ponto de extremidade, mas seu conteúdo não parece estar disponível na rede de distribuição de conteúdo. Os usuários que tentam acessar seu conteúdo por meio da URL da rede de distribuição de conteúdo recebem um código de status HTTP 404.

Causa

Há várias causas possíveis, incluindo:

• A origem do arquivo não é visível para a rede de distribuição de conteúdo.
• O ponto de extremidade está configurado incorretamente, fazendo com que a rede de distribuição de conteúdo procure no lugar errado.
• O host está rejeitando o cabeçalho do host da rede de distribuição de conteúdo.
• O ponto de extremidade não teve tempo de se propagar pela rede de distribuição de conteúdo.

Etapas para solucionar problemas

Importante

Depois de criar um ponto de extremidade de rede de distribuição de conteúdo, ele não estará disponível imediatamente para uso, pois leva tempo para o registro se propagar pela rede de distribuição de conteúdo:

• Para perfis da CDN Standard do Azure da Microsoft, a propagação geralmente conclui em dez minutos.
• Para perfis da CDN do Azure Standard da Edgio e CDN do Azure Premium da Edgio, a propagação geralmente termina em 90 minutos.

Se você concluir as etapas descritas neste documento e ainda obter respostas 404, considere aguardar algumas horas para verificar novamente antes de abrir um tíquete de suporte.

Verificar o arquivo de origem

Primeiro, verifique se o arquivo para cache está disponível no servidor de origem e está acessível publicamente na internet. A maneira mais rápida de fazer isso é abrir um navegador em uma sessão privada ou anônima e navegar diretamente até o arquivo. Digite ou cole a URL na caixa de endereço e verifique se isso resulta no arquivo esperado. Por exemplo, suponha que você tem um arquivo em uma conta de Armazenamento do Azure, acessível em HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt. Se você consegue carregar com êxito o conteúdo desse arquivo, ele está aprovado no teste.

Aviso

Embora essa seja a maneira mais rápida e fácil de verificar se o arquivo está disponível publicamente, algumas configurações de rede em sua organização poderiam dar a impressão de que um arquivo está publicamente disponível quando, na verdade, só está visível para os usuários de sua rede (mesmo que ele esteja hospedado no Azure). Para garantir que este não seja o caso, teste o arquivo com um navegador externo, como um dispositivo móvel que não está conectado à rede de sua organização ou uma máquina virtual no Azure.

Verificar as configurações de origem

Depois de verificar se o arquivo está disponível publicamente na Internet, verifique suas configurações de origem. No portal do Azure, navegue até o seu perfil de rede de distribuição de conteúdo e selecione o ponto de extremidade que você está solucionando. Na página do Ponto de extremidade resultante, selecione a origem.

A página de Origem é exibida.

Tipo e nome do host da origem

Verifique se os valores do Tipo de origem e Nome do host de origem estão corretos. No meu exemplo, HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt, a parte do nome do host da URL é cdndocdemo.blob.core.windows.net, o que está correto. Como as origens do Armazenamento do Azure, do aplicativo Web e do serviço de nuvem usam um valor da lista suspensa para o campo Nome do host de origem, grafias incorretas não são um problema. No entanto, se você usar uma origem personalizada, certifique-se de que seu nome de host esteja escrito corretamente.

Portas HTTP e HTTPS

Verifique suas portas HTTP e HTTPS. Na maioria dos casos, as portas 80 e 443 estão corretas, e nenhuma alteração é necessária. No entanto, se o servidor de origem estiver escutando outra porta, isso precisará ser representado aqui. Caso você não tenha certeza, veja a URL do arquivo de origem. As especificações de HTTP e HTTPS usam as portas 80 e 443 como os padrões. No exemplo de URL, HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt, uma porta não é especificada. Portanto, o padrão de 443 é adotado e as configurações estão corretas.

No entanto, suponha que a URL do arquivo de origem testado anteriormente seja HTTP://www.contoso.com:8080/file.txt. Observe a parte :8080 no final do segmento do nome do host. Esse número instrui o navegador a usar a porta 8080 para se conectar ao servidor Web em www.contoso.com. Portanto, você precisará inserir 8080 no campo Porta HTTP. É importante observar que essas configurações de porta só afetam a porta usada pelo ponto de extremidade para recuperar informações da origem.

Verificar as configurações de ponto de extremidade

Na página Ponto de extremidade, selecione o botão Configurar.

A página Configurar do ponto de extremidade de rede de distribuição de conteúdo é exibida.

Protocolos

Para Protocolos, verifique se o protocolo usado pelos clientes está selecionado. Como o mesmo protocolo usado pelo cliente é usado para acessar a origem, é importante ter as portas de origem configuradas corretamente na seção anterior. O ponto de extremidade da rede de distribuição de conteúdo ouve apenas as portas HTTP e HTTPS (80 e 443) padrão, independentemente das portas de origem.

Vamos voltar ao nosso exemplo hipotético com HTTP://www.contoso.com:8080/file.txt. Como você se lembra, a Contoso especificou 8080 como a porta HTTP, mas vamos também supor que ela especificou 44300 como a porta HTTPS. Se eles tiverem criado um ponto de extremidade chamado contoso, seu nome de host do ponto de extremidade da rede de distribuição de conteúdo será contoso.azureedge.net. Uma solicitação de HTTP://Contoso.azureedge.net/file.txt é uma solicitação HTTP, portanto o ponto de extremidade usará HTTP na porta 8080 para recuperá-la da origem. Uma solicitação segura via HTTPS, HTTPS://Contoso.azureedge.net/file.txt, faria com que o ponto de extremidade usasse HTTPS na porta 44300 ao recuperar o arquivo da origem.

Cabeçalho de host de origem

O Cabeçalho de host de origem é o valor do cabeçalho de host enviado para a origem com cada solicitação. Na maioria dos casos, esse valor deve ser igual ao Nome do host de origem verificado anteriormente. Um valor incorreto nesse campo não causa status 404, mas, provavelmente, causa outros status 4xx, dependendo do que é esperado pela origem.

Caminho de origem

Por fim, devemos verificar nosso Caminho de origem. Por padrão, esse caminho fica em branco. Você só deve usar esse campo se quiser restringir o escopo dos recursos hospedados na origem que quer disponibilizar na rede de distribuição de conteúdo.

No exemplo de ponto de extremidade, queríamos que todos os recursos na conta de armazenamento estivessem disponíveis, então o Caminho de origem foi deixado em branco. Portanto, uma solicitação para HTTPS://cdndocdemo.azureedge.net/publicblob/lorem.txt resulta em uma conexão do ponto de extremidade com o cdndocdemo.core.windows.net que solicita /publicblob/lorem.txt. Da mesma forma, uma solicitação de HTTPS://cdndocdemo.azureedge.net/donotcache/status.png resulta na solicitação de /donotcache/status.png a partir da origem pelo ponto de extremidade.

Mas e se você não quiser usar a rede de distribuição de conteúdo para cada caminho em sua origem? Digamos que você queira expor o caminho do blob público. Se inserirmos /publicblob no campo Caminho de origem, isso fará com que o ponto de extremidade insira /publicblob antes de todas as solicitações feitas para a origem. Portanto, a solicitação de HTTPS://cdndocdemo.azureedge.net/publicblob/lorem.txt já usa a parte da solicitação da URL, /publicblob/lorem.txt e acrescenta /publicblob ao início. Resultando em uma solicitação para /publicblob/publicblob/lorem.txt da origem. Se esse caminho não é resolvido para um arquivo real, a origem retorna um status 404. Na verdade, a URL correta para recuperar lorem.txt neste exemplo seria HTTPS://cdndocdemo.azureedge.net/lorem.txt. Não incluímos o caminho /publicblob, porque a parte da solicitação da URL é /lorem.txt e o ponto de extremidade adiciona /publicblob, fazendo com que /publicblob/lorem.txt seja a solicitação transmitida para a origem.