업스트림 연결 오류? 실제로 무엇이 잘못됐는지 알아보기

upstream connect error or disconnect/reset before headers가 ChatGPT 또는 OpenAI API에서 표시된다면, 이는 OpenAI 측의 문제입니다. 이 메시지는 OpenAI의 엣지에 있는 프록시인 Envoy에서 발생하며, Envoy가 OpenAI 백엔드로부터 사용할 수 있는 응답을 가져오지 못했다는 뜻입니다. ChatGPT 웹사이트에서는 이 내용이 종종 *Error Code 111*로 표시됩니다. reset reason: 뒤의 텍스트가 실제 진단 내용이며, before headers는 프록시가 응답 헤더가 하나도 도착하기 전에 포기했다는 뜻입니다. 즉, 그 503 뒤에는 실제 응답이 있는 것이 아니라 Envoy 자체의 응답만 있습니다. OpenAI의 인프라는 직접 고칠 수 없지만, 다음에 무엇을 해야 하는지는 reset reason과 브라우저에서 발생했는지 코드에서 발생했는지에 따라 달라집니다.

어느 경로에 있습니까:

ChatGPT 웹/앱: status.openai.com를 확인한 다음, 새로고침하거나 새 세션을 시작하세요.
코드의 OpenAI API: 재설정 이유를 읽고, 요청 ID를 캡처한 다음, 재시도 정책을 적용하세요.

Diagram showing the client, Envoy proxy, and upstream service, with the error emitted at the Envoy hop about the upstream connection

이 오류가 실제로 의미하는 것

Envoy는 사용자와 OpenAI의 백엔드 사이에 위치합니다. 요청이 도착하면 Envoy는 백엔드에 연결을 열고, 요청을 전달한 다음 응답 헤더를 기다립니다. 헤더가 돌아오기 전에 해당 연결이 실패하거나, 재설정되거나, 시간 초과되거나, 용량 제한에 걸리면 Envoy는 HTTP 503(때로는 502)과 함께 이 메시지를 반환합니다. 이는 ChatGPT 장애 화면, openai.InternalServerError 스택 트레이스, 그리고 에이전트 로그에 나타납니다.

표현은 다를 수 있습니다: retried and the latest reset reason라는 문구는 Envoy가 이미 재시도했으며 이것이 마지막 시도의 실패였음을 의미합니다. 어느 경우든, OpenAI의 프록시가 자체 백엔드가 응답하지 않았다고 보고하는 것이며, 이는 사용자의 프롬프트나 요청 본문의 문제는 아닙니다.

재설정 이유 해독

재설정 이유는 OpenAI의 프록시가 무엇을 만났는지, 따라서 재시도가 가치가 있는지를 알려줍니다.

reset reason	OpenAI의 프록시가 감지한 것	할 수 있는 일
`connection timeout`	백엔드가 제시간에 연결을 수락하기에 너무 느림	백오프를 적용해 재시도; 상태 확인
`overflow`	용량 또는 속도 제한에 도달함(백엔드 과부하)	동시성을 낮추고, 잠시 기다린 뒤 재시도
`connection failure` / `remote connection failure`	백엔드에 도달할 수 없거나 연결을 거부함	재시도; 계속되면 상태를 확인하고 보고
`connection termination` / `connection reset`	백엔드가 요청 도중 연결을 종료함	재시도; 보통 사고와 함께 발생함
`protocol error`	OpenAI 측의 프로토콜 문제	재시도; 지속되면 요청 ID와 함께 보고

overflow와 connection timeout은 OpenAI 커뮤니티 보고에서 가장 자주 언급되는 두 가지로, 버스트성 부하에서 백엔드가 용량 한계에 도달하는 상황과 잘 맞습니다. 이 중 어떤 것도 사용자 기기에서의 조치로 해결되지 않습니다. 유용한 대응은 상태 확인, 백오프, 그리고 장애 조치입니다.

ChatGPT 웹사이트 또는 앱에서 (오류 코드 111)

먼저 status.openai.com을 확인하세요. 장애 공지가 올라와 있다면, 기다리는 것이 주된 해결책입니다. 다만 특정 계정에서만 지속되는 오류라면 지원팀에 보고할 가치가 있습니다. 상태가 정상이라면 페이지를 새로고침하거나, 새 탭을 열거나, 로그아웃했다가 다시 로그인하세요 — 오래된 세션이 끊어진 연결을 계속 유지할 수 있습니다. 네트워크를 바꾸거나 VPN 또는 회사 프록시를 비활성화하는 것은 해당 계층이 연결을 재설정하고 있을 때만 도움이 되므로, OpenAI의 문제라고 단정하기 전에 먼저 시도해 보세요.

코드에서 OpenAI API로

여기서 오류는 간헐적이며 부하에 따라 달라집니다. openai-python 이슈 트래커의 한 개발자는 한 시간에 수백 건의 요청을 보내는 동안 호출의 약 5%가 openai.InternalServerError: upstream connect error or disconnect/reset before headers로 실패했다고 보고했으며, 나머지 95%는 성공했습니다. 이처럼 부분적인 실패율은 백엔드 포화 상태를 가리키며, 배치 작업이 많은 작업(대량 임베딩, 대규모 문서 수집)은 동시성을 더 높이기 때문에 이 문제를 더 자주 겪습니다. 보통 해결책은 페이로드 변경이 아니라 재시도 정책이며, 다만 동시성을 조정하고 대량 작업을 큐잉하는 것도 높은 부하에서는 그만큼 중요합니다.

에스컬레이션하기 전에, 그것이 제공자 측 문제임을 입증할 수 있을 만큼 충분한 정보를 수집하세요: 타임스탬프, 엔드포인트와 모델, HTTP 상태와 본문, x-request-id, 사용 중인 SDK 버전, 진행 중인 요청 수, 그리고 장애가 게시된 incident와 일치하는지 여부입니다. 그런 다음 운영 환경에서 견딜 수 있는 재시도 정책을 적용하세요:

import random, time
from openai import OpenAI, APIStatusError, APIConnectionError

client = OpenAI()

def with_retry(fn, max_attempts=5, cap=30.0):
    for attempt in range(max_attempts):
        try:
            return fn()
        except (APIConnectionError, APIStatusError) as e:
            status = getattr(e, "status_code", None)
            # 연결 끊김과 5xx(이 503 포함)만 재시도; 4xx는 절대 무작정 재시도하지 않음
            if isinstance(e, APIStatusError) and status and status < 500 and status != 429:
                raise
            if attempt == max_attempts - 1:
                raise
            retry_after = float(getattr(e, "response", None).headers.get("retry-after", 0)) if getattr(e, "response", None) else 0
            backoff = retry_after or min(cap, 0.5 * 2 ** attempt) * (0.5 + random.random())
            time.sleep(backoff)

OpenAI SDK는 이미 일시적 오류를 자체적으로 재시도합니다(max_retries, 기본값 2). 따라서 호출을 감싸기 전에 이를 의도적으로 설정하세요 — 예를 들어 OpenAI(max_retries=0) — 그렇지 않으면 여러분의 레이어와 SDK의 재시도가 중첩됩니다. 총 시도 횟수(3–5회)와 전체 동시성을 제한하여 재시도가 overflow를 유발한 버스트를 증폭시키지 않도록 하세요. 429는 Retry-After를 따르세요. 408/409는 작업을 안전하게 반복할 수 있을 때만 재시도하세요. 비멱등적이거나 스트리밍 호출은 주의하세요 — 무분별한 재시도는 작업을 중복 수행하거나 절반만 소비된 스트림을 다시 재생할 수 있습니다.

클라이언트 측에서 보이는 모습

Envoy의 503 본문은 아예 보지도 못하는 경우가 많습니다 — 연결이 먼저 끊어지기 때문입니다. 죽은 엔드포인트에 대해 curl -v를 실행하면 Request completely sent off 다음에 curl: (52) Empty reply from server가 반환됩니다: 요청은 나갔지만, 아무것도 돌아오지 않은 것입니다. Envoy 자체에서 이 오류를 표현하는 방식은 본문으로 upstream connect error... 텍스트를 담은 503입니다. 공개된 보고도 이를 뒷받침합니다. OpenAI 서브레딧에서 한 사용자는 "Network connection lost"와 함께 정확히 retried and the latest reset reason: connection timeout 문자열을 게시했고, openai-python 트래커에는 높은 요청량에서 동일한 메시지가 InternalServerError로 기록되어 있습니다.

언제 우회해야 하는가

실패하는 홉이 OpenAI의 게이트웨이와 그 백엔드 사이에 있기 때문에, 단일 엔드포인트에 대해 할 수 있는 것은 재시도하고 지수 백오프를 적용하는 것뿐입니다. 다른 수단은 중복성입니다. 즉, 상위 계층 중 하나가 타임아웃되거나 넘칠 때 다른 백엔드로 장애 조치하는 레이어를 통해 라우팅하는 것입니다. OpenRouter와 AIReiter 같은 멀티 제공자 게이트웨이는 여러 모델 제공자를 앞단에 두고 느린 제공자를 우회하며, OpenRouter가 기반으로 삼는 동일한 멀티 제공자 라우팅 모델을 사용하므로, 상위 계층 하나가 느려져도 표면화된 503 대신 재라우팅으로 처리될 수 있습니다. 그 절충은 분명합니다 — 홉이 하나 더 추가되고, 라우터 자체의 가동 시간에 의존하며, 가격, 데이터 처리, 관찰 가능성의 차이도 따져봐야 합니다 — 하지만 이는 특정 제공자 하나의 불안정성에 대한 노출을 줄여줍니다.

자주 묻는 질문

ChatGPT 오류 코드 111이란?

일부 ChatGPT 사용자는 "Error Code 111"이라는 레이블과 함께 이 메시지가 표시된다고 보고합니다. 이는 OpenAI의 프록시가 백엔드로부터 응답을 받지 못했다는 의미이며, 서버 측 문제입니다. status.openai.com을 확인하고 새로고침하세요.

왜 부하가 걸릴 때만 또는 아무 때나 발생하나요?

로드 의존적 실패는 일반적으로 overflow(용량 또는 속도 제한) 또는 백엔드 포화로 인해 연결 시간이 타임아웃을 넘는 것을 의미합니다. 둘 다 동시성이 높아질 때만 나타나므로, 같은 코드가 대부분의 시간에는 잘 동작하는 이유입니다.

VPN이나 방화벽이 원인인가요?

그 레이어가 귀하와 OpenAI 사이의 연결을 재설정하는 원인인 경우에만 그렇습니다. 네트워크를 전환하여 원인을 배제해 볼 가치는 있지만, 실제 OpenAI 장애나 API 측 503 오류는 해결되지 않습니다.

이것은 429 rate-limit 오류와 같은 것인가요?

아니요. 429는 명시적인 rate-limit 응답입니다. 이 503은 아예 사용할 수 있는 응답이 돌아오지 않았음을 의미합니다. 429에서는 Retry-After를 준수하고, 503에서는 지수적으로 대기한 뒤 재시도하세요.

"retried and the latest reset reason"은 무슨 뜻인가요?

Envoy는 이미 요청을 재시도했으며, 이것이 최종 시도가 실패한 이유입니다. 이는 일회성 장애가 아니라 OpenAI 측의 지속적인 백엔드 문제를 가리킵니다.