페이지의 나머지는 로드되는데 이미지 하나만 실패하는 이유
세 가지 조건이 네트워크 결함, 차단된 요청, 렌더링 오류를 구분합니다. 경로를 바꾸기 전에 브라우저가 선택한 URL을 찾아보세요.
페이지는 로드되고 텍스트도 표시되는데 이미지 하나가 깨진 아이콘으로 남습니다. 달라진 것이 터널이기 때문에 첫 반응은 터널을 탓하는 것입니다. 그 전에 페이지 URL과 이미지 URL은 서로 다른 증거이므로 브라우저가 그 이미지에 실제로 요청한 URL이 무엇인지 확인하세요. 이미지 누락 신고의 대부분은 정상적인 요청을 한 번도 받지 못한 호스트로 귀결되며, 그 답은 네트워크 패널을 한 번 보면 나옵니다.
어디를 볼지는 세 가지 조건이 정합니다
첫 번째 조건은 이미지가 페이지와 같은 호스트에서 오는지입니다. 별도의 이미지 호스트는 자체 이름 해석, 자체 연결, 자체 TLS 아이덴티티가 필요하므로 페이지가 로드된다고 해서 그 호스트에 대해 알 수 있는 것은 없습니다.
두 번째는 브라우저가 요청을 보내기 전에 차단했는지입니다. 혼합 콘텐츠, 콘텐츠 보안 정책, 리퍼러 규칙은 일반적인 서버 응답 없이 이미지를 막을 수 있어서 목록에 실패한 요청이 나타나지 않습니다.
세 번째는 전달은 성공했는데 렌더링이 실패한 경우로, 바이트는 도착했지만 이미지가 보이지 않는 경우입니다. 이 세 조건에는 서로 다른 담당자가 셋 있고, 네트워크 문제인 것은 첫 번째뿐입니다.
| What you see | Where the fault sits |
|---|---|
| Request absent from the list | Markup, lazy loading or a policy that blocked it |
| Request failed or timed out | Resolution, route, TLS or the image host itself |
| Request returned 200, image blank | Response type, decoding or rendering |
브라우저가 실제로 선택한 리소스를 찾으세요
페이지 소스에서 보이는 URL이 실제로 요청된 URL이 아닌 경우가 많습니다. 소스 세트, picture 요소, CSS 배경은 모두 뷰포트 너비, 픽셀 밀도, 형식 지원에 따라 브라우저가 다른 리소스를 고르게 합니다. 지연 로드 이미지는 페이지가 특정 상태에 이를 때까지 아예 요청되지 않을 수 있습니다.
요소와 요청을 함께 살펴보고, 문제를 보고할 때는 요청과 함께 시작자를 남기세요. MDN의 이미지 요소 참조는 소스 선택, 로딩 동작, 리퍼러 제어를 한곳에서 다루므로 어떤 속성이 실패한 URL을 골랐는지 판단하기에 충분합니다.
호스트 이름, 상태, 모든 리디렉션 체인, 응답의 콘텐츠 형식을 기록하세요. 로그인 페이지를 돌려주는 200 응답은 쓸 수 있는 이미지가 아니며, HTML 오류 페이지로의 리디렉션은 형식을 읽기 전까지 손상된 파일과 똑같이 보입니다.
네트워크보다 상태를 먼저 읽으세요
시간 초과, 거부된 요청, 디코딩 오류는 다음 단계가 각각 다르며, 이를 구분하는 것이 상태 코드입니다. 시간 초과는 이름 해석, 경로, 응답하지 않는 호스트를 가리킵니다. 거부된 요청은 정책이나 권한 계층을 가리킵니다. 디코딩 오류는 바이트나 형식을 가리킵니다.
요청이 아예 나타나지 않으면 네트워크를 보는 것을 멈추고 마크업을 보세요. 가장 흔한 원인은 브라우저가 선호했지만 서버에 더 이상 없는 소스 세트 항목이고, 그다음이 스크립트가 한 번도 보이게 하지 않은 요소입니다.
이 구분만으로 이런 종류의 신고에서 낭비되는 노력의 대부분이 줄어듭니다.
브라우저가 차단하면 읽을 응답이 없습니다
혼합 콘텐츠는 전형적인 사례로, HTTPS 페이지가 평문 HTTP로 이미지를 요청하면 요청은 실패가 아니라 차단되고 콘솔이 이유를 기록합니다. 콘텐츠 보안 정책도 같은 모양을 만들며 차단된 지시문이 메시지에 나옵니다. 헤더를 제거하는 리퍼러 정책은 핫링크 보호가 걸린 호스트가 이미지 대신 자리 표시자를 돌려주게 할 수도 있습니다.
경로가 바뀌어도 이런 차단은 나아지지 않으므로 네트워크 경로를 건드리기 전에 기록된 이유를 읽으세요. 교차 출처 권한을 추가하는 것도 해결책이 아니며, 다른 호스트의 이미지를 표시하는 것과 그 픽셀을 canvas에서 읽는 것은 다른 작업이라 헤더가 필요한 것은 후자뿐입니다.
관리하는 사이트라면 리소스 URL, 응답, 정책을 소유자 쪽에서 바로잡고 권한과 리퍼러 요구 사항은 그대로 유지하세요. 관리하지 않는 사이트라면 비공개이거나 만료되는 리소스 링크를 다시 게시하는 대신 페이지와 요청 증거를 해당 지원 채널로 보내세요.
증거를 바꾸지 않고 경로를 비교하세요
접근 경로를 정말 시험하려면 같은 페이지, 같은 계정, 같은 선택 이미지에서 허용된 경로 하나만 바꾸며 나머지를 모두 고정하세요. 렌더링된 결과는 이미지가 나타났는지만 알려 주고 이유는 알려 주지 않으므로, 렌더링된 결과가 아니라 요청 항목을 나란히 비교하세요.
새 경로에서 로드된 이미지는 그 경로가 허용되었다는 증거가 아니며, 계속 깨진 이미지는 터널이 원인이라는 증거가 아닙니다. 이미지가 삭제되었거나 접근이 의도적으로 제한된 경우에는 인증서 검사를 끄거나 다른 사람의 보호된 자료를 복제하는 대신 지원되는 대안을 사용하세요.
작업 순서는 선택된 URL을 확인하고, 상태와 형식을 읽고, 기록된 차단 이유가 있는지 확인한 다음, 한 번에 경로 변경 하나씩 비교하는 것입니다.