Inhalt des Artikels

Einleitung: Was du von diesem Guide hast

Wenn du schon mal einen Bot in Telegram gestartet hast, kennst du das eine unangenehme Problem. Der Bot selbst ist an einem Abend geschrieben, aber sein stabiler Betrieb wird zu einem eigenen Projekt. Nachrichten kommen verspätet, Updates gehen verloren, der Server bekommt plötzlich Fehler 429 und der Webhook wird einfach ohne Erklärung nicht mehr aufgerufen. Füge noch einen Proxy hinzu, über den alle Anfragen laufen müssen, und die Zahl der Fehlerquellen verdoppelt sich.

Dieser Schritt-für-Schritt-Guide löst genau diese Probleme. Du lernst, mit der Telegram Bot API über einen Proxyserver so zu arbeiten, dass der Bot nicht abstürzt, keine Nachrichten verliert und korrekt auf Limits reagiert. Wir behandeln weder das MTProto-Protokoll noch bauen wir ein Proxymonitoring-System. Unser Thema ist enger und praktischer: HTTP-Anfragen an api.telegram.org über Proxy, zwei Wege zum Abrufen von Updates und die richtige Reaktion auf Beschränkungen.

Was du am Ende hast

  • Einen funktionierenden Bot, der Anfragen an die Telegram Bot API über deinen Proxy (HTTP oder SOCKS5) sendet.
  • Eingerichtetes Long Polling, das nicht an Timeouts abbricht und Nachrichten nicht dupliziert.
  • Einen Webhook mit HTTPS und Secret Token, der Updates auf deinem Server empfängt.
  • Eine fertige Wrapper-Funktion für Anfragen, die bei Fehler 429 selbst die nötige Zeit abwartet und die Sendung wiederholt.
  • Das Verständnis, welchen Modus du für dein Projekt wählen solltest: Polling oder Webhook.

Für wen dieser Guide ist

Für Marketing-Profis und Affiliates, die Bots für Newsletter, Lead-Benachrichtigungen und Kampagnenstatistiken bauen. Für Entwickler, die eine feste und vorhersehbare ausgehende IP für Serveranfragen brauchen. Für Geschäftsinhaber, deren Bots Kunden bedienen und nicht eine Stunde lang schweigen dürfen. Wenn du mit mobilen Proxys arbeitest und den Bot-Traffic darüber leiten möchtest, bist du hier richtig.

Was du vorher wissen solltest

Wir erklären jeden Schritt von Grund auf, aber ein paar Grundkenntnisse erleichtern vieles. Es hilft, ein Terminal oder eine Kommandozeile öffnen, Befehle kopieren und Python-Skripte starten zu können. Zu wissen, was eine HTTP-Anfrage und JSON ist, ist wünschenswert, aber wir erinnern in einfachen Worten daran. Fortgeschrittene Themen sind in einem eigenen Abschnitt untergebracht, Anfänger können ihn ohne Verlust überspringen.

Wie viel Zeit du brauchst

Vorbereitung und Erstellung des Bots dauern etwa 20 Minuten. Proxy-Einrichtung und die erste erfolgreiche Anfrage weitere 20–30 Minuten. Long Polling startest du in einer halben Stunde. Der Webhook braucht 40–60 Minuten, weil ein HTTPS-Zertifikat nötig ist. Die Behandlung von Fehler 429 kostet weitere 20 Minuten. Insgesamt zwei bis drei Stunden gemütlicher Arbeit mit Prüfungen bei jedem Schritt.

Vorbereitung: Tools und Zugänge

Bevor wir die erste Codezeile schreiben, sammeln wir alles Nötige. So unterbrichst du nicht mitten im Schritt, um das Proxy-Passwort zu suchen oder eine Bibliothek zu installieren.

Benötigte Tools und Zugänge

  1. Telegram-Konto mit verknüpfter Nummer. Damit erstellst du den Bot über den offiziellen BotFather.
  2. Proxy-Zugang: Serveradresse, Port, Login und Passwort. Im Kundenbereich von mobileproxy.space werden diese Daten in der Karte des gekauften Proxys angezeigt. Meist sind zwei Ports verfügbar: einer für HTTP, einer für SOCKS5. Notiere beide.
  3. Computer oder Server mit installiertem Python 3.10 oder neuer. Für den Webhook brauchst du einen Server mit öffentlicher IP-Adresse und Domain, auf dem Heimrechner funktioniert der Webhook nicht.
  4. Das Tool curl. In Windows 10 und 11, macOS und Linux ist es bereits integriert. Prüfe es mit curl --version.
  5. Texteditor: VS Code, Notepad++ oder ein anderer, in dem du bequem Code schreibst.

Systemanforderungen

Für Polling gibt es fast keine Anforderungen: jede Maschine mit Internetzugang, auch ein Laptop. Der Bot verbraucht einige Dutzend Megabyte Speicher. Für den Webhook brauchst du einen VPS mit minimaler Konfiguration: 1 Kern, 1 GB RAM, Ubuntu 22.04 oder 24.04. Erforderlich ist eine Domain, die auf die IP dieses Servers zeigt, und ein offener Port 443 in der Firewall.

Was zu installieren ist

  1. Öffne das Terminal.
  2. Prüfe Python mit python3 --version. Unter Windows kann der Befehl python --version lauten.
  3. Erstelle den Projektordner: mkdir tgbot-proxy, dann wechsle hinein mit cd tgbot-proxy.
  4. Erstelle eine virtuelle Umgebung: python3 -m venv venv. Aktiviere sie: unter Linux und macOS source venv/bin/activate, unter Windows venv\Scripts\activate.
  5. Installiere die Bibliotheken: pip install requests[socks] flask. Das Paket requests übernimmt Anfragen an die Telegram Bot API, die socks-Erweiterung brauchst du für Proxy über SOCKS5, und Flask nimmt den Webhook entgegen.

Backups und Datensicherheit

Behandle den Bot-Token wie das Passwort deiner Banking-App. Wer ihn bekommt, kann im Namen des Bots deinen Kunden schreiben. Lege eine Datei .env mit Token und Proxy-Daten an und schicke sie niemals in ein öffentliches Repository. Wenn der Bot bereits läuft und du ihn auf einen Proxy umstellst, sichere die aktuelle Konfiguration, exportiere die Datenbank, falls vorhanden, und notiere das Ergebnis der Methode getWebhookInfo. Dann dauert ein Rollback zwei Minuten.

Tipp: Lege einen separaten Test-Bot für Experimente an. Arbeite alle Schritte dieses Guides zuerst daran ab und übertrage auf den Produktiv-Bot nur die geprüfte Konfiguration. So zerstörst du nicht die Kommunikation mit echten Kunden.

Grundbegriffe: Wie die Telegram Bot API aufgebaut ist

Wir erklären die wichtigsten Begriffe in einfachen Worten. Ohne sie wirken die nächsten Schritte wie Magie, mit ihnen werden sie logisch und vorhersehbar.

Telegram Bot API

Das ist eine ganz normale HTTP-Schnittstelle. Dein Code sendet eine Anfrage an eine Adresse wie https://api.telegram.org/bot<TOKEN>/<Methode>, und der Telegram-Server antwortet mit einem JSON-Objekt. Zum Beispiel liefert die Methode getMe Informationen über den Bot, und sendMessage schickt Text in einen Chat. Für den Betrieb brauchst du keine speziellen Bibliotheken, curl oder requests genügen. Genau deshalb lässt sich die Telegram Bot API so leicht über einen Proxy leiten: Es ist derselbe Traffic wie bei jeder Website über HTTPS.

Updates

Jedes Ereignis für den Bot, ob Nachricht, Tastendruck oder Hinzufügen zu einer Gruppe, kommt als Update-Objekt mit einer eindeutigen Nummer update_id. Die Nummern wachsen der Reihe nach. Deine Aufgabe ist, diese Objekte abzurufen und zu verarbeiten. Es gibt genau zwei Wege, und sie schließen einander aus.

Long Polling

Dein Bot fragt selbst bei Telegram nach: Gibt es neue Updates für mich? Das macht er mit der Methode getUpdates. Das Wort „long“ bedeutet, dass der Server nicht sofort mit einer leeren Liste antwortet, sondern die Verbindung bis zum angegebenen Timeout offen hält, meist 30–60 Sekunden, und sofort antwortet, sobald ein Ereignis eintritt. Das spart Anfragen und liefert fast sofortige Reaktion. Polling braucht keine öffentliche Adresse, funktioniert hinter dem Router und über jeden Proxy. Ideal für den Start und für Bots mit geringer Last.

Webhook

Der umgekehrte Ansatz. Du teilst Telegram die Adresse deines Servers mit der Methode setWebhook mit, und Telegram sendet jedes Update selbst per POST an diese Adresse. Du musst nichts abfragen. Anforderungen: öffentliche Domain, HTTPS-Zertifikat und einer der Ports 443, 80, 88 oder 8443. Der Webhook skaliert besser und verbraucht keine Ressourcen fürs Warten.

Wichtig zu verstehen: Der Proxy beeinflusst nur die ausgehenden Anfragen deines Bots an Telegram. Eingehende Webhook-Anfragen kommen direkt auf deinem Server an, der Proxy ist an dieser Stelle nicht beteiligt. Deshalb bedeutet die Formulierung „Webhook über Proxy“ in der Praxis: Der Bot antwortet und ruft API-Methoden über den Proxy auf, empfängt Updates aber an seiner öffentlichen Adresse.

Fehler 429 Too Many Requests

Telegram begrenzt die Anfragerate. Richtwerte für 2026: nicht mehr als eine Nachricht pro Sekunde in einen Chat, nicht mehr als 20 Nachrichten pro Minute in eine Gruppe und etwa 30 Nachrichten pro Sekunde insgesamt pro Bot. Bei Überschreitung liefert der Server den HTTP-Status 429 und im Antwortkörper das Feld parameters.retry_after mit der Anzahl der Sekunden Wartezeit. Ignorieren darf man das nicht: Wiederholungsversuche ohne Pausen verlängern die Sperrzeit.

Wozu überhaupt ein Proxy für den Bot

Die Gründe sind rein praktisch. Erstens eine feste und vorhersehbare ausgehende IP: praktisch, wenn es viele Server gibt, aber eine einzige Außenadresse nötig ist. Zweitens die Trennung des Traffics nach Projekten: jeder Kunde oder jede Kampagne bekommt seinen Kanal. Drittens Unternehmensrichtlinien, wenn alle externen Verbindungen über ein Gateway laufen müssen. Mobile Proxys punkten hier mit Stabilität und der Möglichkeit, den IP-Wechsel nach Zeitplan oder per Link zu steuern.

Schritt 1: Bot erstellen und Token bekommen

Ziel dieses Schritts: einen Zugangstoken für die Telegram Bot API erhalten und sicherstellen, dass der Bot existiert.

  1. Öffne Telegram auf dem Handy oder Computer.
  2. Gib in die Suche BotFather ein. Wähle den Bot mit dem blauen Verifizierungshäkchen, bei Fälschungen fehlt es.
  3. Drücke Start oder sende den Befehl /start. Du siehst die verfügbaren Befehle.
  4. Sende den Befehl /newbot.
  5. BotFather fragt nach dem Bot-Namen. Gib einen Anzeigenamen ein, zum Beispiel Proxy Test Bot. Er darf Leerzeichen und Umlaute enthalten.
  6. Dann wird ein Username verlangt. Er muss eindeutig sein, lateinische Zeichen enthalten und auf bot enden, zum Beispiel proxy_test_2026_bot. Ist der Name vergeben, sagt BotFather das, denk dir einen anderen aus.
  7. Als Antwort kommt eine Glückwunsch-Nachricht mit einer Zeile wie 123456789:AAExampleTokenLettersAndDigits. Das ist der Token. Kopiere ihn vollständig, inklusive der Ziffern vor dem Doppelpunkt.
  8. Erstelle im Projektordner die Datei .env und schreibe die Zeile BOT_TOKEN=dein_token hinein.

Achtung: Veröffentliche den Token niemals in Chats, Screenshots oder öffentlichen Repositories. Ist der Token geleakt, sende BotFather sofort den Befehl /revoke, wähle den Bot und hole einen neuen Token. Der alte funktioniert dann sofort nicht mehr.

Erste Anfrage ohne Proxy

Bevor wir die Sache verkomplizieren, prüfen wir mit einer einfachen Anfrage von deiner Maschine, ob der Token funktioniert. Führe im Terminal aus und setze deinen Token ein:

curl https://api.telegram.org/bot123456789:AAExampleToken/getMe

Erwartete Antwort: JSON, das mit {"ok":true,"result":{"id":123456789,"is_bot":true,... beginnt. Darin siehst du den Username des Bots, den du gerade ausgedacht hast.

Prüfung: In der Antwort steht "ok":true und der richtige Username. Kommt stattdessen "error_code":401, wurde der Token falsch kopiert – prüfe, ob an den Rändern Zeichen verloren gingen.

Mögliche Probleme

  • Username vergeben. Füge Ziffern oder eine Projektabkürzung hinzu, Hauptsache die Endung bot bleibt.
  • BotFather antwortet nicht. Stelle sicher, dass du den Bot mit Verifizierungshäkchen geöffnet hast und nicht einen Namensvetter.
  • Fehler 404 Not Found. In der Adresse fehlt das Wort bot vor dem Token. Das Format ist strikt /bot<TOKEN>/methode.

Schritt 2: Proxy einbinden und API-Zugriff prüfen

Ziel dieses Schritts: Anfragen an die Telegram Bot API über deinen Proxy leiten und das tatsächlich überprüfen, nicht nur behaupten.

Das Format der Proxy-Adresse verstehen

Ein Proxy wird durch eine Zeile beschrieben: protokoll://login:passwort@host:port. Nimm die Daten aus dem Kundenbereich. Angenommen, du hast den Host proxy-host, HTTP-Port 8080, SOCKS5-Port 1080, Login user und Passwort pass. Dann sehen die Zeilen so aus:

  • HTTP-Proxy: http://user:pass@proxy-host:8080
  • SOCKS5-Proxy: socks5h://user:pass@proxy-host:1080

Achte auf das h in socks5h. Es bedeutet, dass der Domainname api.telegram.org auf der Seite des Proxys aufgelöst wird und nicht auf deiner Maschine. Das ist die richtige Variante für mobile Proxys: DNS-Anfragen und Traffic laufen über denselben Weg. Ohne h scheitern Anfragen bei DNS-Problemen lokal, obwohl der Proxy intakt ist.

Enthält das Passwort die Zeichen @, : oder /, müssen sie kodiert werden: @ wird zu %40, Doppelpunkt zu %3A, Schrägstrich zu %2F. Sonst wird die Zeile falsch geparst.

Prüfung mit curl

  1. Finde zuerst heraus, welche IP externe Dienste über deinen Proxy sehen. Führe aus: curl -x http://user:pass@proxy-host:8080 https://api.ipify.org. In der Antwort kommt eine IP-Adresse. Sie muss sich von deiner Heim- oder Serveradresse unterscheiden.
  2. Jetzt dieselbe Anfrage an die Telegram Bot API: curl -x http://user:pass@proxy-host:8080 https://api.telegram.org/bot123456789:AAExampleToken/getMe.
  3. Für SOCKS5 tausche den Parameter: curl -x socks5h://user:pass@proxy-host:1080 https://api.telegram.org/bot123456789:AAExampleToken/getMe.
  4. Miss die Antwortzeit: Hänge an den Befehl -w " Zeit: %{time_total}" an. Ein Wert bis 1–2 Sekunden ist für einen mobilen Proxy normal.

Prüfung: Beide Anfragen lieferten "ok":true, und die IP aus dem ersten Befehl unterscheidet sich von deiner eigenen. Das bedeutet, die Route über den Proxy funktioniert und die Telegram Bot API antwortet darüber.

Proxy in Python einrichten

Erstelle die Datei config.py mit folgendem Inhalt und ersetze die Werte durch deine:

import os
TOKEN = os.getenv('BOT_TOKEN', '123456789:AAExampleTokenReplaceMe')
PROXY = os.getenv('BOT_PROXY', 'http://user:pass@proxy-host:8080')
PROXIES = {'http': PROXY, 'https': PROXY}
BASE = f'https://api.telegram.org/bot{TOKEN}'

Der Schlüssel https im Dictionary ist Pflicht, weil die Telegram Bot API nur über HTTPS arbeitet. Ein häufiger Anfängerfehler ist, nur http anzugeben und sich zu wundern, warum der Traffic direkt läuft.

Jetzt das Testskript check.py:

import requests
from config import PROXIES, BASE
ip = requests.get('https://api.ipify.org', proxies=PROXIES, timeout=15).text
print('Ausgehende IP:', ip)
me = requests.get(f'{BASE}/getMe', proxies=PROXIES, timeout=15).json()
print('Bot:', me['result']['username'])

Starte: python check.py. Auf dem Bildschirm erscheinen die Proxy-IP und der Username des Bots.

Tipp: Wenn du den Code einer bereits verwendeten Bibliothek nicht ändern willst, setze die Umgebungsvariable HTTPS_PROXY=http://user:pass@proxy-host:8080. Die Bibliothek requests und die meisten HTTP-Clients übernehmen sie automatisch. Das ist ein bequemer Weg, einen bestehenden Bot ohne Codeänderungen auf einen Proxy umzustellen.

Einrichtung in beliebten Frameworks

  • aiogram 3.x: Erstelle eine Session AiohttpSession(proxy='http://user:pass@proxy-host:8080') und übergib sie bei der Erstellung von Bot(token=TOKEN, session=session). Für SOCKS5 brauchst du das Paket aiohttp-socks.
  • python-telegram-bot 21.x: Verwende HTTPXRequest(proxy='http://user:pass@proxy-host:8080') und übergib es an ApplicationBuilder().token(TOKEN).request(request).
  • Node.js: Die Pakete https-proxy-agent oder socks-proxy-agent erzeugen einen Agenten, der in die Optionen des HTTP-Clients oder den Konstruktor der Bot-Bibliothek übergeben wird.

Mögliche Probleme

  • 407 Proxy Authentication Required. Falscher Login oder falsches Passwort oder Sonderzeichen nicht kodiert. Prüfe die Daten im Kundenbereich.
  • Connection refused. Falscher Port oder HTTP- und SOCKS5-Ports vertauscht. Probiere den anderen Port.
  • Anfrage läuft direkt. Im Dictionary fehlt der Schlüssel https oder die Umgebungsvariable ist in einem anderen Terminalfenster gesetzt.
  • SSL-Fehler. Deaktiviere die Zertifikatsprüfung nicht. Aktualisiere das Paket certifi mit pip install -U certifi und prüfe die Systemzeit.

Schritt 3: Long Polling über den Proxy starten

Ziel dieses Schritts: einen laufenden Bot bekommen, der über den Proxy Updates mit getUpdates abholt und auf Nachrichten antwortet, ohne sie zu verlieren oder zu duplizieren.

Wie man die Polling-Schleife richtig aufbaut

Die Logik ist einfach, aber die Details zählen. Du rufst getUpdates mit dem Parameter offset auf, der gleich der zuletzt verarbeiteten update_id plus eins ist. So versteht Telegram, dass die vorherigen Updates empfangen wurden, und löscht sie auf seiner Seite. Vergisst man den offset, kommt dieselbe Nachricht immer wieder, und der Bot antwortet mehrfach.

Der Parameter timeout legt fest, wie viele Sekunden der Server die Verbindung offen hält und auf Ereignisse wartet. Hier beginnt die Proxy-Spezifik. Jeder Proxy hat ein eigenes Timeout für inaktive Verbindungen, bei mobilen Proxys liegt es oft bei 60–120 Sekunden. Ist das Polling-Timeout größer, kappt der Proxy die Verbindung, bevor Telegram antwortet, und du bekommst einen Fehler statt Updates. Ein sicherer Wert ist timeout=50 bei einem Timeout des HTTP-Clients von 60 Sekunden. Das Client-Timeout muss immer größer als das Polling-Timeout sein, sonst bricht der Client zuerst ab.

Den Bot schreiben

  1. Erstelle die Datei polling.py.
  2. Kopiere den Code unten hinein.
  3. Starte ihn mit python polling.py.
  4. Schreibe dem Bot eine beliebige Nachricht in Telegram.
import time, requests
from config import PROXIES, BASE
offset = 0
print('Polling gestartet über Proxy')
while True:
try:
r = requests.get(f'{BASE}/getUpdates', params={'offset': offset, 'timeout': 50}, proxies=PROXIES, timeout=60)
data = r.json()
except requests.RequestException as e:
print('Netzwerkfehler:', e)
time.sleep(3)
continue
if not data.get('ok'):
print('API-Fehler:', data)
time.sleep(3)
continue
for upd in data['result']:
offset = upd['update_id'] + 1
msg = upd.get('message')
if msg and 'text' in msg:
requests.post(f'{BASE}/sendMessage', json={'chat_id': msg['chat']['id'], 'text': 'Empfangen: ' + msg['text']}, proxies=PROXIES, timeout=15)

Schauen wir, was hier passiert. Die äußere Schleife endet nie von selbst. Der try-Block fängt Netzwerkfehler ab: Proxy-Abbruch, Timeout, IP-Wechsel. Bei einem Fehler wartet das Skript drei Sekunden und versucht es erneut, statt abzustürzen. Die Prüfung data.get('ok') fängt Fehler auf API-Ebene ab. Die innere Schleife verarbeitet jedes Update und verschiebt sofort den offset.

Prüfung: In der Konsole erschien die Startzeile, und nach dem Senden einer Nachricht antwortete der Bot „Empfangen: dein Text“. Sende drei Nachrichten hintereinander, der Bot muss auf jede genau einmal antworten. Stoppe das Skript mit Strg+C, sende eine Nachricht und starte es erneut: Der Bot antwortet auf die verpasste Nachricht, weil Telegram unverarbeitete Updates bis zu 24 Stunden speichert.

Besonderheiten mobiler Proxys beim Polling

Mobile Proxys können die IP-Adresse wechseln: per Timer oder über einen speziellen Link im Kundenbereich. Im Moment des IP-Wechsels reißt die offene Polling-Verbindung ab. Das ist kein Fehler deines Codes, sondern normales Netzwerkverhalten. Unsere Schleife ist darauf vorbereitet: Sie fängt die Ausnahme ab, wartet und macht mit demselben offset weiter. Kein Update geht verloren.

Trotzdem erzeugt häufige Rotation zusätzliches Rauschen in den Logs und Mikroverzögerungen. Empfehlung: Stelle für einen Bot im Polling-Modus im Kundenbereich ein Rotationsintervall von mindestens 10 Minuten ein oder deaktiviere den automatischen Wechsel und ändere die IP per Link nur dann, wenn du sie wirklich brauchst. Ein Bot ist kein Parser, er braucht nicht jede Minute eine frische Adresse.

Tipp: Trage ins Log die Zeit und update_id jedes Updates ein. Wenn jemand eine Woche später sagt, der Bot habe nicht geantwortet, findest du in einer Minute heraus, ob die Nachricht deinen Code erreicht hat oder ob das Problem im Netzwerk lag.

Mögliche Probleme

  • Fehler 409 Conflict. Der häufigste. Für den Bot ist ein Webhook eingerichtet, aber Polling und Webhook können nicht gleichzeitig laufen. Führe curl -x dein_proxy https://api.telegram.org/botTOKEN/deleteWebhook aus und starte das Skript neu. Zweite Ursache: Es laufen zwei Kopien des Skripts, schließe die überflüssige.
  • Bot antwortet doppelt auf jede Nachricht. Der offset wird nicht verschoben oder es laufen zwei Bot-Kopien.
  • Ständige Read timed out. Das Polling-Timeout ist größer als das Proxy-Timeout. Reduziere timeout auf 30–40 Sekunden.
  • Antwortverzögerung von 5–10 Sekunden. Prüfe die Antwortzeit des Proxys mit curl. Ist der Kanal selbst langsam, wechsle den Ausgangspunkt oder den Tarif.

Schritt 4: Webhook mit HTTPS und Secret Token einrichten

Ziel dieses Schritts: Telegram sendet Updates selbst an deinen Server, und der Bot antwortet über den Proxy. Dieser Schritt erfordert einen VPS mit Domain. Wenn du vorerst nur Polling hast und es dir reicht, kannst du zu Schritt 5 springen und später hierher zurückkehren.

Server und Domain vorbereiten

  1. Miete einen VPS mit Ubuntu. Notiere seine öffentliche IP.
  2. Lege in der Domainverwaltung einen A-Record an, zum Beispiel bot.example.com, der auf die Server-IP zeigt. Warte auf die DNS-Aktualisierung, meist 5–30 Minuten. Prüfe mit nslookup bot.example.com.
  3. Verbinde dich per SSH zum Server und aktualisiere die Pakete: sudo apt update.
  4. Installiere nginx und certbot: sudo apt install nginx certbot python3-certbot-nginx.
  5. Öffne die Ports 80 und 443: sudo ufw allow 80, sudo ufw allow 443.
  6. Hole ein kostenloses Zertifikat: sudo certbot --nginx -d bot.example.com. Folge den Hinweisen, gib die E-Mail ein, akzeptiere die Bedingungen. Nach einer Minute ist das Zertifikat ausgestellt.

Telegram akzeptiert Webhooks nur über HTTPS mit einem gültigen Zertifikat einer vertrauenswürdigen Stelle. Ein Zertifikat von certbot erfüllt diese Anforderung. Ein selbstsigniertes Zertifikat ist ebenfalls möglich, aber dann muss der öffentliche Teil per Parameter certificate in setWebhook hochgeladen werden, was mehr Aufwand bedeutet. Für Anfänger ist certbot einfacher.

Nginx als Einstiegspunkt konfigurieren

Nginx nimmt HTTPS-Anfragen von Telegram entgegen und leitet sie an deine Flask-Anwendung weiter, die auf dem lokalen Port 8080 lauscht. Öffne die von certbot erstellte Site-Konfiguration mit sudo nano /etc/nginx/sites-available/default und füge im Server-Block mit Port 443 folgenden location-Block ein:

location /tg/webhook {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_read_timeout 30s;
}

Speichere die Datei, prüfe die Syntax mit sudo nginx -t und lade neu mit sudo systemctl reload nginx.

Tipp: Mache den Webhook-Pfad unauffällig, zum Beispiel /tg/webhook/k8s7d2f. Das ist kein Ersatz für den Secret Token, sondern eine zusätzliche Schicht: Zufällige Scanner finden deinen Einstiegspunkt nicht.

Webhook-Handler schreiben

Erstelle auf dem Server die Datei webhook.py. Sie nimmt POST von Telegram entgegen, prüft den Secret-Header und antwortet dem Nutzer über den Proxy. Die Funktion call schreiben wir im nächsten Schritt, verwende vorerst normales requests.post mit proxies.

import requests
from flask import Flask, request, abort
from config import PROXIES, BASE
app = Flask(__name__)
SECRET = 'MySecret123'
@app.post('/tg/webhook')
def webhook():
if request.headers.get('X-Telegram-Bot-Api-Secret-Token') != SECRET:
abort(403)
update = request.get_json(silent=True) or {}
msg = update.get('message')
if msg and 'text' in msg:
requests.post(f'{BASE}/sendMessage', json={'chat_id': msg['chat']['id'], 'text': 'Per Webhook empfangen'}, proxies=PROXIES, timeout=15)
return 'ok', 200
if __name__ == '__main__':
app.run(host='127.0.0.1', port=8080)

Der entscheidende Punkt: der Header X-Telegram-Bot-Api-Secret-Token. Telegram fügt ihn jeder Anfrage hinzu, wenn du beim Einrichten des Webhooks secret_token angegeben hast. Jede Anfrage ohne den richtigen Wert wird mit Code 403 abgelehnt. So kann niemand von außen dem Bot gefälschte Nachrichten unterjubeln.

Starte die Anwendung: python webhook.py. Für den Dauerbetrieb richte sie später als systemd-Service ein, für den Test genügt der direkte Start.

Webhook über den Proxy registrieren

Auch der Aufruf von setWebhook läuft über den Proxy, denn es ist eine ausgehende Anfrage an die Telegram Bot API. Führe auf einer Maschine mit Proxy-Zugang aus:

curl -x http://user:pass@proxy-host:8080 -F "url=https://bot.example.com/tg/webhook" -F "secret_token=MySecret123" -F "max_connections=40" -F "drop_pending_updates=true" https://api.telegram.org/bot123456789:AAExampleToken/setWebhook

Erklären wir die Parameter. url — die Adresse deines Handlers. secret_token — eine Zeichenkette von 1 bis 256 Zeichen aus lateinischen Buchstaben, Ziffern, Bindestrich und Unterstrich; sie muss mit SECRET im Code übereinstimmen. max_connections — wie viele gleichzeitige Anfragen Telegram an dich öffnen darf, von 1 bis 100, Standard ist 40. drop_pending_updates — angesammelte Updates verwerfen, damit der Bot beim Umschalten nicht eine Flut alter Antworten ausgibt.

Erwartete Antwort: {"ok":true,"result":true,"description":"Webhook was set"}.

Diagnose über getWebhookInfo

Das ist das wichtigste Werkzeug zum Debuggen von Webhooks. Führe aus:

curl -x http://user:pass@proxy-host:8080 https://api.telegram.org/bot123456789:AAExampleToken/getWebhookInfo

Achte in der Antwort auf die Felder: url muss mit deiner übereinstimmen, pending_update_count zeigt die Warteschlange unverarbeiteter Updates, last_error_date und last_error_message erscheinen, wenn Telegram ein Update nicht zustellen konnte. Ein leeres Fehlerfeld nach dem Senden einer Testnachricht bedeutet vollen Erfolg.

Prüfung: Schreibe dem Bot. Er antwortete „Per Webhook empfangen“. In getWebhookInfo gibt es kein last_error_message, und pending_update_count ist null. In den Flask-Logs ist die Zeile mit POST /tg/webhook und Code 200 sichtbar.

Achtung: Der Webhook-Handler muss schnell antworten, innerhalb weniger Sekunden. Wenn dein Code lange nachdenkt, zum Beispiel eine schwere Datenbankabfrage oder einen externen Dienst über einen langsamen Proxy aufruft, hält Telegram die Zustellung für fehlgeschlagen und wiederholt sie. Lagere schwere Arbeit in eine Hintergrundaufgabe aus und gib dem Webhook sofort 200 zurück.

Mögliche Probleme

  • last_error_message: SSL error. Das Zertifikat ist ungültig, abgelaufen oder auf eine andere Domain ausgestellt. Prüfe sudo certbot certificates.
  • Connection timed out. Port 443 ist in der Firewall oder beim Hoster geschlossen. Prüfe sudo ufw status und die Einstellungen im VPS-Panel.
  • Wrong response from the webhook: 403. Der Secret Token im Code und in setWebhook stimmen nicht überein. Prüfe die Groß-/Kleinschreibung.
  • Wrong response from the webhook: 502. Flask läuft nicht oder lauscht auf einem anderen Port. Prüfe ss -tlnp | grep 8080.
  • Bad webhook: port not allowed. Verwende nur 443, 80, 88 oder 8443.

Schritt 5: Fehler 429 behandeln und Anfragen robust machen

Ziel dieses Schritts: eine einzige Funktion für alle Aufrufe der Telegram Bot API schreiben, die bei 429 selbst pausiert, Anfragen bei Netzwerk- und Proxy-Ausfällen wiederholt und den Bot nie abstürzen lässt.

Warum man 429 nicht ignorieren darf

Wenn du einen Newsletter an tausend Nutzer sendest, ist das Limit von 30 Nachrichten pro Sekunde sofort erreicht. Telegram antwortet mit 429 und nennt retry_after. Wenn man weiter auf den Server hämmert, gehen die Nachrichten nicht raus, und die Wartezeit in den nächsten Antworten wächst. Beim Arbeiten über einen Proxy gibt es eine Besonderheit: Die Limits von Telegram hängen am Bot, nicht an der IP. Ein IP-Wechsel per Rotation hilft nicht, das Limit zu umgehen, und sollte dafür auch nicht genutzt werden. Der einzige richtige Weg ist, retry_after zu respektieren und die Sendegeschwindigkeit zu kontrollieren.

Einen universellen Wrapper schreiben

Füge in config.py oder in eine separate api.py folgende Funktion ein:

import time, requests
from config import PROXIES, BASE
def call(method, payload, retries=6):
for attempt in range(retries):
try:
r = requests.post(f'{BASE}/{method}', json=payload, proxies=PROXIES, timeout=15)
except requests.RequestException as e:
print('Netz oder Proxy:', e)
time.sleep(min(2 ** attempt, 30))
continue
if r.status_code == 429:
wait = r.json().get('parameters', {}).get('retry_after', 1)
print('429 Too Many Requests, warte', wait, 'Sek')
time.sleep(wait + 0.5)
continue
if 500 <= r.status_code < 600:
print('Telegram-Serverfehler', r.status_code)
time.sleep(min(2 ** attempt, 30))
continue
data = r.json()
if not data.get('ok'):
print('API-Fehler:', data.get('description'))
return data
raise RuntimeError('Telegram Bot API: alle Versuche für ' + method + ' ausgeschöpft')

Was diese Funktion tut. Bei einem Netzwerkfehler wartet sie exponentiell: 1, 2, 4, 8 Sekunden, aber höchstens 30. So übersteht der Bot einen IP-Wechsel am Proxy oder einen kurzen Kanalausfall. Bei 429 liest sie retry_after, addiert eine halbe Sekunde Reserve und wiederholt. Bei 5xx-Fehlern auf Telegram-Seite wiederholt sie ebenfalls mit Pause. Bei Fehlern 400 oder 403, zum Beispiel wenn der Nutzer den Bot blockiert hat, ist eine Wiederholung sinnlos, deshalb gibt die Funktion die Antwort unverändert zurück, und du entscheidest, was weiter passiert.

Geschwindigkeit vorab begrenzen

Besser ist, es gar nicht erst zu 429 kommen zu lassen. Für Newsletter füge eine Pause zwischen den Nachrichten ein. Die einfachste Variante: time.sleep(0.05) nach jeder Sendung ergibt 20 Nachrichten pro Sekunde, was unter dem Gesamtlimit liegt. Für einen einzelnen Chat halte eine Pause von mindestens einer Sekunde ein. Für Gruppen nicht öfter als 20 Nachrichten pro Minute.

def broadcast(chat_ids, text):
sent, failed = 0, 0
for cid in chat_ids:
res = call('sendMessage', {'chat_id': cid, 'text': text})
if res.get('ok'):
sent += 1
else:
failed += 1
time.sleep(0.05)
print('Gesendet:', sent, 'Fehler:', failed)

Tipp: Speichere Antworten mit Fehler 403 Forbidden: bot was blocked by the user. Entferne solche Nutzer aus der Newsletter-Datenbank. Das senkt die Last und schützt vor überflüssigen Limits, denn fehlgeschlagene Anfragen zählen ebenfalls.

Die 429-Behandlung testen

  1. Erstelle eine Testgruppe und füge den Bot hinzu.
  2. Starte eine Schleife mit 40 Aufrufen von call('sendMessage', {...}) in diesen Chat ohne Pausen.
  3. Beobachte in der Konsole: Nach einigen schnellen Sendungen erscheint eine Zeile zu 429 und Wartezeit.
  4. Stelle sicher, dass nach der Pause das Senden weitergeht und alle 40 Nachrichten ankommen.

Prüfung: Alle Nachrichten wurden zugestellt, der Bot stürzte nicht mit einer Ausnahme ab, im Log sind die retry_after-Pausen zu sehen. Ersetze requests.post in polling.py und webhook.py durch die Funktion call, damit die gesamte Kommunikation mit der Telegram Bot API über einen geschützten Kanal läuft.

Mögliche Probleme

  • retry_after riesig, Hunderte Sekunden. Du hast das Limit lange ignoriert. Stoppe das Senden komplett, warte die genannte Zeit und senke das Tempo.
  • 429 kommt schon bei den ersten Nachrichten. Ein anderer Prozess nutzt denselben Token. Prüfe, ob eine alte Bot-Version läuft.
  • Antwort bei 429 ist kein JSON. Manche Proxys liefern eine eigene HTML-Fehlerseite. Umhülle r.json() mit try und warte bei Misserfolg feste 5 Sekunden.

Schritt 6: Fortgeschrittene Einstellungen für belastete Projekte

Ziel dieses Schritts: den Bot auf Wachstum vorbereiten: mehrere Bots über mehrere Proxys, Sendewarteschlange, lokaler Bot-API-Server und geschickte Rotation. Anfänger können den Abschnitt überspringen und zurückkehren, wenn die Nutzerzahl über tausend steigt.

Mehrere Bots über verschiedene Proxys

Marketing-Profis betreiben oft ein Dutzend Bots für verschiedene Projekte von einem Server. Die richtige Architektur: für jeden Bot ein eigenes proxies-Dictionary und eine eigene requests.Session(). Die Session verwendet TCP-Verbindungen wieder, was die Proxy-Last senkt und Anfragen um das 2- bis 3-Fache beschleunigt. Halte die Konfiguration als Liste: Token, Proxy-Adresse, Modus zum Abrufen von Updates. Ein Prozess pro Bot ist leichter zu debuggen als ein Prozess für alle.

Sendewarteschlange statt direkter Aufrufe

Für Newsletter ab 10.000 Nutzern funktionieren direkte Aufrufe aus dem Hauptcode nicht mehr. Richte eine Warteschlange ein: Redis oder zumindest eine Tabelle in der Datenbank mit den Feldern chat_id, text, status, attempts. Ein separater Worker holt Aufgaben und ruft die Funktion call mit Geschwindigkeitskontrolle auf. Bei 429 schläft der Worker, statt den Empfang von Webhooks zu blockieren. So antwortet der Bot weiterhin auf Nutzerbefehle, während der Newsletter im Hintergrund läuft. Für 2026 erlaubt die Telegram Bot API bezahlten Bots über den Parameter allow_paid_broadcast, das Limit auf 1000 Nachrichten pro Sekunde zu erhöhen, aber dafür werden Stars abgebucht. Für die meisten Projekte bleibt eine Warteschlange mit 20–25 Nachrichten pro Sekunde die optimale Wahl.

Lokaler Bot-API-Server

Telegram veröffentlicht die Quellen des Bot-API-Servers, den man selbst starten kann. Dein Code wendet sich dann nicht an api.telegram.org, sondern an localhost, und der lokale Server kommuniziert mit Telegram. Vorteile: Dateiuploads bis 2 GB statt 50 MB, Webhooks auf jedem Port und ohne HTTPS im eigenen Netz, Aufhebung einiger Limits. Nachteil: Der Proxy muss auf Ebene des lokalen Servers eingerichtet werden, nicht im Bot-Code. Eine Variante für Teams mit DevOps-Kompetenz, für den Start überdimensioniert.

IP-Rotation und Webhooks

Bei Webhooks fällt die IP-Rotation am Proxy kaum auf: Jeder sendMessage-Aufruf ist kurz, und ein Verbindungsabbruch beim Wechsel betrifft höchstens eine Anfrage, die der Wrapper call wiederholt. Deshalb ist bei Webhooks eine häufigere Rotation erlaubt als beim Polling. Trotzdem macht häufiges Wechseln keinen Sinn: Die Telegram Bot API begrenzt Anfragen nicht nach IP, und die Limits hängen am Token. Stelle die Rotation aus Gründen deiner Infrastruktur ein, nicht wegen der API.

Health-Monitoring ohne separates System

Ein minimales Set, das du sofort einrichten solltest: Rufe jede Minute getWebhookInfo auf und schreibe pending_update_count und last_error_message ins Log. Wächst die Warteschlange drei Messungen hintereinander, kommt dein Handler nicht mit. Beim Polling notiere die Zeit des letzten erfolgreichen getUpdates: Sind mehr als zwei Minuten vergangen, hängt die Verbindung, starte den Prozess neu. Das reicht, um Probleme früher zu erfahren als die Kunden.

Tipp: Logge nicht nur Fehler, sondern auch die Zeit jeder Anfrage an die Telegram Bot API über den Proxy. Ein langsames Ansteigen der durchschnittlichen Antwortzeit von 0,3 auf 2 Sekunden warnt Tage im Voraus vor einer Verschlechterung des Kanals, bevor der Bot Nachrichten verliert.

Ergebnis prüfen: Checkliste für die fertige Lösung

Gehe die Liste durch. Jeder Punkt muss abgehakt sein, erst dann gilt der Bot als bereit für echte Nutzer.

Checkliste

  • Der curl-Befehl mit Parameter -x über den Proxy liefert "ok":true auf die Methode getMe.
  • Das Skript check.py zeigt die Proxy-IP, nicht deine eigene.
  • Polling antwortet genau einmal auf eine Nachricht, ohne Duplikate.
  • Nach Stoppen und Neustarten des Pollings werden verpasste Nachrichten verarbeitet.
  • Beim erzwungenen IP-Wechsel am Proxy erholt sich das Polling selbst in 3–5 Sekunden.
  • Webhook: getWebhookInfo zeigt deine url, pending_update_count null und last_error_message leer.
  • Eine Anfrage an den Webhook ohne Secret-Header erhält 403.
  • Schnelles Senden von 40 Nachrichten in einen Chat läuft ohne Absturz, im Log sind retry_after-Pausen sichtbar.
  • Token und Proxy-Daten liegen in .env, nicht im Code.

Wie man alles komplett testet

  1. Starte den Bot im gewählten Modus.
  2. Schreibe ihm von drei verschiedenen Konten je zwei Nachrichten.
  3. Stelle sicher, dass es sechs Antworten gibt, eine pro Nachricht.
  4. Klicke im Proxy-Kundenbereich den Link zum IP-Wechsel und sende sofort eine weitere Nachricht.
  5. Der Bot muss innerhalb von 10 Sekunden antworten.
  6. Starte den 429-Test aus Schritt 5.
  7. Prüfe die Logs: keine unbehandelten Ausnahmen und Stacktraces.

Erfolgsindikatoren

Die Antwortzeit des Bots auf eine Nachricht liegt unter 2 Sekunden. Der Anteil fehlgeschlagener Anfragen an die Telegram Bot API nach allen Wiederholungen liegt unter 0,1 Prozent. Kein einziges Duplikat in 24 Stunden Betrieb. pending_update_count in getWebhookInfo überschreitet in Spitzenzeiten zehn nicht. Entsprechen die Werte, dann herzlichen Glückwunsch: Du hast ein zuverlässiges Setup gebaut, das viele Monate hält.

Typische Fehler und ihre Lösungen

Fehler 409 Conflict bei getUpdates

Ursache: Für den Bot ist ein Webhook eingerichtet oder es laufen zwei Polling-Instanzen. Lösung: deleteWebhook über den Proxy aufrufen, sicherstellen, dass nur ein Prozess läuft. Prüfe den Befehl ps aux | grep polling.

Bot antwortet doppelt auf jede Nachricht

Ursache: Der offset wird nicht erhöht oder es laufen zwei Bot-Kopien auf verschiedenen Servern mit demselben Token. Lösung: Prüfe die Zeile offset = update_id + 1, stoppe überflüssige Kopien. Beim Webhook stelle sicher, dass nginx Anfragen nicht an zwei Backends dupliziert.

Fehler 407 Proxy Authentication Required

Ursache: Falsche Proxy-Zugangsdaten oder nicht kodierte Sonderzeichen im Passwort. Lösung: Login und Passwort im Kundenbereich prüfen, @, : und / im Passwort kodieren, IP-Authentifizierung versuchen, falls sie im Tarif verfügbar ist.

Read timed out alle 50–60 Sekunden

Ursache: Das Polling-Timeout ist größer oder gleich dem Idle-Timeout des Proxys. Lösung: Senke timeout in getUpdates auf 30–40 Sekunden und halte das Client-Timeout 10 Sekunden höher.

Webhook eingerichtet, aber es kommen keine Updates

Ursache: Port geschlossen, Zertifikat ungültig oder Handler antwortet nicht mit 200. Lösung: Sieh dir last_error_message in getWebhookInfo an, das ist die genaue Diagnose. Prüfe curl -I https://bot.example.com/tg/webhook von einem anderen Computer aus.

Wrong response from the webhook: 403 Forbidden

Ursache: Der Secret Token im Code unterscheidet sich von dem in setWebhook übergebenen. Lösung: Richte den Webhook mit demselben Wert wie im Code neu ein. Denk daran, dass setWebhook mit neuen Parametern die vorherigen vollständig ersetzt.

Ständige 429 bei geringer Last

Ursache: Der Bot sendet in einen Chat öfter als einmal pro Sekunde, zum Beispiel mehrere Nachrichten hintereinander als Antwort auf einen Befehl. Lösung: Fasse Antworten in einer Nachricht zusammen, nutze editMessageText statt neuer Nachrichten für Fortschritt, füge Pausen zwischen Sendungen an dieselbe chat_id ein.

Traffic läuft direkt, am Proxy vorbei

Ursache: Im proxies-Dictionary fehlt der Schlüssel https, die Umgebungsvariable ist für den Prozess nicht sichtbar, das Framework hat die Einstellung nicht übernommen. Lösung: Prüfe die ausgehende IP mit einer Anfrage an api.ipify.org im selben Code, mit dem du Nachrichten sendest. Vertraue nicht Vermutungen, prüfe tatsächlich.

SSL: CERTIFICATE_VERIFY_FAILED bei Anfragen über Proxy

Ursache: Veralteter Root-Zertifikatssatz oder falsche Systemzeit. Lösung: certifi aktualisieren, Zeit synchronisieren. Deaktiviere niemals die Zertifikatsprüfung mit dem Parameter verify=False: Das öffnet die Möglichkeit, Traffic mit dem Token zu ersetzen.

FAQ: Häufige Fragen zur Einrichtung

Was sollte man für den Anfang wählen: Polling oder Webhook?

Polling. Es funktioniert überall, braucht keine Domain und kein Zertifikat, und man kann später in einer Stunde auf Webhook umstellen. Ein Webhook ist sinnvoll, wenn der Bot Tausende Nutzer bedient oder auf einem Server läuft, auf dem es bereits HTTPS gibt.

Kann man einen Proxy für mehrere Bots nutzen?

Ja. Die Limits der Telegram Bot API hängen am Token des Bots, nicht an der IP. Zehn Bots über einen Proxy stören sich aus Sicht der API nicht. Die einzige Einschränkung ist der Durchsatz des Proxys selbst, für Textbots reicht er mit großem Spielraum.

Muss man sowohl Webhook als auch Antworten über den Proxy leiten?

Eingehende Webhook-Anfragen kommen direkt auf deinem Server an, über einen Proxy kann man sie per Definition nicht leiten. Über den Proxy laufen nur ausgehende Aufrufe: sendMessage, setWebhook, getFile und andere Methoden. Das ist ein normales und das einzig mögliche Vorgehen.

Wie erkennt man, dass Anfragen tatsächlich über den Proxy laufen?

Rufe im selben Code https://api.ipify.org mit denselben proxies-Einstellungen auf und vergleiche mit deiner echten IP. Zusätzlich kannst du die Traffic-Statistik im Proxy-Kundenbereich ansehen: Der Zähler muss beim Betrieb des Bots wachsen.

Was tun, wenn sich die IP am Proxy während des Bot-Betriebs ändert?

Nichts, wenn du den Code aus diesem Guide verwendet hast. Das Polling fängt den Verbindungsabbruch ab und macht mit dem gespeicherten offset weiter. Die Funktion call wiederholt die fehlgeschlagene Anfrage. Die einzige Empfehlung: Stelle die Rotation im Polling-Modus nicht häufiger als alle paar Minuten ein.

SOCKS5 oder HTTP-Proxy für die Telegram Bot API?

Für den Bot gibt es fast keinen Unterschied, beide funktionieren. HTTP-Proxy ist einfacher einzurichten und wird von allen Clients ohne Zusatzpakete unterstützt. SOCKS5 ist bequemer, wenn du DNS garantiert auf der Proxy-Seite auflösen willst, über das Schema socks5h. Wähle das, was du bereits in anderen Projekten nutzt.

Wie viele Nachrichten kann man senden, ohne 429 zu bekommen?

Halte dich an die Richtwerte: bis zu 1 Nachricht pro Sekunde in einen persönlichen Chat, bis zu 20 pro Minute in eine Gruppe, bis zu 25–30 pro Sekunde insgesamt. Für Massenaussendungen rechne mit 20 Nachrichten pro Sekunde und behandle unbedingt retry_after, denn die Limits können bei hoher Last auf Telegram vorübergehend sinken.

Wie stellt man einen bereits laufenden Bot sicher auf Proxy um?

Prüfe zuerst den Proxy mit curl auf getMe. Dann setze die Variable HTTPS_PROXY oder konfiguriere proxies im Code, starte den Bot mit einem Test-Token. Erst nach erfolgreichen Prüfungen schalte den Produktiv-Token um. Halte die alte Konfiguration für ein Rollback bereit.

Wie rollt man den Webhook zurück und kehrt zu Polling zurück?

Ein Aufruf von deleteWebhook über den Proxy. Wenn du die angesammelten Updates fürs Polling behalten willst, übergib nicht drop_pending_updates. Danach starte polling.py, und der Bot übernimmt die Warteschlange.

Kann man mehrere Webhook-URLs für einen Bot angeben?

Nein, ein Bot hat genau einen Webhook. Wenn du die Last verteilen musst, stelle hinter die einzige URL einen nginx-Loadbalancer, der Anfragen auf mehrere Anwendungsinstanzen verteilt. Für Telegram sieht das wie ein einziger Einstiegspunkt aus.

Fazit

Fassen wir die geleistete Arbeit zusammen. Du hast einen Bot erstellt und einen Token erhalten, gelernt, den Proxy mit curl und Python zu prüfen, und sichergestellt, dass der Traffic zur Telegram Bot API über die richtige Route läuft. Du hast eine robuste Long-Polling-Schleife gebaut, die einen IP-Wechsel übersteht und Nachrichten nicht dupliziert. Du hast einen Webhook mit echtem HTTPS-Zertifikat aufgesetzt und ihn mit einem Secret Token geschützt. Und das Wertvollste: Du hast eine Funktion geschrieben, die retry_after bei 429 respektiert, Anfragen bei Netzwerkausfällen wiederholt und einen launischen Kanal in einen zuverlässigen verwandelt.

Was als Nächstes zu tun ist. Richte den Bot als systemd-Service ein, damit er nach einem Serverneustart wieder startet. Lagere Tokens und Proxy-Adressen in Umgebungsvariablen auf der Produktivmaschine aus. Füge ein einfaches Log der Antwortzeiten hinzu und sieh es einmal pro Woche durch. Wenn die Nutzer zahlreich werden, wechsle zur Sendewarteschlange aus dem fortgeschrittenen Abschnitt.

Wohin du dich entwickeln kannst. Lerne die Methoden der Telegram Bot API für Inline-Tasten, Zahlungen und Mini-Apps kennen, sie eröffnen Bots völlig neue Szenarien für Marketing und Vertrieb. Meistere asynchrone Frameworks wie aiogram oder python-telegram-bot, sie nehmen dir die Routine von Polling und Wiederholungen ab, und du verstehst bereits, was unter der Haube passiert. Und vor allem: Hab keine Angst, mit einem Test-Bot zu experimentieren. Jeder Fehler 429 oder 409, den du selbst gefunden und behoben hast, macht dich stärker als jede fertige Vorlage. Du schaffst das.

Über den Autor

Roman Melnikov

Roman Melnikov

Technical Writer and System Administrator

Berufserfahrung: Technical writer and DevOps engineer with 9 years of experience. Created over 50 detailed guides on system configuration and administration. His instructions helped thousands of professionals successfully solve technical tasks. Popular author on Habr and YouTube.
Ausbildung: Bauman Moscow State Technical University. Information Systems and Technologies
Expertise:
Technical Documentation DevOps System Administration Linux Docker and Kubernetes CI/CD Infrastructure Automation Cloud Technologies System Monitoring Bash and Python Scripting

Diesen Artikel teilen: