ל-polling יש אובייקט בקשה משלו ב-python-telegram-bot 22.8. לכן קריאת API רגילה מוצלחת אינה מוכיחה ש-getUpdates קיבל את אותו מסלול פרוקסי.

עבור אפליקציית polling, הגדירו את שני המסלולים:

from telegram.ext import Application

proxy_url = 'http://proxy-user:[email protected]:8080'
application = (
    Application.builder()
    .token(bot_token)
    .proxy(proxy_url)
    .get_updates_proxy(proxy_url)
    .build()
)

proxy מגדיר פעולות Bot API כלליות; get_updates_proxy מגדיר polling. המשיכו להשתמש ב-handlers הקיימים ובמחזור החיים של polling או webhook סביב בניית האפליקציה הזו.

פרטי הגישה ב-URL הם מצייני מקום. קבלו ערכים אמיתיים באמצעות מנגנון פרטי הגישה של הפריסה ו-קודדו באחוזים תווים שמורים ברכיבי ה-URL. השתמשו בסכימה בפועל של המתווך: HTTPXRequest מקבל כתובות פרוקסי HTTP ותומך ב-SOCKS5 עם תלות ה-SOCKS הנדרשת על ידי החבילה. רשימת פרוקסי SOCKS5 מספקת מועמדים לנקודות קצה עבור פרוטוקול זה, ולא פרטי גישה לחשבון פרוקסי.

אם האפליקציה מספקת אובייקטים מותאמים דרך request או get_updates_request, הגדירו את האובייקטים האלה באופן עקבי במקום זאת. הגדרת פרוקסי ב-builder ואובייקט בקשה שסופק בנפרד הם קלטים חלופיים למסלול המתאים.

מתכוני Updater ישנים יותר המשתמשים ב-request_kwargs וב-urllib3_proxy_kwargs מכוונים לדור אחר.

מאמרים קשורים