Типове значення PySocks не перенаправляє ftplib
Простежте, які сокети ftplib насправді створює, замість того щоб припускати, що set_default_proxy змінює вбудовану реалізацію сокетів Python.
socks.set_default_proxy() зберігає типові значення для майбутніх об'єктів socksocket PySocks. Він не замінює вбудований клас socket у Python. Тому він не перенаправляє ftplib лише через те, що виклик відбувається до з'єднання FTP.
Стежте за конструкторами, а не за змінною, у якій зберігається URL проксі. ftplib створює керівне з'єднання та додаткові з'єднання для передавання. За пасивного FTP успішний вхід доводить лише те, що керівне з'єднання працювало; сокет даних, який використовується для списку або передавання файлу, також має йти потрібним маршрутом.
Рецепт, який замінює socket.socket або обгортає модуль, робить дещо інше, ніж встановлення типових значень PySocks. Він може вплинути на інші бібліотеки, що використовують той самий модуль. Пізніше відновлення оригіналу не робить одночасні з'єднання ізольованими від цієї зміни.
Власний підклас ftplib може охопити шляхи з'єднань, але скопійовані внутрішні частини несуть припущення тієї версії Python, з якої вони взяті, зокрема вартові значення тайм-ауту й обробку протоколу. Оновлення стандартної бібліотеки не оновлюють копію.
Виберіть підтримуваний клієнт або підтримувану інтеграцію для потрібного проксі та режиму FTP. Приклад пасивного завантаження FTP із PycURL показує окремий шлях клієнта. Для доробки, що належить застосунку, визначте, який конструктор відкриває кожен керівний і кожен сокет даних, і збережіть поведінку, яку вона замінює. Правильне значення проксі корисне лише тоді, коли ці конструктори справді його використовують.