QGIS はプロキシを使うが、Requests ベースのプラグインは使わない

地図レイヤーは社内プロキシ経由で読み込まれる一方、プラグインの API 呼び出しは失敗します。どちらも QGIS 内で実行されますが、異なる HTTP クライアントを使っている可能性があります。

QGIS はネットワーク操作のために QgsNetworkAccessManager を公開しています。これは QGIS のネットワーク設定を、そのマネージャー経由のリクエストに引き継ぎます。Requests をインポートする Python プラグインは、独自のプロキシと認証の挙動を持つ別のクライアントを作成します。

共有したい設定を選ぶ

ユーザーの QGIS ネットワーク設定に従うべきプラグインでは、QGIS のネットワークマネージャーを使うことで、その設定を独自に再構築せずに済みます。サポートする QGIS バージョンに適した API を確認し、非同期動作と認証の統合も含めて把握してください。

別の理由で Requests が必要な場合は、意図的に設定する。そのプロキシ辞書と 環境変数の扱い は Requests のドキュメントに従います。QGIS の設定で選んだプロキシが、自動的に Requests セッションの設定になるわけではありません。

フォーラムの Qt の例を試すときは、適用範囲を正確に捉えてください。Qt アプリケーションのプロキシを設定すると、Qt のネットワークに影響します。別のネットワーク実装を使う Requests の経路が変わったことを証明するものではありません。

同じ宛先で比較する

挙動を比較するときは、失敗しているプラグインの URL を使ってください。地図サービスと無関係な API では、バイパス規則、プロキシ権限、証明書チェーンが異なる場合があります。地図リクエストの成功は、その経路自体が機能することを示すだけです。

HTTP クライアント名、宛先ホスト、プロキシ認証が要求されたかどうか、実際のエラー段階を記録してください。プラグインのログからパスワードは除外します。この小さな比較で、ユーザーにとって既に機能しているプロキシ設定をリセットせずに、QGIS のネットワーク統合と独立した Python クライアントのどちらを修正すべきかが通常わかります。