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

# 出图一直等不到结果，日志却显示回写失败？

> 程序绕开代理直连 API易，1K/2K 正常、4K 大图却一直卡住，没有任何报错，调用日志里是 write_response_body_failed 且不扣费。原因是本地直连线路传不了几十 MB 的大响应，让出图请求改走代理即可。

## 症状

在自己电脑上用脚本、AI 编程工具（Codex、Claude Code 等）里的 Skill 出图，出现这些情况：

* 1K、2K 的图基本都能拿到，**4K 或多参考图的大图经常拿不到**
* 程序**没有任何报错**，一直显示「等待中」，直到你自己设的超时（600 秒、900 秒）才报 `read timed out`，或者被你手动终止
* 等待期间**一个字节都没收到**，连响应头（HTTP 状态码）都没有
* 到 [调用日志](/faq/call-logs.md) 里看，对应请求在提交后 **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 图几乎全部送达

所以问题出在**你的电脑直连 API易 的那段线路上传不了大响应**，不是模型出图失败，也不是网络完全不通。这类线路用 `curl`、浏览器测连通性一切正常（小请求零点几秒就返回），很难自己察觉。

> [!NOTE]
>
> 这和 [开着代理调用出图，总在 90 秒左右断开？](/faq/proxy-idle-timeout-disconnect.md) 正好相反：那篇是**代理**掐断了等图期间的空闲连接，解决方法是设直连；本篇是**直连**线路传不了大响应，解决方法是走代理。哪条路对你有效，以下文的对比测试为准。

## 怎么确认是这个问题

**1. 对照调用日志**

在 [调用日志](/faq/call-logs.md) 里找到对应时间段。程序还在等、日志里却早已记了一条 `write_response_body_failed` 失败，就说明服务端已经出完图、开始往回发了，是回程断的。

**2. 看是不是越大越容易失败**

同样的提示词和参考图，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 模式**

Clash / Clash Verge / mihomo 等打开 **TUN 模式**后，会接管电脑上所有程序的流量，不管程序读不读系统代理都会走代理，最省事。

如果你之前按 [代理空闲断开](/faq/proxy-idle-timeout-disconnect.md) 那篇给 `apiyi.com` 加过 `DIRECT` 规则，记得删掉，否则 TUN 模式下它仍然是直连。

**暂时降低单次响应大小**

换不了网络时，可以先用 2K 出图，响应大小降到几 MB，直连成功率会明显提高。需要 4K 时再到能走代理的环境里跑。

> [!WARNING]
>
> **两种问题可能同时存在。** 走代理后如果又出现「90\~180 秒成批断开」，就是代理节点的空闲超时在起作用，见 [开着代理调用出图，总在 90 秒左右断开？](/faq/proxy-idle-timeout-disconnect.md)。这时优先换一个空闲超时更长的代理节点，或者把出图程序部署到服务器上运行。

### 超时也要设得合理

这种情况下程序收不到任何断开信号，只能靠自己的超时发现问题。超时设成 900 秒，就要白等 15 分钟才知道失败了。

非流式出图在出图期间本来就没有数据，读取超时不能设得比出图时间短。建议设成**比正常出图耗时略长**：4K 约 300 秒、1K/2K 约 180 秒。超时后先去调用日志确认这次请求是否扣费，再决定要不要重试，避免重复出图。

## 部署到服务器后还会遇到吗？

国内云服务器、海外服务器到 API易 的线路质量通常远好于家庭宽带，这个问题主要出现在本地开发环境。如果服务器上也出现「响应头到了、内容传一半就断」，排查方法见 [图片 API 连接中断排查](/api-capabilities/image-connection-drops.md)。

## 常见疑问

> **这些失败的请求扣费了吗？**
>
> 没有。调用日志里记为 `write_response_body_failed` 的请求不扣费，具体以日志里每条记录的扣费金额为准。

> **直连测 api.apiyi.com 明明是通的，为什么说是线路问题？**
>
> 连通性测试的请求和响应都只有几百字节，零点几秒就完成了。这个问题只在传几十 MB 的大响应时才出现，小请求测不出来。

> **程序终止后，服务端还会继续出图吗？**
>
> 请求一旦提交，服务端会照常出图。所以手动终止后马上重试，可能和上一次请求同时在出图。不过在本篇这种情况下，你终止程序时服务端往往早就出完了图，回传也已经失败，不会扣费。

> **只是 4K 有问题，为什么 2K 偶尔也会卡住？**
>
> 响应越大越容易被中断，但并不是超过某个大小就一定失败。2K 的响应也有几 MB，线路差的时候同样可能中招，只是概率低得多。

## 相关文档

> **[开着代理调用出图，总在 90 秒左右断开？](/faq/proxy-idle-timeout-disconnect.md)**
>
> 反方向的问题：代理掐断空闲连接，设直连解决

> **[图片 API 连接中断排查](/api-capabilities/image-connection-drops.md)**
>
> write\_response\_body\_failed、SSL EOF 等断连报错的完整排查

> **[日志显示已完成，客户端却收不到响应？](/faq/log-duration-vs-client-wait.md)**
>
> 日志用时与客户端等待时间的差值在哪里

> **[如何查看我的调用记录？](/faq/call-logs.md)**
>
> 按时间段核对每条请求的状态与扣费


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