🌐 httpbin.org 503 / CORS 콘솔 에러 — 네트워크 품질 체크 원인 분석

근본 원인 외부 무료 테스트 서비스 httpbin.org 의 503 Service Unavailable. httpbin.org 는 공개 무료 서비스라 과부하·다운이 잦고, 현재 503 을 반환 중. 우리 코드 버그가 아님.

CORS 는 503 의 부수 증상 httpbin 이 503 에러를 낼 때 그 에러 응답에는 Access-Control-Allow-Origin 헤더가 없다. 그래서 mode: "cors" 요청의 응답 읽기가 브라우저에 의해 차단 → CORS 에러 + ERR_FAILED 까지 같이 찍힘. 즉 CORS 에러는 별개 문제가 아니라 503 응답의 헤더 부재에서 파생된 것.

서비스 영향 없음 리소스 다운로드 · AI 세션 · 미디어 서버 어디에도 영향 없음. 호출은 try/catch 로 감싸져 실패해도 throw 하지 않고 externalOk=false 로만 처리됨. 게다가 이 외부 체크 결과는 코드 어디서도 읽지 않는 죽은 데이터(아래 4·5장).

유일한 실질 피해 콘솔 오염(10초마다 에러 스택) 과, 외부 연결이 정상이어도 항상 비정상으로 판정되는 issue 필드 오판 — 그런데 그 issue 를 읽는 코드도 없어 사용자 영향 0.

3-1. 네트워크 품질 체크의 의도

useNetworkQuality 는 "사용자 네트워크 문제"인지 "우리 서버 문제"인지 구분하기 위해 두 곳을 동시에 측정한다:

// apps/web/shared/lib/use-network-quality.ts
async function measureExternalLatency() {            // 외부 인터넷 도달성
  await fetchWithAlert("https://httpbin.org/status/200",
    { cache: "no-store", method: "HEAD", mode: "cors" });
}
async function measureServerLatency() {              // 우리 서버 도달성
  await fetchWithAlert("/api/health",
    { cache: "no-store", method: "HEAD" });
}
// determineIssue(externalOk, serverOk):
//   external O / server X → "server"        (우리 서버 문제)
//   external X / server X → "user-network"  (사용자 망 문제)
//   external O / server O → "none"

3-2. 두 에러가 겹치는 과정

1. 503 — httpbin.org 가 과부하로 Service Unavailable 응답.
2. CORS 차단 — 503 응답에 CORS 허용 헤더가 없어, mode:"cors" 요청의 응답을 브라우저가 차단.
3. ERR_FAILED — 위 차단으로 fetch Promise reject → 콘솔 스택 출력.
4. catch 로 흡수 — use-network-quality.ts 의 try/catch 가 잡아 externalLatency=null, externalOk=false 로만 처리. 앱 흐름 영향 없음.

4-1. CORS 전파 불가 — 왜 S3 다운로드를 못 막는가

CORS 차단은 해당 요청 하나에만 적용된다. httpbin.org 로의 fetch 가 막혀도 다른 origin(S3)으로의 fetch 에는 영향이 없다. "한 origin 이 막혔으니 다른 것도 막는다" 같은 전파(cascade)나 연결 풀 공유로 인한 차단은 존재하지 않는다.

4-2. 로그 실증 — 503 구간에도 S3 25개 전부 성공

httpbin 이 503 을 반복하던 동일 시간대에 S3 영상/이미지 리소스가 전부 정상 캐싱됨:

[RESOURCE_CACHE] Successfully cached video_firstopeningJW_yoona.mp4
[RESOURCE_CACHE] Successfully cached video_pingpong01_bridge_jw01~04.mp4
... (총 25개 전부 성공, 실패 0건)
[GUEST_PAGE_SESSION] Resources cached successfully

httpbin 호출이 만들어내는 값이 어디서 소비되는지 전수 추적한 결과:

소비처 3곳(app/client-guest/page.tsx, widgets/guest/guest-layout/ui/guest-layout.tsx, components/pages/guest-entry.tsx)은 모두 .quality 와 .latency 만 사용하며, 이 둘은 전부 /api/health 기반이다.

6-1. 왜 소켓 서버(/health)로는 안 되는가

소켓 서버(socket-prod./health)는 여전히 우리 인프라다. 웹과 다른 호스트이긴 하나 동일 리전/ALB권이라, 사용자 인터넷이 끊기면 웹·소켓이 같이 실패해 "사용자 망 다운"을 가릴 수 없다. 게다가 /health는 Redis가 degraded면 503을 내므로(apps/socket/src/sfu-api/restHandlers.ts:441) 503 노이즈가 형태만 바뀐다. → C안의 기준점으로 부적합.

6-2. 채택 — 독립적·고신뢰 연결성 엔드포인트로 교체

채택 외부 체크 대상만 httpbin → 연결성 체크 전용 제3자 엔드포인트로 교체한다. 본문을 읽지 않고 도달성·지연만 재므로 mode: "no-cors"(opaque)로 호출 → CORS 차단 없음. 503이 사실상 없는 대형 인프라라 노이즈도 제거된다.

• 1순위 — https://www.gstatic.com/generate_204 (Google, 204 즉시 응답, 캡티브 포털 감지용 표준)
• 대안/병행 — https://1.1.1.1/cdn-cgi/trace (Cloudflare). 단발 제3자 장애 오탐이 걱정되면 2곳 핑 후 다수결.

async function measureExternalLatency() {
  const start = performance.now();
  // no-cors: 응답 본문은 못 읽지만 "도달 성공/실패 + 시간"은 확보, CORS 차단 없음
  await fetchWithAlert("https://www.gstatic.com/generate_204", {
    cache: "no-store",
    method: "GET",       // 204 엔드포인트는 GET 권장 (HEAD 미지원 가능)
    mode: "no-cors",
    timeoutMs: 3000,     // 100% 패킷 손실 시 무한 대기 방지
    skipSlowAlert: true,
  });
  return Math.round(performance.now() - start);
}

6-3. issue 신호 활성화 (죽은 데이터 → 실사용)

외부+서버 조합으로 determineIssue를 살려 원인을 가르고, 그 issue를 UI/알림 등 실제 소비처에 연결한다(현재는 계산만 되고 미사용 — 5장).

6-4. 함께 처리

• 두 측정 호출 모두 timeoutMs 부여 + skipSlowAlert: true
• 여러 컴포넌트에서 독립 마운트되는 useNetworkQuality를 단일/공유 인스턴스로 dedup (10초 × 인스턴스 수 중복 요청 제거)

검토했으나 미채택

• 외부 체크 제거(기존 A안) — 가장 단순하나, C안 목표(사용자 망 다운 구분)를 포기하게 됨. 진단 가치를 살리기로 결정해 미채택.
• 소켓 /health로 교체(B안) — 우리 인프라라 사용자 망 다운을 구분 못 하고 Redis-gated 503 잔존(6-1).