Die Anwendung ignoriert Proxys: wie man den Verkehr umleitet

```html

Sie haben einen Proxy in den Windows-Einstellungen konfiguriert, das Programm neu gestartet – und es verwendet immer noch die heimische IP. Oder umgekehrt: Der Browser geht brav über den Proxy, während der Desktop-Client daneben weiterhin die echte Adresse anzeigt. Das ist kein Proxy-Bug und keine fehlerhaften Zugangsdaten. Es ist eine grundlegende Eigenschaft, wie Betriebssysteme mit dem „Systemproxy“ umgehen: Er zwingt nicht, sondern bietet nur an.

Im Folgenden finden Sie vier funktionierende Methoden, um eine bestimmte Anwendung über SOCKS5 zu leiten, mit den Einschränkungen jeder Methode und den Fallstricken, an denen die Konfiguration häufig scheitert.

Warum der Systemproxy nicht funktioniert: eine kurze technische Wahrheit

In Windows gibt es nicht einen „Systemproxy“. Es gibt mindestens zwei unabhängige Satz von Einstellungen. Der erste ist WinINET: das, was Sie unter „Einstellungen → Netzwerk und Internet → Proxy-Server“ ändern. Dies wird von Internet Explorer/Edge, einigen .NET-Anwendungen und allem, was den standardmäßigen Benutzer-HTTP-Stack verwendet, gelesen. Der zweite ist WinHTTP, der von Systemdiensten und Hintergrundprozessen verwendet wird. Und hier ist der Schlüssel: WinHTTP verwendet die WinINET-Einstellungen nicht, es sei denn, Sie importieren sie ausdrücklich. Dies geschieht mit dem Befehl netsh winhttp import proxy source=ie, und – ein wichtiger Punkt aus der Microsoft-Dokumentation – der Befehl nimmt einen Schnappschuss der aktuellen Einstellungen. Haben Sie den Proxy später in den Einstellungen geändert? Der Schnappschuss wird nicht automatisch aktualisiert, der Befehl muss erneut ausgeführt werden.

Doch selbst der Import schützt nicht vor der Hauptkategorie von Problemen. Eine enorme Anzahl von Programmen fragt das System überhaupt nicht: Sie verwenden ihren eigenen Netzwerk-Stack und öffnen TCP-Sockets direkt. So funktionieren viele Desktop-Clients von sozialen Netzwerken und Messengern, Spiel-Launcher, Torrents, einige Electron-Anwendungen mit fest codierter Konfiguration, kompilierte Go- und Rust-Utilities. Für sie existiert die Zeile „Proxy“ in den Betriebssystemeinstellungen einfach nicht als Begriff.

Hieraus ergibt sich die Regel: Wenn eine Anwendung kein eigenes Feld für den Proxy hat, ist der einzige zuverlässige Weg, ihren Verkehr unterhalb der Anwendungsebene abzufangen. Es gibt genau vier Klassen von Methoden, die sich grundlegend in Preis, Zuverlässigkeit und erforderlichen Rechten unterscheiden.

Schritt 0: Stellen Sie sicher, dass das Problem genau darin liegt

Starten Sie die Anwendung und sehen Sie, welche IP sie anzeigt (Profilseite, Dienstseite, jeder integrierte Indikator).
Öffnen Sie parallel den Browser über denselben Proxy und vergleichen Sie die Adresse. Verschiedene IPs = die Anwendung ignoriert die Systemeinstellung.
Überprüfen Sie, ob das Programm eigene Proxy-Einstellungen hat – oft sind sie in „Netzwerk“, „Verbindung“ oder in der Konfigurationsdatei versteckt. Nativ unterstützte Konfigurationen sind immer besser als externe Abfangmethoden: weniger Schichten, weniger Fehler.
Überprüfen Sie separat DNS. Wenn die Anwendung Namen lokal auflöst und der Verkehr über den Proxy geht, sieht Ihr tatsächlicher Anbieter trotzdem, wohin Sie gehen.

Methode 1. Proxifier – der kommerzielle Standard für Windows und macOS

Proxifier fängt die Verbindungen von Anwendungen ab und leitet sie gemäß den Regeln an den angegebenen Proxy weiter: Sie können festlegen „dieses exe – über Proxy A, jenes – über Proxy B, das übrige – direkt“, nach Ports und Zieladressen aufteilen und eine Kette aus mehreren Proxys aufbauen.

Aktuelle Versionen zum Zeitpunkt des Schreibens: 4.14 für Windows (Veröffentlichung am 23. April 2025) und 3.15 für macOS (18. September 2025). Lizenz – $39.95 pro Kopie, einmaliger Kauf, unbefristet, mit kostenlosen Minor-Updates; es gibt eine 31-tägige voll funktionsfähige Testversion, Mengenrabatte ab zwei Kopien und eine Rückgabe innerhalb von 30 Tagen.

Praxis der Konfiguration:

Proxy-Server → Hinzufügen: Geben Sie die Adresse, den Port, das SOCKS5-Protokoll und die Zugangsdaten an. Klicken Sie auf Überprüfen – der Test sollte bestehen, bevor Sie Regeln erstellen, sonst debuggen Sie zwei Probleme gleichzeitig.
Proxifizierungsregeln → Hinzufügen: Wählen Sie unter Anwendungen die spezifische ausführbare Datei aus, unter Aktion – Ihren Proxy.
Das Standardregel lassen Sie auf Direkt, wenn Sie nicht die gesamte Maschine umleiten möchten. Das ist der häufigste Fehler von Anfängern: Standard → Proxy leitet auch den OS-Updater, das Antivirenprogramm und unnötigen Verkehr, für den Sie pro Gigabyte bezahlen.
Überwachen Sie die Registerkarte Verbindungen in Echtzeit: dort sehen Sie, welche Verbindung über den Proxy und welche direkt gegangen ist.

Stärken – Reife, stabile Regeln und verständliche Diagnosen. Schwächen – kostenpflichtig und dass bei aggressiven Anti-Cheat-Systemen der Treiberabfang bemerkt werden kann.

Methode 2. ProxiFyre – kostenlose Alternative für Windows mit UDP-Unterstützung

Wenn das Budget null ist und die Plattform Windows ist, gibt es das Open-Source-Projekt ProxiFyre (Lizenz AGPL-3.0). Es basiert auf NDISAPI/Windows Packet Filter – das heißt, es arbeitet auf der Ebene des Paketfiltertreibers und kann das, was oft fehlt: transparent nicht nur TCP, sondern auch UDP für jede Anwendung separat zu leiten. Dies ist entscheidend für alles, was auf UDP und QUIC basiert – Sprachkanäle, Spiel-Clients, Teile moderner Browserverbindungen.

Aus nützlichen Funktionen in den neuesten Versionen: Unterstützung für IPv6 wurde in v2.3.0 hinzugefügt, SOCKS5-over-TLS – in v2.4.0, es gibt Ausschlussregeln für Anwendungen und eine Catch-All-Regel für alle anderen. Anforderungen: installierter Windows Packet Filter, Runtime-Bibliotheken von Visual Studio und Administratorrechte.

Die Konfiguration erfolgt über eine Konfigurationsdatei mit einer Liste von Anwendungen und den zugehörigen SOCKS5-Endpunkten. Die Einstiegshürde ist höher als bei Proxifier, aber Sie zahlen nichts und erhalten UDP.

Methode 3. proxychains-ng – schnelle Option für Linux, mit Vorbehalten

Ein Klassiker für Unix-Systeme: proxychains4 curl https://example.com. Der Mechanismus – LD_PRELOAD: die Bibliothek ersetzt die Socket-Aufrufe in dem dynamisch verlinkten Programm und leitet sie an SOCKS weiter.

Einschränkungen, die Sie wissen sollten, bevor Sie darauf einen Arbeitsprozess aufbauen:

Nur TCP. UDP und ICMP werden überhaupt nicht umgeleitet – ping über proxychains überprüft nichts Sinnvolles.
Nur dynamisch verlinkte Binärdateien. Statisch kompilierte Utilities (typische Situation für Go) ignorieren LD_PRELOAD stillschweigend – der Verkehr wird direkt gehen, und Sie werden es nicht bemerken.
Auf macOS stößt es auf SIP. System Integrity Protection blockiert das Laden der Bibliothek in systemeigene Binärdateien: proxychains4 ssh user@host funktioniert nicht. Ein funktionierender Umgehungsweg ist, die Binärdatei in Ihr Verzeichnis zu kopieren (cp /usr/bin/ssh ~/.local/bin/) und die Kopie zu starten. SIP aus Bequemlichkeit zu deaktivieren, empfehle ich nicht: Sie schwächen den Schutz des gesamten Systems für ein einziges Tool.

Für punktuelle Aufgaben (curl, Python-Skript, Konsolen-Utility) bleibt proxychains der schnellste Weg – es wird mit einem Befehl installiert und benötigt kein Root.

Methode 4. TUN-Modus: Abfangen auf der Ebene des virtuellen Interfaces

Die universellste Klasse von Lösungen. Es wird ein virtuelles Netzwerk-Interface erstellt, die Routen des Systems werden darin umgeleitet, und der Benutzer-TCP/IP-Stack verarbeitet die Pakete und gibt sie über SOCKS5 nach außen aus. So funktionieren tun2socks (verwendet den gVisor-Stack, unterstützt TCP und UDP, ist für alle Plattformen verfügbar) und sing-box im TUN-Modus.

Der entscheidende Vorteil gegenüber LD_PRELOAD: Es wird alles abgefangen, einschließlich statischer Binärdateien und Anwendungen mit eigenem Stack. Bei sing-box gibt es zusätzlich eine Prozess-Routing-Funktion – die Felder process_name, process_path und process_path_regex, was echte per-App-Regeln ermöglicht; laut Dokumentation wird dies auf Linux, Windows und macOS unterstützt (auf mobilen Plattformen werden Regeln nach Paketnamen oder Bundle-ID festgelegt).

Zwei Fallstricke, an denen fast alle scheitern:

Routing-Schleife. Wenn der gesamte Verkehr in TUN geht, versucht auch die Verbindung zum SOCKS5-Server, in TUN zu gehen – der Tunnel beginnt, sich selbst zu umleiten. Dies wird durch eine explizite Ausschlussroute zur IP des Proxys über das physische Interface behoben. Dies ist ein bekanntes und regelmäßig auftretendes Problem bei der Konfiguration von sing-box.
Rechte. Die Erstellung eines TUN-Interfaces und das Bearbeiten der Routing-Tabelle erfordert Root/Administratorrechte. Auf einem Unternehmensrechner mit Richtlinien kann dies möglicherweise nicht verfügbar sein.

Unter Linux gibt es zwei verwandte Ansätze: redsocks – Abfangen über iptables-Regeln mit Umleitung auf einen lokalen Port (nur Linux, benötigt Root), und sshuttle, das eine VPN-ähnliche Routing über normalen SSH-Zugang aufbaut und das klassische Problem „TCP über TCP“ umgeht.

Was am häufigsten kaputt geht

DNS-Leck. Selbst mit korrekt konfiguriertem SOCKS5 kann die Anwendung Domains lokal auflösen. Überprüfen Sie, dass die Auflösung über den Proxy und nicht über Ihren Anbieter erfolgt.
SOCKS4 anstelle von SOCKS5 gewählt. SOCKS4 unterstützt UDP grundsätzlich nicht und kann in einigen Implementierungen den Domainnamen nicht übermitteln. Für das Abfangen beliebigen Verkehrs verwenden Sie nur SOCKS5 – warum genau, wird ausführlich im Artikel über die Funktionsweise von SOCKS5 erläutert.
HTTP-Proxy anstelle von SOCKS. HTTP-Proxy kann HTTP und über CONNECT – TLS-Verbindungen proxifizieren. Beliebiger TCP-Verkehr eines Spielclients oder Messengers wird nicht umgeleitet.
Standardregel für gesamten Verkehr. Wenn Sie die gesamte Maschine umleiten, verbrauchen Sie den Verkehr des Resident-Pools für Updates und Telemetrie.
Fehlende Überprüfung nach der Konfiguration. Überprüfen Sie immer die tatsächliche ausgehende IP aus der Anwendung selbst, nicht aus dem danebenstehenden Browser.

Welchen Proxy-Typ für das Abfangen wählen

Technisch funktioniert das Abfangen mit jedem SOCKS5-Endpunkt, aber die Wahl des Typs bestimmt, ob Ihr Szenario zum Ziel führt.

Residential – wenn die Anwendung mit einem Dienst arbeitet, der den Ruf der IP bewertet: soziale Netzwerke, Marktplätze, Werbe-Dashboards, Zahlungsformulare. Datacenter-Adressen werden dort fast sofort erkannt. Geeignet sind residential Proxys mit SOCKS5-Unterstützung und Sticky-Sessions – letzteres ist entscheidend, da ein IP-Wechsel mitten in einer aktiven Sitzung für Anti-Fraud-Systeme schlechter aussieht als eine „fremde“ IP von Anfang an.
Datacenter – für technische Aufgaben ohne strenge Anti-Fraud-Maßnahmen: Zugang zu APIs, interne Dienste, Testumgebungen, alles, wo Geschwindigkeit und Stabilität des Kanals wichtiger sind als das „wohnliche“ Aussehen der Adresse. Hier bieten Datacenter-Proxys die beste Latenz und Vorhersehbarkeit.
Mobile – wenn die Anwendung von Natur aus mobil ist (Emulator, Client eines sozialen Netzwerks) und maximales Vertrauen in die Plattform erforderlich ist.

Separat: Abfangen auf Anwendungsebene ist kein VPN, und es ist nicht ratsam, das eine gegen das andere auszutauschen. Wenn Sie genau einen sicheren Kanal für die gesamte Maschine benötigen und nicht verschiedene IPs für verschiedene Programme, gibt es einen Vergleich der Ansätze im Artikel WireGuard gegen Proxy.

Wie man in einer Minute die Methode auswählt

Die Anwendung hat eigene Proxy-Einstellungen → verwenden Sie diese, nichts abfangen.
Windows, Ergebnis heute benötigt, Budget vorhanden → Proxifier.
Windows, UDP benötigt und kostenlos → ProxiFyre.
Linux, einmalige Aufgabe mit Konsolen-Utility → proxychains-ng.
Ein statisches Binary, ein Spiel oder alles gleichzeitig mit per-App-Regeln abfangen → TUN-Modus (sing-box, tun2socks), nicht vergessen, die Ausschlussroute zum Proxy anzugeben.

Die Hauptschlussfolgerung ist einfach: „Proxy funktioniert nicht“ bedeutet in neun von zehn Fällen „Proxy ist nicht auf der richtigen Ebene konfiguriert“. Die Systemeinstellung ist eine höfliche Anfrage an die Anwendung, während das Abfangen auf Treiber-, LD_PRELOAD- oder TUN-Interface-Ebene ein Zwang ist. Wählen Sie die Schicht richtig, überprüfen Sie die tatsächliche ausgehende IP aus der Anwendung selbst und vergessen Sie nicht das DNS – und das Problem wird einmal gelöst und taucht nicht nach jedem Programmupdate wieder auf.