개발자 도구 Network 오류 빨간 줄 원인 8가지와 확인 순서

웹사이트가 겉으로는 잘 열리는데 개발자 도구를 열어 보면 Network 탭에 붉은 줄이 여러 개 보이는 경우가 있습니다. 이 붉은 줄은 브라우저가 어떤 파일을 요청했다가 실패했다는 표시입니다. 개발자 도구 Network 오류는 원인이 하나가 아니라, 요청 단계마다 다른 이유로 발생합니다.

중요한 것은 붉은 줄 하나하나가 서로 다른 문제를 가리킨다는 점입니다. 404와 CORS, 시간 초과, 차단된 요청은 겉모습만 비슷할 뿐 대응 방법이 전혀 다릅니다. 이 글은 붉게 표시되는 대표 유형을 나누고, 어떤 순서로 확인하면 원인에 가장 빨리 도달하는지 정리합니다.

Network 탭이 요청을 붉게 표시하는 기준

브라우저는 응답 상태 코드가 400번대 또는 500번대이거나, 응답을 아예 받지 못한 요청을 실패로 간주합니다. 이 두 경우가 목록에서 붉은색으로 강조됩니다. 반대로 200이나 304처럼 정상 처리된 요청은 색이 입혀지지 않습니다.

응답을 받지 못한 요청은 Status 열에 코드 대신 실패 문구가 표시됩니다. 서버까지 연결 자체가 되지 않았거나, 브라우저 확장 프로그램 또는 보안 정책이 중간에서 막았을 때 이런 형태가 됩니다. 개발자 도구 Network 오류를 볼 때 숫자가 있는지 없는지를 먼저 구분하면 절반은 갈라집니다.

목록 상단의 필터에서 실패한 요청만 골라 보는 기능을 쓰면 확인이 빨라집니다. 요청이 수백 개에 이르는 페이지에서도 문제가 있는 항목만 남기므로, 원인 후보를 좁히는 데 유리합니다.

숫자가 있는 실패와 숫자가 없는 실패

Status 열에 404나 500 같은 숫자가 찍혀 있다면 요청은 서버까지 도달했습니다. 서버가 파일을 찾지 못했거나 처리 도중 문제가 생긴 것이므로, 원인은 서버 쪽 경로와 코드에 있습니다.

반대로 숫자가 없이 실패 문구만 있다면 요청이 서버에 닿지 못했다는 뜻입니다. 도메인 이름을 찾지 못했거나, 연결이 거부되었거나, 브라우저 정책이 요청을 차단한 상황입니다. 이 경우 서버 로그를 아무리 뒤져도 흔적이 남지 않습니다.

따라서 개발자 도구 Network 오류를 만났을 때 가장 먼저 할 일은 서버 로그에 해당 요청이 기록되어 있는지 확인하는 것입니다. 기록이 있으면 서버 문제, 없으면 브라우저와 네트워크 구간 문제로 범위가 좁혀집니다.

표시 형태	뜻하는 것	확인할 위치	먼저 할 조치
404·403·500 같은 숫자	서버까지 도달했고 응답이 왔음	Status 열과 Response 탭	주소와 서버 로그 확인
(failed)	응답을 받지 못하고 끊김	Timing 탭의 단계별 시간	네트워크와 도메인 확인
(blocked:csp)	보안 정책이 요청을 막음	Console 탭의 정책 메시지	허용 목록 점검
(canceled)	브라우저나 코드가 요청을 취소	Initiator 열	중복 요청과 화면 이동 확인
(pending)	응답을 기다리는 중	Waterfall 막대 길이	서버 처리 시간 확인

가정 예시 — 실제 표시 문구는 브라우저 버전에 따라 다를 수 있음

붉은 줄이라고 해서 모두 같은 문제가 아닙니다. 숫자가 붙은 실패는 서버까지 요청이 갔다는 뜻이므로 서버 쪽을 보고, 숫자가 없는 실패는 요청이 도중에 끊겼다는 뜻이므로 네트워크와 정책을 봅니다. 개발자 도구 Network 오류를 읽을 때 이 구분이 첫 갈림길입니다.

404로 표시되는 요청의 전형적인 원인

가장 흔한 원인은 경로 오타와 대소문자 불일치입니다. 윈도우 환경에서 만든 파일 이름이 리눅스 서버로 올라가면 대소문자를 구분하기 때문에, 로컬에서는 열리던 파일이 서버에서만 404가 됩니다.

배포 과정에서 파일이 누락되는 경우도 많습니다. 빌드 결과물 폴더를 통째로 올리지 않았거나, 특정 확장자가 업로드 제외 규칙에 걸려 빠지는 상황이 대표적입니다. 서버에 접속해 실제 파일 목록을 확인하면 바로 드러납니다.

테마나 플러그인을 교체한 뒤 예전 경로를 참조하는 코드가 남아 있을 때도 같은 증상이 생깁니다. 이때는 요청 목록에서 Initiator 열을 눌러 어떤 파일이 그 요청을 만들었는지 역추적하면 원인 위치를 찾을 수 있습니다.

차단된 요청과 보안 정책

브라우저는 안전하지 않다고 판단한 요청을 스스로 막습니다. HTTPS 페이지에서 HTTP 자원을 부르는 경우, 다른 출처의 응답에 허용 헤더가 없는 경우, 콘텐츠 보안 정책에 어긋나는 경우가 여기에 해당합니다.

이런 요청은 Status 열에 차단 표시가 뜨고 Console 탭에 이유가 함께 출력됩니다. 개발자 도구 Network 오류 중에서 서버 로그에 흔적이 없는 유형은 대부분 이 범주에 들어갑니다.

광고 차단 확장 프로그램이 원인인 경우도 적지 않습니다. 분석 스크립트나 광고 관련 요청이 유독 실패한다면, 시크릿 창에서 확장 프로그램 없이 접속해 같은 증상이 재현되는지 확인해 보는 편이 좋습니다.

차단 표시	원인이 되는 정책	확인할 곳	대응 방향
blocked:csp	콘텐츠 보안 정책	응답 헤더의 Content-Security-Policy	허용 출처 목록에 주소 추가
blocked:mixed-content	HTTPS 화면의 HTTP 요청	요청 주소의 프로토콜	주소를 HTTPS로 통일
blocked:other	확장 프로그램 또는 차단기	시크릿 창에서 재현	확장 프로그램 해제 후 비교
CORS 오류	다른 출처 요청 허용 헤더 없음	Console 탭 메시지	서버에 허용 헤더 추가

가정 예시 — 실제 표시 문구는 브라우저 버전에 따라 다를 수 있음

차단은 서버가 아니라 브라우저가 스스로 내린 판단입니다. 그래서 서버 로그에는 아무 기록도 남지 않는 경우가 많고, 개발자 도구 Network 오류만 보고 서버를 뒤지면 시간을 잃게 됩니다.

차단 표시가 보이면 Console 탭을 먼저 확인하는 편이 빠릅니다. 브라우저는 어떤 정책 때문에 막았는지를 대부분 문장으로 남겨 둡니다.

시간 초과와 연결 실패

서버가 응답하지 않아 요청이 오래 대기하다 끊기면 시간 초과로 실패합니다. Timing 탭을 열어 어느 구간에서 시간이 소모되었는지 보면 원인 추정이 가능합니다. 연결 수립 구간이 길면 네트워크, 대기 구간이 길면 서버 처리 쪽입니다.

연결 자체가 거부되는 경우에는 방화벽이나 포트 설정을 확인해야 합니다. 특정 사무실 네트워크에서만 실패한다면 사내 정책이 해당 도메인이나 포트를 막고 있을 가능성이 큽니다.

도메인 이름을 찾지 못하는 실패는 이름 해석 단계 문제입니다. 주소를 잘못 적었거나, 도메인 설정이 아직 전파되지 않았거나, 사용 중인 이름 서버에 문제가 있는 상황입니다.

Initiator와 Timing으로 원인을 좁히는 방법

요청 목록에서 열 이름을 오른쪽 버튼으로 눌러 Initiator 열을 켜 두면, 각 요청을 누가 발생시켰는지 확인할 수 있습니다. 스크립트가 만든 요청인지 문서가 직접 참조한 자원인지에 따라 수정할 위치가 달라집니다.

Timing 탭은 요청 한 건의 생애를 구간별로 보여 줍니다. 대기, 이름 해석, 연결, 전송, 응답 대기가 각각 몇 밀리초씩 걸렸는지 나오므로 병목 지점을 숫자로 확인할 수 있습니다.

Preserve log 항목을 켜 두면 페이지가 이동해도 이전 요청 기록이 남습니다. 로그인 직후나 리다이렉션 과정에서 발생하는 개발자 도구 Network 오류를 잡을 때 특히 유용합니다.

상태 코드 구간별로 읽는 실패 유형

400번대는 요청을 보낸 쪽의 문제를 뜻합니다. 경로가 틀렸거나, 권한이 없거나, 요청 형식이 서버가 기대한 모양과 다를 때 이 구간의 코드가 돌아옵니다. 401과 403은 인증과 권한, 404는 자원 부재, 429는 요청 횟수 초과를 가리킵니다.

500번대는 서버 내부에서 처리가 실패했다는 신호입니다. 500은 원인을 특정하지 않은 일반 오류, 502와 504는 앞단 서버가 뒤쪽 서버로부터 정상 응답을 받지 못한 상황을 의미합니다. 이 구간이 보이면 브라우저에서 할 수 있는 일은 거의 없고 서버 로그를 확인해야 합니다.

같은 붉은 줄이라도 400번대와 500번대는 담당 영역이 다릅니다. 개발자 도구 Network 오류를 팀에 공유할 때 상태 코드를 함께 적어 두면 확인해야 할 사람이 곧바로 정해집니다.

상태 코드 구간	대표 코드	주로 생기는 원인	확인 지점
2xx	200, 204	실패가 아님. 본문이 비었을 수 있음	Response 탭의 본문
3xx	301, 302, 304	주소 이동 또는 캐시 검증	Location과 Cache-Control 헤더
4xx	400, 401, 403, 404	주소·권한·정책 문제	요청 URL과 인증 헤더
5xx	500, 502, 503	서버 처리 실패	서버 오류 로그
숫자 없음	failed, blocked	연결·정책 단계에서 중단	Console 메시지와 Timing

가정 예시 — 실제 코드 사용 방식은 서비스마다 다름

구간만 알아도 원인을 찾을 범위가 절반으로 줄어듭니다. 개발자 도구 Network 오류를 볼 때 4xx는 요청을 보낸 쪽, 5xx는 받는 쪽을 먼저 의심하면 됩니다.

재현이 되지 않을 때의 접근

특정 사용자에게만 발생하고 개발자 화면에서는 재현되지 않는 경우가 있습니다. 이때는 브라우저 종류와 버전, 접속 네트워크, 설치된 확장 프로그램을 먼저 물어보는 편이 빠릅니다. 세 가지 중 하나가 원인인 사례가 대부분입니다.

화면 기록보다 요청 기록을 받는 편이 정확합니다. 개발자 도구의 요청 목록은 파일로 내보낼 수 있으므로, 사용자에게 그 파일을 요청하면 실제로 어떤 요청이 실패했는지 그대로 확인할 수 있습니다.

간헐적으로만 발생한다면 시간대와 접속량을 함께 봐야 합니다. 특정 시간에만 시간 초과가 몰린다면 서버 자원 부족이나 외부 연동 지연을 의심할 수 있습니다.

재현 조건을 좁힐 때는 변수를 하나씩만 바꿉니다. 브라우저를 바꾸고 네트워크도 함께 바꾸면 어느 쪽이 원인인지 알 수 없게 됩니다.

요청 목록을 기록으로 남기는 방법

문제를 다른 사람과 함께 확인해야 할 때는 화면을 캡처하는 것보다 요청 기록 자체를 남기는 편이 정확합니다. 개발자 도구의 요청 목록은 파일 형태로 내보낼 수 있고, 이 파일에는 각 요청의 헤더와 소요 시간이 그대로 담깁니다.

내보낸 파일은 다시 같은 도구로 불러와 열 수 있습니다. 그러면 문제가 발생한 시점의 요청 순서와 실패 지점을 그대로 재생할 수 있어, 재현이 어려운 개발자 도구 Network 오류를 분석할 때 특히 유용합니다.

다만 이 파일에는 인증 토큰이나 쿠키 같은 민감한 값이 포함될 수 있습니다. 외부에 공유하기 전에 해당 항목을 지우거나, 공유 범위를 팀 내부로 제한하는 절차가 필요합니다.

정기적으로 확인해야 하는 페이지라면 자동화 도구로 같은 요청을 주기적으로 실행해 실패율을 기록해 두는 방법도 있습니다. 사람이 눈으로 확인하기 어려운 간헐적 실패를 숫자로 잡아낼 수 있습니다.

실패한 요청을 그대로 다시 보내 보고 싶다면 요청을 명령 형태로 복사하는 기능을 씁니다. 목록에서 해당 요청을 오른쪽 클릭하고 Copy as cURL을 고르면 헤더까지 포함한 명령이 클립보드에 담깁니다.

snippetCODE

1
2
3

curl -i 'https://example.com/api/items' \
  -H 'Accept: application/json' \
  -H 'Referer: https://example.com/'

터미널에 붙여 넣어 실행하면 브라우저 확장 프로그램이나 서비스 워커의 영향 없이 서버 응답만 확인할 수 있습니다. 브라우저에서는 실패하는데 터미널에서는 성공한다면 원인은 서버가 아니라 브라우저 쪽 환경입니다.

요청 목록 전체를 남기려면 Network 탭의 내려받기 아이콘으로 HAR 파일을 저장합니다. 다만 HAR에는 인증 토큰과 쿠키가 그대로 담기므로 공유하기 전에 민감한 값을 지워야 합니다.

확인 후 정리해 두면 좋은 것

원인을 찾았다면 같은 증상이 다시 나왔을 때를 대비해 짧게 기록을 남겨 두는 편이 좋습니다. 어떤 요청이 어떤 상태 코드로 실패했고, 어느 설정을 바꿔 해결했는지 세 줄이면 충분합니다.

반복해서 등장하는 유형이 있다면 배포 절차 자체를 손봐야 할 신호입니다. 빌드 결과물 누락이나 경로 대소문자 문제는 배포 스크립트에서 한 번 걸러 주면 이후로는 발생하지 않습니다.

브라우저 확장 프로그램이 원인이었던 사례는 사용자 안내 문구로 정리해 두면 문의 대응 시간이 줄어듭니다. 개발자 도구 Network 오류의 상당수는 코드 수정이 아니라 환경 안내로 마무리됩니다.

개발자 도구 Network 오류를 좁히는 점검 순서

아래 순서는 위에서부터 차례대로 확인하도록 정리한 것입니다. 앞 단계에서 원인이 드러나면 뒤 단계는 건너뛰어도 됩니다.

1단계 · 기록을 켠 상태로 다시 재현

Network 탭을 열기 전에 발생한 요청은 목록에 남지 않습니다. 탭을 먼저 열고 Preserve log를 켠 다음 문제 상황을 다시 만들어야 합니다.

화면 이동이 끼어 있는 경우에는 Preserve log를 켜지 않으면 목록이 초기화되어 개발자 도구 Network 오류를 놓치게 됩니다.

2단계 · 실패한 요청만 걸러 내기

필터 줄에서 상태별 보기를 쓰면 성공한 요청을 화면에서 걷어 낼 수 있습니다. 목록이 수백 건이라도 실패만 남기면 확인할 대상이 몇 건으로 줄어듭니다.

같은 주소가 반복해서 실패한다면 요청을 만드는 코드가 재시도하고 있을 가능성이 큽니다.

3단계 · 요청 한 건을 끝까지 읽기

실패한 요청을 선택해 Headers, Payload, Response, Timing을 차례로 확인합니다. 요청 주소가 의도한 주소와 같은지, 인증 헤더가 실려 있는지부터 봅니다.

Response 탭에 서버가 남긴 메시지가 있으면 원인이 그대로 적혀 있는 경우가 많습니다.

4단계 · 요청을 만든 위치 확인

Initiator 열을 누르면 어느 스크립트의 몇 번째 줄이 요청을 만들었는지 볼 수 있습니다. 예상하지 못한 파일이 나온다면 플러그인이나 외부 스크립트가 개입한 것입니다.

요청을 만든 위치를 특정하면 서버가 아니라 코드 쪽에서 해결해야 하는 문제인지 판단할 수 있습니다.

5단계 · 브라우저 밖에서 같은 요청 보내기

Copy as cURL로 복사한 명령을 터미널에서 실행해 결과를 비교합니다. 두 결과가 다르면 브라우저 환경이 원인이고, 같으면 서버 쪽 문제입니다.

이 한 번의 비교로 확인 범위가 크게 줄어들기 때문에 순서상 뒤로 미루지 않는 편이 좋습니다.

6단계 · 다른 환경에서 재현 여부 확인

시크릿 창과 다른 브라우저에서 같은 동작을 반복해 봅니다. 시크릿 창에서 정상이라면 확장 프로그램이나 남아 있는 캐시가 원인입니다.

모든 환경에서 같은 개발자 도구 Network 오류가 보인다면 서버나 정책 설정을 확인하는 편이 빠릅니다.

내 상황에 맞는 개발자 도구 Network 오류 판단 기준

Status에 숫자가 있다 — 서버까지 도달한 요청입니다. 서버 경로와 로그를 확인합니다.
Status에 숫자가 없다 — 브라우저 또는 네트워크 구간에서 끊겼습니다. Console 탭의 메시지를 함께 읽습니다.
Console에 출처 관련 문구가 있다 — 다른 출처 요청 정책 문제이므로 서버 응답 헤더를 손봐야 합니다.
시크릿 창에서는 정상이다 — 확장 프로그램이나 브라우저 캐시가 원인입니다.
특정 네트워크에서만 실패한다 — 방화벽이나 사내 프록시 정책을 확인합니다.

개발자 도구 Network 오류를 확인하는 5단계 체크리스트

실패한 요청만 필터로 걸러냅니다. 목록이 길수록 이 과정이 시간을 크게 줄여 줍니다.
Status 열에 숫자가 있는지 확인합니다. 서버 문제와 브라우저 문제를 가르는 가장 빠른 기준입니다.
Console 탭을 함께 엽니다. 차단된 요청은 이유가 여기에 문장으로 출력됩니다.
Initiator를 눌러 요청을 만든 코드를 찾습니다. 수정할 파일 위치가 바로 특정됩니다.
시크릿 창에서 재현해 봅니다. 여기서 정상이면 확장 프로그램이나 캐시가 원인입니다.

개발자 도구 Network 오류에서 흔히 생기는 오해 3가지

첫 번째, 붉은 줄이 있으면 사이트가 고장 났다고 보는 시각입니다. 광고나 분석 스크립트가 차단되어 붉게 표시되는 경우는 화면 동작과 무관합니다. 실제로 기능이 멈추는지 먼저 확인하는 편이 순서에 맞습니다.

두 번째, 서버 로그만 보면 원인을 알 수 있다는 생각입니다. 브라우저가 차단한 요청은 서버에 기록이 남지 않습니다. 로그가 비어 있다는 사실 자체가 중요한 단서입니다.

세 번째, 새로 고침만 하면 목록이 정확해진다는 판단입니다. 캐시가 살아 있으면 일부 요청은 아예 발생하지 않습니다. Disable cache를 켜고 다시 측정해야 실제 요청 흐름이 보입니다.

마지막으로 덧붙이면, 목록에 붉은 줄이 하나도 없다고 해서 화면이 정상이라는 뜻은 아닙니다. 모든 요청이 200으로 끝났는데도 응답 본문이 비어 있거나 형식이 어긋나면 화면은 그대로 비어 보입니다. 이 경우에는 Network 탭이 아니라 Console 탭과 Response 탭을 함께 봐야 합니다.

개발자 도구 Network 오류 자주 묻는 질문

Network 탭을 열어도 목록이 비어 있습니다

개발자 도구를 연 뒤에 발생한 요청만 기록되기 때문입니다. 도구를 열어 둔 상태로 페이지를 새로 고치면 목록이 채워집니다.

붉은 줄이 매번 다른 파일에서 생깁니다

네트워크 상태가 불안정하거나 서버가 동시 요청을 감당하지 못하는 상황일 수 있습니다. Timing 구간을 비교해 대기 시간이 긴지 확인해 보십시오.

모바일에서도 같은 방법으로 확인하나요

휴대전화를 컴퓨터에 연결해 원격 디버깅으로 같은 화면을 볼 수 있습니다. 브라우저 설정에서 원격 대상 목록을 열면 연결된 기기의 탭이 표시됩니다.

실패한 요청을 다시 보내 볼 수 있나요

요청을 오른쪽 버튼으로 누르면 명령어 형태로 복사하는 기능이 있습니다. 이를 터미널에서 실행하면 브라우저 밖에서도 같은 요청을 재현할 수 있습니다.

워드프레스에서 자주 보이는 유형은 무엇인가요

플러그인 교체 후 남은 옛 경로 참조, 테마 파일 누락, 관리자 화면의 비동기 요청 실패가 흔합니다. 세 경우 모두 Status 숫자가 함께 표시됩니다.

Console과 Network 중 어디를 먼저 봐야 하나요

Network에서 어떤 요청이 실패했는지 목록을 먼저 잡고, 그 이유를 Console에서 읽는 순서가 효율적입니다.

숫자 없이 failed만 표시됩니다

요청이 서버에 닿기 전에 끊겼다는 뜻입니다. 도메인 이름 해석, 인증서, 방화벽 순서로 확인하면 원인이 대부분 드러납니다.

요청이 두 번씩 보내집니다

사전 확인 요청이 함께 나가거나 코드가 재시도하는 경우입니다. Initiator 열을 보면 두 요청을 만든 위치가 같은지 다른지 알 수 있습니다.

Timing 탭의 대기 시간이 유독 깁니다

서버가 응답을 만드는 데 시간이 걸린다는 뜻입니다. 이때는 개발자 도구 Network 오류가 아니라 서버 처리 성능을 살펴야 합니다.

편집팀 노트 — 개발자 도구 Network 오류를 직접 따져보며 정리한 기준

이 글을 정리하면서 편집팀은 같은 화면을 여러 조건으로 바꿔 가며 요청 목록을 관찰했습니다. 가장 자주 시간을 뺏긴 지점은 붉은 줄을 모두 같은 문제로 묶어서 본 습관이었습니다.

숫자가 있는 실패와 숫자가 없는 실패는 확인해야 할 곳이 아예 다릅니다. 이 둘을 먼저 갈라 놓으면 개발자 도구 Network 오류를 읽는 시간이 눈에 띄게 줄어듭니다.

또 하나 정리해 둔 기준은 목록을 넓게 보지 않고 한 건을 끝까지 읽는다는 점입니다. 요청 하나의 Headers와 Response를 끝까지 확인하면 목록 전체를 훑는 것보다 답이 빨리 나옵니다.

마지막으로 재현 조건을 기록해 두는 습관을 권합니다. 브라우저, 로그인 여부, 회선까지 함께 적어 두면 같은 증상이 다시 생겼을 때 확인 순서를 처음부터 다시 만들 필요가 없습니다.

핵심 요약

개발자 도구 Network 오류는 하나의 증상이 아니라 여러 원인의 묶음입니다. Status 열에 숫자가 있는지로 서버 문제와 브라우저 문제를 먼저 가르고, Console 메시지와 Initiator, Timing을 차례로 확인하면 대부분의 사례에서 원인 위치가 특정됩니다.

붉은 줄이 있다고 해서 반드시 화면이 망가지는 것은 아닙니다. 실제 기능에 영향을 주는 요청인지 먼저 판단하고, 그다음에 수정 범위를 정하는 순서를 권합니다. 이 글은 정보 제공을 위한 정리이며, 실제 조치는 사용 중인 서버와 브라우저 환경에 맞춰 확인하시기 바랍니다.