{"id":611,"date":"2026-08-24T16:22:54","date_gmt":"2026-08-24T16:22:54","guid":{"rendered":"https:\/\/wordpress-foccwcs4gooocs44ogwkggo0.thunderproxy.com\/?p=611"},"modified":"2026-08-24T16:22:54","modified_gmt":"2026-08-24T16:22:54","slug":"wie-viele-accounts-pro-proxy","status":"publish","type":"post","link":"https:\/\/wordpress-foccwcs4gooocs44ogwkggo0.thunderproxy.com\/index.php\/de\/2026\/08\/24\/wie-viele-accounts-pro-proxy\/","title":{"rendered":"Wie viele Accounts pro Proxy? Ein praktischer Leitfaden nach Anwendungsfall"},"content":{"rendered":"

Last updated: August 20, 2026<\/em><\/p>\n

F\u00fcr jeden Account, in den Sie sich anmelden, planen Sie eine dedizierte IP pro Account. H\u00f6here Verh\u00e4ltnisse sind nur f\u00fcr zustandslosen Traffic akzeptabel, der sich nie anmeldet; dort dimensionieren Sie nach gleichzeitigen Sitzungen statt nach Accounts. Bei Thunderproxy entspricht das statischen ISP-Adressen f\u00fcr dauerhafte Identit\u00e4ten und rotierendem Residential f\u00fcr zustandsloses Volumen. Was die Antwort \u00e4ndert, ist, wie empfindlich das Ziel gegen\u00fcber Adresswiederverwendung ist, wie lange jede Sitzung l\u00e4uft und ob Sie eine dedizierte IP halten oder aus einem gemeinsamen Pool beziehen.<\/p>\n

Die kurze Antwort, nach Anwendungsfall<\/h2>\n

Das Accounts-pro-Proxy-Verh\u00e4ltnis ist keine einzelne Zahl. Es h\u00e4ngt vollst\u00e4ndig davon ab, ob die Arbeit eine Anmeldung umfasst. Die Tabelle unten gibt das praktische Verh\u00e4ltnis f\u00fcr die h\u00e4ufigsten Aufgaben. F\u00fcr jeden anmeldebezogenen Anwendungsfall lautet die Antwort ein Account pro IP. F\u00fcr zustandslose Arbeit gibt es \u00fcberhaupt kein Account-Verh\u00e4ltnis, nur ein Gleichzeitigkeitslimit.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Anwendungsfall<\/th>\nAccounts oder Sitzungen pro IP<\/th>\nProxy-Typ<\/th>\nSession-Modus<\/th>\nWarum<\/th>\n<\/tr>\n<\/thead>\n
Langlebige Social-Profile<\/td>\n1<\/td>\nStatic ISP<\/td>\nPersistent<\/td>\nFeste Identit\u00e4t braucht feste Adresse<\/td>\n<\/tr>\n
Marketplace-Verk\u00e4uferaccounts<\/td>\n1<\/td>\nStatic ISP<\/td>\nPersistent<\/td>\nEin Storefront, eine Adresse<\/td>\n<\/tr>\n
Werbeaccounts<\/td>\n1<\/td>\nStatic ISP<\/td>\nPersistent<\/td>\nHohe Empfindlichkeit gegen\u00fcber Wiederverwendung<\/td>\n<\/tr>\n
Crypto-Wallet-Dashboards<\/td>\n1<\/td>\nStatic ISP<\/td>\nPersistent<\/td>\nAnmeldegebundene Identit\u00e4t<\/td>\n<\/tr>\n
E-Mail-Postf\u00e4cher<\/td>\n1<\/td>\nStatic ISP<\/td>\nPersistent<\/td>\nAnmeldegebundene Identit\u00e4t<\/td>\n<\/tr>\n
Agentur-Client-Accounts (teamgeteilt)<\/td>\n1<\/td>\nStatic ISP<\/td>\nPersistent<\/td>\nEine Adresse pro Client-Identit\u00e4t<\/td>\n<\/tr>\n
Checkout- oder Drop-Aufgaben<\/td>\n1 pro Task-Sitzung<\/td>\nRotating residential<\/td>\nSticky<\/td>\nKurzlebig, pro Task-Sitzung<\/td>\n<\/tr>\n
Scraping und Monitoring, ohne Anmeldung<\/td>\nPro gleichzeitiger Sitzung<\/td>\nRotating residential<\/td>\nRotating<\/td>\nKein Sitzungszustand zu sch\u00fctzen<\/td>\n<\/tr>\n
SERP- und Rank-Tracking<\/td>\nPro gleichzeitiger Sitzung<\/td>\nRotating residential<\/td>\nRotating<\/td>\nZustandslose Abfragen<\/td>\n<\/tr>\n
QA und Geo-Testing<\/td>\nPro gleichzeitiger Sitzung<\/td>\nRotating residential<\/td>\nSticky oder rotating<\/td>\nKeine dauerhafte Identit\u00e4t<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Compliance-Hinweis: Die Plattformbedingungen entscheiden, wie viele Accounts Sie halten d\u00fcrfen. Proxies entscheiden nur, wie sauber die Accounts, zu denen Sie berechtigt sind, im Netzwerk getrennt bleiben. Diese Seite behandelt Kapazit\u00e4tsplanung und Sitzungshygiene f\u00fcr legitimes Account-Management, nicht das Umgehen von Durchsetzung oder Nutzungsbedingungen.<\/p>\n

Warum das Verh\u00e4ltnis \u00fcberhaupt z\u00e4hlt<\/h2>\n

Eine geteilte Adresse ist ein geteiltes Signal. Wenn zwei Accounts, die Sie getrennt halten, sich von derselben IP anmelden, haben Sie dem Netzwerk signalisiert, dass sie zusammengeh\u00f6ren, unabh\u00e4ngig von Ihrer Absicht. Diese Verbindung wird st\u00e4rker, wenn derselbe Ger\u00e4te-Fingerprint hinter derselben Adresse sitzt, weil sich die beiden Signale gegenseitig verst\u00e4rken.<\/p>\n

Es gibt zwei weitere mechanische Gr\u00fcnde, warum das Verh\u00e4ltnis z\u00e4hlt. Erstens werden Rate Limits pro Adresse durchgesetzt; mehrere Accounts hinter einer IP konkurrieren also um dasselbe Request-Budget und l\u00f6sen Limits fr\u00fcher aus. Zweitens invalidiert eine Rotation mitten im Ablauf die Sitzung: \u00e4ndert sich die Adresse w\u00e4hrend Sie angemeldet sind, sieht die Gegenseite die Sitzung wandern und kann sie abbrechen. Nichts davon geht um Verstecken. Es geht darum, keine widerspr\u00fcchlichen Netzwerksignale f\u00fcr Identit\u00e4ten zu senden, die unabh\u00e4ngig sein sollen.<\/p>\n

Die drei Variablen, die Ihr Verh\u00e4ltnis bestimmen<\/h2>\n

Ihr Verh\u00e4ltnis wird von drei Dingen entschieden, in dieser Reihenfolge.<\/p>\n

1) Dedizierte IP versus gemeinsamer Pool.<\/strong> Eine statische ISP-Adresse ist eine Adresse, die Sie f\u00fcr die Laufzeit des Lease halten. Ein rotierender Residential-Proxy ist ein Pool, den Sie \u00fcber eine Session-ID ansprechen; selbst eine Sticky-Session ist best-effort und an eine TTL gebunden. Wenn eine Identit\u00e4t bestehen muss, braucht sie eine Adresse, die besteht \u2014 also eine dedizierte IP. Wenn die Arbeit zustandslos ist, ist ein Pool nicht nur akzeptabel, sondern das richtige und g\u00fcnstigere Werkzeug.<\/p>\n

2) Sitzungsl\u00e4nge versus Rotation.<\/strong> Eine langlebige Anmeldung will, dass die Adresse Stunden oder Tage stehen bleibt. Eine zustandslose Anfrage will so oft wie m\u00f6glich eine frische Adresse. Passen Sie den Session-Modus an die Arbeit an: persistent f\u00fcr Logins, rotating f\u00fcr Volumen, sticky nur f\u00fcr kurze, begrenzte Aufgaben.<\/p>\n

3) Wie empfindlich das Ziel gegen\u00fcber Adresswiederverwendung ist.<\/strong> Manche Plattformen behandeln eine wiederholte Adresse als Routine. Andere behandeln sie als starke Verkn\u00fcpfung zwischen Accounts. Wenn ein Ziel empfindlich ist, halten Sie das Verh\u00e4ltnis bei eins und teilen Sie nicht.<\/p>\n

Statischer ISP versus rotierendes Residential: welches pro Account<\/h2>\n

Verwenden Sie einen statischen ISP-Proxy, wenn eine dauerhafte Identit\u00e4t eine feste Adresse braucht. Ein Social-Profil, ein Verk\u00e4ufer-Shop, ein Anzeigenkonto oder ein Postfach ist bei jeder Anmeldung dieselbe Identit\u00e4t und sollte daher jedes Mal dieselbe Adresse pr\u00e4sentieren. Eine Thunderproxy-Static-ISP-Adresse ist ein 30-Tage-Lease mit unbegrenzten Verl\u00e4ngerungen und unbegrenzter Bandbreite; die Identit\u00e4t beh\u00e4lt also eine stabile Adresse, solange Sie erneuern, und schwere In-Session-Daten \u00e4ndern die Rechnung nicht. Die Abdeckung ist auf eine kleinere L\u00e4ndergruppe begrenzt \u2014 pr\u00fcfen Sie, ob Ihre Zielregion verf\u00fcgbar ist. Aktuelle L\u00e4nderabdeckung finden Sie in den Static-ISP-Pl\u00e4nen<\/a>.<\/p>\n

Verwenden Sie rotierendes Residential, wenn die Arbeit zustandslos ist und Rotation pro GB die g\u00fcnstigere und richtige Wahl ist. Scraping, Monitoring, SERP- und Rank-Tracking sowie Geo-Testing halten kein Login; sie gewinnen nichts von einer festen Adresse und alles von einem gro\u00dfen, frischen Pool. Rotierendes Residential zieht aus 30M+ IPs in 155+ L\u00e4ndern mit Country-, State- und City-Targeting; abgerechnet wird die bewegte Datenmenge, nicht geparkte Adressen. Zum Unterschied zwischen rotating und sticky siehe Sticky Sessions<\/a>.<\/p>\n

So dimensionieren und bepreisen Sie Ihre Flotte<\/h2>\n

Dimensionieren Sie die Flotte nach Identit\u00e4ten f\u00fcr Logins und nach Gleichzeitigkeit f\u00fcr zustandslose Arbeit, und bepreisen Sie jeweils mit dem passenden Abrechnungsmodell.<\/p>\n

Beispiel 1: eine Agentur mit dauerhaften Client-Logins (pro IP).<\/strong> Sie verwalten 10 Client-Accounts, die jeweils eine stabile Identit\u00e4t brauchen: Social-Profile und Anzeigenkonten. Das Verh\u00e4ltnis ist eine dedizierte IP pro Account, also brauchen Sie 10 Static-ISP-Adressen.<\/p>\n