Von Server- und Regionswahl über Basissicherheit, Proxy-Installation, Authentifizierung und Ports bis zur Client-Einrichtung, Prüfung und einer sinnvollen Reihenfolge für die Fehlersuche.
Server und Region auswählen
Ein Proxy selbst benötigt kaum CPU oder Arbeitsspeicher. Diese Werte sind bei der Auswahl der Serverkonfiguration daher nicht der wichtigste Punkt.
Eine leistungsstarke Konfiguration ist am Anfang meist unnötig. Paketangebote wie Lightweight-Application-Server mit fester Bandbreite und monatlichem Datenvolumen reichen für einen privaten Proxy mit einem oder wenigen Konten in der Regel aus und sind günstig. Erst wenn mehrere Instanzen oder klar definierte Bandbreitenanforderungen nötig sind, lohnt sich ein allgemeiner Servertyp, bei dem Ressourcen separat gewählt werden können.
Die Region ist wichtiger als die Hardware, denn der Exit-IP wird der Standort zugeordnet, an dem der Knoten betrieben wird. Die Regel ist einfach: Für den Markt, in dem ein Konto genutzt wird, sollte auch der Knoten stehen. Viele wählen nach Zugriffsgeschwindigkeit. Ein Knoten in Hongkong kann von Festlandchina aus schnell sein, doch wenn im Kontoprofil die USA stehen und der Exit in Asien liegt, ist diese Inkonsistenz wichtiger als die Geschwindigkeit. Geschwindigkeit ist zweitrangig; Konsistenz hat Priorität.
Die Bandbreite sollte sich am tatsächlichen Einsatz orientieren. Für Backend-Zugriffe und tägliche Verwaltung genügt wenig Bandbreite; für Bilder und Videos wird mehr benötigt; je mehr Konten gleichzeitig online sind, desto höher ist der Bedarf. Bei Unsicherheit mit dem kleinsten Paket starten, einen Monat beobachten und danach anpassen.
Diese Schritte direkt nach dem Start erledigen
Als Systemabbild eignet sich Linux. Solche Distributionen bringen SSH normalerweise bereits mit, sodass kein zusätzlicher Remote-Dienst eingerichtet werden muss. Beim Kauf ist ein eigenes Passwort statt einer Schlüsseldatei praktisch, weil später bei der Proxy-Konfiguration ein Umwandlungsschritt entfällt.
Nach dem Erhalt des Servers zuerst vier Angaben notieren: öffentliche IP, Benutzername (unter Linux standardmäßig root), Passwort und SSH-Port (standardmäßig 22). Genau diese Daten werden später im Client eingetragen.
Anschließend die grundlegende Sicherheit konfigurieren. Durch das Ändern des Standardports 22 lässt sich ein großer Teil automatisierter Scans abwehren. Unterstützt der Anbieter die Anmeldung per Schlüssel, kann nach deren Einrichtung die Passwortanmeldung deaktiviert werden. In Sicherheitsgruppe und System-Firewall nur tatsächlich benötigte Ports freigeben und alle anderen schließen. Das dauert nur wenige Minuten und reduziert dauerhaftes Scanning und Credential-Stuffing.
Zwei Wege für den Proxy-Dienst
Eine Möglichkeit ist ein direkter SSH-Tunnel. Auf dem Server muss nichts zusätzlich installiert werden: Der Client nutzt den vorhandenen SSH-Dienst zur Weiterleitung, mit Port 22 und den normalen Server-Zugangsdaten. Nachteil ist die begrenzte Leistung; bei dauerhaftem Betrieb oder hoher Parallelität kann es eng werden. Diese Variante eignet sich daher eher für kurzfristige Nutzung oder sehr wenige Konten.
Die zweite Möglichkeit ist ein eigener Proxy-Dienst auf dem Server. Häufig wird er mit einem einzigen Installationsbefehl eingerichtet; Authentifizierung und Port werden danach selbst konfiguriert. Das bietet mehr Leistung und Kontrolle und passt besser zum Dauerbetrieb. Nach der Installation den automatischen Start beim Booten aktivieren, sonst ist der Proxy nach einem Serverneustart nicht mehr verfügbar.
Authentifizierung und Ports
Grob gibt es drei Sicherheitsstufen: Benutzername und Passwort sind am einfachsten, aber ein bekannt gewordenes Passwort gibt praktisch den Proxy frei. Passwort plus Quell-IP-Allowlist reicht für den Alltag meist aus. Schlüssel- oder Zertifikatsauthentifizierung ist am robustesten, erfordert jedoch mehr Einrichtung und lohnt sich für langfristig genutzte Konten.
Beim Port genügt es nicht, nur den Listener des Proxy-Dienstes zu konfigurieren. Derselbe Port muss zusätzlich sowohl in der System-Firewall als auch in der Sicherheitsgruppe des Anbieters freigegeben werden. Beide Ebenen sind unabhängig; nur eine davon zu öffnen ist ein häufiger Grund für fehlgeschlagene Verbindungen. Außerdem darf die Listen-Adresse nicht ausschließlich an das lokale Loopback-Interface gebunden sein. Funktioniert ein Test auf dem Server selbst, aber nicht von außen, ist das oft die Ursache.
Im Client verbinden und prüfen
In einem Umgebungsverwaltungstool eine neue Umgebung anlegen, Name und Notiz hinzufügen und am besten Kontozweck sowie Zielregion in die Benennung aufnehmen. Danach je nach Proxy-Typ Serveradresse, Port, Benutzername und Passwort in den Proxy-Einstellungen eintragen und den Test starten. Eine Erfolgsmeldung zeigt, dass die Verbindung grundsätzlich steht. Die genauen Feldnamen richten sich nach der jeweiligen Oberfläche.
Ein bestandener Test ist nur der erste Schritt. Danach die Umgebung öffnen und drei Punkte prüfen.
Erstens: Entspricht die Exit-IP der öffentlichen IP des Servers? Auf einer Seite zur Anzeige der aktuellen IP muss die Serveradresse erscheinen.
Zweitens: Läuft auch DNS über den Proxy? Wird DNS weiterhin lokal aufgelöst, können die sichtbaren Standortinformationen nicht zur Exit-IP passen; dann hilft auch die eingestellte Kontoregion wenig.
Drittens: Passen Zeitzone und Sprache zur Exit-Region? Eine US-IP zusammen mit chinesischer Zeitzone und chinesischer Sprache ist eine leicht erkennbare Inkonsistenz.
Erst wenn alle drei Prüfungen bestanden sind, ist die Umgebung einsatzbereit.
Bei Verbindungsproblemen in dieser Reihenfolge prüfen
Scheitert der Proxy-Test sofort, zuerst die Erreichbarkeit kontrollieren: Ist der Port in Sicherheitsgruppe und System-Firewall freigegeben? Danach prüfen, ob der Proxy-Dienst läuft, besonders nach einem Neustart. Anschließend Benutzername und Passwort sowie die Serveradresse kontrollieren. Eine öffentliche mit einer privaten IP zu verwechseln kommt häufig vor.
Besteht der Test, aber Webseiten öffnen sich nicht, liegt das Problem meist auf der Umgebungsseite. Prüfen, ob der richtige Proxy zugeordnet ist und ob DNS nicht wieder auf lokale Auflösung zurückgestellt wurde.
Ist die Verbindung langsam, zuerst zwischen Entfernung und Bandbreite unterscheiden. Die Zielseite direkt vom Server aus testen. Ist schon der Server langsam, liegt es an Region oder Netzroute. Ist der Server schnell, der Client aber langsam, fehlt meist Bandbreite oder es sind zu viele Konten gleichzeitig online.
Skalierung bei mehr Konten
Mehrere Konten auf einem Server sind günstig, teilen sich aber dieselbe Exit-IP. Wenn eine Plattform Zusammenhänge anhand von IP-Bereichen erkennt, können die Konten weiterhin miteinander verknüpft werden. Ein Server pro Konto kostet mehr, trennt die Umgebungen dafür vollständig und ist bei wertvolleren Konten die robustere Variante.
Mit einem Umgebungsverwaltungstool wie PurpleMark lässt sich für jedes Konto ein eigener Exit zuverlässiger binden als über eine manuell gepflegte Zuordnungstabelle. Bei typischen Preisen für Lightweight-Server ist ein Exit pro Konto in vielen Fällen bezahlbar und erspart später möglicherweise den Neuaufbau verbundener Konten. Zusätzlich sollte ein separater Testserver vorhanden sein. Nicht alle Konten auf einer Maschine bündeln, denn ein einzelner Ausfall würde sonst alle gleichzeitig treffen.
