Un valor predeterminado de PySocks no redirige ftplib
Siga los sockets que ftplib crea realmente en lugar de suponer que set_default_proxy cambia la implementación nativa de socket de Python.
socks.set_default_proxy() guarda valores predeterminados para futuros objetos PySocks socksocket. No reemplaza la clase socket nativa de Python. Por lo tanto, no redirige ftplib solo porque la llamada ocurra antes de una conexión FTP.
Siga los constructores, no la variable que contiene la URL del proxy. ftplib crea una conexión de control y conexiones de transferencia adicionales. Con FTP pasivo, un inicio de sesión correcto solo demuestra que la conexión de control funcionó; el socket de datos usado para un listado o una transferencia de archivo también necesita la ruta prevista.
Una receta que reemplaza socket.socket o envuelve un módulo realiza otra acción más allá de establecer los valores predeterminados de PySocks. Puede afectar a otras bibliotecas que comparten ese módulo. Restaurar temporalmente el original después no aísla las conexiones concurrentes de la mutación.
Una subclase personalizada de ftplib puede cubrir las rutas de conexión, pero las interioridades copiadas arrastran las suposiciones de la versión de Python de la que provienen, incluidos los centinelas de tiempo de espera y el manejo del protocolo. Las actualizaciones de la biblioteca estándar no actualizan la copia.
Elija un cliente mantenido o una integración compatible para el proxy y el modo FTP requeridos. Un ejemplo de descarga FTP pasiva con PycURL ilustra una ruta de cliente separada. Para una personalización propia de la aplicación, identifique qué constructor abre cada socket de control y de datos y conserve el comportamiento original que reemplaza. Un valor de proxy correcto solo es útil cuando esos constructores lo consumen de verdad.