> ## 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 狀態碼）都沒有
* 到 [呼叫日誌](/zh-Hant/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 圖幾乎全部送達

所以問題出在**你的電腦直連 API易 的那段線路上傳不了大響應**，不是模型出圖失敗，也不是網路完全不通。這類線路用 `curl`、瀏覽器測連通性一切正常（小請求零點幾秒就返回），很難自己察覺。

> [!NOTE]
>
> 這和 [開著代理調用出圖，總在 90 秒左右斷開？](/zh-Hant/faq/proxy-idle-timeout-disconnect) 正好相反：那篇是**代理**掐斷了等圖期間的空閒連線，解決方法是設直連；本篇是**直連**線路傳不了大響應，解決方法是走代理。哪條路對你有效，以下文的對比測試為準。

## 怎麼確認是這個問題

**1. 對照呼叫日誌**

在 [呼叫日誌](/zh-Hant/faq/call-logs) 裡找到對應時間段。程式還在等、日誌裡卻早已記了一條 `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 模式**後，會接管電腦上所有程式的流量，不管程式讀不讀系統代理都會走代理，最省事。

如果你之前按 [代理空閒斷開](/zh-Hant/faq/proxy-idle-timeout-disconnect) 那篇給 `apiyi.com` 加過 `DIRECT` 規則，記得刪掉，否則 TUN 模式下它仍然是直連。

**暫時降低單次響應大小**

換不了網路時，可以先用 2K 出圖，響應大小降到幾 MB，直連成功率會明顯提高。需要 4K 時再到能走代理的環境裡跑。

> [!WARNING]
>
> **兩種問題可能同時存在。** 走代理後如果又出現「90\~180 秒成批斷開」，就是代理節點的空閒超時在起作用，見 [開著代理調用出圖，總在 90 秒左右斷開？](/zh-Hant/faq/proxy-idle-timeout-disconnect)。這時優先換一個空閒超時更長的代理節點，或者把出圖程式部署到伺服器上執行。

### 超時也要設得合理

這種情況下程式收不到任何斷開訊號，只能靠自己的超時發現問題。超時設成 900 秒，就要白等 15 分鐘才知道失敗了。

非流式出圖在出圖期間本來就沒有資料，讀取超時不能設得比出圖時間短。建議設成**比正常出圖耗時略長**：4K 約 300 秒、1K/2K 約 180 秒。超時後先去呼叫日誌確認這次請求是否扣費，再決定要不要重試，避免重複出圖。

## 部署到伺服器後還會遇到嗎？

國內雲伺服器、海外伺服器到 API易 的線路品質通常遠好於家庭寬頻，這個問題主要出現在本地開發環境。如果伺服器上也出現「響應頭到了、內容傳一半就斷」，排查方法見 [圖片 API 連線中斷排查](/zh-Hant/api-capabilities/image-connection-drops)。

## 常見疑問

> **這些失敗的請求扣費了嗎？**
>
> 沒有。呼叫日誌裡記為 `write_response_body_failed` 的請求不扣費，具體以日誌裡每條記錄的扣費金額為準。

> **直連測 api.apiyi.com 明明是通的，為什麼說是線路問題？**
>
> 連通性測試的請求和響應都只有幾百位元組，零點幾秒就完成了。這個問題只在傳幾十 MB 的大響應時才出現，小請求測不出來。

> **程式終止後，服務端還會繼續出圖嗎？**
>
> 請求一旦提交，服務端會照常出圖。所以手動終止後馬上重試，可能和上一次請求同時在出圖。不過在本篇這種情況下，你終止程式時服務端往往早就出完了圖，回傳也已經失敗，不會扣費。

> **只是 4K 有問題，為什麼 2K 偶爾也會卡住？**
>
> 響應越大越容易被中斷，但並不是超過某個大小就一定失敗。2K 的響應也有幾 MB，線路差的時候同樣可能中招，只是機率低得多。

## 相關文件

> **[開著代理調用出圖，總在 90 秒左右斷開？](/zh-Hant/faq/proxy-idle-timeout-disconnect)**
>
> 反方向的問題：代理掐斷空閒連線，設直連解決

> **[圖片 API 連線中斷排查](/zh-Hant/api-capabilities/image-connection-drops)**
>
> write\_response\_body\_failed、SSL EOF 等斷連報錯的完整排查

> **[日誌顯示已完成，客戶端卻收不到響應？](/zh-Hant/faq/log-duration-vs-client-wait)**
>
> 日誌用時與客戶端等待時間的差值在哪裡

> **[如何檢視我的呼叫記錄？](/zh-Hant/faq/call-logs)**
>
> 按時間段核對每條請求的狀態與扣費


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