fetch()에 404가 왔는데 catch가 안 돈다면?

fetch()는 404나 500 같은 HTTP 오류 상태만으로 반환한 Promise를 거부하지 않습니다. 응답을 받았다는 사실과 HTTP 성공 여부는 다릅니다. response.ok로 상태를 확인한 뒤 본문을 읽으면, HTTP 오류와 JSON 파싱 오류를 나눠 볼 수 있습니다.

AI가 만든 호출 코드에 try...catch가 있는데도 오류 본문을 정상 데이터처럼 넘긴다면, catch를 더 붙이기 전에 이 순서를 보세요.

404인데 JSON도 읽히는 경우

다음은 실제 서비스가 아니라, Node.js v26.5.0에서 조건을 고정한 로컬 합성 서버로 확인한 결과입니다. 서버가 404와 함께 올바른 JSON 문법의 오류 본문을 보냈습니다.

HTTP 상태: 404
response.ok: false
response.json() 결과: {"error":"synthetic missing item"}

fetch()와 json()의 Promise가 모두 이행돼도, HTTP 상태는 여전히 404입니다. 파싱할 수 있는 오류 본문을 받았을 뿐, 요청한 자료가 정상적으로 왔다는 뜻은 아닙니다.

응답을 받는 일과 HTTP 성공 여부는 다릅니다. 설명을 위한 생성 일러스트입니다.

응답 수신, 상태 확인, 본문 읽기는 별개입니다

MDN의 Window.fetch() 문서는 HTTP 오류 상태가 반환돼도 Promise가 거부되지 않는다고 설명합니다. 거부되는 요청 실패와, 응답 안에 적힌 오류 상태를 구분해야 합니다.

Response.ok의 기준은 상태 코드 200~299입니다. 본문이 올바른 JSON인지, 그 안의 값이 업무 조건에 맞는지까지 검사하는 속성은 아닙니다.

어느 단계가 성공했는지 구분해야 다음에 볼 곳도 달라집니다. 설명용 생성 이미지입니다.

HTTP 상태를 먼저 검사하는 작은 예시

아래는 성공 본문이 JSON인 GET 응답을 다루는 시험용 함수입니다. 2xx가 아니면 상태를 담은 오류를 먼저 던지고, 상태가 허용될 때만 본문을 JSON으로 읽습니다.

class HttpStatusError extends Error {
  constructor(status){super('HTTP '+status);this.name='HttpStatusError';this.status=status;}
}
async function checkedJson(url){
  const response=await fetch(url);
  if(!response.ok){
    const status=response.status;
    await response.body?.cancel();
    throw new HttpStatusError(status);
  }
  return response.json();
}

이 함수를 호출하는 쪽에서 await checkedJson(url)을 try 블록 안에 두면, 상태 검사에서 던진 오류도 catch로 전달됩니다. 여기서는 오류 본문을 보관하지 않고 스트림을 닫습니다. 서버가 보낸 자세한 오류 정보까지 남겨야 하는 앱에 그대로 쓰는 완성형 클라이언트는 아닙니다.

같은 404라도 먼저 읽은 것에 따라 오류가 달라집니다

합성 응답	바로 json()을 읽음	상태를 먼저 검사
404 + 유효한 JSON	JSON 값 반환	HttpStatusError, 404
404 + HTML	SyntaxError	HttpStatusError, 404
200 + 깨진 JSON	SyntaxError	SyntaxError
응답 전 소켓 단절	fetch 단계에서 TypeError	fetch 단계에서 TypeError

404 HTML을 먼저 JSON으로 읽으면, 문법 오류가 앞에 나타나 HTTP 상태를 놓치기 쉽습니다. 상태를 먼저 검사한 함수는 같은 응답을 HTTP 404로 구분했습니다. 반면 200의 깨진 JSON은 상태 검사를 통과한 뒤에도 파싱에 실패했습니다.

상태가 같아도 본문 형식은 다를 수 있습니다. 실제 응답 화면이 아닌 생성 설명 그림입니다.

Response.json() 문서는 본문을 JSON으로 파싱할 수 없을 때 SyntaxError가 난다고 설명합니다. 따라서 catch에 들어왔다는 사실만 보지 말고, 응답을 받기 전인지, HTTP 상태 검사인지, 본문 파싱인지를 나누는 편이 낫습니다.

소켓을 끊은 시험에서 TypeError가 났다는 것은 그 조건의 관측입니다. 모든 TypeError를 네트워크 문제로 단정하면 안 됩니다. MDN은 잘못된 요청 URL 등 다른 원인도 함께 설명합니다.

확인한 범위와 다음 질문

2026년 10월 21일, Windows x64의 Node.js v26.5.0에서 기본 fetch와 127.0.0.1 합성 GET 응답으로 시험했습니다. 실제 서비스의 인증·결제·재시도 복구, 브라우저 CORS 동작은 시험하지 않았습니다.

HTTP 상태와 JSON 파싱을 통과했어도 값 자체의 검산은 남습니다. 그다음 단계는 JSON 파싱 성공과 합계의 정확성을 구분한 글로 이어집니다. 상태 검사로 서버의 404가 고쳐지는 것은 아닙니다. 적어도 실패 응답을 성공 데이터처럼 넘기는 지점을 구분하는 데 목적이 있습니다.

출처 및 확인일

• MDN Web Docs, Window: fetch() method. 원문 게시일 미확인. https://developer.mozilla.org/en-US/docs/Web/API/Window/fetch
• MDN Web Docs, Response: ok property. 원문 게시일 미확인. https://developer.mozilla.org/en-US/docs/Web/API/Response/ok
• MDN Web Docs, Response: json() method. 원문 게시일 미확인. https://developer.mozilla.org/en-US/docs/Web/API/Response/json

문서 확인: 2026-10-21 KST. 공식 API 설명, 조건을 고정한 Node.js 실행 결과, 설명용 생성 이미지를 구분했습니다.