CDN64 – Tunnel ohne Portfreigabe

Mit CDN64 erreichst du einen Dienst aus deinem Heimnetz über das Internet, ohne im Router einen Port zu öffnen. Das klappt auch hinter DS-Lite, CGNAT und an Anschlüssen nur mit IPv4 oder nur mit IPv6. Diese Seite erklärt Schritt für Schritt, was dabei passiert.

Wer verbindet sich mit wem?

Das Wichtigste zuerst: Die Verbindung baut deine Node auf – von innen nach außen. Für deinen Router ist das ein ganz normaler ausgehender Verbindungsaufbau, so wie wenn du eine Webseite aufrufst. Deshalb muss zu Hause kein Port offen sein.

  Dein Heimnetz                           ipv64-Edge-Server (Deutschland)
 ┌────────────────┐                     ┌──────────────────────────┐
 │                │ ════ Tunnel 1 ═════►│ Nürnberg                 │
 │     Node64     │                     └──────────────────────────┘
 │                │                     ┌──────────────────────────┐
 │                │ ════ Tunnel 2 ═════►│ Falkenstein              │
 └────────────────┘                     └──────────────────────────┘
  Router: kein Port offen                         ▲
                                                  │ Besucher kommen hier an
                                                  │ (per IPv4 und IPv6)
 Die Node baut beide Tunnel ausgehend auf: QUIC (UDP), Port 7844, sonst 443.
 Ist UDP gesperrt, nimmt sie TCP mit TLS.

• Zwei Tunnel, immer: Die Node hält zu jedem der beiden Edge-Server einen eigenen Tunnel offen.
• Protokoll: QUIC über UDP mit TLS 1.3. Die Node versucht zuerst Port 7844, sonst 443 – der zuletzt erfolgreiche Port kommt zuerst.
• UDP gesperrt? Nach zwei gescheiterten QUIC-Versuchen nimmt die Node TCP mit TLS und versucht alle 5 Minuten wieder QUIC.
• Welcher Weg gerade läuft, zeigt die Host-Liste von PROXY64 je Edge-Server mit einem Symbol (Tooltip je Server): QUIC über den eigenen Port 7844, QUIC über Port 443, Rückfall auf TLS über TCP, nicht verbunden. Auch der Selbsttest im CDN64-Dialog nennt den Weg; per API liefert GET /api/cdn64/online ihn je Server im Feld via (quic, quic443 oder tls, nur wenn verbunden).
• Anmeldung: Die Node prüft das Zertifikat des Servers und meldet sich mit einem Token an. Das Token liegt verschlüsselt in der Node, bei ipv64 und auf den Servern nur als Hash.
• Lebenszeichen: Alle 10 Sekunden geht ein Keepalive durch den Tunnel. Reißt er ab, verbindet sich die Node selbst neu – erst nach 1 Sekunde, dann mit wachsendem Abstand bis höchstens 60 Sekunden.

Was passiert bei einem Besuch?

Angenommen, jemand ruft https://cloud.example.com auf und du hast diesen Namen mit CDN64 eingeschaltet:

1. DNS fragen
   Der Browser fragt das DNS nach der Adresse. ipv64 antwortet mit den Adressen der beiden Edge-Server (IPv4 und IPv6).
2. Edge-Server nimmt an
   Der Browser verbindet sich mit einem der beiden Edge-Server. Der schaut nur nach, für welchen Namen die Verbindung ist.
3. Durch den Tunnel
   Der Edge-Server öffnet im schon bestehenden Tunnel deiner Node einen neuen Kanal und schickt die Verbindung hinein – zusammen mit der echten Adresse des Besuchers.
4. Node64 übernimmt
   In deiner Node kommt die Verbindung an, als käme sie direkt auf Port 443 oder 80. Zugriffslisten, Limits, Blocklisten, Statistik und Log wirken genau wie im Heimnetz.
5. Dein Dienst antwortet
   Der Proxy-Host leitet an deinen Dienst weiter, die Antwort geht denselben Weg zurück.

Wo die Verschlüsselung endet, hängt vom Modus ab – dazu jetzt mehr.

Modus 1 – durchreichen (Standard)

In Modus 1 sind die Edge-Server reine Briefträger: Sie lesen nur die Adresse auf dem Umschlag und reichen den verschlossenen Brief weiter.

 Besucher                ipv64-Edge-Server             Dein Heimnetz
 ┌────────────┐          ┌──────────────────┐          ┌──────────────────┐
 │ Browser    │  HTTPS   │ liest nur den    │ Tunnel   │ Node64           │
 │ oder App   │═════════►│ Namen (SNI)      │═════════►│                  │
 │            │          │                  │ (QUIC)   │ TLS endet hier   │
 │ IPv4/IPv6  │          │ entschlüsselt    │          │ Zertifikat und   │
 └────────────┘          │ nicht            │          │ Schlüssel bleiben│
                         │                  │          │ hier             │
                         │ grober Schutz:   │          │ Zugriffslisten,  │
                         │ Blocklisten,     │          │ Limits, Log      │
                         │ Verbindungen/IP  │          └────────┬─────────┘
                         └──────────────────┘                   ▼
                                                        Dienst im Heimnetz
 Verschlüsselt vom Besucher bis zu deiner Node (Ende-zu-Ende).

• Auf Port 443 liest der Edge-Server nur den Namen aus dem Verbindungsaufbau (SNI) und reicht die Verbindung ohne Entschlüsselung durch.
• Zertifikat und Schlüssel bleiben in deiner Node. Das Zertifikat kommt wie gewohnt aus der Zertifikatsverwaltung.
• HTTP/3: Ist beim Proxy-Host HTTP/3 an (Standard), liest der Edge-Server den Namen aus dem ersten QUIC-Paket und reicht QUIC roh durch. TLS und HTTP/3 enden auch dann erst in deiner Node.
• Auf Port 80 (unverschlüsseltes HTTP) liest der Edge-Server die erste Anfragezeile und den Host-Kopf, um den Namen zu finden.
• Auf den Edge-Servern gibt es schon einen groben Schutz für alle: Blockliste und Grenzen für Verbindungen je IP bzw. IPv6-/64 – siehe Schutz vor Überlastung auf den Servern. Alles Feinere macht deine Node.
• Modus 1 geht auch für Hosts mit „TLS durchreichen“.

Modus 2 – auf den Edge-Servern beenden

In Modus 2 öffnen die Edge-Server den Brief, prüfen ihn und schicken ihn dann durch den Tunnel weiter. Dafür können sie schon dort aussortieren.

 Besucher                ipv64-Edge-Server             Dein Heimnetz
 ┌────────────┐          ┌──────────────────┐          ┌──────────────────┐
 │ Browser    │  HTTPS   │ TLS endet hier   │ Tunnel   │ Node64           │
 │ oder App   │═════════►│ Zertifikat für   │═════════►│                  │
 │            │          │ Name und *.Name  │ (QUIC)   │ Anfrage kommt    │
 │ IPv4/IPv6  │          │                  │          │ als HTTPS mit    │
 └────────────┘          │ Blocklisten,     │          │ echter Besucher- │
                         │ Limits je IP/64, │          │ IP an            │
                         │ Host passt zu SNI│          │ Zugriffslisten,  │
                         │ HTTP/1.1, 2, 3   │          │ Log wie gewohnt  │
                         └──────────────────┘          └────────┬─────────┘
                                                                ▼
                                                        Dienst im Heimnetz

• TLS endet auf den Edge-Servern (TLS 1.2 oder 1.3, HTTP/1.1, HTTP/2 und HTTP/3).
• Zertifikat: Die Edge-Server holen es selbst bei Let's Encrypt, für den Namen und *.Name. Ein Server bestellt, der andere übernimmt es verschlüsselt. Erneuert wird 30 Tage vor Ablauf.
• Bis das Zertifikat da ist, reichen die Server wie in Modus 1 durch. Ein Wechsel fällt also nie aus.
• Schutz schon vorne: Blocklisten, Verbindungs- und Anfrage-Limits je IP bzw. IPv6-/64 (darüber Antwort 429) und die Prüfung „Host passt zum SNI“ (sonst 421).
• Jede Anfrage geht als eigener Kanal mit der echten Besucher-IP durch den Tunnel und gilt in der Node als HTTPS. Deine Node muss dafür keinem Kopf vertrauen. Vom Besucher mitgeschickte X-Forwarded-* werden entfernt.
• Port 80 leitet mit 301 auf HTTPS um. Ist deine Node nicht erreichbar, zeigen die Server eine verständliche Fehlerseite (502) – siehe Fehlerseite.
• Modus 2 geht nicht für Hosts mit „TLS durchreichen“.
• Es gibt in Modus 2 kein Caching auf den Edge-Servern. Jede Anfrage geht bis in deine Node; dort wirken „Cache Assets“ und „Block Common Exploits“ wie gewohnt.

Was sieht ipv64?

Unverschlüsseltes HTTP über Port 80 ist in beiden Modi lesbar – das ist bei HTTP immer so. Nutze HTTPS, dann ist Modus 1 Ende-zu-Ende verschlüsselt. Mehr zum Datenschutz bei ipv64: ipv64.net/datenschutz.

Welcher Modus passt?

• Modus 1 ist für fast alle Fälle die richtige Wahl: maximale Vertraulichkeit, dein Zertifikat, deine Regeln.
• Modus 2 lohnt sich, wenn unerwünschter Verkehr schon vor deinem Anschluss gebremst werden soll – etwa bei einem kleinen Upload – oder wenn die Edge-Server das Zertifikat übernehmen sollen.

Modus wechseln

In der Host-Liste wechselst du mit dem Knopf Modus wechseln zwischen Modus 1 und 2. Das DNS bleibt dabei gleich, du musst nichts umstellen. Wechselst du auf Modus 2, reichen die Server so lange durch, bis ihr Zertifikat da ist – der Dienst bleibt die ganze Zeit erreichbar.

Load-Balancing und Ausfallsicherheit mit zwei Edge-Servern

Load-Balancing ist eingebaut: Das DNS nennt beide Edge-Server, die Besucher verteilen sich so automatisch auf Nürnberg und Falkenstein. Du musst dafür nichts einrichten. Fällt ein Server aus, nimmt ipv64 ihn nach rund einer Minute aus dem DNS, und der andere übernimmt.

                            ┌─────────────────────────┐
                 ┌─────────►│ Edge-Server Nürnberg    │◄═══════════╗
                 │          └───────────┬─────────────┘  Tunnel 1  ║
 ┌──────────┐    │ DNS: A/AAAA          │ Nachbar-            ┌────╨─────┐
 │ Besucher │────┤ beider Server        │ Ausweichweg         │  Node64  │
 └──────────┘    │ (TTL 10)             │ (~20 ms mehr)       └────╥─────┘
                 │          ┌───────────┴─────────────┐  Tunnel 2  ║
                 └─────────►│ Edge-Server Falkenstein │◄═══════════╝
                            └─────────────────────────┘

• Immer zu beiden verbunden: In der Host-Liste zeigt je Server ein Abzeichen den Zustand: grün = Tunnel verbunden, blau = über den anderen Server erreichbar, rot = kein Tunnel.
• Nachbar-Ausweichweg: Fehlt der Tunnel zu einem Server, nimmt dieser Besucher trotzdem an und reicht sie über den anderen Server weiter. Gemessen kostet das etwa 20 ms mehr.
• DNS-Failover: Fällt ein Server ganz aus, nimmt ipv64 ihn nach rund einer Minute aus dem DNS. Der andere übernimmt allein.
• Startet ein Server neu, verbindet sich die Node von selbst wieder – im Test nach gut einer Sekunde.
• Ist ipv64 selbst gestört, laufen die Tunnel mit der letzten Konfiguration weiter. Nur Änderungen warten, bis ipv64 wieder erreichbar ist.

Parallele Verbindungen für Business und Company

Mit den Account-Klassen Business und Company baut die Node ab PROXY64 1.26.0 zu jedem Edge-Server vier parallele Tunnel-Verbindungen auf statt einer – jede mit eigenem Rückfall QUIC → QUIC über 443 → TLS. Die Server geben neue Besucher an die am wenigsten belastete Verbindung.

   Edge-Server Nürnberg            Edge-Server Falkenstein
  ┌──────────────────────┐        ┌──────────────────────┐
  │ neue Besucher an die │        │ neue Besucher an die │
  │ Verbindung mit der   │        │ Verbindung mit der   │
  │ wenigsten Last       │        │ wenigsten Last       │
  └──┬───┬───┬───┬───────┘        └──┬───┬───┬───┬───────┘
     ║   ║   ║   ║                   ║   ║   ║   ║  je 4 Tunnel pro Server
     ║   ║   ║   ║                   ║   ║   ║   ║
  ┌──╨───╨───╨───╨───────────────────╨───╨───╨───╨───────┐
  │                        Node64                        │
  └──────────────────────────────────────────────────────┘
  Fällt eine Verbindung aus, laufen die anderen weiter.

• Mehr Leistung: Mit den parallelen Verbindungen ist CDN64 etwa doppelt bis 2,5-mal so schnell. An einem Heimanschluss bleibt dein Upload die Grenze.
• Entlastet auch deine Node: Die Arbeit verteilt sich nicht nur auf den Edge-Servern, sondern auch in deiner Node auf mehrere CPU-Kerne statt auf einen.
• Mehr Sicherheit: Fällt eine Verbindung aus, laufen die anderen weiter – zusätzlich zum zweiten Edge-Server und zum Nachbar-Ausweichweg.
• Load-Balancing also zweimal: zwischen den beiden Servern per DNS und auf jedem Server zwischen den vier Verbindungen.
• In der Host-Liste zeigt das Abzeichen des Servers ×4. Ein Wechsel der Account-Klasse baut die Verbindungen automatisch neu auf.

Fehlerseite der Edge-Server

Ist deine Node bzw. dein Ziel nicht erreichbar oder antwortet mit einem Fehler 5xx, zeigen die Edge-Server Browsern eine kleine Seite im ipv64-Stil („Gerade nicht erreichbar“, hell und dunkel, Deutsch und Englisch, mit Link zu ipv64.net). Das gilt in Modus 2 und 3.

• Abrufe von Apps und APIs (ohne text/html) bekommen die Antwort deines Ziels unverändert.
• Eigene Fehlerseite behalten: Dein Ziel sendet den Antwort-Header CDN64-Error-Page: off – dann reichen die Server seine Antwort durch.
• In Modus 1 endet TLS erst bei dir; die Seite gibt es dort nur über HTTP, wenn die Node nicht verbunden ist oder der Name gesperrt ist.

Ruft jemand einen Edge-Server direkt auf – über seinen eigenen Namen, seine IP oder einen Namen ohne Kunden –, zeigt er eine Infoseite im selben Stil: Server des IPv64 CDN, der Webseiten und Dienste der Kunden ausliefert, mit Links zu ipv64.net und node64.de. Andere Pfade bekommen eine 404 im selben Stil.

Schutz vor Überlastung auf den Servern

Läuft ein Host über CDN64, ist er zweifach geschützt: grob und für alle schon auf den beiden ipv64-Edge-Servern – bevor überhaupt Verkehr deine Node erreicht – und danach fein und je Host in deiner Node. In der Host-Liste erkennst du das am grünen Schild in der Spalte „CDN64“.

  Besucher, Bots, Angreifer
                           │
                           ▼
 ┌──────────────────────────────────────────────────┐
 │ ipv64-Edge-Server · Deutschland                  │
 │ • Spamhaus DROP: gekaperte Netze fliegen raus    │
 │ • je IP höchstens 256 Verbindungen, 50 neue/s    │
 │ • Pause: Notbremse je Name, IP bleibt verborgen  │
 │ • faire Drossel ab 80 % Last, niemand fliegt     │
 └─────────────────────────┬────────────────────────┘
                           ║  verschlüsselter Tunnel, echte Besucher-IP
 ┌─────────────────────────╨────────────────────────┐
 │ Node64 · PROXY64 im Heimnetz                     │
 │ • Honeypot64-Sofortsperre, ipv64-Blocklisten     │
 │ • Ländersperre, Rate-Limits je Host              │
 │ • Zugriffslisten, Block Common Exploits          │
 └─────────────────────────┬────────────────────────┘
                           ▼
                       Dein Dienst

Das gilt für alle Kunden und in allen Modi. Wer nur viel Verkehr macht, wird nicht getrennt; gebremst wird erst bei echter Überlastung.

Danach in deiner Node – in Modus 1 und 2 immer mit der echten Besucher-IP – greift der volle lokale Schutz: Rate-Limits je Host, ipv64-Blocklisten, Ländersperre, Zugriffslisten und Block Common Exploits. Eine eigene Erlauben-/Sperrliste je Name direkt auf den Servern gibt es mit Modus 3 auf ipv64.net/cdn64.

Faire Drossel und Kontingent

Die Edge-Server teilen ihre Leitung fair zwischen allen Nutzern auf:

• Niemand wird getrennt, höchstens gebremst. Erst ab 80 % Auslastung eines Servers wird gerecht geteilt: Wer wenig braucht, bekommt alles. 10 % bleiben für neue Besucher frei, und jeder bekommt mindestens 1 Mbit/s. Unter 60 % Auslastung fällt die Drossel wieder weg. Das gilt für alle Modi.
• Bandbreite je Account: Je nach Account-Klasse gilt zusätzlich eine Bandbreitengrenze, über beide Server zusammen (siehe Tabelle).
• Kontingent: Jeder eingeschaltete Name zählt als CDN-Domain, und der Datenverkehr zählt gegen den CDN-Traffic deiner Klasse – jeweils gemeinsam mit dem bisherigen ipv64-CDN. Ist der Traffic des Monats aufgebraucht, sind deine Namen bis zum Monatswechsel gesperrt – oder bis zu einem Upgrade der Account-Klasse.

Stand 21.10.2026. Ein Upgrade gilt sofort: Wegen Traffic gesperrte Namen sind wieder frei, die Server übernehmen das nach etwa 10 Sekunden; die neue Bandbreite gilt nach höchstens 10 Sekunden.

Was deine Klasse enthält, siehst du unter ipv64.net/pricing. Die Zahlen deiner eingeschalteten Hosts im Monat (Traffic, Anfragen, Abweisungen) und dein Kontingent zeigt Node64 direkt in der Host-Liste: zwei Kacheln mit Fortschrittsbalken für die belegten CDN-Domains (mit der Bandbreite deiner Klasse) und den Traffic diesen Monat. Ab dem zweiten Tag des Monats steht dort eine Prognose – ob der Traffic bei gleichem Verbrauch bis zum Monatsende reicht, sonst bis wann. Dieselben Balken zeigen auf dem Dashboard die Karten von PROXY64 und des ipv64-Accounts (ab 80 % gelb, voll rot).

DNS: Du musst nichts eintragen

• Kein CNAME nötig. Beim Einschalten stellt ipv64 den Namen selbst um: Er zeigt dann mit A- und AAAA-Einträgen (TTL 10 Sekunden) auf beide Edge-Server.
• Deine bisherigen A/AAAA-Einträge ruhen in der Zeit und kommen beim Ausschalten zurück.
• Voraussetzung: Der Name selbst hat keinen CNAME und kein DNS-Failover.
• Platzhalter-Namen (*.example.com) werden beim Einschalten übersprungen.

Im Heimnetz bleibt der Verkehr zu Hause

Nutzt dein Netz DNS64 derselben Node, beantwortet es eingeschaltete Namen mit der lokalen Adresse der Node (geteilter DNS). Aufrufe von zu Hause gehen dann nicht über das Internet. Läuft die Node im Docker-Bridge-Netz, gilt das nicht – dann bleibt es bei der normalen Antwort.

Voraussetzungen

• Node64 ab Version 0.11.98 mit eingeschaltetem Modul PROXY64 und einem Proxy-Host für den Namen.
• Ein verbundener ipv64.net-Account (zentraler API-Key unter Einstellungen → ipv64, siehe ipv64.net verknüpfen) mit einer Account-Klasse, die CDN-Domains enthält. Die Klassen findest du unter ipv64.net/pricing.
• Der Name liegt in einer Domain deines ipv64-Accounts – etwa eine DynDNS-Domain oder eine eigene Domain, die du bei ipv64 verwaltest.
• Ausgehend muss UDP oder TCP auf Port 7844 oder 443 erlaubt sein. Das ist in fast jedem Heimnetz so.

Einrichtung mit einem Klick

1. Einschalten
   In Node64 unter PROXY64 → Proxy-Hosts in der Spalte CDN64 beim Host auf Einschalten klicken und den Modus wählen. Das Fenster erklärt oben die drei Modi mit kleiner Skizze; ein Klick auf den Kasten wählt den Modus, Modus 3 verweist auf ipv64.net/cdn64.
2. Account prüfen
   Die Node prüft den ipv64-Account und das Kontingent. Ohne Account führt der Dialog zu Account verbinden.
3. Tunnel aufbauen
   Die Node meldet sich bei den Edge-Servern an und baut beide Tunnel auf. Ist UDP gesperrt, läuft der Tunnel über TCP.
4. Namen einschalten
   Jeder Name des Hosts wird einzeln bei ipv64 eingeschaltet, ab dann zeigt das DNS auf die Edge-Server. Auf Wunsch legt die Node gleich einen Online-Healthcheck auf den ersten Namen an.
5. Selbsttest
   Die Node testet über das Internet jeden Namen über jeden Server und jede Adressfamilie (IPv4, IPv6). „Ok“ heißt: Die Probe kam genau durch den Tunnel dieser Node an. Dazu siehst du, ob das Zertifikat für Besucher vertrauenswürdig ist und ob das DNS schon umgestellt ist.

Jeder Schritt zeigt sein Ergebnis und bei einem Fehler gleich die Abhilfe. Fertig, wenn alles grün ist.

Benachrichtigungen

Über deine Benachrichtigungskanäle meldet Node64, wenn der Tunnel 3 Minuten lang zu keinem Server steht, wenn er wieder da ist und wenn ipv64 einen Namen sperrt (z. B. weil der Traffic aufgebraucht ist).

Ausschalten

Ausschalten in der Host-Liste schaltet die Namen bei ipv64 aus, das DNS zeigt wieder auf die alte Adresse. Mit dem letzten Namen meldet die Node auch den Tunnel ab. Löschst du einen Host oder entfernst einen Namen, trägt der Abgleich (jede Minute) ihn bei ipv64 aus. Im Notfall – etwa wenn die Node nicht erreichbar ist – kannst du Namen auch auf ipv64.net/cdn64 ausschalten; die Node übernimmt das dann.

Node gelöscht, ohne abzumelden

Löschst du den Container, ohne die Namen auszuschalten, bleibt der Tunnel bei ipv64 verwaist (Modus 1 und 2). Dann gilt:

• Ab 48 Stunden ohne Verbindung zeigt ipv64.net/cdn64 einen Hinweis – ohne Mail oder Benachrichtigung.
• Nach 14 Tagen entfernt ipv64 alles automatisch: Das DNS kommt auf die ursprünglichen Einträge zurück, dazu verschwinden die Namen mit ihrer Zuordnung, Ziel, Liste, Portmapper, Zertifikat und der Tunnel samt Token. Das steht im Log.
• Namen, die zusätzlich an einem anderen verbundenen Tunnel hängen, bleiben. Ein Tunnel, der nie verbunden war, zählt ab dem Anlegen. Modus 3 ist nicht betroffen.

Pausieren

Mit Pausieren in der Host-Liste nehmen die Edge-Server für einen Namen sofort nichts mehr an – in allen Modi. Gedacht ist das als schneller Selbstschutz, etwa bei einem Angriff.

• Offene Verbindungen trennen die Server nach wenigen Sekunden. Modus 1 trennt die Verbindung, Modus 2 und 3 antworten mit 503, Portmapper und QUIC nehmen nichts an.
• Der Tunnel bleibt verbunden und das DNS zeigt weiter auf die Edge-Server – deine eigene Adresse bleibt verborgen. Darin liegt der Unterschied zum Ausschalten, bei dem das DNS wieder auf deine Adresse zeigt.
• Einstellungen und Statistik bleiben erhalten. Fortsetzen geht mit demselben Knopf. Pausierte Namen sind in der Host-Liste und unter Weitere Namen in CDN64 gelb hinterlegt.
• Pausieren und fortsetzen kannst du auch auf ipv64.net/cdn64 – für alle Namen deines Kontos, etwa wenn die Node selbst nicht erreichbar ist.
• Per API: POST /api/cdn64/hosts/{id}/online/pause mit {"paused": true} bzw. false.

Weitere Namen in CDN64

Unter der Host-Liste zeigt die Karte Weitere Namen in CDN64 die Namen deines Kontos, die diese Node nicht verwaltet: Namen in Modus 3, die auf ipv64.net eingerichtet sind, und Namen in Modus 1 oder 2 über eine andere Node. Zu sehen sind Ziel, Cache der Server, Erlauben- und Sperrliste, Portmapper, Status und der Traffic im Monat. Bearbeitet werden diese Namen auf ipv64.net bzw. in der anderen Node; pausieren kannst du sie direkt hier – per API mit POST /api/cdn64/online/names/{rid}/pause und {"paused": true|false}.

Gibt es in PROXY64 schon einen Host mit demselben Namen, erscheint der Name nicht in der Karte, sondern in der CDN64-Spalte dieses Hosts: Modus, „ipv64.net“ bzw. „andere Node“, Status, Cache, Traffic und Pause, bei Modus 3 ein Link zum Bearbeiten. Einschalten und Modus wechseln gibt es dort nicht. Die Karte zeigt also nur Namen, zu denen es hier keinen Host gibt.

Den Stand holt die Node auch ohne eigene CDN64-Namen: ohne Namen im Konto alle 5 Minuten, beim Öffnen der Liste sofort.

Häufige Meldungen

sysctl -w net.core.rmem_max=7500000 net.core.wmem_max=7500000

Damit der Wert einen Neustart übersteht, trägst du ihn zusätzlich in /etc/sysctl.conf oder eine Datei unter /etc/sysctl.d/ ein.

Portmapper: TCP und UDP über CDN64

Ein Portmapper ist ein Port der Edge-Server zwischen 50000 und 62000 – auf beiden Servern derselbe –, der Verbindungen roh per TCP oder UDP weiterreicht. Er ist für Dienste ohne HTTP(S) gedacht, etwa SSH, WireGuard, Spiele-Server oder die Proxmox-Oberfläche. Erreichbar ist der Dienst dann als <name>:<port>, zum Beispiel home.example.ipv64.net:55349.

 Besucher          ipv64-Edge-Server         Node64 (Heimnetz)
 ┌───────────┐     ┌──────────────┐          ┌──────────────┐   ┌──────────┐
 │ SSH,      │ TCP │ Port 55349   │  QUIC    │ Stream in    │   │ NAS,     │
 │ WireGuard,│────►│ Blockliste,  │═════════►│ PROXY64,     │──►│ Proxmox, │
 │ Spiel     │ UDP │ Grenzen je IP│  Tunnel  │ echte IP     │   │ Server   │
 └───────────┘     └──────────────┘          └──────────────┘   └──────────┘
  name.ipv64.net:55349                        Router: kein Port offen

 Besucher          ipv64-Edge-Server                Dein Server
 ┌───────────┐     ┌──────────────┐                 ┌───────────────┐
 │ Browser,  │ TCP │ Cache,       │  direkt, ohne   │ Webseite,     │
 │ App,      │────►│ Portmapper,  │────────────────►│ Spiele-Server │
 │ Spiel     │ UDP │ Blockliste   │  Tunnel         │ öffentlich    │
 └───────────┘     └──────────────┘                 └───────────────┘
                                                     Port am Ziel offen

Modus 1 und 2: mit Node64

1. Stream anlegen
   Unter PROXY64 → Streams einen Stream anlegen: Port auf der Node → Ziel im Heimnetz, TCP und/oder UDP.
2. CDN64-Namen wählen
   Im Stream bei Über CDN64 aus dem Internet erreichbar einen CDN64-Namen dieser Node auswählen und speichern.
3. Port ablesen
   Der Port der Server steht in der Stream-Liste (name:port mit TCP/UDP) und in der Zeile des Hosts.

• Die Verbindung läuft durch den verschlüsselten Tunnel. Zu Hause muss kein Port offen sein, und deine IP bleibt verborgen.
• Geschützt wird nach der echten Besucher-IP: Blocklisten, Grenzen je IP und Ländersperre des Streams gelten, TLS-Abschluss optional mit einem Zertifikat aus der Verwaltung.
• An- und Abmelden bei ipv64 passiert automatisch – wenn du den Stream ausschaltest, löschst, seinen Port änderst oder den Namen ausschaltest.
• API: Feld online_name am Stream; die Ausgabe enthält cdn64_ports (name, listen_port, transport) und bei Problemen cdn64_error.

Modus 3: ohne Node64

• Eingerichtet wird auf ipv64.net/cdn64 beim Namen unter Bearbeiten → Port mappings: Port der Server → Ziel-Port an deinem eigenen Ziel.
• Die Server verbinden sich direkt zum Ziel – es muss also aus dem Internet erreichbar sein.
• Mit Stufe 0 nutzt ein Name nur den Portmapper, ohne Webseite.
• In PROXY64 erscheinen diese Ports nur lesend in der Zeile des Hosts bzw. unter Weitere Namen in CDN64 (Port der Server → Port des Ziels).

Für alle Modi

• Die Zahl der Portmapper richtet sich nach deiner Account-Klasse (Kontingent CDN-Mappings); das bisherige ipv64-CDN zählt mit.
• Erlauben- und Sperrliste sowie Pause des Namens gelten auch für seine Ports.
• Der Traffic zählt zum CDN-Kontingent (siehe Kontingent). Für UDP gilt der Schutz vor Reflexion.
• Grenzen: Je IP höchstens 256 gleichzeitige Verbindungen und 50 neue je Sekunde, dazu 200 neue UDP-Sitzungen je Sekunde und höchstens 4096 je Port. Aus dem Tunnel gehen in Modus 1 und 2 je Stream höchstens 1024 UDP-Sitzungen und 4096 TCP-Verbindungen. Bandbreite und Traffic richten sich nach deiner Account-Klasse.
• Leerlauf: TCP-Verbindungen trennen die Server nach 1 Stunde ohne Daten in beide Richtungen; aktive Verbindungen bleiben beliebig lange bestehen. UDP-Sitzungen enden nach 2 Minuten ohne Pakete. Tipp für SSH: ein Keepalive setzen, z. B. ServerAliveInterval 60 in ~/.ssh/config.

Grenzen

• Nur Namen in Domains deines ipv64-Accounts. Domains bei anderen Anbietern lassen sich online derzeit nicht einschalten.
• Streams nur über den Portmapper: TCP/UDP-Streams (z. B. WireGuard) gehen über einen Port der Edge-Server, nicht über 443 – siehe Portmapper.
• Keine Platzhalter-Namen (*.) beim Einschalten.
• Kein Caching auf den Edge-Servern in Modus 1 und 2.
• Dein Upload ist die Grenze: Der Durchsatz hängt am Upload deines Anschlusses. Im Test schöpfte der Tunnel den vollen Upload der Testleitung (rund 48 Mbit/s) aus; die Antwortzeiten lagen bei HTTP/2 im Mittel bei etwa 26–30 ms. Deine Werte hängen von deiner Leitung ab.

Modus 3 und Portmapper auf ipv64.net

Ist dein Dienst schon öffentlich erreichbar (öffentliche IP oder Name), brauchst du keinen Tunnel: Bei Modus 3 gehen die Edge-Server direkt zu deinem Ziel – mit Caching am Rand, Frontend-Stufen und einem Portmapper für rohe TCP- und UDP-Ports. Modus 3 läuft ohne Node64 und wird nur auf ipv64.net/cdn64 eingerichtet. Der Dialog in Node64 verlinkt dorthin.

Komprimierung: In Modus 1 und 2 komprimiert deine Node die Antworten (siehe PROXY64 → Komprimierung). In Modus 3 komprimieren die Edge-Server Text-Antworten des Ziels selbst mit zstd, Brotli oder gzip, wenn das Ziel es nicht tut – das spart Traffic-Kontingent. Traffic und Bandbreite zählen in Modus 3 nach den tatsächlich gesendeten, komprimierten Bytes des Inhalts, auch bei Antworten aus dem Cache; Kopfzeilen zählen nicht mit. Stark komprimiert werden nur Antworten, die in den Cache kommen. Abgebrochene Antworten landen nie im Cache, und je Verfahren, das der Browser annimmt, hält der Cache eine eigene Fassung.

Weiter geht's mit dem Reverse Proxy im Heimnetz oder den Zertifikaten. Überblick zum Produkt: PROXY64 & CDN64.

Etwas unklar, fehlt etwas oder hast du eine Frage zu Node64? Frag im offiziellen Forum v64.tech.