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

Importante

O Azure CDN Standard da Microsoft (clássico) será desativado em 30 de setembro de 2027. Para evitar qualquer interrupção do serviço, é importante migrar o Azure CDN Standard dos perfis Microsoft (clássicos) para o Azure Front Door Standard ou Premium até 30 de setembro de 2027. Para obter mais informações, consulte Azure CDN Standard da aposentadoria (clássica) da Microsoft.

A CDN do Azure de Edgio será aposentada em 15 de janeiro de 2025. Você deve migrar sua carga de trabalho para o Azure Front Door antes dessa data para evitar a interrupção do serviço. Para obter mais informações, consulte CDN do Azure das Perguntas frequentes sobre aposentadoria do Edgio.

Este artigo permite solucionar problemas com pontos de extremidade da Rede de Entrega de Conteúdo do Azure que retornam códigos de status de resposta HTTP 404.

Se precisar de mais ajuda em qualquer ponto deste artigo, entre em contato com os especialistas do Azure nos fóruns MSDN Azure e Stack Overflow. Como alternativa, você também pode registrar um incidente de Suporte do Azure. Vá para o site de Suporte do Azure e selecione Obter Suporte.

Sintoma

Você criou um perfil de rede de entrega de conteúdo e um ponto de extremidade, mas seu conteúdo não parece estar disponível na rede de entrega de conteúdo. Os utilizadores que tentam aceder ao seu conteúdo através do URL da rede de distribuição de conteúdos recebem um código de estado HTTP 404.

Causa

Existem 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 entrega de conteúdo pareça no lugar errado.
• O host está rejeitando o cabeçalho do host da rede de entrega de conteúdo.
• O ponto de extremidade não teve tempo de se propagar por toda a rede de distribuição de conteúdo.

Passos de resolução de problemas

Importante

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

• Para os perfis CDN do Azure Standard da Microsoft, a propagação normalmente fica concluída em dez minutos.
• Para os perfis CDN Standard do Azure do Edgio e CDN Premium do Azure do Edgio , a propagação geralmente é concluída em 90 minutos.

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

Verifique o ficheiro de origem

Primeiro, verifique se o arquivo a armazenar em 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 para o arquivo. Digite ou cole o URL na caixa de endereço e verifique se ele resulta no arquivo esperado. Por exemplo, suponha que você tenha um arquivo em uma conta de Armazenamento do Azure, acessível em HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt. Se você conseguir carregar com êxito o conteúdo desse arquivo, ele passará no teste.

Aviso

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

Verifique 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 perfil da rede de entrega de conteúdo e selecione o ponto de extremidade que você está solucionando. Na página Ponto de extremidade resultante, selecione a origem.

A página Origem é exibida.

Tipo de origem e nome do host

Verifique se os valores do tipo Origin e do nome de host Origin estão corretos. Neste 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 de lista suspensa para o campo Nome do host Origem, ortografias incorretas não são um problema. No entanto, se você usar uma origem personalizada, verifique se o nome do host está escrito corretamente.

Portas HTTP e HTTPS

Verifique suas portas HTTP e HTTPS. Na maioria dos casos, 80 e 443 estão corretos, e você não precisa de alterações. No entanto, se o servidor de origem estiver escutando em uma porta diferente, isso precisa ser representado aqui. Se não tiver a certeza, veja o URL do seu ficheiro de origem. As especificações HTTP e HTTPS usam as portas 80 e 443 como padrão. No URL de exemplo, HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt, uma porta não é especificada, portanto, o padrão de 443 é assumido e as configurações estão corretas.

No entanto, suponha que a URL para o arquivo de origem que você testou anteriormente é HTTP://www.contoso.com:8080/file.txt. Observe a parte : 8080 no final do segmento hostname. Esse número instrui o navegador a usar a porta 8080 para se conectar ao servidor Web em www.contoso.com, portanto, você precisa digitar 8080 no campo Porta HTTP. É importante observar que essas configurações de porta afetam apenas a porta que o ponto de extremidade usa para recuperar informações da origem.

Verifique as configurações do endpoint

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

A página Configurar ponto de extremidade da rede de entrega de conteúdo é exibida.

Protocolos

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

Voltemos ao nosso exemplo hipotético com HTTP://www.contoso.com:8080/file.txt. Como você se lembra, a Contoso especificou 8080 como sua porta HTTP, mas também vamos supor que eles especificaram 44300 como sua porta HTTPS. Se eles criassem um ponto de extremidade chamado contoso, seu nome de host de ponto de extremidade da rede de entrega de conteúdo seria contoso.azureedge.net. Uma solicitação para HTTP://Contoso.azureedge.net/file.txt é uma solicitação HTTP, então o ponto de extremidade usaria HTTP na porta 8080 para recuperá-la da origem. Uma solicitação segura por 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 anfitrião de origem

O cabeçalho do host Origin é o valor do cabeçalho do host enviado para a origem com cada solicitação. Na maioria dos casos, esse valor deve ser o mesmo que o nome de host Origin que verificamos anteriormente. Um valor incorreto neste campo não causa um status 404, mas é provável que cause outros status 4xx, dependendo do que a origem espera.

Caminho de origem

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

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

Mas e se você não quiser usar a rede de entrega de conteúdo para cada caminho em sua origem? Digamos que você só queria expor o caminho público blob . Se inserirmos /publicblob no campo Caminho de origem , isso fará com que o ponto de extremidade insira /publicblob antes de cada solicitação ser feita à origem. Portanto, a solicitação por HTTPS://cdndocdemo.azureedge.net/publicblob/lorem.txt enquanto usa a parte de solicitação da URL, /publicblob/lorem.txt, e anexa /publicblob ao início. Resultando em uma solicitação de /publicblob/publicblob/lorem.txt desde a origem. Se esse caminho não for resolvido para um arquivo real, a origem retornará um status 404. O URL correto para recuperar lorem.txt neste exemplo seria, na verdade, 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, resultando em /publicblob/lorem.txt sendo a solicitação passada para a origem.