Skip to main content

Symptoms

You are developing or debugging an image generation app on your own computer, with a VPN or proxy client running (many developers keep one on so their AI coding tools can reach the internet). You see the following:
  • Image requests often fail with connection errors such as socket hang up, ECONNRESET, RemoteDisconnected, or Connection aborted
  • Your client timeout is 600 or even 900 seconds, yet requests drop after about 90-180 seconds
  • Several requests often fail at the same moment, as if cut off together
  • Slower models are hit more often (for example gpt-image-2-vip, which usually takes 60-120 seconds per image)
  • In the call logs, most of these requests show as successful and billed

Short Answer

This is not a concurrency limit and not an APIYI timeout. The proxy on your computer is closing connections that have carried no data for a while.While an image is being generated, no data flows on the connection at all. The longer the image takes, the more likely the proxy treats the connection as idle and closes it. Route api.apiyi.com directly (bypassing the proxy) and the problem goes away. APIYI is reachable directly from mainland China.

Why It Happens

A non-streaming image request has three phases:
  1. Upload: the prompt and reference images are sent, taking a few seconds to a few tens of seconds
  2. Wait: the server generates the image, usually 60-200 seconds. No data flows on the connection during this time
  3. Download: the finished image is returned in one go
The problem is phase 2. To free up resources, proxy clients and proxy servers give every connection an idle timeout: if no data moves in either direction for that long, the connection is closed. In the widely used Xray / V2Ray core, the setting is connIdle, with a default of 300 seconds, but the proxy server operator can set it much lower, and you can neither see nor change that from your computer. In the case we investigated, the value was about 90 seconds. As a result:
  • Your client timeout cannot help. The timeout only says how long your program is willing to wait. The proxy in the middle closes first, and your program just sees a dropped connection
  • Why they fail in batches: the proxy usually sweeps on a timer and closes every connection that has been idle too long at once, so several requests waiting on images fail in the same second
  • Why chat and coding tools are fine: streaming chat keeps sending data, so the connection is never idle. Image generation sends nothing for minutes
Dropped requests are usually still billed. The request has already reached APIYI and generation has started. Disconnecting does not stop it, so the image is generated and billed as usual, but the result never reaches your program. Check the call logs for the actual charges instead of counting your program’s errors.

How to Confirm

1

Check the timing

Log how long each failed request ran before the error. If the durations cluster around a fixed value (such as 90 or 180 seconds), and several requests often fail in the same second, a proxy idle timeout is almost certainly the cause.
2

Compare with the call logs

Look up the same time window in the call logs. If your program reported a disconnect but the log shows a successful, billed request, APIYI finished the image and the connection back to you was cut.
3

Run a small batch with a direct route

Route api.apiyi.com directly as described below and run 10-20 images with the same parameters. If the drops disappear, the proxy was the cause.

How to Fix It

Will This Happen After Deploying to a Server?

Usually not. Servers normally run without a proxy and connect to APIYI directly, so there is no proxy closing idle connections. This is also the recommended production setup: a cloud server in mainland China can reach api.apiyi.com directly. If there are other layers between your server and APIYI, they have idle timeouts too. Check them when you deploy: A single image usually finishes within 60-200 seconds, below the cloud NAT defaults. You only need extra work if you added your own reverse proxy or the server also goes through a proxy.

FAQ

It helps with cloud NAT gateways, because keepalive probes tell the NAT the connection is still alive. It does almost nothing against proxy clients, which judge idleness by actual data, and keepalive probes do not count as data. For the local development case, a direct route is still the fix.
Their requests either return quickly or stream output continuously, so the connection is never idle for 90 seconds or more. Only requests like image generation, which send nothing for minutes and then return everything at once, run into this.
Both are caused by a local proxy, but the symptoms differ. In the empty 502 case, the proxy makes up a 502 with no body. Here, the connection is cut while waiting for the image, and your program sees a dropped connection. The fix is the same for both: keep APIYI requests off the proxy.
These drops happen on the proxy between you and APIYI, after APIYI has already generated and billed the image. If the amount is significant, send the time window (with time zone, such as 16:30-17:00 (UTC+8)) and your username to support, and we will check the call logs with you.
Image endpoints currently return synchronously, with no task ID polling; see Is There an Async Image API? Can I Query Results by Task ID?. Once APIYI is routed directly, the long wait itself is not a problem.

Script Gets 502 but Nothing in the Call Logs?

An empty 502 made up by your local proxy; bypass the system proxy to fix it

Do I Need a Proxy to Use the API?

Direct access from mainland China, no proxy or VPN needed

How do I avoid API timeouts?

Timeout settings and layer-by-layer troubleshooting

Is There an Async Image API?

Why responses are synchronous, and how to wrap them asynchronously