Skip to main content

症状

ご自身のコンピューターでVPNやプロキシクライアントを実行しながら画像生成アプリの開発やデバッグを行っている場合(多くの開発者はAIコーディングツールをインターネットに接続させるために常時有効にしています)、以下のような現象が発生することがあります。
  • 画像リクエストが socket hang up、ECONNRESET、RemoteDisconnected、Connection aborted などの接続エラーで頻繁に失敗する
  • クライアント側のタイムアウトを600秒や900秒に設定しているにもかかわらず、リクエストが約90〜180秒で切断される
  • 複数のリクエストがまとめて遮断されたかのように、同時に失敗することが多い
  • 応答が遅いモデルほど頻繁に影響を受ける(例えば、1画像あたり通常60〜120秒かかる gpt-image-2-vip など)
  • 呼び出しログでは、これらのリクエストのほとんどが成功として記録され、課金されている

簡潔な回答

これは同時実行数の制限ではなく、APIYIのタイムアウトでもありません。お使いのコンピューター上のプロキシが、一定時間データ通信のない接続を切断しています。画像の生成中は、接続上にデータが一切流れません。画像の生成に時間がかかるほど、プロキシが接続をアイドル状態と見なして切断する可能性が高くなります。api.apiyi.com を直接ルーティング(プロキシをバイパス)すれば、問題は解決します。APIYI は中国本土から直接アクセス可能です。

発生する原因

非ストリーミングの画像リクエストには3つのフェーズがあります:
  1. アップロード:promptと参照画像が送信され、数秒から数十秒かかります
  2. 待機:サーバーが画像を生成します。通常は60〜200秒かかります。この間、接続上には一切データが流れません
  3. ダウンロード:完成した画像が一括で返却されます
問題となるのはフェーズ2です。リソースを解放するため、プロキシクライアントおよびプロキシサーバーはすべての接続に対してアイドルタイムアウトを設定しています。その時間内に双方向でデータのやり取りがない場合、接続は切断されます。広く利用されているXray / V2Rayコアでは、この設定はconnIdleであり、デフォルトは300秒ですが、プロキシサーバーの運用者はこれをはるかに短い値に設定することが可能であり、お使いのコンピューターからそれを確認・変更することはできません。調査した事例では、この値は約90秒に設定されていました。 その結果:
  • クライアント側のタイムアウト設定では解決できません。 タイムアウト設定はプログラムがどれだけ待機できるかを指定しているに過ぎません。中間のプロキシが先に接続を切断するため、プログラム側からは接続が切断されたようにしか見えません
  • まとめて失敗する理由:プロキシは通常、タイマーで定期的にチェックを行い、アイドル時間が長すぎる接続を一括で切断します。そのため、画像の生成待ちをしている複数のリクエストが同じ秒に一斉に失敗します
  • チャットやコーディングツールで問題が発生しない理由:ストリーミングチャットはデータを送信し続けるため、接続がアイドル状態になることはありません。一方、画像生成は何分間もデータを一切送信しません
切断されたリクエストも通常は課金対象となります。 リクエストはすでにAPIYIに到達し、生成処理が開始されています。切断されても処理は停止しないため、画像は通常通り生成されて課金されますが、その結果がプログラムに届くことはありません。プログラムのエラー数ではなく、呼び出しログで実際の請求額をご確認ください。

確認方法

1

タイミングを確認する

失敗した各リクエストがエラー発生までに実行されていた時間を記録します。所要時間が一定の値(90秒や180秒など)前後に集中しており、複数のリクエストが頻繁に同一秒で失敗している場合、ほぼ確実にプロキシのアイドルタイムアウトが原因です。
2

呼び出しログと比較する

呼び出しログで同じ時間帯を確認します。プログラム側で切断が報告されているにもかかわらず、ログ上に成功および課金済みのリクエストとして表示されている場合、APIYI側では画像の生成が完了したものの、クライアントへの接続が切断された状態です。
3

直接ルートで小規模なバッチを実行する

以下で説明するようにapi.apiyi.comへ直接ルーティングし、同じパラメータで10〜20枚の画像を生成します。切断が発生しなくなった場合、プロキシが原因です。

解決方法

プロキシクライアントに APIYI 向けの直接接続ルールを追加します。その他の通信は引き続きプロキシを経由するため、AIコーディングツールに影響はありません。Clash / Clash Verge / mihomo の場合、設定ファイルの rules の先頭に以下を追加します:
v2rayN などのクライアントの場合は、ルーティング設定の直接接続リストに apiyi.com を追加します。
TUNモードまたはグローバルモードでは、プロキシがコンピュータ上のすべてのプログラムからのトラフィックをキャプチャするため、コード側からこれをバイパスすることはできません。このような直接接続ルールを設定することが唯一の解決策です。

サーバーにデプロイした後もこれが発生しますか?

通常は発生しません。 サーバーは通常プロキシなしで稼働し、APIYIに直接接続するため、プロキシによってアイドル状態の接続が切断されることはありません。これは推奨される本番環境の構成でもあります。中国本土のクラウドサーバーからapi.apiyi.comに直接アクセスできます。 サーバーとAPIYIの間に他のレイヤーが存在する場合、それらにもアイドルタイムアウトが設定されています。デプロイ時に以下を確認してください。 1枚の画像は通常60〜200秒以内に完了するため、クラウドNATのデフォルト値を下回ります。独自のリバースプロキシを追加した場合や、サーバー側でもプロキシを経由している場合にのみ、追加の対応が必要になります。

よくある質問

クラウドNATゲートウェイに対しては効果があります。keepaliveプローブによって接続がまだアクティブであることをNATに通知できるためです。一方、実際のデータに基づいてアイドル状態を判定するプロキシクライアントに対しては、keepaliveプローブがデータとしてカウントされないため、ほとんど効果がありません。ローカル開発環境の場合は、直接接続ルートを設定することが解決策となります。
それらのリクエストはすぐに返るか、出力を継続的にストリーミングするため、接続が90秒以上アイドル状態になることがありません。数分間にわたって何も送信されず、一度にすべての結果が返される画像生成のようなリクエストでのみ、この問題が発生します。
どちらもローカルプロキシが原因ですが、症状が異なります。空の502エラーのケースでは、プロキシがボディのない502を返します。今回のケースでは、画像を待機している間に接続が切断され、プログラム側では接続ドロップとして認識されます。解決策はどちらも同じで、APIYIへのリクエストをプロキシ経由にしないことです。
これらの切断は、APIYIがすでに画像を生成して課金した後に、お客様とAPIYIの間のプロキシで発生します。金額が大きい場合は、時間帯(16:30-17:00 (UTC+8) のようにタイムゾーンを明記)とユーザー名をサポートまでお送りいただければ、呼び出しログを確認いたします。
画像エンドポイントは現在同期的に結果を返し、タスクIDによるポーリングには対応していません。非同期の画像APIはありますか?タスクIDで結果を照会できますか? をご覧ください。APIYIへ直接ルーティングするように設定すれば、長時間の待機自体は問題になりません。

関連ドキュメント

スクリプトで502が発生するのに呼び出しログに記録がない?

ローカルプロキシによって生成された空の502です。システムプロキシをバイパスすることで解決します

APIの利用にプロキシは必要ですか?

中国本土から直接アクセス可能で、プロキシやVPNは不要です

APIタイムアウトを回避するには?

タイムアウト設定とレイヤー別のトラブルシューティング

非同期の画像APIはありますか?

レスポンスが同期である理由と、非同期にラップする方法