> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apiyi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 이미지 요청이 결과 없이 멈추지만 로그에 쓰기 실패가 표시되나요?

> 프로그램이 프록시를 우회해 APIYI에 직접 연결됩니다. 1K/2K 이미지는 정상적으로 작동하지만 대용량 4K 이미지는 오류 없이 멈추고, 호출 로그에는 과금 없이 write_response_body_failed가 표시됩니다. 직접 연결로는 수십 MB에 달하는 응답을 전송할 수 없습니다. 이미지 요청을 프록시를 통해 라우팅하세요.

## 증상

스크립트나 AI 코딩 도구(Codex, Claude Code 등) 내부의 스킬을 사용해 자신의 컴퓨터에서 이미지를 생성할 때 다음과 같은 현상이 나타납니다.

* 1K 및 2K 이미지는 대부분 돌아오지만, **4K 이미지 또는 참조 이미지가 여러 장 포함된 요청은 도착하지 않는 경우가 많습니다**
* 프로그램에 **오류가 전혀 표시되지 않고** 자체 타임아웃(600초, 900초)이 `read timed out`와 함께 발생하거나 프로그램을 종료할 때까지 계속 기다립니다
* 기다리는 동안 아무것도 도착하지 않습니다. **단 한 바이트도**, 응답 헤더(HTTP 상태 코드)조차 도착하지 않습니다
* [호출 로그](/ko/faq/call-logs)에서 해당 요청은 제출 후 **30\~90초**가 지나 실패로 표시되었으며, 오류 코드 `write_response_body_failed`가 기록되고 **과금되지 않았습니다**
* 프로그램이 **프록시를 우회해 직접 연결합니다**. `NO_PROXY` 또는 `trust_env=False`를 설정했거나, 프록시 앱에서 `apiyi.com`에 대한 직접 연결 규칙을 추가했습니다

## 짧은 답변

> [!NOTE]
>
> **이미지는 이미 생성되었습니다. 컴퓨터로 돌아오는 도중 유실되었습니다.**
>
> 4K 이미지 응답은 수십 MB에 달합니다. 일부 가정용 광대역 네트워크와 사무실 네트워크에서는 해외 노드에 직접 연결할 경우, 이처럼 큰 응답을 수십 KB 정도 받는 도중 연결이 끊깁니다. 서버 측에서는 연결이 끊긴 것으로 확인되지만 컴퓨터에는 아무것도 도착하지 않아 프로그램이 계속 대기합니다. **이미지 요청을 프록시(VPN)를 통해 라우팅하면 대개 해결됩니다.** 이러한 실패에는 과금되지 않습니다.

## 이런 문제가 발생하는 이유

스트리밍을 사용하지 않는 이미지 요청은 마지막에 결과를 **한꺼번에** 반환합니다.

| 이미지 크기 | 응답 크기(base64 인코딩 후) |
| - | - |
| 1K | 1-3 MB |
| 2K | 3-10 MB |
| 4K | 30-50 MB |

조사한 사례에서는 서버가 40-60초 안에 이미지 생성을 마친 뒤 결과를 전송하기 시작했습니다. 응답 헤더와 처음 64-135 KB는 이미 전송된 상태였고, 약 1초 후 연결이 끊겼습니다. 고객의 프로그램은 0바이트를 수신했고 “연결 종료” 신호도 받지 못해 자체 타임아웃이 발생할 때까지 대기했습니다. 같은 시간 동안 다음과 같은 현상이 나타났습니다.

* 같은 컴퓨터에서 요청한 작은 1K 및 2K 이미지는 대부분 정상적으로 도착했습니다.
* 같은 계정에서 **프록시를 통해 전송한** 요청은 40-50 MB 크기의 4K 이미지가 거의 모두 전달됐습니다.

따라서 문제는 **컴퓨터와 APIYI 사이의 직접 연결이 대용량 응답을 전송하지 못한다는 것**입니다. 모델에 문제가 생긴 것도 아니고 네트워크가 완전히 끊긴 것도 아닙니다. `curl`을 사용하거나 브라우저에서 연결을 테스트하면 이러한 연결에서도 정상으로 보입니다(작은 요청은 1초도 안 되어 반환됨). 따라서 직접 원인을 파악하기 어렵습니다.

> [!NOTE]
>
> 이는 [프록시 사용 시 약 90초 후 이미지 호출이 끊기나요?](/ko/faq/proxy-idle-timeout-disconnect)와 정반대의 상황입니다. 해당 사례에서는 이미지 응답을 기다리며 유휴 상태인 **프록시**가 연결을 끊으므로 직접 연결하는 것이 해결 방법입니다. 여기서는 대용량 응답을 전송하지 못하는 것이 **직접 연결**이므로 프록시를 사용하는 것이 해결 방법입니다. 어떤 경로가 적합한지는 아래 비교 테스트를 통해 판단할 수 있습니다.

## 확인 방법

**1. 호출 로그 확인**

[호출 로그](/ko/faq/call-logs)에서 해당 시간대를 찾습니다. 프로그램이 계속 대기 중인데 로그에 이미 실패한 `write_response_body_failed` 레코드가 표시된다면, 서버가 이미지 처리를 마치고 이미지를 전송하기 시작한 것입니다. 전송 도중 연결이 끊겼습니다.

**2. 이미지가 클수록 실패율이 높아지는지 확인**

같은 prompt와 참조 이미지를 사용했을 때 1K / 2K는 돌아오지만 4K는 돌아오지 않는다면, 이것이 원인일 가능성이 매우 높습니다.

**3. 프로그램이 실제로 프록시를 사용하는지 확인**

많은 AI 코딩 도구는 시스템 프록시를 **읽지 않는** Python / Node 자식 프로세스를 실행합니다. Clash를 글로벌 모드로 설정해도 이러한 프로세스는 직접 연결할 수 있습니다. 같은 터미널이나 도구에서 다음을 실행합니다.

```bash theme={null}
curl -s https://ipinfo.io/ip
```

로컬 광대역 IP가 출력되면 해당 환경의 요청은 직접 전송됩니다.

**4. 4K 이미지 몇 개로 프록시와 직접 연결을 번갈아 테스트**

프록시, 직접 연결, 프록시, 직접 연결 순으로 번갈아 실행합니다. 한쪽 방식으로 5회 실행한 다음 다른 방식으로 5회 실행하지 마세요. 일시적인 네트워크 변동으로 잘못 판단할 수 있습니다. 프록시를 사용한 실행은 안정적으로 성공하고 직접 연결한 실행은 자주 멈춘다면 원인이 확인된 것입니다.

## 해결 방법

**프로그램이 프록시를 통과하도록 설정합니다(권장)**

프로그램이 프록시를 우회하게 만드는 설정을 모두 제거하여 이미지 요청이 프록시를 통과하도록 합니다.

* `NO_PROXY`에서 `apiyi.com` 제거
* Python `requests` / `httpx`: `trust_env=False` 제거
* Python `urllib`: `ProxyHandler({})`로 opener를 만들지 않습니다
* Node.js: 기본적으로 네이티브 `fetch`는 프록시를 사용하지 않습니다. `ProxyAgent` 같은 라이브러리로 프록시를 명시적으로 지정합니다

자식 프로세스가 시스템 프록시를 사용하지 않는다면, 실행 전에 환경 변수에 프록시 주소를 설정합니다(포트는 프록시 앱의 HTTP 포트로 바꿉니다).

```bash theme={null}
# macOS / Linux
export HTTPS_PROXY="http://127.0.0.1:7890"
# Windows PowerShell
$env:HTTPS_PROXY="http://127.0.0.1:7890"
```

**프록시 앱에서 TUN 모드를 켭니다**

**TUN 모드**를 켜면 Clash / Clash Verge / mihomo 및 유사한 앱이 컴퓨터의 모든 프로그램에서 발생하는 트래픽을 가져옵니다. 프로그램이 시스템 프록시를 사용하는지와 관계없이 모든 트래픽이 프록시를 통과하므로, 가장 간편한 방법입니다.

이전에 [프록시 유휴 연결 끊김](/ko/faq/proxy-idle-timeout-disconnect)에 따라 `apiyi.com`에 `DIRECT` 규칙을 추가했다면 제거합니다. 그렇지 않으면 TUN 모드에서도 해당 연결은 계속 직접 연결됩니다.

**일단 응답 크기를 줄입니다**

네트워크를 변경할 수 없다면 일단 2K로 생성합니다. 응답 크기가 몇 MB로 줄어들어 직접 연결이 훨씬 더 자주 성공합니다. 프록시를 사용할 수 있는 환경에서 나중에 4K 작업을 실행합니다.

> [!WARNING]
>
> **두 문제가 동시에 발생할 수 있습니다.** 프록시로 전환한 뒤 요청이 90\~180초 후에 묶음 단위로 실패하기 시작한다면 프록시 노드의 유휴 시간 제한 때문입니다. [프록시를 사용할 때 약 90초 후 이미지 호출이 중단되나요?](/ko/faq/proxy-idle-timeout-disconnect)를 참고하세요. 이 경우 먼저 유휴 시간 제한이 더 긴 프록시 노드로 전환하거나, 대신 서버에서 이미지 프로그램을 실행합니다.

### 적절한 타임아웃도 설정합니다

이 상황에서는 프로그램이 연결 끊김 신호를 받지 못하므로, 자체 타임아웃만이 실패를 감지할 방법입니다. 타임아웃을 900초로 설정하면 요청이 실패했다는 사실을 확인하는 데 15분을 기다려야 합니다.

비스트리밍 이미지 요청은 이미지 생성 중에 데이터를 전송하지 않으므로, 읽기 타임아웃은 생성 시간보다 짧게 설정할 수 없습니다. **일반적인 생성 시간보다 조금 더 길게** 설정합니다. 4K는 약 300초, 1K/2K는 약 180초입니다. 타임아웃이 발생하면 먼저 호출 로그를 확인하여 요청에 과금되었는지 살펴본 다음 재시도 여부를 결정합니다. 이렇게 하면 같은 이미지를 두 번 생성하지 않습니다.

## 서버에 배포한 후에도 이런 현상이 발생하나요?

중국 본토 또는 해외의 클라우드 서버에서 APIYI까지 연결하는 회선은 일반적으로 가정용 광대역보다 훨씬 안정적이므로, 이 문제는 주로 로컬 개발 환경에서 발생합니다. 서버에서도 “헤더는 도착하지만 본문이 중간에 끊기는” 현상이 발생한다면 [이미지 API 연결 끊김 문제 해결](/ko/api-capabilities/image-connection-drops)을 참고하세요.

## 일반적인 질문

> **이러한 실패한 요청에도 과금되었습니까?**
>
> 아닙니다. 호출 로그에 `write_response_body_failed`로 기록된 요청에는 과금되지 않습니다. 각 로그 기록에 표시된 요금이 정확한 과금 내역입니다.

> **api.apiyi.com에 직접 연결하는 테스트는 성공합니다. 왜 회선 문제라고 보십니까?**
>
> 연결 테스트는 수백 바이트만 송수신하며 1초도 걸리지 않습니다. 수십 MB의 응답을 전송할 때만 문제가 발생하므로, 작은 요청으로는 이를 확인할 수 없습니다.

> **프로그램을 강제 종료한 뒤에도 서버가 계속 생성 작업을 진행합니까?**
>
> 요청을 제출하면 서버는 평소처럼 이미지를 생성합니다. 따라서 프로그램을 강제 종료한 뒤 바로 재시도하면 두 요청의 생성 작업이 동시에 진행될 수 있습니다. 다만 여기서 설명한 상황에서는 프로그램을 강제 종료할 즈음이면 서버가 이미 이미지 생성을 마쳤지만 응답을 전송하는 데 실패한 경우가 대부분이므로 과금되지 않습니다.

> **4K에만 문제가 발생해야 하는데, 왜 가끔 2K에서도 응답이 멈춥니까?**
>
> 응답이 클수록 전송이 끊길 가능성은 커지지만, 특정 크기를 넘으면 항상 실패하는 것은 아닙니다. 2K 응답도 여전히 몇 MB에 달하므로, 회선 상태가 좋지 않으면 문제가 발생할 수 있습니다. 다만 그 빈도는 훨씬 낮습니다.

## 관련 문서

> **[프록시를 통해 이미지 호출이 약 90초 후에 중단되나요?](/ko/faq/proxy-idle-timeout-disconnect)**
>
> 반대 상황입니다. 프록시가 유휴 연결을 닫습니다. 직접 연결하여 해결하세요.

> **[이미지 API 연결 끊김 문제 해결](/ko/api-capabilities/image-connection-drops)**
>
> write\_response\_body\_failed, SSL EOF 및 기타 연결 끊김 오류에 대한 전체 문제 해결 안내

> **[로그에는 호출이 완료되고 과금되었다고 표시되지만 클라이언트가 응답을 받지 못했습니다. 어떻게 문제를 해결하나요?](/ko/faq/log-duration-vs-client-wait)**
>
> 로그에 기록된 처리 시간과 클라이언트의 대기 시간 사이에 차이가 발생하는 이유

> **[호출 기록을 확인하는 방법](/ko/faq/call-logs)**
>
> 시간 범위별로 각 요청의 상태와 요금을 확인합니다.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.