Requests の ProxyError と urllib3 の ProxyError
呼び出しに使った HTTP ライブラリが公開する例外を捕捉し、クラス名だけに頼らずに入れ子になった原因を調べます。
requests.exceptions.ProxyError と urllib3.exceptions.ProxyError は異なる例外クラスです。短い名前が同じでも、1 つの except 節で両方を捕捉できるわけではありません。
Requests の呼び出しでは、まず Requests の公開例外 API から始めます。そのトランスポートアダプタは通常、下位層の失敗を Requests が公開する例外に変換します。古いバージョンには特有のラップ不具合があったため、予期しない traceback が出たらライブラリのバージョンを控えておきます。
調査するときは、例外のモジュール、クラス、連鎖した原因を確認します。入れ子になった MaxRetryError や接続失敗には、以前のプロキシ段階に関する有用な証拠が残っていることがあります。
過去の回避策に由来する古い vendored パスを現代のアプリケーションに import するのは避けてください。現在の呼び出しに適した公開例外を捕捉し、診断用に原因を保持し、再試行の動作は別に決めます。すべての Exception を捕捉して永遠に続けることは、元の不一致を隠すだけです。