TL;DR: Instagram sperrt keine Konten, weil ein Bot sie angefasst hat. Es markiert Verhalten, das automatisiert aussieht — gleichmäßige Abstände, Schübe, identische Texte, fehlendes Browsen. Das hier ist ein Build-Log über einen kleinen Automations-Stack, der sich wie ein Mensch verhalten soll, die Recherche hinter jeder Schutzmaßnahme und die ehrliche Antwort darauf, was das bringt.
Vor dem technischen Teil der langweilige Teil: Automatisierte Interaktion verstößt gegen Instagrams Nutzungsbedingungen. Gebaut wurde das für einen einzelnen, klar markierten Burner-Account und für die Recherche darüber, wie Plattformen Automatisierung erkennen — nicht für Skalierung, nicht für Spam und nicht für ein Hauptkonto. Alles hier ist dokumentiert, weil die Detektionsseite das interessante technische Problem ist, nicht weil es einen sicheren Weg gibt, einen Bot zu betreiben.
Die Ausgangslage
Das Ziel war eng: ein Konto, Follow, Like, Kommentar und Unfollow, von einer lokalen Maschine, mit der Möglichkeit, alles sofort zu stoppen und danach genau zu sehen, was passiert ist. Keine Cloud, keine Farm, keine weiterverkauften Proxys. Ein Worker auf einem Laptop, eine kleine Web-Konsole, ein Protokoll.
Der interessante Teil sind nicht die API-Aufrufe. Es ist die Tatsache, dass ein Automationssystem genau auf die Signale optimiert, an denen eine Plattform es erkennt.
Was die Plattform wirklich misst
Instagram veröffentlicht seine Limits nicht, und die Zahlen, die online kursieren, sind Folklore. Was Meta sagt: Die Schwellen sind dynamisch und hängen von Alter des Kontos, Historie, Geschwindigkeit, Wiederholung und Meldungen ab. Genau gelesen ist das eine Beschreibung der Form des Verhaltens, nicht eines Zählers.
Vier Eigenschaften zählen mehr als jede Tageszahl:
- Regelmäßigkeit der Abstände. Maschinelle Zeitpläne erzeugen gleichmäßige Abstände. Menschen klicken nicht eine Stunde lang alle 30,0 Sekunden auf „Gefällt mir".
- Geschwindigkeit und Cluster. Zwanzig Aktionen in neunzig Sekunden aus einer Quelle wirken skriptgesteuert, selbst wenn die Tagessumme klein ist. Aktionen pro Stunde zählen mehr als Aktionen pro Tag.
- Wiederholung. Derselbe Kommentartext über mehrere Posts ist der klarste Fingerabdruck, den es gibt.
- Kein Browsen. Eine Session, die nur schreibt — folgen, liken, kommentieren, schließen — nie scrollt, nie ein Profil öffnet, ohne zu handeln, nie zum Lesen innehält.
Wenn sich diese Signale häufen, folgt eine Leiter, kein Schalter:
| Stufe | Symptom | Typische Dauer |
|---|---|---|
| 1 | „Versuche es später erneut" — weiche Warnung | Minuten bis Stunden |
| 2 | Action-Block für eine Aktion | Stunden bis 48 h |
| 3 | Erweiterter Block, teils mehrere Aktionen | 3 bis 7 Tage |
| 4 | Reichweiten-Drosselung, kein Fehler sichtbar | 14 bis 30 Tage |
| 5 | Funktionslimits oder Konto deaktiviert | bis zur Prüfung |
Die Falle ist Stufe zwei. Eine blockierte Aktion erneut zu versuchen, verlängert den Block — so wird aus einer weichen Warnung eine Woche. Jeder vernünftige Client behandelt eine Rate-Limit-Ausnahme als Stoppsignal, nicht als Retry.
Der Stack
Das System besteht aus drei Teilen und einer Handvoll Zustandsdateien.
| Teil | Aufgabe |
|---|---|
| Worker | Python-Prozess auf der Loopback-Schnittstelle mit Bearer-Token; kapselt die Client-Bibliothek und besitzt den gesamten Zustand |
| Konsole | Passwortgeschützte Seite, die nur mit dem lokalen API-Proxy spricht — das Worker-Token erreicht nie den Browser |
| Zustand | Einfache Dateien: Session, Kontoprofil, Limits, Queue, Aktivitätsprotokoll, Log der verwendeten Kommentare |
| Protokoll | Eine append-only Zeile pro Aktion — das macht einen Lauf im Nachhinein prüfbar |
Zwei Entwurfsregeln halten das System langweilig. Jobs starten standardmäßig als Dry-Run — jeder Runner protokolliert, was er tun würde, und berührt nichts, bis die Ausführung ausdrücklich angefordert wird. Und es laufen höchstens zwei Jobs gleichzeitig, nie zwei derselben Art: Ein Kommentar-Job und ein Unfollow-Job dürfen sich überlappen, aber die Aktionsrate bleibt innerhalb des Pacing-Rahmens.
Die Pacing-Engine
Jede Aktion ist von der nächsten durch eine Verzögerung getrennt, die aus einer gewichteten Verteilung gezogen wird, nicht aus einer gleichmäßigen. Gleichmäßiger Zufall wirkt ebenfalls maschinell, weil die Varianz falsch ist: Menschen handeln meist schnell, trödeln gelegentlich und erzeugen selten den langen Ausläufer.
Jede Aktionsart hat einen Bereich, und jeder Bereich wird in drei Bändern gezogen:
Standard-Verzögerungen:
| Aktion | Bereich | Ziehung |
|---|---|---|
| Follow | 45 bis 120 s | meist unteres Drittel, 5 Prozent langer Ausläufer |
| Like | 20 bis 60 s | gleiche Form |
| Kommentar | 60 bis 180 s | gleiche Form |
| Unfollow | 40 bis 90 s | gleiche Form |
| Session-Durchlauf | 30 bis 120 s | gleiche Form |
Danach multipliziert ein globaler Jitter das Ergebnis mit einem Zufallsfaktor von bis zu 40 Prozent, und der Wert wird ausdrücklich unrund erzwungen — eine Verzögerung von 102,4 Sekunden, nie 100. Runde Zahlen sind ein Verräter.
Dazu kommt:
- Micro-Breaks. Nach vier bis acht Aktionen legt der Pacer eine Pause von zwei bis acht Minuten ein. Eine lange Session ohne Pausen ist ein Schub, egal wie die einzelnen Verzögerungen aussehen.
- Ein Aktivfenster. Jobs starten nur zwischen 08:00 und 23:00 Uhr Ortszeit, außer sie werden ausdrücklich erzwungen. Um 04:00 Uhr zu automatisieren ist kostenloses Beweismaterial.
- Settle-in. Jeder Job wartet nach dem Start fünf bis fünfundvierzig Sekunden bis zur ersten Aktion — so wie ein Mensch nicht in der Sekunde klickt, in der eine Seite öffnet.
- Szenenpausen. In Feed-Sessions folgt auf jeden Durchlauf eine zufällige Pause von zwei bis acht Minuten — die „schaut gerade etwas"-Lücke.
Im Code sind es vier Zeilen:
span = max_s - min_s
roll = random.random()
if roll < 0.7: return random.uniform(min_s, min_s + span * 0.4)
if roll < 0.95: return random.uniform(min_s + span * 0.4, max_s)
return random.uniform(max_s, max(max_s * 1.8, max_s + 30))
Die Limits
Verzögerungen formen eine Session; Limits formen einen Tag. Beide werden serverseitig durchgesetzt, damit die Konsole den Worker nicht überreden kann, sie zu überschreiten.
| Aktion | Pro Stunde | Pro Tag |
|---|---|---|
| Follow | 10 | 30 |
| Like | 30 | 100 |
| Kommentar | 5 | 20 |
| Unfollow | 25 | 150 |
Zwei dieser Zahlen kamen wegen der Recherche dazu, nicht trotz ihr. Die Tageslimits gab es von Anfang an; die Stundenlimits nicht — und die Recherche ist eindeutig, dass Geschwindigkeit pro Stunde beurteilt wird, nicht pro Tag.
Der Rest der Schutzmaßnahmen sitzt auf derselben Ebene:
- Warm-up. Ein frisches Konto bekommt auf jedes Limit einen Multiplikator — 10 Prozent, dann 25, dann 50 — für die ersten vierzehn Tage, und die Konsole verweigert die Ausführung, bis das Konto mindestens einen Tag alt und das Profil vollständig ist.
- Harte Pause. Rate-Limit-Ausnahmen stoppen nicht nur den laufenden Job; sie schreiben einen
paused_until-Zeitstempel, der jeden Job für 24 bis 48 Stunden blockiert (48 bis 72 bei den stärkeren Signalen). Die weiche Warnung wird als Urteil behandelt, nicht als Schluckauf. - Kill-Switch. Eine einzelne Datei auf der Platte bricht alles ab: laufende Jobs prüfen sie bei jedem Sleep-Tick, und die API lehnt neue Arbeit ab, solange sie existiert.
- Ein Konto, ein Ausgang. Registrierung und Automations-Traffic verlassen dasselbe Netz. Eine Residential-IP, die mitten im Leben wechselt, ist ein Signal, keine Tarnung.
Nicht zweimal dasselbe sagen
Das Kommentarsystem ist der Teil, den die Recherche am stärksten verändert hat — Wiederholung ist der klarste Automations-Fingerabdruck.
Der Pool umfasst 152 Kommentare in 17 Kategorien — von typography und art bis datascience und city —, aber der Pool ist nicht das Interessante. Das Matching ist es:
- Die Caption eines Posts wird per Keyword-Regeln über Caption und Hashtags einer Kategorie zugeordnet.
- Ein Kommentar wird aus dieser Kategorie gezogen, ohne etwas, das in der Session bereits verwendet wurde.
- Verwendete Kommentare landen mit einem Dreißig-Tage-Fenster in einem Log, damit derselbe Text nicht Wochen später wieder auftaucht.
- Der Betreiber kann den Entwurf bearbeiten — das System schlägt vor, es veröffentlicht nicht blind.
Ein Kommentar-Job, der vier von fünf Entwürfen postet und einen vom Klassifizierer verworfen bekommt, ist normal. Was nie passieren darf: denselben Satz zweimal posten.
Den Feed wie ein Mensch lesen
Der interessanteste Job ist der, der am wenigsten tut: eine „Sofa-Session", die den echten Timeline-Feed liest.
Sie zieht den authentifizierten Home-Feed, filtert Werbung, überspringt bereits gelikte Posts, mischt jeden Durchlauf neu und verhält sich dann wie jemand, der nebenbei schaut: Sie likt einen konfigurierbaren Anteil (standardmäßig 65 Prozent), kommentiert eine kleine klassifizierte Teilmenge und „schaut eine Szene" für zufällige zwei bis acht Minuten zwischen den Durchläufen. Nichts davon ist gezielt. Das einzige Produkt ist Historie — ein Konto mit Timeline und Leerlauf sieht aus wie ein Konto, das jemand benutzt, und genau diese Eigenschaft fehlt einem Bot.
Was die Recherche verändert hat
Die Übersetzung der Recherche in Code ergab eine kurze, unangenehme Liste. Vier Punkte wurden umgesetzt:
- Stundenlimits kamen dazu, weil die Geschwindigkeit pro Stunde der eigentliche Auslöser ist.
- Warm-up wurde ein Profil mit Multiplikatoren statt einer Notiz im Readme.
- Die harte Pause ersetzte Cooldowns pro Job, damit das Konto stoppt, nicht nur der Job.
- Kommentar-Rotation bekam ein persistentes Log mit Dreißig-Tage-Fenster.
Drei Punkte sind bewusst nicht umgesetzt, weil sie das System schlechter machen würden, nicht besser: Ban-Evasion (ein Ersatzkonto vom selben Gerät wird verknüpft und stirbt binnen Stunden), gekauftes Engagement und alles, was ein Hauptkonto berührt. Kreuz-Ansteckung ist real — eine verknüpfte Seite, die aus einem unrelated Grund gesperrt wird, kann das Konto mitreißen.
Was nichts davon garantiert
Die ehrliche Zusammenfassung: Jede Zahl in diesem Artikel ist eine Milderung, keine Kontrolle. Instagrams Schwellen sind unveröffentlicht und dynamisch, und die einzige belastbare Aussage ist verhaltensförmig — „das sieht automatisiert aus" ist ein Urteil, und Urteile können in beide Richtungen falsch sein. Ein perfekt getakteter Bot kann durch eine Meldungswelle von Nutzern markiert werden; eine schlampige manuelle Session durch gar nichts.
Diese Asymmetrie ist die Erkenntnis. All diese Technik kauft nur eine geringere Wahrscheinlichkeit, maschinell offensichtlich zu sein — und ein System, das sauber stoppt, wenn die Plattform Stopp sagt. Wenn das Konto blockiert wird, funktioniert nur das langweilige Protokoll: Aktion sofort einstellen, alles ein bis zwei Tage pausieren, die App weiter menschlich nutzen, mit einem Viertel des Volumens zurückkommen. Wenn je ein Drittanbieter-Tool Zugriff hatte: widerrufen und Passwort ändern.
Und der wichtigste Teil: Die Konsole für dieses System ist abgeschaltet. Sie läuft nur gegen einen dedizierten Burner-Account — und bleibt aus, bis es einen gibt.
Fazit
- Plattformen erkennen die Form des Verhaltens — Abstandsregelmäßigkeit, Geschwindigkeit, Wiederholung, fehlendes Browsen — lange bevor sie Aktionen zählen.
- Eine blockierte Aktion erneut zu versuchen verlängert den Block; eine Rate-Limit-Ausnahme ist ein Stoppsignal, kein Retry.
- Gewichtete Verzögerungen, Jitter, Micro-Breaks und ein Aktivfenster greifen die Form an; Limits greifen das Volumen. Beides ist nötig, nichts davon reicht.
- Wiederholung ist der klarste Fingerabdruck — deshalb geht es beim Kommentarsystem um Klassifikation und Rotation, nicht um Volumen.
- Manches lässt sich clientseitig gar nicht mildern: Ban-Evasion, gekauftes Engagement und Kreuz-Ansteckung machen es einfach nur schlimmer.