Skip to main content

症状

バッチスクリプト(通常は Windows + Python requests)が断続的に 502 レスポンスを受信し、出力はおおよそ次のようになります。
また、次のことにも気付きます。
  • レスポンスの本文は空で、ヘッダーは ConnectionContent-Length のみです
  • Webコンソールはその間も継続して動作しています
  • 失敗したリクエストは呼び出しログまったく表示されません
  • スクリプトは 502 時にリトライし、1 回成功するまで連続して数回失敗することが多く、バックオフはそのたびに長くなります

短い回答

この 502 は APIYI からのものではありません。ご利用のマシン上のプロキシソフトウェア(Clash、v2rayN、および類似ツール)によって生成されています。修正するには、スクリプトでシステムプロキシをバイパスしてください。requests では、session.trust_env = False を設定します。その他のオプションについては以下で説明します。

これが該当するケースかを見分ける方法

APIYI の各レイヤーは識別可能な特性を持つレスポンスを返し、いずれも上記の空の 502 とは一致しません。 502 に Server ヘッダーも Date ヘッダーもなく、ボディが空の場合、それは APIYI ではなく、ほぼ間違いなくプロキシソフトウェアから返されたものです。
サービスコンテナが短時間再起動する際には、プラットフォームから実際の 502 が返されることもあります。この場合、Web コンソールも同時に停止し、サービスは約 1 分以内に復旧します。レスポンスには完全なヘッダーとボディが含まれます。Webサイトまたは API が 502 を返すを参照してください。

プロキシが介在する理由

  1. Python requests はシステムプロキシを自動的に取得します。 Windows では、レジストリからシステムプロキシ設定を読み取ります。Clash、v2rayN、または類似ツールで「システムプロキシ」を有効にすると、スクリプトは気付かないうちにそれを経由してルーティングされ、コード上には何も表示されません。
  2. プロキシはプレーン HTTP リクエストを自身で転送します。 http://api.apiyi.com:16888 のようなプレーン HTTP アドレスでは、プロキシは単に透過トンネルを開くだけではなく、リクエストを代理で再送信します。プロキシノードが停止、切り替え、またはタイムアウトすると、プロキシは空の 502 をスクリプトに返します。
  3. 大きなリクエストボディと高い同時実行数によって問題が悪化します。 画像編集では数 MB の画像データをアップロードし、1 回の生成には 45 ~ 70 秒かかります。数十件の同時リクエストが 1 つのプロキシノードを共有している場合、わずかな障害でもバッチ全体が一度に失敗します。
https:// では、プロキシは暗号化トンネルを開くだけであるため、失敗は通常、偽造された 502 ではなく接続エラー(ProxyError など)として現れます。ただし、HTTPS トラフィックも引き続きプロキシを経由するため、根本的な解決策はスクリプトをプロキシから切り離すことです。

修正

1

スクリプトがプロキシを使用しているか確認します

スクリプトと同じ環境で次を実行します。
出力に http または https のエントリ(例: 127.0.0.1:7890)が含まれる場合、requests はデフォルトでそのプロキシを経由します。
2

プロキシをバイパスします(いずれかを選択)

1回のリクエストのみ変更する場合: requests.post(..., proxies={"http": None, "https": None})
3

小規模なバッチで検証します

同時実行ワーカー数を5~10に設定し、数十件のリクエストを実行します。空の502が解消されれば、原因はプロキシでした。APIYI には直接アクセスでき、プロキシは必要ありません。API を使用するためにプロキシは必要ですか?を参照してください。
http://api.apiyi.com:16888 は、画像ワークロードのレイテンシを低減するために公式に提供されているプレーン HTTP エンドポイントです(画像 API のレイテンシを低減するには?を参照)。引き続き使用できます。ただし、上記の説明どおりプロキシをバイパスしてください。

よくある質問

プロキシが失敗したタイミングによって異なります。
  • リクエストがAPIYIに到達する前にプロキシが失敗した場合、APIYIはリクエストを受信していないため、課金も呼び出しログへの記録もありません。
  • リクエスト送信後、結果を待機している間にプロキシが接続を切断した場合、APIYIはすでに画像を生成している可能性があり、通常どおり課金されますが、結果はスクリプトに届きません。
したがって、スクリプトのエラー出力だけに頼らないでください。呼び出しログで実際に課金された呼び出し数を確認してください。
プロキシノードの一時的な不具合であることが多いため、ノードが復旧した後に到達したリトライは通過します。ただし、リトライのたびに完全な画像が再アップロードされ、バックオフも毎回増加するため、バッチジョブ全体の所要時間が大幅に長くなります。根本的な解決策はプロキシをバイパスすることです。
できません。障害はお使いのマシンとAPIYIの間にあるプロキシで発生しています。リクエストがAPIYIに到達していないか、プロキシ自体が接続を閉じているため、サーバー側でできることはありません。
まずヘッダーを確認してください。レスポンスにServerDateが含まれ、HTMLまたはJSONの本文がある場合は、プラットフォーム側の502です。ウェブサイトまたはAPIが502を返すを参照してください。継続して発生する場合は、障害発生時刻(タイムゾーン付き。例:14:30 (UTC+8))と完全なレスポンスをサポートへ送信してください。

関連ドキュメント

WebサイトまたはAPIが502を返す場合、どうすればよいですか?

プラットフォーム側の502:短時間のコンテナ再起動で、約1分で復旧します

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

直接接続で利用できます。プロキシやVPNは不要です

Image APIのレイテンシを削減するにはどうすればよいですか?

HTTPエンドポイント、接続の再利用、タイムアウト設定

APIのタイムアウトを回避するにはどうすればよいですか?

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