QGIS Uses the Proxy, but a Requests-Based Plugin Does Not

A map layer loads through the office proxy, while a plugin's API call fails. Both actions run inside QGIS, but they may use different HTTP clients.

QGIS exposes QgsNetworkAccessManager for network operations. It carries QGIS's network configuration into requests made through that manager. A Python plugin that imports Requests creates another client with its own proxy and authentication behavior.

Choose the configuration you want to share

For a plugin intended to follow the user's QGIS network preferences, using the QGIS network manager avoids rebuilding those preferences independently. Check the API appropriate to the QGIS version you support, including its asynchronous behavior and authentication integration.

If Requests is needed for another reason, configure it deliberately. Its proxy dictionary and environment handling follow the Requests documentation. A proxy selected in QGIS's settings is not automatically a Requests session setting.

Be precise about scope when trying Qt examples from a forum. Setting a Qt application proxy affects Qt networking. It does not establish that Requests, which uses a different networking implementation, has changed its route.

Compare the same destination

Use the failing plugin URL when comparing behavior. A map service and an unrelated API can have different bypass rules, proxy permissions, or certificate chains. A successful map request establishes only that its own route works.

Capture the HTTP client name, destination host, whether proxy authentication was requested, and the actual error stage. Exclude passwords from plugin logs. That small comparison usually tells you whether to fix QGIS network integration or the independent Python client, without resetting proxy preferences that already work for the user.