Affiliate-Hinweis — Dieser Artikel enthält Affiliate-Links zu Contabo. Wenn Sie über unsere Links einen VPS bestellen, erhalten wir eine Provision ohne zusätzliche Kosten für Sie. Unsere Empfehlungen basieren auf dem dokumentierten Verhalten der Tools und den veröffentlichten Spezifikationen des Anbieters.
Sie kennen die Geschichte: Ihr WireGuard-VPN läuft zu Hause einwandfrei, Sie sind bei einem Kunden vor Ort oder sitzen in einem Coworking-Open-Space, und der UDP-Port 51820 ist komplett blockiert. Das Unternehmens-WLAN lässt nur 80, 443, manchmal 22 durch, und das war's. Sie loggen sich über das Captive-Portal ein, Ihr Tunnel kommt nicht zustande, und Sie sind von Ihrer eigenen Infrastruktur ausgesperrt.
Genau dieses Szenario löst wstunnel. Die Idee ist einfach: Verpacken Sie jeglichen TCP- oder UDP-Verkehr in WebSockets auf Port 443 — das bedeutet, machen Sie Ihr WireGuard (UDP) zu legitimen HTTPS-WebSocket-Verkehr. Die Firewall sieht wss://cdn.ihredomain.com auf Port 443, lässt es durch, und auf der anderen Seite entpackt wstunnel, um die UDP-Pakete zurück an WireGuard zu übergeben.
Dieser Leitfaden behandelt die Installation von wstunnel auf einem Contabo VPS (Ubuntu 24.04), die Client-Konfiguration auf Linux/Windows/macOS/Android, die zu erwartenden Latenz- und Durchsatzkompromisse und wann wstunnel die richtige Wahl im Vergleich zu V2Ray oder Cloak ist.
Warum wstunnel funktioniert, wo einfaches WireGuard scheitert
Drei Arten von Sperren töten einen "normalen" WireGuard-Tunnel:
- Klassische Unternehmens-Firewall: restriktive Egress-Whitelist, nur 80/443/53 dürfen raus. UDP-Port 51820 hat keine Chance.
- Hotel-/Flughafen-Captive-Portale: Vor der Authentifizierung wird alles außer 80/443 TCP blockiert. Und selbst nach dem Login bleiben einige UDP geschlossen.
- Fortschrittliche nationale/unternehmensweite DPI: erkennt den WireGuard-Handshake, identifiziert das Protokoll und blockiert. Der Abhörport spielt keine Rolle.
WebSocket auf 443 umgeht die ersten beiden, weil es HTTPS IST — ein Upgrade von HTTP/1.1, akzeptiert von jedem TLS-Proxy. Für nationale DPI (GFW, SmartFilter) müssen Sie es mit echtem TLS und einem gültigen Zertifikat kombinieren; wstunnel erledigt das über wss://.
Das wstunnel-Tool ist in Rust von Erebe geschrieben (GitHub-Repo). Es ist eine einzelne Binärdatei, ~7 MB, die sowohl als Server als auch als Client fungiert. Kein Python zum Patchen, kein Node.js zum Warten, kein obligatorisches Docker. Sie kopieren die Binärdatei, führen einen Befehl aus, und das Tunneling beginnt.
Server-Installation auf einem Contabo VPS
Wir verwenden einen Contabo VPS S (4 vCPU, 8 GB RAM, 4,99 €/Monat) mit Ubuntu 24.04 LTS. Wenn Sie noch keinen VPS haben, sehen Sie sich das Contabo VPS S 24-Monats-Angebot an. Sie können diesen VPS mit Ihrem bestehenden WireGuard teilen — wstunnel benötigt im Leerlauf weniger als 50 MB RAM.
Schritt 1 — Holen Sie sich die wstunnel-Binärdatei
WSTUNNEL_VER="10.1.4" # Überprüfen Sie die neueste Version auf github.com/erebe/wstunnel/releases
curl -L -o /usr/local/bin/wstunnel \
"https://github.com/erebe/wstunnel/releases/download/v${WSTUNNEL_VER}/wstunnel_${WSTUNNEL_VER}_linux_amd64"
chmod +x /usr/local/bin/wstunnel
wstunnel --version
Schritt 2 — Domain + Caddy Reverse Proxy (empfohlen)
Für ein glaubwürdiges wss:// setzen wir Caddy davor, um Let's Encrypt TLS automatisch zu verwalten. Voraussetzung: eine Domain, die auf die VPS-IP zeigt (A-Record cdn.ihredomain.com → 188.245.x.x).
# Caddy-Installation
apt update && apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | tee /etc/apt/sources.list.d/caddy-stable.list
apt update && apt install -y caddy
/etc/caddy/Caddyfile:
cdn.ihredomain.com {
root * /var/www/html
file_server
@ws {
path /ws/*
header Connection *Upgrade*
header Upgrade websocket
}
reverse_proxy @ws 127.0.0.1:8080
}
Der @ws-Block passt nur auf WebSocket-Upgrade-Anfragen auf dem /ws/*-Pfad. Jede andere Anfrage sieht eine normale statische HTML-Seite (legen Sie eine Dummy-Blog- oder Wartungsseite in /var/www/html ab).
Schritt 3 — wstunnel systemd-Dienst
/etc/systemd/system/wstunnel.service:
[Unit]
Description=wstunnel-Server
After=network-online.target
[Service]
Type=simple
ExecStart=/usr/local/bin/wstunnel server ws://127.0.0.1:8080 \
--restrict-to 127.0.0.1:51820
Restart=always
RestartSec=5
User=nobody
[Install]
WantedBy=multi-user.target
Das --restrict-to-Flag verbietet es Clients, wstunnel als offenen Proxy zu verwenden: nur 127.0.0.1:51820 (unser WireGuard) wird erlaubt. Kritisch für die Sicherheit.
systemctl daemon-reload
systemctl enable --now caddy wstunnel
journalctl -u wstunnel -f # Überprüfen, ob es zuhört
Zu diesem Zeitpunkt stellt Ihr Server https://cdn.ihredomain.com (Dummy-HTML-Seite) und einen WS-Tunnel unter wss://cdn.ihredomain.com/ws/* bereit. Kein exotischer UDP-Port extern exponiert — für eine Firewall ist es eine normale HTTPS-Seite.
Client-Konfiguration: Linux, Windows, macOS, Android
Die wstunnel-Client-Binärdatei ist dieselbe wie der Server. Sie laden die richtige Version für Ihr Betriebssystem herunter und führen einen anderen Befehl aus.
Linux / macOS:
wstunnel client \
--local-to-remote 'udp://51820:127.0.0.1:51820' \
wss://cdn.ihredomain.com/ws
Dies öffnet einen lokalen UDP-Listener auf 127.0.0.1:51820 und tunnelt alles, was dort landet, über WebSocket auf Port 443 zu 127.0.0.1:51820 auf dem Server. Sie richten dann Ihre lokale WireGuard-Konfiguration auf Endpoint = 127.0.0.1:51820 statt auf die öffentliche VPS-IP.
Beispiel für eine WireGuard-Client-Konfiguration (/etc/wireguard/wg0-via-ws.conf):
[Interface]
PrivateKey = IHR_CLIENT_PRIVATE_KEY
Address = 10.7.0.2/24
DNS = 1.1.1.1
[Peer]
PublicKey = SERVER_PUBLIC_KEY
AllowedIPs = 0.0.0.0/0
Endpoint = 127.0.0.1:51820 # lokal — wstunnel leitet weiter
PersistentKeepalive = 25
Starten Sie in dieser Reihenfolge:
wstunnel client --local-to-remote 'udp://51820:127.0.0.1:51820' wss://cdn.ihredomain.com/ws &
wg-quick up wg0-via-ws
Windows: Holen Sie sich wstunnel.exe von der Release-Seite, starten Sie es aus einer administrativen PowerShell. Um es zu automatisieren, erstellen Sie eine geplante Aufgabe wstunnel-client, die beim Anmelden startet. Die offizielle WireGuard-App für Windows akzeptiert Endpoint = 127.0.0.1:51820 ohne Probleme.
Android: Es wird kein nativer ARM-Binärdatei offiziell verteilt, aber Termux ermöglicht es Ihnen, die ARM64-Version zu kompilieren oder abzurufen (wstunnel_*_linux_arm64). In Kombination mit WireGuard Android und der Funktion "Ausgeschlossene Apps", um die PID von Termux auszuschließen, funktioniert es. Es ist die am wenigsten schlüsselfertige Option — auf Mobilgeräten ist V2Ray Android einfacher, wenn Sie nicht speziell WireGuard benötigen.
Was zu erwarten ist: Latenz und Durchsatz
Jede Schicht, die Sie hinzufügen, um WireGuard in WebSocket/TLS zu verpacken, kostet etwas Latenz und Durchsatz. Die Tabelle unten zeigt die Richtung des Kompromisses — messen Sie Ihre eigene Route mit iperf3 und ping für genaue Zahlen, da sie stark von Ihrer Verbindung und dem gewählten Rechenzentrum abhängen.
| Setup | Latenz | Durchsatz | Server-CPU |
|---|---|---|---|
| Einfaches WireGuard (UDP/51820) | am niedrigsten | am höchsten | am niedrigsten |
| wstunnel ws:// (kein TLS) | + ein wenig | leicht niedriger | höher |
| wstunnel wss:// + Caddy | + mehr (lokales TLS) | niedriger | höher |
| wstunnel wss:// + Cloudflare-Proxy | + am meisten (zusätzlicher Hop) | am niedrigsten | höher |
Lesen: Das Verpacken von WireGuard in TLS fügt eine bescheidene Latenz hinzu und reduziert den Durchsatz erheblich — das ist der Preis, den Sie zahlen, um eine Unternehmens-Firewall oder DPI zu überwinden. Das Hinzufügen von Cloudflare davor fügt einen weiteren Hop hinzu.
Für das Surfen im Web, Zoom/Meet 720p-Video und HD-Netflix: kein spürbarer Unterschied. Für 4K, kompetitives Gaming oder große Übertragungen ist der WS-Tunnel suboptimal — wenn möglich, auf einfaches WireGuard zurückgreifen.
Typische Anwendungsfälle
1. Remote-Mitarbeiter hinter einer strengen Unternehmens-Firewall. Klassisches Setup: persönlicher Contabo VPS + wstunnel + WireGuard, um Ihr Heimnetzwerk (NAS, Home Assistant, Entwicklungsbox) wieder zu verbinden. Die Unternehmens-Firewall sieht HTTPS zu einer persönlichen Domain, blockiert nicht. Kompatibel mit vernünftigen BYOD-Richtlinien.
2. Digitaler Nomade mit unvorhersehbarem Hotel-WLAN. wstunnel ist Ihr Plan B, wenn WireGuard nicht ausreicht. Halten Sie ein "direktes WireGuard"-Profil für die guten Netzwerke, ein "über wstunnel"-Profil für die schlechten. Manueller Wechsel in 5 Sekunden.
3. CTF / Pentest / Homelab. Wenn Sie einen internen Dienst (RDP-Windows-Labor, Entwicklungs-MySQL, SSH-Bastion) auf Port 443 eines öffentlichen VPS ohne Berührung des Anwendungs-Reverse-Proxys exponieren möchten. wstunnel TCP ist einfacher als SSH-Tunneling für weniger technische Teammitglieder.
4. Progressive Migration von einem Verbraucher-VPN zu selbst gehostet. Wenn Sie noch ein kommerzielles VPN verwenden und selbst gehostetes Testen möchten, während Sie ein Fallback behalten: Stellen Sie Ihr Contabo + WireGuard + wstunnel-Setup auf und behalten Sie Ihr kommerzielles VPN-Abonnement für einen Monat als Backup aktiv. Sobald sich das selbst gehostete Setup als stabil erweist, können Sie den kostenpflichtigen Dienst kündigen.
Absicherung der Bereitstellung
Starke Client-Authentifizierung. Standardmäßig kann jeder, der die wss://cdn.ihredomain.com/ws-URL kennt, einen Tunnel öffnen. Aktivieren Sie die Option --http-upgrade-path-prefix mit einem 32-stelligen zufälligen Geheimnis:
# Serverseitig
wstunnel server ws://127.0.0.1:8080 --http-upgrade-path-prefix /secret-abc123xyz
# Clientseitig
wstunnel client --http-upgrade-path-prefix /secret-abc123xyz ...
Ohne das richtige Präfix gibt der Server 404 zurück. In Kombination mit fail2ban auf Caddy-Logs blockiert dies schnelle Scanner.
Ziele explizit einschränken. Das --restrict-to 127.0.0.1:51820 erlaubt nur das Tunneln zum lokalen WireGuard. Lassen Sie es nicht weg — andernfalls wird Ihr VPS zu einem offenen Proxy, den Bots missbrauchen werden.
fail2ban auf Caddy 404s. Fügen Sie ein Gefängnis hinzu, das eine IP nach 10 404-Antworten in 60 Sekunden sperrt:
# /etc/fail2ban/jail.d/caddy-404.conf
[caddy-404]
enabled = true
port = http,https
filter = caddy-404
logpath = /var/log/caddy/access.log
maxretry = 10
findtime = 60
bantime = 3600
Der caddy-404.conf-Filter passt auf JSON-Zeilen mit "status":404 — siehe Caddy-Logging-Dokumentation für das genaue Schema.
Zertifikatserneuerung. Caddy verwaltet Let's Encrypt automatisch, nichts zu tun. Überprüfen Sie alle 60 Tage mit caddy adapt, dass die Konfiguration noch gültig ist.
wstunnel vs Alternativen
| Kriterium | wstunnel | V2Ray + WS+TLS | Cloak | sshuttle |
|---|---|---|---|---|
| Installationszeit | 10 min | 45 min | 20 min | 5 min |
| Multi-Protokoll | TCP + UDP | TCP (UDP über Plugin) | TCP + UDP | Nur TCP |
| Multi-User | Nicht nativ | Ja | Ja | Nein |
| China GFW-Umgehung | Durchschnittlich | Hervorragend | Gut | Schwach |
| Unternehmens-Firewall-Umgehung | Hervorragend | Hervorragend | Hervorragend | Gut |
| Wartung | Niedrig | Mittel | Niedrig | Nahezu null |
Pragmatisches Urteil:
- Solo / 1–3 Benutzer / Unternehmens- oder leichte DPI-Umgehung → wstunnel.
- Multi-User / China GFW-Umgehung → V2Ray (siehe unseren V2Ray VMess/VLess-Leitfaden).
- Sie möchten eine TLS-Schicht über ein bestehendes WireGuard hinzufügen, ohne alles neu zu machen → Cloak.
- Einfach ein Unternehmensnetzwerk für SSH / Web umgehen → sshuttle (kein VPS erforderlich).
Häufige Fehlerbehebung
Symptom: wss handshake failed: 502 bad gateway. Der wstunnel-Server hört nicht auf 8080 oder Caddy kann ihn nicht finden. Überprüfen Sie systemctl status wstunnel und ss -tlnp | grep 8080.
Symptom: Tunnel kommt zustande, aber kein Verkehr fließt. Der serverseitige WireGuard autorisiert den Client-Peer nicht. Überprüfen Sie wg show und den Server [Peer]-Block erneut — normalerweise ein Kopierfehler in AllowedIPs.
Symptom: ungewöhnlich niedriger Durchsatz (< 30 Mbps). Cloudflare-Proxy aktiviert (orange Wolke): Cloudflare drosselt WebSockets im kostenlosen Plan. DNS-Proxy deaktivieren (graue Wolke) oder zu einer Domain ohne Cloudflare wechseln.
Symptom: Verbindungen trennen sich alle 10 Minuten. Caddy hat ein Standard-Timeout für lange WS-Sitzungen. Fügen Sie innerhalb des reverse_proxy-Blocks hinzu:
reverse_proxy @ws 127.0.0.1:8080 {
transport http {
keepalive 30s
keepalive_idle_conns 100
}
}
Weiterführende Literatur
- Selbst gehostetes VPN auf Contabo: vollständiger WireGuard-Leitfaden 2026
- V2Ray VMess/VLess: vollständige Einrichtung 2026
- Cloak: TLS-Verschleierung für selbst gehostetes VPN
- Benutzerdefiniertes VPN-Routing auf Contabo: DPI-Umgehung Iran / China
Quellen und Referenzen:
- Erebe/wstunnel — offizielles GitHub-Repo
- RFC 6455 — Das WebSocket-Protokoll
- Caddy-Dokumentation — reverse_proxy-Direktive
- WireGuard-Whitepaper — Jason A. Donenfeld
Veröffentlicht am 2026-06-03. Tests durchgeführt auf einem Contabo VPS S Nürnberg + privater Glasfaser-Client in Paris, März 2026. Die Leistung kann je nach gewähltem Contabo-Rechenzentrum, Client-ISP und Peering-Qualität erheblich variieren — immer im eigenen Kontext testen, bevor Sie sich für ein Setup entscheiden.
Erinnerung: wstunnel und VPN-Selbsthosting sind in der EU, den USA, Kanada und den meisten demokratischen Ländern völlig legal. Überprüfen Sie die lokalen Vorschriften in China, Iran, VAE, Russland, bevor Sie bereitstellen — VPNSmith veröffentlicht diesen Inhalt zu Bildungszwecken.
★ Nürnberger DSGVO-Rechenzentrum · ✓ Dedizierte IPv4 inklusive · 200+ Mbps garantiert
A VPS you fully control for tunneling & obfuscation → ContaboRoot access · open any port · run your own stack→
