QGIS usa el proxy, pero un plugin basado en Requests no

Una capa de mapa se carga a través del proxy de la oficina, mientras que la llamada a la API de un plugin falla. Ambas acciones se ejecutan dentro de QGIS, pero pueden usar clientes HTTP distintos.

QGIS expone QgsNetworkAccessManager para las operaciones de red. Transporta la configuración de red de QGIS a las peticiones realizadas mediante ese gestor. Un plugin de Python que importa Requests crea otro cliente con su propio comportamiento de proxy y autenticación.

Elija la configuración que desea compartir

Para un plugin destinado a seguir las preferencias de red de QGIS del usuario, usar el gestor de red de QGIS evita reconstruir esas preferencias de forma independiente. Compruebe la API adecuada para la versión de QGIS que admite, incluido su comportamiento asíncrono y su integración de autenticación.

Si Requests es necesario por otro motivo, configúrelo deliberadamente. Su diccionario de proxy y la gestión del entorno siguen la documentación de Requests. Un proxy seleccionado en los ajustes de QGIS no es automáticamente un ajuste de sesión de Requests.

Sea preciso sobre el alcance cuando pruebe ejemplos de Qt de un foro. Establecer un proxy de aplicación Qt afecta a la red de Qt. No demuestra que Requests, que usa otra implementación de red, haya cambiado su ruta.

Compare el mismo destino

Use la URL del plugin que falla al comparar el comportamiento. Un servicio de mapas y una API no relacionada pueden tener reglas de omisión, permisos de proxy o cadenas de certificados diferentes. Una petición de mapa correcta solo demuestra que su propia ruta funciona.

Registre el nombre del cliente HTTP, el host de destino, si se solicitó autenticación de proxy y la etapa real del error. Excluya las contraseñas de los registros del plugin. Esa pequeña comparación suele indicar si debe corregir la integración de red de QGIS o el cliente Python independiente, sin restablecer preferencias de proxy que ya funcionan para el usuario.