Pour une application qui utilise la classe API de Tweepy 4.14, transmettez le proxy à ce client :

api = tweepy.API(
    auth,
    proxy="http://proxy.example:8080",
    timeout=20,
)

L'extrait suppose que Tweepy est chargé et que auth est le gestionnaire d'authentification existant de l'application. Le routage par proxy ne remplace pas le compte du fournisseur ni ses autorisations d'API. Là où des intermédiaires publics sont autorisés, la liste de proxys HTTP propose des candidats pour cette route HTTP sans compte de proxy.

La classe API documentée est l'interface v1.1 de Tweepy. Son argument proxy fournit l'intermédiaire HTTP utilisé pour les requêtes. Une recette historique qui remplaçait l'ouvreur global d'urllib ne configure pas un client moderne dont le transport réel est une session Requests.

Conservez l'instance configurée là où les opérations sont effectuées. Créer cet objet puis appeler une autre instance d'API ailleurs laisse la route prévue sur l'objet inutilisé.

Le client v2 de Tweepy est une classe distincte avec un constructeur différent. Adaptez l'intégration du proxy à cette interface plutôt que de supposer que tout objet Tweepy accepte les arguments de la classe API. L'argument explicite ci-dessus est utile pour maintenir la génération de client correspondante sans modifier le comportement du proxy pour des bibliothèques Python sans rapport.

Articles similaires