VPN oder Proxy: Was jedes von beiden abdeckt und was nicht
Ein VPN deckt den gerouteten App-Verkehr ab; ein Proxy deckt nur die App ab, die Sie konfigurieren. Prüfen Sie Abdeckung, Verschlüsselung, DNS und Fehlerverhalten, bevor Sie wählen.
Sowohl ein VPN als auch ein Forward-Proxy ändern die Adresse, die eine Website sieht, und genau dort hören die meisten Vergleiche auf. Der Unterschied, der Ihre Einrichtung entscheidet, ist die Abdeckung: Ein Forward-Proxy ist ein Vermittler, den Ihre Anwendung selbst nutzt, anders als der Reverse-Proxy vor einer Website, während ein VPN alles bewegt, was das Betriebssystem in einen Tunnel routet. Verschlüsselung, DNS-Behandlung und Fehlerverhalten folgen alle aus dieser Aufteilung. Führen Sie diese fünf Prüfungen der Reihe nach aus, und die erste, die fehlschlägt, sagt Ihnen, welches Werkzeug Sie tatsächlich brauchen.
Welche Apps deckt der Vermittler ab?
Eine Browser-Proxy-Erweiterung gilt nur für dieses Browserprofil. Mail-Clients, Paketmanager und ein zweiter Browser verwenden weiter ihre eigenen Einstellungen, und manche Anwendungen ignorieren System-Proxy-Variablen völlig. Ein VPN deckt ab, was die Routing-Tabelle in den Tunnel schickt, und das können alle Anwendungen oder eine Teilmenge bei Split-Tunneling sein, je nach Routen und Client-Richtlinie.
Testen Sie die Anwendungen, auf die es ankommt, statt von einem einzigen Seitenaufruf zu verallgemeinern. curl https://ifconfig.me folgt den Proxy-Umgebungsvariablen; eine Desktop-App vielleicht nicht. Unter Windows gibt netsh winhttp show proxy den WinHTTP-Proxy aus, den Dienste verwenden, und das ist eine andere Einstellung als die des Browsers.
Ist der Hop verschlüsselt, und wo endet TLS?
Ein Proxy-Protokoll ist ein Treffpunkt, keine Garantie. SOCKS5 leitet TCP weiter, ohne es zu verschlüsseln, und ein einfacher HTTP-Proxy überträgt Anforderungszeile und Header im Klartext. HTTPS über einen Proxy verwendet CONNECT, sodass Ihre TLS-Sitzung weiterhin am Ziel endet und nicht am Proxy. Der MDN-Leitfaden zu Proxyservern und Tunneling beschreibt diesen Unterschied von der Protokollseite.
Ein VPN verschlüsselt die Strecke zwischen Ihrem Gerät und seinem Endpunkt. Jenseits des Endpunkts gelten dieselben Regeln wie in jedem anderen Netz, weshalb ein Tunnel allein keine Anwendung schützt, die Anmeldedaten über einfaches HTTP sendet. Keines der beiden Designs verbirgt ein angemeldetes Konto, ein Cookie oder einen Browser-Fingerabdruck.
curl -v -x http://127.0.0.1:3128 https://example.com/ -o /dev/null
curl -v -x socks5h://127.0.0.1:1080 https://example.com/ -o /dev/null
Die ausführliche Ausgabe zeigt, ob curl CONNECT an Port 443 oder ein einfaches GET mit vollständiger URL gesendet hat. Mit socks5h:// erhält der Proxy den Hostnamen innerhalb der SOCKS5-Anforderung und leitet dann TLS weiter, das er nicht lesen kann, sodass er den Namen und die Byteanzahl sieht. Über einen http://-Proxy ist eine https://-URL ein CONNECT, sodass dieser Proxy ebenfalls den Zielnamen und das Volumen sieht, nicht aber die Anforderung oder den Antwortkörper.
Welcher Resolver sieht den Namen?
Die Namensauflösung kann lokal geschehen, bevor die Anforderung das Gerät verlässt, oder entfernt am Proxy. Bei curl sendet socks5h:// den Hostnamen an den Proxy, während socks5:// ihn zuerst lokal auflöst. Die Proxy-Einstellungen des Browsers bieten eine vergleichbare DNS-Option, und PAC-Dateien können verschiedene Hosts unterschiedlich routen.
Zwei Protokolle können einen Proxy ohne jede Fehlkonfiguration umgehen. WebRTC sammelt Kandidaten über STUN, und QUIC betreibt HTTP/3 über UDP, was ein TCP-Proxy nicht transportieren kann. Der Browser fällt auf TCP zurück, wenn UDP 443 blockiert ist, deshalb ist das Blockieren von UDP 443 in der Firewall des Hosts (oder auf dem Router für ein ganzes Netz), nicht ein Browser-Flag, der zuverlässige Weg, HTTP/3 im Proxy-Pfad zu halten.
Prüfen Sie den Resolver aus Sicht des Ziels, nicht aus Sicht Ihres Laptops. Eine Anforderung, die mit der Ausgangsadresse des Proxys, aber mit einem lokal aufgelösten Namen ankommt, verrät dem lokalen Resolver immer noch, welche Seiten Sie besuchen.
Was passiert, wenn der Vermittler ausfällt?
Ein expliziter Proxy scheitert geschlossen: Beenden Sie den Proxy-Prozess, und der Browser oder die App liefert einen Verbindungsfehler, statt direkt zu gehen. PAC- und WPAD-Setups sind diejenigen, die offen scheitern - wenn das Skript nicht abgerufen werden kann, fällt der Client auf DIRECT zurück, und die Website sieht wieder Ihre echte Adresse. Ein VPN kann offen oder geschlossen scheitern, je nach Client und ob ein Kill-Switch oder eine Firewall-Regel aktiv ist.
Testen Sie den Fehlerfall absichtlich: Stoppen Sie den Proxy-Dienst und laden Sie neu; erhalten Sie eine Fehlerseite statt einer direkten Ladung, richten Sie die PAC-URL auf einen unerreichbaren Host, um den Rückfall zu sehen. Lädt die Seite weiterhin über Ihre gewohnte Route, bietet der Proxy keinen Schutz gegen seinen eigenen Ausfall, und das ist eine Eigenschaft, die Sie kennen sollten, bevor Sie sich darauf verlassen.
Die Reihenfolge entscheidet, was die Website sieht. Ein Proxy, dessen ausgehender Verkehr durch das VPN läuft, lässt die Website die Adresse des VPN-Endpunkts sehen; legen Sie den Proxy außerhalb des Tunnels (VPN zu einem Proxy auf einem entfernten Host), sieht die Website stattdessen die Ausgangsadresse dieses Proxys. In beiden Fällen können die beiden Hops Unterschiedliches protokollieren.
Fünf Prüfungen, der Reihe nach
Die folgende Checkliste ist die ganze Entscheidung an einem Ort. Die Abdeckung kommt zuerst, weil sie die meisten Fehlpaarungen ausschließt: Wenn die App, die abgedeckt werden muss, die Einstellung nicht beachtet, rettet nichts weiter unten auf der Liste sie.
| Check | Forward proxy | VPN |
|---|---|---|
| What is covered | The app or browser you configure | Traffic the OS routes into the tunnel, all or split |
| Encryption scope | Protocol-dependent; SOCKS5 alone encrypts nothing | Device to VPN endpoint |
| DNS path | Local or remote, depending on the setting | Normally inside the tunnel |
| Failure mode | Explicit config: connection error; PAC/WPAD: DIRECT fallback | Client policy: fail-open or kill switch |
| What the site sees | The proxy's exit address | The VPN endpoint's exit address |
Bestätigen Sie dann das Ergebnis mit der App, die die Änderung ausgelöst hat. Laden Sie eine Seite im konfigurierten Browser, rufen Sie dieselbe Seite mit curl ab, und vergleichen Sie die Adresse, die jede meldet. Weichen sie voneinander ab, sind noch eine Erweiterung, eine PAC-Regel oder eine Überschreibung auf App-Ebene im Spiel, und keine Tunnel-Abstimmung wird das beheben.
Notieren Sie, was Sie konfiguriert haben: welche Apps den Proxy nutzen, ob DNS lokal oder entfernt ist, ob UDP blockiert ist und wie das Fehlerverhalten aussieht. Genau dieses kleine Inventar ermöglicht den nächsten Vergleich, denn „die IP hat sich geändert“ hat Ihnen nie gesagt, welche dieser fünf Prüfungen bestanden wurde.