404 상태 코드를 반환하는 Azure Content Delivery Network 엔드포인트 문제 해결

Important

Microsoft의 Azure CDN 표준(클래식)은 2027년 9월 30일에 사용 중지됩니다. 서비스 중단을 방지하려면 2027년 9월 30일까지 Azure Front Door 표준 또는 프리미엄 계층으로 Microsoft의 Azure CDN 표준(클래식) 프로필을 마이그레이션해야 합니다. 자세한 내용은 Microsoft의 Azure CDN 표준(클래식) 사용 중지를 참조하세요.

Edgio의 Azure CDN은 2025년 11월 4일에 사용 중지됩니다. 서비스 중단을 방지하려면 이 날짜 이전에 워크로드를 Azure Front Door로 마이그레이션해야 합니다. 자세한 내용은 Edgio 사용 중지 FAQ의 Azure CDN을 참조 하세요.

이 문서에서는 404 HTTP 응답 상태 코드를 반환하는 Azure Content Delivery Network 엔드포인트의 문제를 해결할 수 있습니다.

이 문서의 어디에서든 도움이 필요한 경우 MSDN Azure 및 스택 오버플로 포럼에서 Azure 전문가에게 문의할 수 있습니다. 또는 Azure 지원 인시던트를 제출할 수도 있습니다. Azure 지원 사이트로 가서 지원 받기를 선택합니다.

증상

콘텐츠 배달 네트워크 프로필 및 엔드포인트를 만들었지만 콘텐츠를 콘텐츠 배달 네트워크에서 사용할 수 없습니다. 콘텐츠 배달 네트워크 URL을 통해 콘텐츠에 액세스하려는 사용자에게는 HTTP 404 상태 코드가 수신됩니다.

원인

몇 가지 가능한 원인은 다음과 같습니다.

• 파일의 원본은 콘텐츠 배달 네트워크에 표시되지 않습니다.
• 엔드포인트가 잘못 구성되어 콘텐츠 배달 네트워크가 잘못된 위치에 표시됩니다.
• 호스트가 콘텐츠 배달 네트워크에서 호스트 헤더를 거부합니다.
• 엔드포인트는 콘텐츠 배달 네트워크 전체에 전파할 시간이 없었습니다.

문제 해결 단계

Important

콘텐츠 배달 네트워크 엔드포인트를 만든 후 등록이 콘텐츠 배달 네트워크 전체에 전파되는 데 시간이 걸리기 때문에 엔드포인트를 즉시 사용할 수는 없습니다.

• Microsoft의 Azure CDN 표준 프로필의 경우 일반적으로 10분 이내에 전파가 완료됩니다.
• Edgio의 Azure CDN Standard 및 Edgio의 Azure CDN Premium 프로필의 경우 일반적으로 전파가 90분 이내에 완료됩니다.

이 문서의 단계를 완료한 후에도 여전히 404 응답이 반환되면 몇 시간 정보 기다렸다가 다시 확인한 후 지원 티켓을 열어 보세요.

원본 파일 확인

먼저 캐시할 파일을 원본 서버에서 사용할 수 있고 인터넷에서 공개적으로 액세스할 수 있는지 확인합니다. 이 작업을 수행하는 가장 빠른 방법은 프라이빗 또는 Incognito(시크릿) 세션에서 브라우저를 열고 해당 파일을 직접 찾아보는 것입니다. 주소 상자에 URL을 입력하거나 붙여넣고 예상하는 파일이 나오는지 확인합니다. 예를 들어 HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt.에서 액세스 가능한 Azure Storage 계정의 파일이 있다고 가정해 봅시다. 이 파일의 콘텐츠를 성공적으로 로드할 수 있으면 테스트를 통과한 것입니다.

Warning

이 방법은 파일이 공개적으로 사용 가능한지 확인하는 가장 빠르고 쉬운 방법이지만, 조직의 일부 네트워크 구성에 따라 이 파일이 살제 네트워크 사용자에게만 보이는 경우에도(Azure에서 호스팅되어 있는 경우도 마찬가지) 공개적으로 사용 가능한 것으로 보일 수 있습니다. 그렇게 되지 않으려면 조직의 네트워크에 연결되지 않은 모바일 디바이스나 Azure의 가상 컴퓨터처럼 외부 브라우저를 사용하여 파일을 테스트합니다.

원본 설정 확인

파일이 인터넷에서 공개적으로 사용할 수 있는 것을 확인한 후에는 원본 설정을 확인합니다. Azure Portal에서 콘텐츠 배달 네트워크 프로필을 찾아서 문제를 해결하려는 엔드포인트를 선택합니다. 결과 엔드포인트 페이지에서 원본을 선택합니다.

원본 페이지가 나타납니다.

원본 유형 및 호스트 이름

원본 유형 및 원본 호스트 이름의 값이 올바른지 확인합니다. 이 예제(HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt)에서 URL의 호스트 이름 부분은 cdndocdemo.blob.core.windows.net으로 올바릅니다. Azure Storage, 웹앱 및 클라우드 서비스 원본은 원본 호스트 이름 필드에 드롭다운 목록 값을 사용하므로 잘못된 철자는 문제가 되지 않습니다. 그러나 사용자 지정 원본을 사용하는 경우 호스트 이름의 철자가 올바른지 확인합니다.

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의 웹 서버에 연결하라고 지시하는 것이므로 HTTP 포트 필드에 8080을 입력해야 합니다. 이러한 포트 설정은 엔드포인트가 원본에서 정보를 검색할 때 사용하는 포트에만 영향을 줍니다.

엔드포인트 설정 검사

엔드포인트 페이지에서 구성 단추를 선택합니다.

콘텐츠 배달 네트워크 엔드포인트 구성 페이지가 나타납니다.

프로토콜

프로토콜의 경우 클라이언트에서 사용하는 프로토콜이 선택되었는지 확인합니다. 클라이언트에서 사용한 것과 동일한 프로토콜이 원본 액세스에 사용되므로 이전 섹션에서 원본 포트를 올바르게 구성하는 것이 중요합니다. 콘텐츠 배달 네트워크 엔드포인트는 원본 포트에 관계없이 기본 HTTP 및 HTTPS 포트(80 및 443)에서만 수신합니다.

가상의 예 HTTP://www.contoso.com:8080/file.txt.로 돌아가 봅시다. 기억하시겠지만 Contoso는 HTTP 포트로 8080을 지정했습니다. 거기에 덧붙여 HTTPS 포트로 44300을 지정했다고 가정해 봅시다. contoso라는 엔드포인트를 만들었다면 콘텐츠 배달 네트워크 엔드포인트 호스트 이름은 contoso.azureedge.net입니다. HTTP://Contoso.azureedge.net/file.txt에 대한 요청은 HTTP 요청이므로 엔드포인트가 포트 8080에서 HTTP를 사용하여 원본에서 파일을 검색합니다. HTTPS 통한 보안 요청 HTTPS://Contoso.azureedge.net/file.txt는 엔드포인트가 포트 44300에서 HTTPS를 사용하여 원본에서 파일을 검색하게 만듭니다.

원본 호스트 헤더

원본 호스트 헤더 는 각 요청과 함께 원본으로 전송되는 호스트 헤더 값입니다. 대부분의 경우 이 값은 앞에서 확인한 원본 호스트 이름과 같아야 합니다. 이 필드의 값이 잘못되어도 404 상태가 발생하지 않지만 원본이 예상하는 것이 무엇인지에 따라 다른 4xx 상태가 발생할 가능성이 있습니다.

원본 경로

마지막으로 원본 경로를 확인해야 합니다. 기본적으로 이 경로는 비어 있습니다. 콘텐츠 배달 네트워크에서 사용 가능하게 만들려는 원본 호스트 리소스의 범위를 좁히려는 경우에만 이 필드를 사용해야 합니다.

예제 엔드포인트에서는 스토리지 계정의 모든 리소스를 사용하게 만들기 위해 원본 경로를 비워 두었습니다. 즉, HTTPS://cdndocdemo.azureedge.net/publicblob/lorem.txt에 대한 요청이 결국 엔드포인트에서 /publicblob/lorem.txt를 요청하는 cdndocdemo.core.windows.net으로 연결됩니다. 이와 마찬가지로, 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 상태를 반환합니다. 이 예에서 lorem.txt를 검색하는 올바른 URL은 HTTPS://cdndocdemo.azureedge.net/lorem.txt.입니다. URL의 요청 부분이 /lorem.txt이고 엔드포인트가 /publicblob을 추가하여 /publicblob/lorem.txt가 원본에 전달되는 요청이 되기 때문에 /publicblob 경로를 전혀 포함하지 않습니다.