NaiveProxy: Verstecken von Proxy-Traffic in Chromes eigenem HTTPS-Stack

NaiveProxy ist ein kostenloser Open-Source-Proxy, dessen Client aus Chromiums eigenem Netzwerkcode aufgebaut ist, sodass ein Zensor gewöhnlichen Chrome-HTTPS-Traffic zu einer echten Website sieht. Die Serverseite ist ein Caddy-Webserver mit dem Plugin forwardproxy, der autorisierte Verbindungen unauffällig weiterleitet. Er deckt nur Apps ab, die auf ihn verweisen – es ist also ein Proxy, kein vollwertiges VPN.

Warum die Wiederverwendung von Chromiums Code die Nachahmung schlägt

Go-basierte Tarn-Proxys wie Xray setzen auf uTLS, um den ClientHello eines Browsers zu kopieren – das erste Paket des TLS-Handshakes. Die Begrüßung geht durch, doch Paketlängen, Timing und HTTP/2-Framing eines Go-Binärprogramms unterscheiden sich weiterhin von einem echten Browser. NaiveProxy liefert stattdessen eine gestutzte Kopie von Chromiums Netzwerk-Stack aus – etwa 0,3 % des ursprünglichen Quellcodes –, sodass der Handshake und jedes spätere Frame zu Chrome selbst gehören.

Der Weg einer Verbindung

Der naive Client liest eine kleine config.json und öffnet einen lokalen SOCKS5-Port, standardmäßig 127.0.0.1:1080, an den Apps oder die System-Proxy-Einstellungen ihren Traffic senden. Der Traffic läuft in einem CONNECT-Tunnel zu Ihrer Domain und trägt Benutzername und Passwort. Auf dem VPS leitet Caddy, gebaut mit dem naive-Fork des forwardproxy-Plugins, Anfragen anhand des Authorization-Headers weiter: Anfragen mit gültigen Zugangsdaten werden ins Internet weitergeleitet; alle anderen erhalten eine gewöhnliche Website als Antwort. Der Server braucht eine echte Domain mit einem vertrauenswürdigen TLS-Zertifikat, das Caddy automatisch beschafft. Der Transport erfolgt standardmäßig per HTTP/2 CONNECT über TCP, optional mit HTTP/3 über QUIC (dazu das Proxy-Schema von https auf quic umstellen).

Wogegen es schützt

Padding und die Gewohnheiten, die einen Proxy verraten

Padding setzt Zufall nur dort ein, wo es darauf ankommt. Die ersten acht Lese- und Schreibvorgänge jedes Streams erhalten 0 bis 255 Bytes zufälligen Füllmaterials; CONNECT-Anfrage und -Antwort tragen einen gepaddeten Header zufälliger Länge; RST_STREAM-Frames wird ein gepaddeter Datenframe vorangestellt, damit sie wie gewöhnliche Header aussehen. Späterer Traffic bleibt ungepadet, um den Overhead gering zu halten.

Der Rest hängt vom Betreiber ab. Setzen Sie die neueste stabile Version ein, denn die Builds folgen den Chrome-Releases und die Signatur eines veralteten Clients weicht vom imitierten Browser ab. Verzichten Sie auf selbstsignierte Zertifikate: Laut der sing-box-Dokumentation verändern sie das Traffic-Verhalten. Halten Sie die Concurrency-Einstellung (insecure_concurrency in sing-box) bei einer einzelnen Tunnelverbindung, denn mehr parallele Verbindungen erleichtern die Analyse.

Proxy, nicht VPN: Was NaiveProxy nicht abdeckt

NaiveProxy besitzt keinen eigenen virtuellen Netzwerkadapter und dokumentiert weder Kill Switch noch Schutz vor Datenlecks; Apps, die nicht auf den Proxy eingestellt sind, umgehen ihn einfach. Für ein Routing des gesamten Geräts betreiben Sie ihn über einen Wrapper-Client mit TUN-Modus wie sing-box, der seit Version 1.13.0 einen naive-Outbound auf Basis von Chromiums Cronet-Bibliothek mitbringt und UDP im Tunnel über UDP-over-TCP transportieren kann. Ihre Exit-IP ist die des Servers: Websites sehen diese Adresse, und der Betreiber sieht Ihren Traffic.

Wo es eingesetzt wird und wo es an seine Grenzen stößt

NaiveProxy wurde gegen Chinas Great Firewall entwickelt; das Arch-Linux-Wiki vermerkt, dass es dort großflächige Blockaden TLS-basierter Umgehungstools überstanden hat, und Nutzer in Russland diskutieren es als Ausweichoption, wenn VLESS-Verbindungen mit Reality gekappt werden. Offizielle Builds gibt es für Windows, Linux, macOS und OpenWrt; unter Android funktionieren Exclave, husi oder NekoBox mit dem naive-Plugin.

Die Grenzen sind real: Sie brauchen einen VPS, eine Domain und ein Zertifikat, und die Einrichtung des Clients ist manueller als bei jeder VPN-App. Blockiert der Zensor die IP oder Domain Ihres Servers, hilft keine Chrome-Tarnung. Der standardmäßige TCP-Modus funktioniert dort, wo UDP blockiert ist; der QUIC-Modus braucht UDP.

NaiveProxy unter den VPN-Diensten

Im VPNRadarLab-Hauptranking von 371 Diensten führt nicht ein einziger NaiveProxy-Unterstützung auf: 65 geben an, dass sie sie nicht bieten, und 312 veröffentlichen dazu nichts – das bedeutet nicht offengelegt, nicht fehlend. Unser Ranking kostenloser Software, die NaiveProxy unterstützt zeigt ein anderes Bild: sieben Open-Source-Einträge, von Client-Apps und Cores bis zu einem selbst gehosteten Server-Panel und dem NaiveProxy-Projekt selbst, keiner davon im Hauptranking. Wenn der Kauf einer Domain unattraktiv klingt, sehen Sie sich an, wie VLESS Reality funktioniert – die nächstliegende Alternative.

NaiveProxy-FAQ

Ist NaiveProxy ein VPN?

Nein. Es leitet nur den Traffic von Apps weiter, die dafür konfiguriert sind; die Abdeckung des gesamten Geräts erfordert einen Wrapper-Client mit TUN-Modus.

Brauche ich eine eigene Domain für NaiveProxy?

Ja. Die gesamte Tarnung beruht auf einer echten Website mit einem vertrauenswürdigen TLS-Zertifikat.

Funktioniert NaiveProxy über QUIC?

Als Option: Stellen Sie das Proxy-Schema von https auf quic um. Standard ist HTTP/2 über TCP.

Kann ich NaiveProxy ohne eigenen Server nutzen?

Nur wenn jemand den Zugang zu seiner Einrichtung teilt; das Projekt selbst stellt keinen Dienst bereit.

NaiveProxy auf einen Blick

Ein Open-Source-Proxy auf Basis von Chromiums Netzwerkcode, getarnt als gewöhnliche Website, mit Padding für den frühen Traffic. Stark gegen Fingerprinting und Sondierung, wehrlos gegen eine IP-Sperre und so zuverlässig wie Ihre Update-Disziplin. Design-Hinweise und Downloads finden sich im offiziellen Repository.