> ## 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画像や複数の参照画像を含むリクエストは、返ってこないことがよくあります**
* プログラムには**エラーがまったく表示されず**、`read timed out`を伴って独自に設定したタイムアウト（600 s、900 s）が発生するまで、またはプロセスを強制終了するまで待機し続けます
* 待機中は何も返ってこず、**1バイトも受信しません**。HTTPステータスコードを含むレスポンスヘッダーすら届きません
* [呼び出しログ](/ja/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秒後に画像リクエストが切断される場合](/ja/faq/proxy-idle-timeout-disconnect)とは正反対の状況です。そちらでは、画像を待って接続がアイドル状態の間に**プロキシ**が接続を切断するため、直接接続することで解決します。こちらでは、**直接接続**では大きなレスポンスを転送できないため、プロキシを使うことで解決します。どちらの経路が使えるかは、以下の比較テストで判断できます。

## 確認方法

**1. 呼び出しログを確認する**

[呼び出しログ](/ja/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 などのアプリがコンピューター上のすべてのプログラムのトラフィックを引き受けます。プログラムがシステムプロキシを読み込むかどうかにかかわらず、すべての通信がプロキシ経由になるため、最も手間がかかりません。

[プロキシ接続がアイドル時に切断される](/ja/faq/proxy-idle-timeout-disconnect)に従って、以前`apiyi.com`用に`DIRECT`ルールを追加した場合は、それを削除してください。削除しないと、TUN モードでも直接接続されます。

**ひとまず応答のサイズを小さくする**

ネットワークを変更できない場合は、ひとまず 2K で生成してください。応答サイズが数 MB まで小さくなり、直接接続でも成功しやすくなります。4K のジョブは、プロキシを利用できる環境から後で実行してください。

> [!WARNING]
>
> **両方の問題が同時に起きることがあります。** プロキシに切り替えた後、リクエストが 90～180 秒でまとめて切断されるようになった場合は、プロキシノードのアイドルタイムアウトが原因です。[プロキシ経由で画像リクエストが約 90 秒後に切断される場合](/ja/faq/proxy-idle-timeout-disconnect)を参照してください。その場合は、まずアイドルタイムアウトがより長いプロキシノードに切り替えるか、画像を生成するプログラムをサーバー上で実行してください。

### 適切なタイムアウトも設定する

この状況では、プログラムに切断シグナルが届かないため、失敗に気付く方法はプログラム自身のタイムアウトだけです。タイムアウトを 900 秒に設定すると、リクエストが失敗したと分かるまでに 15 分も待つことになります。

ストリーミングを使わない画像リクエストでは、画像の生成中にデータが送信されないため、読み取りタイムアウトを生成時間より短くすることはできません。**通常の生成時間より少し長め**に設定してください。4K なら約 300 秒、1K/2K なら約 180 秒です。タイムアウト後は、まず呼び出しログを確認してリクエストが課金されたかどうかを確かめてから、再試行するかどうかを判断してください。同じ画像を二重に生成しないようにするためです。

## サーバーにデプロイした後も発生しますか？

中国本土または海外のクラウドサーバーからAPIYIまでの回線は、通常、自宅のブロードバンド回線よりもはるかに良好なため、この問題は主にローカル開発時に発生します。サーバーでも「ヘッダーは届くものの、本文が途中で途切れる」場合は、[画像APIの接続切断に関するトラブルシューティング](/ja/api-capabilities/image-connection-drops)をご確認ください。

## よくある質問

> **これらの失敗したリクエストには課金されましたか？**
>
> いいえ。呼び出しログに`write_response_body_failed`として記録されたリクエストには課金されません。各ログレコードに表示される請求額が正確な金額です。

> **api.apiyi.comへの直接接続テストは成功します。なぜ回線が原因だと言えるのですか？**
>
> 接続テストでは数百バイトだけを送受信し、1秒もかからずに完了します。問題が発生するのは数十MBのレスポンスを転送するときだけなので、小さなリクエストでは問題を検出できません。

> **プログラムを強制終了した後も、サーバーは生成を続けますか？**
>
> リクエストが送信されると、サーバーは通常どおり画像を生成します。そのため、プログラムを強制終了してすぐに再試行すると、2つのリクエストが同時に生成される可能性があります。ただし、ここで説明している状況では、プログラムを強制終了する時点で、サーバーはすでに画像の生成を終えていて、画像を返す処理に失敗していることがほとんどなので、課金は発生しません。

> **影響を受けるのは4Kだけのはずなのに、なぜ2Kでもときどきハングするのですか？**
>
> レスポンスが大きいほど途中で切断されやすくなりますが、必ず失敗する明確なサイズの境界があるわけではありません。2Kのレスポンスでも数MBあるため、回線の状態が悪いと影響を受けることがあります。ただし、その頻度はかなり低くなります。

## 関連ドキュメント

> **[プロキシ経由で画像リクエストが約90秒後に切断される場合](/ja/faq/proxy-idle-timeout-disconnect)**
>
> 逆の問題です。プロキシがアイドル状態の接続を閉じるため、直接接続して解決します

> **[画像APIの接続切断に関するトラブルシューティング](/ja/api-capabilities/image-connection-drops)**
>
> write\_response\_body\_failed、SSL EOF、その他の切断エラーに関する包括的なトラブルシューティング

> **[ログにはリクエストが完了して課金されたと表示されますが、クライアントはレスポンスを受信していません。トラブルシューティング方法を教えてください](/ja/faq/log-duration-vs-client-wait)**
>
> ログ上の所要時間とクライアントの待ち時間に差が生じる原因

> **[リクエスト記録を確認する方法](/ja/faq/call-logs)**
>
> 期間を指定して各リクエストのステータスと料金を確認します


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