증상
스크립트나 AI 코딩 도구(Codex, Claude Code 등) 내부의 스킬을 사용해 자신의 컴퓨터에서 이미지를 생성할 때 다음과 같은 현상이 나타납니다.- 1K 및 2K 이미지는 대부분 돌아오지만, 4K 이미지 또는 참조 이미지가 여러 장 포함된 요청은 도착하지 않는 경우가 많습니다
- 프로그램에 오류가 전혀 표시되지 않고 자체 타임아웃(600초, 900초)이
read timed out와 함께 발생하거나 프로그램을 종료할 때까지 계속 기다립니다 - 기다리는 동안 아무것도 도착하지 않습니다. 단 한 바이트도, 응답 헤더(HTTP 상태 코드)조차 도착하지 않습니다
- 호출 로그에서 해당 요청은 제출 후 30~90초가 지나 실패로 표시되었으며, 오류 코드
write_response_body_failed가 기록되고 과금되지 않았습니다 - 프로그램이 프록시를 우회해 직접 연결합니다.
NO_PROXY또는trust_env=False를 설정했거나, 프록시 앱에서apiyi.com에 대한 직접 연결 규칙을 추가했습니다
짧은 답변
이미지는 이미 생성되었습니다. 컴퓨터로 돌아오는 도중 유실되었습니다.4K 이미지 응답은 수십 MB에 달합니다. 일부 가정용 광대역 네트워크와 사무실 네트워크에서는 해외 노드에 직접 연결할 경우, 이처럼 큰 응답을 수십 KB 정도 받는 도중 연결이 끊깁니다. 서버 측에서는 연결이 끊긴 것으로 확인되지만 컴퓨터에는 아무것도 도착하지 않아 프로그램이 계속 대기합니다. 이미지 요청을 프록시(VPN)를 통해 라우팅하면 대개 해결됩니다. 이러한 실패에는 과금되지 않습니다.
이런 문제가 발생하는 이유
스트리밍을 사용하지 않는 이미지 요청은 마지막에 결과를 한꺼번에 반환합니다.
조사한 사례에서는 서버가 40-60초 안에 이미지 생성을 마친 뒤 결과를 전송하기 시작했습니다. 응답 헤더와 처음 64-135 KB는 이미 전송된 상태였고, 약 1초 후 연결이 끊겼습니다. 고객의 프로그램은 0바이트를 수신했고 “연결 종료” 신호도 받지 못해 자체 타임아웃이 발생할 때까지 대기했습니다. 같은 시간 동안 다음과 같은 현상이 나타났습니다.
- 같은 컴퓨터에서 요청한 작은 1K 및 2K 이미지는 대부분 정상적으로 도착했습니다.
- 같은 계정에서 프록시를 통해 전송한 요청은 40-50 MB 크기의 4K 이미지가 거의 모두 전달됐습니다.
curl을 사용하거나 브라우저에서 연결을 테스트하면 이러한 연결에서도 정상으로 보입니다(작은 요청은 1초도 안 되어 반환됨). 따라서 직접 원인을 파악하기 어렵습니다.
이는 프록시 사용 시 약 90초 후 이미지 호출이 끊기나요?와 정반대의 상황입니다. 해당 사례에서는 이미지 응답을 기다리며 유휴 상태인 프록시가 연결을 끊으므로 직접 연결하는 것이 해결 방법입니다. 여기서는 대용량 응답을 전송하지 못하는 것이 직접 연결이므로 프록시를 사용하는 것이 해결 방법입니다. 어떤 경로가 적합한지는 아래 비교 테스트를 통해 판단할 수 있습니다.
확인 방법
1
호출 로그 확인
호출 로그에서 해당 시간대를 찾습니다. 프로그램이 계속 대기 중인데 로그에 이미 실패한
write_response_body_failed 레코드가 표시된다면, 서버가 이미지 처리를 마치고 이미지를 전송하기 시작한 것입니다. 전송 도중 연결이 끊겼습니다.2
이미지가 클수록 실패율이 높아지는지 확인
같은 prompt와 참조 이미지를 사용했을 때 1K / 2K는 돌아오지만 4K는 돌아오지 않는다면, 이것이 원인일 가능성이 매우 높습니다.
3
프로그램이 실제로 프록시를 사용하는지 확인
많은 AI 코딩 도구는 시스템 프록시를 읽지 않는 Python / Node 자식 프로세스를 실행합니다. Clash를 글로벌 모드로 설정해도 이러한 프로세스는 직접 연결할 수 있습니다. 같은 터미널이나 도구에서 다음을 실행합니다.로컬 광대역 IP가 출력되면 해당 환경의 요청은 직접 전송됩니다.
4
4K 이미지 몇 개로 프록시와 직접 연결을 번갈아 테스트
프록시, 직접 연결, 프록시, 직접 연결 순으로 번갈아 실행합니다. 한쪽 방식으로 5회 실행한 다음 다른 방식으로 5회 실행하지 마세요. 일시적인 네트워크 변동으로 잘못 판단할 수 있습니다. 프록시를 사용한 실행은 안정적으로 성공하고 직접 연결한 실행은 자주 멈춘다면 원인이 확인된 것입니다.
해결 방법
- 프로그램이 프록시를 통과하도록 설정합니다(권장)
- 프록시 앱에서 TUN 모드를 켭니다
- 일단 응답 크기를 줄입니다
프로그램이 프록시를 우회하게 만드는 설정을 모두 제거하여 이미지 요청이 프록시를 통과하도록 합니다.
NO_PROXY에서apiyi.com제거- Python
requests/httpx:trust_env=False제거 - Python
urllib:ProxyHandler({})로 opener를 만들지 않습니다 - Node.js: 기본적으로 네이티브
fetch는 프록시를 사용하지 않습니다.ProxyAgent같은 라이브러리로 프록시를 명시적으로 지정합니다
적절한 타임아웃도 설정합니다
이 상황에서는 프로그램이 연결 끊김 신호를 받지 못하므로, 자체 타임아웃만이 실패를 감지할 방법입니다. 타임아웃을 900초로 설정하면 요청이 실패했다는 사실을 확인하는 데 15분을 기다려야 합니다. 비스트리밍 이미지 요청은 이미지 생성 중에 데이터를 전송하지 않으므로, 읽기 타임아웃은 생성 시간보다 짧게 설정할 수 없습니다. 일반적인 생성 시간보다 조금 더 길게 설정합니다. 4K는 약 300초, 1K/2K는 약 180초입니다. 타임아웃이 발생하면 먼저 호출 로그를 확인하여 요청에 과금되었는지 살펴본 다음 재시도 여부를 결정합니다. 이렇게 하면 같은 이미지를 두 번 생성하지 않습니다.서버에 배포한 후에도 이런 현상이 발생하나요?
중국 본토 또는 해외의 클라우드 서버에서 APIYI까지 연결하는 회선은 일반적으로 가정용 광대역보다 훨씬 안정적이므로, 이 문제는 주로 로컬 개발 환경에서 발생합니다. 서버에서도 “헤더는 도착하지만 본문이 중간에 끊기는” 현상이 발생한다면 이미지 API 연결 끊김 문제 해결을 참고하세요.일반적인 질문
이러한 실패한 요청에도 과금되었습니까?
이러한 실패한 요청에도 과금되었습니까?
아닙니다. 호출 로그에
write_response_body_failed로 기록된 요청에는 과금되지 않습니다. 각 로그 기록에 표시된 요금이 정확한 과금 내역입니다.api.apiyi.com에 직접 연결하는 테스트는 성공합니다. 왜 회선 문제라고 보십니까?
api.apiyi.com에 직접 연결하는 테스트는 성공합니다. 왜 회선 문제라고 보십니까?
연결 테스트는 수백 바이트만 송수신하며 1초도 걸리지 않습니다. 수십 MB의 응답을 전송할 때만 문제가 발생하므로, 작은 요청으로는 이를 확인할 수 없습니다.
프로그램을 강제 종료한 뒤에도 서버가 계속 생성 작업을 진행합니까?
프로그램을 강제 종료한 뒤에도 서버가 계속 생성 작업을 진행합니까?
요청을 제출하면 서버는 평소처럼 이미지를 생성합니다. 따라서 프로그램을 강제 종료한 뒤 바로 재시도하면 두 요청의 생성 작업이 동시에 진행될 수 있습니다. 다만 여기서 설명한 상황에서는 프로그램을 강제 종료할 즈음이면 서버가 이미 이미지 생성을 마쳤지만 응답을 전송하는 데 실패한 경우가 대부분이므로 과금되지 않습니다.
4K에만 문제가 발생해야 하는데, 왜 가끔 2K에서도 응답이 멈춥니까?
4K에만 문제가 발생해야 하는데, 왜 가끔 2K에서도 응답이 멈춥니까?
응답이 클수록 전송이 끊길 가능성은 커지지만, 특정 크기를 넘으면 항상 실패하는 것은 아닙니다. 2K 응답도 여전히 몇 MB에 달하므로, 회선 상태가 좋지 않으면 문제가 발생할 수 있습니다. 다만 그 빈도는 훨씬 낮습니다.
관련 문서
프록시를 통해 이미지 호출이 약 90초 후에 중단되나요?
반대 상황입니다. 프록시가 유휴 연결을 닫습니다. 직접 연결하여 해결하세요.
이미지 API 연결 끊김 문제 해결
write_response_body_failed, SSL EOF 및 기타 연결 끊김 오류에 대한 전체 문제 해결 안내
로그에는 호출이 완료되고 과금되었다고 표시되지만 클라이언트가 응답을 받지 못했습니다. 어떻게 문제를 해결하나요?
로그에 기록된 처리 시간과 클라이언트의 대기 시간 사이에 차이가 발생하는 이유
호출 기록을 확인하는 방법
시간 범위별로 각 요청의 상태와 요금을 확인합니다.