> ## 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.

# Image Request Hangs With No Result, but the Log Shows a Write Failure?

> Your program bypasses the proxy and connects to APIYI directly. 1K/2K images work, but large 4K images hang with no error, and the call log shows write_response_body_failed with no charge. Your direct line cannot carry responses of tens of MB; route image requests through your proxy.

## Symptoms

You generate images on your own computer with a script, or with a Skill inside an AI coding tool (Codex, Claude Code, etc.), and see the following:

* 1K and 2K images mostly come back, but **4K images or requests with several reference images often never arrive**
* The program shows **no error at all** and keeps waiting until your own timeout (600 s, 900 s) fires with `read timed out`, or until you kill it
* Nothing arrives while it waits, **not a single byte**, not even the response headers (no HTTP status code)
* In the [call log](/en/faq/call-logs.md), the matching request ended **30-90 seconds** after submission, marked as failed with error code `write_response_body_failed`, and **was not billed**
* The program **bypasses the proxy and connects directly**: you set `NO_PROXY` or `trust_env=False`, or added a direct rule for `apiyi.com` in your proxy app

## Short Answer

> [!NOTE]
>
> **The image was already generated. It got lost on its way back to your computer.**
>
> A 4K image response is tens of MB. On some home broadband and office networks, a direct connection to overseas nodes gets cut a few dozen KB into a response that large: the server side sees the disconnect, while your computer receives nothing, so your program just keeps waiting. **Routing image requests through your proxy (VPN)** usually fixes it. These failures are not billed.

## Why This Happens

A non-streaming image request returns its result **all at once** at the end:

| Image size | Response size (after base64 encoding) |
| - | - |
| 1K | 1-3 MB |
| 2K | 3-10 MB |
| 4K | 30-50 MB |

In the cases we investigated, the server finished the image within 40-60 seconds and started sending it back. The response headers and the first 64-135 KB had already gone out, and about 1 second later the connection was cut. The customer's program received 0 bytes and never got any "connection closed" signal, so it waited until its own timeout. During the same period:

* Small 1K and 2K images from the same computer mostly arrived normally
* Requests from the same account **that went out through the proxy** delivered nearly every 40-50 MB 4K image

So the problem is that **the direct line between your computer and APIYI cannot carry large responses**. The model did not fail, and the network is not fully down. A connectivity test with `curl` or a browser looks perfectly healthy on such a line (small requests return in well under a second), which makes this hard to spot on your own.

> [!NOTE]
>
> This is the exact opposite of [Image Calls Drop After About 90 Seconds Behind a Proxy?](/en/faq/proxy-idle-timeout-disconnect.md). There, the **proxy** kills the connection while it sits idle waiting for the image, and the fix is to connect directly. Here, the **direct** line cannot carry the large response, and the fix is to use the proxy. Which route works for you is decided by the comparison test below.

## How to Confirm

**1. Check the call log**

Find the matching time range in the [call log](/en/faq/call-logs.md). If your program is still waiting while the log already shows a failed `write_response_body_failed` record, the server finished the image and started sending it back. The connection broke on the way back.

**2. See whether larger images fail more**

With the same prompt and reference images, if 1K / 2K come back and 4K does not, this is almost certainly the cause.

**3. Check whether your program actually uses the proxy**

Many AI coding tools start Python / Node child processes that **do not read the system proxy**. Even with Clash in global mode, those processes may still connect directly. Run this in the same terminal or tool:

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

If it prints your local broadband IP, requests from that environment go out directly.

**4. Alternate proxy and direct runs with a few 4K images**

Run them in alternating order: proxy, direct, proxy, direct. Do not run 5 of one kind and then 5 of the other, or a temporary network fluctuation can mislead you. If the proxy runs succeed reliably and the direct runs often hang, that confirms it.

## Solutions

**Route the program through the proxy (recommended)**

Remove whatever setting makes the program bypass the proxy, so image requests go through it:

* Remove `apiyi.com` from `NO_PROXY`
* Python `requests` / `httpx`: remove `trust_env=False`
* Python `urllib`: do not build the opener with `ProxyHandler({})`
* Node.js: native `fetch` does not use a proxy by default; specify one explicitly with a library such as `ProxyAgent`

If the child process does not read the system proxy, set the proxy address in an environment variable before running it (replace the port with your proxy app's HTTP port):

```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"
```

**Turn on TUN mode in the proxy app**

With **TUN mode** on, Clash / Clash Verge / mihomo and similar apps take over traffic from every program on the computer. Everything goes through the proxy whether or not the program reads the system proxy, which is the least effort.

If you previously added a `DIRECT` rule for `apiyi.com` following [Proxy idle disconnects](/en/faq/proxy-idle-timeout-disconnect.md), remove it. Otherwise it still connects directly in TUN mode.

**Shrink the response for now**

If you cannot change networks, generate at 2K for now. The response drops to a few MB, and direct connections succeed far more often. Run 4K jobs later from an environment that can use the proxy.

> [!WARNING]
>
> **Both problems can happen at once.** If, after switching to the proxy, requests start dropping in batches at 90-180 seconds, that is the proxy node's idle timeout; see [Image Calls Drop After About 90 Seconds Behind a Proxy?](/en/faq/proxy-idle-timeout-disconnect.md). In that case, switch to a proxy node with a longer idle timeout first, or run the image program on a server instead.

### Set a sensible timeout too

In this situation your program never receives a disconnect signal, so its own timeout is the only way to notice the failure. With a 900-second timeout, you wait 15 minutes just to learn the request failed.

A non-streaming image request carries no data while the image is being generated, so the read timeout cannot be shorter than the generation time. Set it to **a bit longer than a normal generation**: about 300 seconds for 4K, about 180 seconds for 1K/2K. After a timeout, check the call log first to see whether the request was billed, then decide whether to retry, so you do not generate the same image twice.

## Will This Happen After Deploying to a Server?

Lines from cloud servers in mainland China or overseas to APIYI are usually far better than home broadband, so this mainly shows up in local development. If a server also sees "headers arrive, then the body breaks off halfway", follow [Troubleshooting Image API Connection Drops](/en/api-capabilities/image-connection-drops.md).

## Common Questions

> **Were these failed requests billed?**
>
> No. Requests recorded as `write_response_body_failed` in the call log are not billed. The charge shown on each log record is authoritative.

> **A direct connectivity test to api.apiyi.com works. Why blame the line?**
>
> A connectivity test sends and receives only a few hundred bytes and finishes in well under a second. The problem only appears when a response of tens of MB is transferred, which a small request cannot reveal.

> **Does the server keep generating after I kill my program?**
>
> Once a request is submitted, the server generates the image as usual. So if you kill the program and retry immediately, two requests may be generating at the same time. In the situation described here, though, by the time you kill the program the server has usually long finished the image and failed to send it back, so nothing is billed.

> **Only 4K should be affected, so why does 2K occasionally hang too?**
>
> The larger the response, the more likely it gets cut, but there is no hard size above which it always fails. A 2K response is still a few MB, so it can be hit on a bad line too, just much less often.

## Related Docs

> **[Image Calls Drop After About 90 Seconds Behind a Proxy?](/en/faq/proxy-idle-timeout-disconnect.md)**
>
> The opposite problem: the proxy closes idle connections; fix it by connecting directly

> **[Troubleshooting Image API Connection Drops](/en/api-capabilities/image-connection-drops.md)**
>
> Full troubleshooting for write\_response\_body\_failed, SSL EOF, and other disconnect errors

> **[The log says the call finished and was billed, but my client never received a response — how do I troubleshoot?](/en/faq/log-duration-vs-client-wait.md)**
>
> Where the gap between logged duration and client wait time comes from

> **[How to view my call records?](/en/faq/call-logs.md)**
>
> Check each request's status and charge by time range


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