Deine Dienste online.
Ohne Portfreigabe. Ohne nginx.
PROXY64 ist der Reverse-Proxy in Node64 – die Nginx-Proxy-Manager-Alternative ohne nginx, mit HTTP/3, Zertifikaten und Schutz ab Werk. Mit CDN64 bringst du Dienste aus dem Heimnetz ins Internet, ohne einen Port zu öffnen – auch hinter DS-Lite und CGNAT. Die Cloudflare-Tunnel-Alternative mit Edge-Servern in Deutschland und Ende-zu-Ende-Verschlüsselung.
Zwei Wege ins Netz – ein Modul
Du entscheidest je Dienst: klassisch über deine eigene Portfreigabe im Heimnetz oder über den CDN64-Tunnel zu ipv64.net. Beides läuft über dieselben Proxy-Hosts, dieselben Zertifikate und dieselben Schutzregeln.
PROXY64 – Reverse-Proxy im Heimnetz
Der Ersatz für den Nginx Proxy Manager – aber ohne nginx. Node64 spricht HTTP/1.1, HTTP/2 und HTTP/3 selbst. Du leitest 80 und 443 im Router auf die Node und legst Proxy-Hosts per Klick an.
- Proxy-Hosts, Weiterleitungen, 404-Hosts, TCP/UDP-Streams
- TLS durchreichen für Dienste mit eigenem Zertifikat
- Custom Locations, Zugriffslisten, WebSockets
- Läuft komplett lokal, auch ohne ipv64-Account
CDN64 – Tunnel ohne Portfreigabe
Die Node baut von sich aus einen verschlüsselten Tunnel zu zwei ipv64-Edge-Servern in Deutschland (Nürnberg und Falkenstein) auf. Besucher kommen per IPv4 und IPv6 – egal ob dein Anschluss DS-Lite, CGNAT oder gar keine Portfreigabe hat.
- Ein Klick: Account, Tunnel, DNS und Selbsttest
- Modus 1: Zertifikat und Schlüssel bleiben bei dir
- Immer zu beiden Edge-Servern verbunden – bei Business und Company mit vier parallelen Tunneln je Server
- Echte Besucher-IP in Zugriffslisten, Limits und Log
- Portmapper für TCP und UDP, Notbremse per Pause
Alles, was ein Reverse Proxy braucht
Bekannte Bedienlogik wie beim Nginx Proxy Manager, dazu vieles, was du dort selbst in nginx-Konfiguration schreiben müsstest.
Alle Host-Arten
Proxy-Hosts mit mehreren Domains und Wildcards, Weiterleitungen (300–308), 404-Hosts, TLS durchreichen nach SNI und Streams für TCP und UDP – auch mit IPv6-Zielen.
HTTP/3 eingebaut
HTTP/1.1, HTTP/2 und HTTP/3 über QUIC – ohne nginx, ohne Zusatzmodul. Dazu HTTPS erzwingen, HSTS und Mindestversion TLS 1.2 oder 1.3 je Host.
Erweitert statt Config-Datei
Kopfzeilen setzen oder entfernen, Host-Kopf, Timeout, Upload-Grenze, Puffern, Komprimierung mit zstd und Brotli und vertrauenswürdige Proxys mit Cloudflare-Vorlage – alles als Felder im Formular.
Zugriffslisten
Benutzer mit Passwort (bcrypt) und IP-Regeln, „beides nötig“ oder „eine Bedingung genügt“. Nach 10 Fehlversuchen ist die IP 15 Minuten gesperrt.
Ziele im Blick
Jedes Ziel wird jede Minute geprüft. Mit einem Klick wird daraus ein Healthcheck mit Benachrichtigung im Modul Healthchecks.
Teilt sich 443 mit DNS64
Ein gemeinsamer Eingang verteilt 80 und 443 nach Namen: PROXY64, DNS-over-HTTPS von DNS64, Let's Encrypt und die Node64-Oberfläche – ohne zweiten Container.
Sicher, bevor die erste Anfrage durch ist
Wer einen Dienst ins Internet stellt, bekommt ungebetenen Besuch. PROXY64 bremst ihn ab, bevor er dein Ziel erreicht – mit Standardwerten, die sofort greifen.
- Limits wie beim HAProxy: Verbindungen, neue Verbindungen und Anfragen je IP bzw. je IPv6-/64, dazu eine Grenze je Ziel und insgesamt.
- Automatische Sperre: Wer in einer Minute 300-mal abgewiesen wird, bleibt 10 Minuten schon beim Verbindungsaufbau draußen.
- ipv64-Blocklisten per Schalter: Gesamtliste (empfohlen ohne Tor), Spamhaus DROP, FireHOL, blocklist.de, DShield, Botnetze, Tor, Cloud-Netze und KI-Bots – abgewiesen schon vor TLS. Neue Listen kommen ohne Update dazu.
- KI-Bots fernhalten je Host – per User-Agent (täglicher Spiegel von ai.robots.txt) und per IP, auf Wunsch mit passender robots.txt.
- Ländersperre je Host und Stream: bestimmte Länder sperren oder nur bestimmte zulassen, auch für TCP/UDP-Streams – das Heimnetz bleibt immer frei.
- Block Common Exploits: Regeln wie im NPM, dazu
.git,.envundwp-config.php. - Neutrale Fehlerseiten verraten nichts über Node64 oder dein Ziel.
Das Heimnetz ist von den Limits ausgenommen. Die Listen kommen von ipv64.net/v64_blocklists und werden alle 30 Minuten aktualisiert.
So funktioniert CDN64
Deine Node verbindet sich von innen nach außen mit den ipv64-Edge-Servern. Besucher landen dort und werden durch den Tunnel zu dir gereicht. Du wählst, wo die Verschlüsselung endet.
Modus 1 – durchreichen Standard
Der Edge-Server liest nur den Namen (SNI) und reicht die verschlüsselte Verbindung unverändert weiter. Zertifikat und Schlüssel bleiben in deiner Node, ipv64 sieht keine Inhalte – auch bei HTTP/3.
Besucher ipv64-Edge-Server Node64 (Heimnetz) ┌─────────┐ ┌───────────────┐ ┌───────────────┐ ┌────────┐ │ Browser │ TLS │ liest nur SNI │ QUIC │ Node64 │ │ Dienst │ │IPv4/IPv6│─────►│ entschlüsselt │══════►│ TLS endet hier│──►│ │ └─────────┘ │ nicht │Tunnel │ Zertifikat, │ └────────┘ └───────────────┘ │ Limits, Log │ └───────────────┘ Den Tunnel baut die Node ausgehend auf. Zu Hause ist kein Port offen.
Modus 2 – auf dem Edge-Server beenden
TLS endet auf den Edge-Servern. Sie holen das Zertifikat selbst, filtern schon dort (Blocklisten, Limits) und schicken jede Anfrage mit der echten Besucher-IP durch den Tunnel. Wechsel per Knopf, ohne DNS-Änderung.
Besucher ipv64-Edge-Server Node64 (Heimnetz) ┌─────────┐ ┌───────────────┐ ┌───────────────┐ ┌────────┐ │ Browser │ TLS │ TLS endet hier│ QUIC │ Node64 │ │ Dienst │ │IPv4/IPv6│─────►│ Zertifikat, │══════►│ Anfrage als │──►│ │ └─────────┘ │ Limits, 429 │Tunnel │ HTTPS, echte │ └────────┘ └───────────────┘ │ Besucher-IP │ └───────────────┘ Den Tunnel baut die Node ausgehend auf. Zu Hause ist kein Port offen.
Ein Klick mit Selbsttest
Account prüfen, Tunnel aufbauen, Namen bei ipv64 einschalten, Probe über das Internet – jeder Schritt mit Ergebnis und Abhilfe.
Load-Balancing eingebaut
Das DNS nennt beide Edge-Server, die Besucher verteilen sich automatisch auf Nürnberg und Falkenstein. Die Node hält zu beiden einen Tunnel – bei Business und Company vier parallele je Server, die Server geben neue Besucher an die am wenigsten belastete Verbindung. Fällt ein Server aus, nimmt ipv64 ihn nach rund einer Minute aus dem DNS und der andere übernimmt.
Kein CNAME, kein DNS-Gefrickel
ipv64 stellt den Namen beim Einschalten selbst auf beide Edge-Server um. Beim Ausschalten kommt der alte Eintrag zurück.
Let's Encrypt für alles – nicht nur für den Proxy
Die Zertifikatsverwaltung gehört zum Kern von Node64. PROXY64 nutzt sie, DNS64 und die Oberfläche auch – und du kannst Zertifikate an NAS, Proxmox oder Windows verteilen.
- ipv64 DNS-01: Wildcards für deine ipv64-Domains, ohne offenen Port.
- 26 DNS-Anbieter wie Hetzner, netcup, INWX, IONOS, ALL-INKL oder Cloudflare – oder per Alias über ipv64.
- Eigene CA für
nas.lanund private IPs, Upload eigener Zertifikate, selbst signiert. - Automatische Erneuerung 30 Tage vor Ablauf, mit Meldung bei Problemen.
- Download und API als PEM, ZIP oder
.p12, Abruf mit ETag.
Du siehst, was passiert
- Statistik je Host und Stunde über 90 Tage: Antworten nach 2xx–5xx, Datenmenge und Abgewiesene – als Diagramm für 24 Stunden, 7 oder 30 Tage.
- Zugriffs-Log je Host einschaltbar, 1–90 Tage, IPs auf Wunsch gekürzt.
- Jede Abweisung mit Grund – Blockliste, Sperre, Limit, Zugriffsliste oder Exploit-Sperre –, auch ohne Zugriffs-Log.
- Dashboard-Karte und Prometheus-Metriken für Grafana.
Leicht und schnell
PROXY64 steckt im selben Go-Binary wie der Rest von Node64. Ist das Modul aus, kostet es nichts.
Lasttest mit 1.000 gleichzeitigen Clients; Client, Proxy und Ziel liefen auf derselben Maschine mit 4 Kernen. Im echten Betrieb hängt der Durchsatz von Hardware und Anschluss ab – bei CDN64 vor allem vom Upload deines Anschlusses.
Ehrlich verglichen
PROXY64 und CDN64 sind nicht für jeden die beste Wahl. Hier siehst du, wo sie stark sind – und wo andere Werkzeuge mehr können.
| Punkt | Node64 PROXY64 & CDN64 | Nginx Proxy Manager | Cloudflare Tunnel |
|---|---|---|---|
| Reverse Proxy mit Web-Oberfläche im Heimnetz | Steuerung im Cloudflare-Dashboard | ||
| Erreichbar ohne Portfreigabe (DS-Lite, CGNAT) | CDN64 | Portfreigabe nötig | |
| TLS endet zu Hause, auch über den Tunnel | Modus 1, auch HTTP/3 | – kein Tunnel | typischerweise bei Cloudflare |
| Standort der Edge-Server | Deutschland, zwei Standorte | – | weltweites Netz |
| Komprimierung mit zstd und Brotli | nach Browser, statische Dateien vorkomprimiert | gzip über nginx | |
| HTTP/3 im lokalen Proxy | nicht von Haus aus | – | |
| Rate-Limits und Blocklisten ab Werk | über eigene nginx-Konfiguration | je nach Tarif | |
| Zertifikate: viele DNS-Anbieter, eigene CA, Verteilung per API | 26 Anbieter + ipv64 | certbot-DNS-Plugins | – Zertifikate am Rand von Cloudflare |
| Freie Konfiguration (eigene Config-Dateien) | feste Felder „Erweitert“ | nginx | – |
| Lastverteilung auf mehrere Ziele im Heimnetz (Backends) | eingeschränkt | ||
| Weltweites CDN mit Caching am Rand | Caching am Rand: ipv64.net/cdn64 | – | |
| Domain bei beliebigem Anbieter über den Tunnel | Domains im ipv64-Account | – | typischerweise DNS bei Cloudflare |
| Monitoring, DNS-Filter und DynDNS im selben Container | |||
| Kosten | Node64 kostenlos; online nach Account-Klasse | Open Source, kostenlos | Free-Tarif vorhanden |
Angaben zu anderen Produkten nach allgemein bekanntem Stand und ohne Gewähr; Funktionen und Tarife können sich ändern. Nginx Proxy Manager und Cloudflare sind Marken ihrer jeweiligen Inhaber.
Schluss mit Portfreigaben und nginx-Dateien
Installiere Node64, schalte PROXY64 ein und lege deinen ersten Proxy-Host an. Für den Weg ins Internet ohne Portfreigabe verbindest du deinen ipv64.net-Account – ein Klick, fertig.
Das öffentliche Node64-Image erscheint in Kürze. Account-Klassen und Kontingente: ipv64.net/pricing
