PROXY64 – Reverse-Proxy

PROXY64 leitet Anfragen für deine Domains an Dienste im Heimnetz weiter – mit Zertifikaten, Zugriffslisten, Schutz vor Überlastung und Statistik. Es ersetzt den Nginx Proxy Manager und braucht kein nginx: Node64 spricht HTTP/1.1, HTTP/2 und HTTP/3 selbst.

Überblick

Ein Reverse Proxy nimmt alle Aufrufe auf Port 80 und 443 an und entscheidet anhand des Namens, wohin sie gehen. So erreichst du cloud.example.com, ha.example.com und nas.example.com über einen einzigen Anschluss, jeweils mit gültigem Zertifikat.

 Internet        Router             Node64 (PROXY64)        Heimnetz
                ┌─────────┐       ┌────────────────────┐
 Besucher ─────►│ 80/TCP  │──────►│ TLS endet hier     │──► Nextcloud
 (IPv4/IPv6)    │ 443/TCP │       │ Name entscheidet,  │──► Home Assistant
                │ 443/UDP │       │ wohin es geht      │──► NAS
                └─────────┘       └────────────────────┘
 443/UDP brauchst du nur für HTTP/3.

• Ist das Modul aus, läuft nichts: keine Routen, keine Prüfungen, kein Cache, und die Ports bleiben zu.
• PROXY64 läuft komplett lokal. Einen ipv64.net-Account brauchst du nur für CDN64, für ipv64-DNS-Einträge und für Zertifikate per ipv64 DNS-01.

Einschalten und einrichten

1. Modul einschalten
   Unter Einstellungen → Module → PROXY64.
2. Router einstellen
   Port 80/TCP und 443/TCP auf die Node weiterleiten, für HTTP/3 zusätzlich 443/UDP. Details unter Ports und Router.
3. DNS einrichten
   Die Domain muss auf deinen Anschluss zeigen, am besten als CNAME auf deine DynDNS-Domain. Siehe DNS.
4. Zertifikat holen
   Im Menüpunkt Zertifikate die Nutzungsbedingungen von Let's Encrypt annehmen und ein Zertifikat anfordern – oder im Host-Formular „Neues Zertifikat gleich mit anfordern“ wählen.
5. Proxy-Host anlegen
   Unter PROXY64 → Proxy-Hosts Domain und Ziel eintragen, fertig. Siehe Proxy-Host anlegen.

Ports und Router

PROXY64 braucht die Standard-Ports, damit Besucher ohne Portnummer im Link ankommen.

• Anderer Port am Router: Leitet der Router z. B. 443 auf 8443 weiter, stellst du unter Einstellungen → Ports den HTTPS-Port auf 8443 und „HTTPS-Port von außen“ auf 443.
• Belegte Ports: Die Port-Verwaltung unter Einstellungen → Ports zeigt, wer welchen Port nutzt, und meldet Überschneidungen – auch mit anderen Programmen auf dem Host.
• Ports unter 1024 gehen ohne Root: Das Image erlaubt dem Programm das Öffnen (cap_net_bind_service). Wird dem Container diese Fähigkeit entzogen, reicht auch root nicht.

Docker: Host-Netz empfohlen

Am einfachsten läuft PROXY64 im Host-Netz. Dann sieht die Node die Ports direkt, und Streams können jeden Port öffnen, ohne dass du den Container neu anlegen musst.

services:
  node:
    image: ghcr.io/ipv64net/node64:latest
    container_name: node64
    restart: unless-stopped
    network_mode: host        # 80, 443 und Stream-Ports direkt am Host
    volumes:
      - node64-data:/data
volumes:
  node64-data:

Die Oberfläche erreichst du dann unter http://<host>:8080. Im Bridge-Netz gibst du die Ports einzeln frei – und je Stream einen weiteren:

    ports:
      - "8080:8080"
      - "80:80"
      - "443:443/tcp"
      - "443:443/udp"         # HTTP/3

Im Bridge-Netz prüft PROXY64, ob 80 und 443 wirklich auf dem Docker-Host veröffentlicht sind. Fehlt ein Port, warnen die Host-Liste und Einstellungen → Ports deutlich – mit Beispiel für docker run und Compose.

Das öffentliche Image ghcr.io/ipv64net/node64 erscheint in Kürze. Alles zur Installation: Installation und Konfiguration.

DNS: Domain auf den Anschluss zeigen lassen

Damit Besucher bei deiner Node ankommen, muss der Name auf die öffentliche Adresse deines Anschlusses zeigen.

• Am besten per CNAME auf deine DynDNS-Domain, z. B. cloud.example.com → deinname.ipv64.net. Ändert sich deine IP, hält DynDNS64 die DynDNS-Domain aktuell, und alle CNAMEs folgen automatisch.
• Domains bei ipv64: Liegt die Domain in deinem ipv64.net-Account, legt PROXY64 den Eintrag (CNAME oder A/AAAA) beim Anlegen des Hosts auf Wunsch selbst an. Vorhandene Einträge bleiben unverändert.
• Für CDN64 brauchst du keinen CNAME – dort stellt ipv64 den Namen selbst um. Siehe CDN64 → DNS.

Im Heimnetz direkt zum Proxy (DNS64)

Läuft DNS64 auf der Node, trägt der Knopf Lokal in DNS64 eintragen (Haus-Symbol) in der Liste der Proxy-Hosts alle Namen des Hosts als eigene DNS-Einträge ein – ohne Zone, als A und auf Wunsch AAAA auf die Adresse des Reverse-Proxys. Geräte im Heimnetz, die DNS64 fragen, gehen dann direkt zum Proxy statt über das Internet.

• Vorschlag: die Adresse, über die du Node64 gerade aufrufst, sonst die LAN-Adresse der Node.
• Namen mit einem vorhandenen Eintrag desselben Typs oder einem CNAME bleiben unverändert.
• Ein grünes Haus zeigt, dass schon alle Namen lokal eingetragen sind. Ändern und löschen unter DNS64 → Eigene DNS-Einträge.
• Nur in der Oberfläche, nicht über die API.

Host-Arten

Die übrigen Namen auf 443 bleiben bei Node64, auch wenn einzelne Namen durchgereicht werden. Für Streams sind die Ports des gemeinsamen Eingangs (80, 443) gesperrt.

Statusseite unter eigener Domain

Im Reiter Statusseiten legst du einen Host an, trägst die Domain ein und wählst eine Statusseite aus. Sie erscheint dann direkt unter /.

• Zertifikat aus der zentralen Verwaltung, Force-SSL, HSTS und HTTP/3 wie bei einem Proxy-Host.
• Davor greifen Blocklisten, Ländersperre, Limits, die Exploit-Sperre und eine Zugriffsliste. Statistik und Zugriffs-Log zählen mit.
• Über CDN64 schaltest du den Host wie einen Proxy-Host in Modus 1 oder 2 ein. Dann brauchst du keine Portfreigabe und deine IP bleibt verborgen.
• Beim Import auf einer anderen Node wird der Host über den Slug der Seite zugeordnet; fehlt die Seite dort, wird der Host ausgeschaltet angelegt.
• Ist die Statusseite ausgeschaltet oder gibt es sie nicht, antwortet der Host mit 404; ist das Modul Healthchecks aus, mit 503.
• Export und Import behalten die Zuordnung.

Besucher erreichen so nur die Statusseite, nie die Verwaltung – der Port der Oberfläche bleibt zu. Neue Statusseiten stehen zusätzlich auf dem Node-Port unter /status/<slug>; soll die Seite nur über die Domain erreichbar sein, schaltest du dort „Auf dem Node-Port veröffentlichen“ aus.

Standardseite für unbekannte Namen

Ruft jemand die Node per IP oder mit einem Namen auf, für den es keinen Host gibt, greift die Standardseite. Du hast vier Möglichkeiten:

• Antwort 404 „nicht gefunden“,
• Verbindung ohne Antwort schließen (wie 444 bei nginx),
• Weiterleitung auf eine Adresse deiner Wahl,
• eigene HTML-Seite bis 64 KB.

Ist der Honeypot-Köder eingeschaltet, ersetzt er die Standardseite. Die Einstellungen der Standardseite zeigen das dann mit einem Hinweis und Link; per API meldet GET /api/edge es im Feld unknown_replaced.

Proxy-Host anlegen

Das Formular hat vier Reiter: Details, Locations, SSL und Erweitert.

1. Details
   Domain(s) eintragen, Ziel wählen (http oder https, Host, Port). Optional gleich den DNS-Eintrag bei ipv64 anlegen lassen.
2. SSL
   Ein Zertifikat aus der Zentrale wählen (passend zum Namen oder fest) oder gleich ein neues anfordern.
3. Speichern
   Der Host ist sofort aktiv. In der Liste siehst du, ob das Ziel erreichbar ist, und die Antwortzeit.

Optionen je Proxy-Host

Grundoptionen

SSL

• Zertifikat aus der zentralen Verwaltung (passend zum Namen oder fest gewählt) – oder nur HTTP.
• HTTPS erzwingen (Umleitung von 80 auf 443).
• HSTS, auf Wunsch auch für Subdomains.
• HTTP/2 und HTTP/3 (QUIC über 443/UDP; ab Werk an).
• Mindestversion TLS 1.2 oder TLS 1.3.

Erweitert

Statt einer freien nginx-Konfiguration gibt es feste Felder für das, was man dort meistens einträgt:

• Kopfzeilen zum Ziel und zum Besucher setzen oder entfernen,
• Host-Kopf zum Ziel (Standard: der Name, unter dem der Besucher kam),
• Timeout zum Ziel,
• Upload-Grenze (darüber Antwort 413),
• Puffern abschalten (für Streaming und lange Antworten),
• Antworten komprimieren (zstd, Brotli, gzip),
• vertrauenswürdige Proxys davor, mit Vorlage für Cloudflare,
• „Ohne Limits je IP“ (siehe Schutz vor Überlastung).

Was das Ziel bekommt

Das Ziel erhält X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Host und X-Real-IP – immer mit der echten Gegenstelle. Solche Kopfzeilen, die ein Besucher selbst mitschickt, verwirft PROXY64. Ausnahme: Er kommt über einen eingetragenen vertrauenswürdigen Proxy. Dann zählt dessen Angabe zur echten Client-IP. Unter Erweitert lassen sich X-Forwarded-For und X-Real-IP deshalb weder setzen noch entfernen.

Komprimierung

Der Schalter Antworten komprimieren unter Erweitert verkleinert Antworten, bevor sie zum Besucher gehen. Für neue Proxy-Hosts ist er ab Werk an; bestehende Hosts behalten ihre Einstellung. Welches Verfahren genutzt wird, richtet sich nach dem, was der Browser kann:

• Was komprimiert wird: Text, HTML, CSS, JSON, JavaScript, XML, SVG, WASM und Schriften außer woff/woff2 – ab 512 Byte und nur bei Status 200.
• Was nicht: Bilder, Videos und Archive, Range-Anfragen, HEAD, WebSocket, Antworten mit Cache-Control: no-transform und alles, was das Ziel schon selbst komprimiert hat.
• Der Cache hält je Verfahren eine eigene Fassung. Starke ETags werden dabei schwach (W/).
• Das gilt auch über CDN64 in Modus 1 und 2 – die Antwort kommt von deiner Node; in Modus 2 spart es zusätzlich Verkehr im Tunnel.
• Per API heißt das Feld weiter advanced.gzip.

Custom Locations

Mit Locations schickst du einzelne Pfade eines Proxy-Hosts an ein anderes Ziel, z. B. /api an einen eigenen Dienst.

• Jede Location hat ein eigenes Ziel und optional einen anderen Pfad beim Ziel.
• Eigener Schalter für WebSockets und eigene Zugriffsliste.
• Der längste passende Pfad gewinnt. /api/v2 geht also vor /api.

Zugriffslisten

Zugriffslisten schützen Proxy-Hosts, Locations und Weiterleitungen mit Passwort, IP-Regeln oder beidem.

• Benutzer: Anmeldung per Basic Auth. Das Passwort liegt nur als bcrypt-Hash vor. Auf Wunsch reicht PROXY64 die Anmeldung an das Ziel weiter.
• IP-Regeln: erlauben oder sperren, für IPv4 und IPv6, auch Netze. Die erste passende Regel gilt. Passt keine, wird gesperrt.
• Verknüpfung: „Beides nötig“ (IP passt und Anmeldung stimmt) oder „eine Bedingung genügt“.
• Schutz gegen Raten: Nach 10 Fehlversuchen in 5 Minuten ist die IP 15 Minuten gesperrt. Die Sperre steht im Audit.

ipv64-Blocklisten

Unter PROXY64 → Zugriffslisten schaltest du Listen schadhafter IP-Adressen von ipv64.net ein – per Klick für den ganzen Reverse-Proxy. Die Auswahl kommt direkt von ipv64.net: Neue Listen erscheinen ohne Update von Node64, und jede Liste zeigt Lizenz und Beschreibung. Stand heute:

• Früh abgewiesen: Gesperrt wird an erster Stelle – beim Verbindungsaufbau, vor TLS und vor jeder Zugriffsliste. Das gilt für Proxy-Hosts, Durchreich-Hosts und Streams. HTTP/3 bekommt 403.
• Aktualisierung alle 30 Minuten. Ist ipv64.net nicht erreichbar, gilt der letzte Stand weiter.
• Ausnahmen: Eingetragene IPs oder Netze werden nie gesperrt.
• Hinter einem vertrauenswürdigen Proxy (z. B. Cloudflare) zählt zusätzlich die echte Client-IP.

Live-Listen mit Listen-Token

Die Listen „ipv64 Honeypot“ gibt es in zwei Fassungen: den Tagesstand (einmal täglich, für alle frei) und die Live-Fassung (alle 30 Minuten neu bewertet). Für die Live-Fassung hinterlegst du in der Blocklisten-Karte unter PROXY64 → Zugriffslisten das Listen-Token aus deinem ipv64-Account (ipv64.net/honeypot/token.php) (32 Zeichen, Buchstaben und Ziffern).

• Jede Liste zeigt, welche Fassung geladen ist: live oder Tagesstand.
• Hat das Token keine Berechtigung, steht dort „Tagesstand – Token ohne Berechtigung“. Lehnt ipv64 den Abruf ab, lädt PROXY64 den Tagesstand und zeigt den Fehler. Geschützt bist du also immer.
• Das Token wird verschlüsselt gespeichert und nie angezeigt, geloggt oder exportiert. Ändern und löschen geht in derselben Karte; ohne Token kommen die Listen wieder im Tagesstand.
• Per API: GET /api/cdn64/blocklists liefert token_set und je Liste edition, live_denied und live_error; PUT nimmt token (leer = löschen).

Wer die Live-Fassung bekommt, legt ipv64 fest – mehr dazu unter v64 Blocklist und auf ipv64.net/v64_blocklists.

Zusammenarbeit mit Honeypot64

Läuft auf derselben Node das Modul Honeypot64, können PROXY64 und die Fallen zusammenarbeiten. Die Karte Honeypot64 unter PROXY64 → Zugriffslisten (rechts unter „Schutz vor Überlastung“) hat dafür drei Schalter – alle standardmäßig aus und nur wirksam, solange Honeypot64 läuft – und darunter die Wege für als schädlich erkannte Anfragen:

• Nie gesperrt: private Adressen, CGNAT, die Ausnahmen der Blocklisten und die vertrauenswürdigen Proxys der Hosts.
• Sperrliste: nur im Speicher, höchstens 50.000 Einträge (ist sie voll, weicht der am frühesten ablaufende), nach einem Neustart leer. Die Karte zeigt jeden Eintrag mit Grund und Ende; einzeln aufheben geht dort oder per API. Ausschalten leert die Liste.
• Sichtbar: Abgewiesene erscheinen in Statistik und Zugriffs-Log mit dem Grund „vom Honeypot gemeldet“.
• API: GET/PUT /api/cdn64/honeypot, DELETE /api/cdn64/honeypot/blocks/{ip}. Prometheus: node64_cdn64_honeypot_blocks, …_blocks_total, …_rejected_total, …_decoy_total, …_reported_total (nur, wenn ein Schalter an ist).

Als schädlich erkannte Anfragen an den Köder

Im Block Auch als schädlich erkannte Anfragen an den Köder derselben Karte bekommt der Köder statt einer 403 auch Anfragen, die PROXY64 sonst abweist – Angreifer merken nichts, der Honeypot sammelt mehr. Je Art gibt es einen Schalter:

• Überlast – zu viele Anfragen oder Verbindungen – geht nie an den Köder; das ist Schutz, kein Angriff.
• Gilt nur, solange der Köder aktiv ist (Schalter „Unbekannte Anfragen an den Honeypot“ oder Honeypot64 mit der Vorlage Nur über PROXY64), und nur für HTTP(S). TCP/UDP-Streams und „TLS durchreichen“ weisen weiter ab.
• Läuft Honeypot64 mit der Vorlage Nur über PROXY64, ist der Köder automatisch an; die Karte zeigt dazu einen Hinweis mit Link zur Vorlage.
• Ist der Weg für Blocklisten oder gemeldete Angreifer an, trennt der Web-Eingang gesperrte IPs nicht mehr vor TLS – die Anfrage bekommt den Köder. Durchgereichte Hosts prüfen die Sperren selbst nach dem ersten TLS-Paket.
• In der Statistik zählen solche Anfragen eigen unter An Honeypot, nicht unter „abgewiesen“.

KI-Bots abweisen

Je Host (Reiter Details) hältst du KI-Crawler und KI-Assistenten von deinen Seiten fern:

• KI-Bots abweisen (User-Agent): Anfragen, deren User-Agent eine Kennung der Liste v64 KI-Bots (User-Agent) enthält, bekommen eine neutrale 403. In Statistik und Zugriffs-Log stehen sie mit dem Grund „KI-Bot“.
• Nutzer-Abrufe auch sperren (Standard an): auch Abrufe, die ein Mensch über einen Assistenten auslöst – etwa ChatGPT-User, Perplexity-User, Claude-User oder Agenten. Aus = nur Crawler sperren.
• robots.txt mit KI-Sperre ausliefern (nur Proxy-Hosts): Hat das Ziel keine eigene /robots.txt, liefert PROXY64 eine mit Disallow: / für alle Kennungen. Eine eigene robots.txt bleibt unberührt, und /robots.txt selbst wird nie gesperrt.
• Gilt für Proxy-Hosts, Weiterleitungen und Statusseiten.
• Zusätzlich per IP: Die Blockliste v64 KI-Bots (IP) sperrt die offiziellen Netze der KI-Crawler schon beim Verbindungsaufbau, für alle Hosts – OpenAI (GPTBot, OAI-SearchBot, ChatGPT-User), Perplexity (PerplexityBot, Perplexity-User), Common Crawl (CCBot), MistralAI-User und Google-Agent, zusammen rund 310 Netze. Suchmaschinen-Crawler von Google, Bing und Apple sind bewusst nicht dabei.

Die Liste: ein täglicher Spiegel von ai.robots.txt auf ipv64.net mit rund 190 Kennungen – Node64 lädt nichts von GitHub. Groß- und Kleinschreibung zählen nicht; eine Kennung muss als eigenes Wort stehen („Spider“ trifft nicht „Baiduspider“). Geladen wird die Liste nur, solange ein Host sie nutzt, alle 30 Minuten und nur bei Änderung; ohne Verbindung zu ipv64.net gilt der letzte Stand. Stand und Zähler stehen auf der Karte der Blocklisten.

Ländersperre

Je Host – für Proxy-Hosts, Weiterleitungen und „TLS durchreichen“ – und je Stream (TCP und UDP) sperrst du Besucher aus bestimmten Ländern oder lässt nur bestimmte Länder zu. Bei Hosts findest du die Einstellung im Reiter Details, bei Streams im Stream-Formular unter dem TLS-Feld. Eine Änderung gilt sofort, ohne den Stream neu zu starten; bei UDP entscheidet das erste Paket eines Clients.

• Zwei Modi: „diese Länder sperren“ oder „nur diese Länder zulassen“, Länder als ISO-Code (z. B. DE, AT, CH).
• Länderlisten von ipv64.net: täglich aktualisiert, geladen und zwischengespeichert werden nur die Länder, die du wirklich nutzt.
• Beim Laden: Fehlt die Liste eines erlaubten Landes noch – kurz nach dem Start oder wenn der Download scheitert –, sperrt „nur diese Länder zulassen“ niemanden, statt Besucher aus diesem Land abzuweisen.
• Nie gesperrt: private Netze, CGNAT und die Ausnahmen der Blocklisten. Hinter Cloudflare o. Ä. zählt die echte Client-IP.
• Sichtbar: Abgewiesene erscheinen in Statistik und Zugriffs-Log mit dem Grund „Ländersperre“.

Schutz vor Überlastung (Rate-Limits)

PROXY64 begrenzt Verbindungen und Anfragen ähnlich wie Stick-Tables und maxconn beim HAProxy. Der Schutz ist ab Werk eingeschaltet, mit Werten, die für Browser, Apps und Sync-Clients passen. Gezählt wird je IPv4-Adresse bzw. je IPv6-/64.

• Ausgenommen sind das Heimnetz (private, Loopback- und Link-Local-Adressen; abschaltbar), die vertrauenswürdigen Proxys der Hosts (dort zählt die echte Client-IP) und die Ausnahmen der Blocklisten.
• Je Host gibt es unter Erweitert „Ohne Limits je IP“: Dann entfallen Anfrage-Limit und Grenze je Ziel. Verbindungs-Limits und Sperren bleiben.
• Mit dem Wert 0 schaltest du ein einzelnes Limit ab.
• Gilt für Proxy-Hosts, Weiterleitungen, 404-Hosts, durchgereichtes TLS (nur Verbindungen) und TCP-Streams.
• Gesperrte Adressen stehen in der Karte und lassen sich dort freigeben. Jede Sperre steht im Log.
• In der Host-Liste zeigt ein Tacho-Symbol, dass die lokalen Limits für den Host gelten (Klick führt zu den Einstellungen); ein grünes Schild heißt, der Host läuft über CDN64 und ist zusätzlich auf den Edge-Servern geschützt – siehe Schutz vor Überlastung auf den Servern.

Fehlerseiten

Neutrale Fehlerseiten (404, 403, 502, 508) verraten nichts über Node64 oder dein Ziel. Ist ein Ziel nicht erreichbar, sehen Besucher eine 502. Zeigt ein Ziel auf den Proxy selbst, erkennt PROXY64 die Schleife und antwortet mit 508.

Statistik und Zugriffs-Log

• Statistik: Anfragen je Host und Stunde – nach 2xx, 3xx, 4xx und 5xx, Datenmenge und Abgewiesene – werden 90 Tage gehalten. Das Diagramm zeigt 24 Stunden, 7 oder 30 Tage, für alle Hosts oder einen. „24 Std.“ auf Seite, Karte und in Prometheus sind genau die letzten 24 vollen Stunden; Summen und Verlauf zählen dieselben Stunden. Die Zahlen je Host in der Tabelle – Anfragen, Datenverkehr, Fehler, 4xx, Abgewiesene und an Honeypot – folgen dem Zeitraum-Schalter der Verkehrs-Karte; Spaltenköpfe und Kennzahlen nennen den Zeitraum.
• Was wo zählt:
  • Fehler sind nur 5xx und „Ziel nicht erreichbar“.
  • 4xx des Ziels stehen getrennt in Grau – etwa fehlende Icons bei Bitwarden (404) oder abgelaufene Anmeldungen (401). Das ist meist kein Fehler.
  • Abgewiesen sind Anfragen, die PROXY64 selbst ablehnt; sie zählen nur dort, nicht zusätzlich bei 4xx. Ältere Stunden (vor PROXY64 1.29.0) enthalten Abgewiesenes noch bei 4xx.
  • An Honeypot sind Anfragen, die statt einer Abweisung den Köder bekamen – unbekannte Namen und als schädlich erkannte. Je Host in der Tabelle, als Kennzahl, im Diagramm und im Zugriffs-Log (Kennzeichen „an Honeypot“ und eigener Filter). Sichtbar, solange der Köder aktiv ist oder es im Zeitraum Umleitungen gab.
• Farben im Diagramm (auch auf dem Dashboard): Anfragen blau, 4xx grau, Fehler (5xx) gelb, abgewiesen rot, an Honeypot lila, Datenverkehr als Linie.
• Dashboard-Karte: Anfragen, Datenverkehr, 5xx-Fehler mit Anteil, Abgewiesene (24 Stunden) und aktive TCP-Streams.
• Zugriffs-Log: je Host einschaltbar (Reiter Zugriffe), Aufbewahrung 1–90 Tage, Client-IPs auf Wunsch gekürzt.
• Abweisungen werden immer mit Grund erfasst, auch ohne Zugriffs-Log: Blockliste, Sperre, Limits, Zugriffsliste, Exploit-Sperre und KI-Bot. Filter „Abgewiesen“ im Reiter Zugriffe; Anfragen an den Köder haben den eigenen Filter „An Honeypot“. Ins Log kommt je Adresse, Grund und Host höchstens ein Eintrag alle 10 Sekunden; gezählt wird jede Abweisung.
• Ablage: Statistik und Zugriffs-Log liegen in /data/cdn64/cdn64.db. Ins Backup kommen sie nur, wenn du die Statistik mitsicherst (siehe Update & Backup).
• Audit: Jede Änderung aus Oberfläche und API steht im Audit-Log.
• Prometheus: Anfragen, Fehler, Abgewiesene und die Erreichbarkeit der Ziele gibt es auch als Metriken, siehe Prometheus.

Zielerreichbarkeit und Healthchecks

• Ziele von Proxy-Hosts, Durchreich-Hosts und TCP-Streams prüft PROXY64 jede Minute: per TCP, bei HTTP zusätzlich mit HEAD /.
• Die Liste zeigt die Antwortzeit oder „nicht erreichbar seit …“.
• „Healthcheck für dieses Ziel anlegen“ übernimmt das Ziel mit einem Klick ins Modul Healthchecks – mit Benachrichtigungen. Das Modul Healthchecks muss dafür laufen. Der Check heißt dann „PROXY64: <Name>“; Online-Checks aus CDN64 heißen „CDN64: <Name>“.
• Überwacht schon ein Healthcheck genau dieses Ziel, zeigt die Tabelle ihn mit Zustand an: „Healthcheck (lokal)“ für Checks dieser Node, sonst „ipv64/andere Node“. Das gilt auch für Checks, die du von Hand angelegt hast.

Gemeinsamer Eingang mit DNS64 (DoH)

Ein Port lässt sich je Adresse nur einmal öffnen. Deshalb gehören 80 und 443 keinem Modul, sondern dem gemeinsamen Eingang im Kern von Node64. Er verteilt nach dem Namen: bei TLS nach dem SNI, bei HTTP nach dem Host-Kopf. Jeder Name gehört genau einem Abnehmer.

                       Node64 – gemeinsamer Eingang (80/443)
                     ┌─────────────────────────────────────────┐
 Aufruf ────────────►│ Name (SNI bzw. Host-Kopf) entscheidet   │
                     └──┬───────────┬────────────┬──────────┬──┘
                        ▼           ▼            ▼          ▼
                 ┌──────────┐ ┌───────────┐ ┌──────────┐ ┌──────────┐
                 │ PROXY64  │ │ DNS64     │ │ Let's    │ │ Node64-  │
                 │ alle     │ │ DoH unter │ │ Encrypt  │ │ Ober-    │
                 │ Host-    │ │ /dns-query│ │ HTTP-01  │ │ fläche   │
                 │ Arten    │ │           │ │          │ │          │
                 └──────────┘ └───────────┘ └──────────┘ └──────────┘

• PROXY64 und DNS-over-HTTPS teilen sich Port 443 – du brauchst keinen zweiten Container und keine zweite IP. DoH unter /dns-query gibt es ab DNS64 1.8.0, siehe DNS64.
• Die Oberfläche von Node64 lässt sich unter einem eigenen Namen über den Eingang erreichen. Ab Werk nur aus dem eigenen Netz, „aus dem Internet“ musst du ausdrücklich einschalten.
• Offen sind die Ports nur, solange ein Abnehmer sie braucht. Gibt es nur DoH, bleibt Port 80 zu.
• DNS bleibt im LAN: DoH antwortet nur Clients aus der Freigabeliste von DNS64. Dabei zählt immer die echte Gegenstelle, nie ein Kopf. Alle anderen bekommen eine neutrale 404. Port 53 und 853 gibst du im Router nie frei.
• Einen zweiten Container oder eine zweite IP brauchst du nur, wenn ein anderes Programm auf demselben Host 443 belegen will, etwa ein alter NPM.

Zertifikate

PROXY64 nimmt seine Zertifikate aus der zentralen Zertifikatsverwaltung. Kurz zusammengefasst:

Erneuert wird automatisch 30 Tage vor Ablauf – auch wenn PROXY64 gerade aus ist.

Im Host-Formular (Reiter SSL) kannst du mit Neues Zertifikat gleich mit anfordern direkt eines anlegen. Unter Weg zum Zertifikat stehen dieselben Wege wie in der Zertifikatsverwaltung: Automatisch, ipv64 DNS-01, HTTP-01, anderer DNS-Anbieter je hinterlegtem Zugang, eigene CA je CA und selbst signiert. Was gerade nicht geht, ist ausgegraut mit Grund – etwa ipv64 DNS-01 ohne API-Key oder ein DNS-Anbieter ohne Zugang. Alias über ipv64 braucht vorher den CNAME und geht deshalb nur unter Zertifikate → Neu. Bei den Let's-Encrypt-Wegen setzt du den Haken für die Nutzungsbedingungen, sonst wird der Host nicht gespeichert; eigene CA und selbst signiert brauchen kein Konto.

Umstieg vom Nginx Proxy Manager

Einen Import aus dem NPM gibt es bewusst nicht. Du legst die Hosts neu an, die Zertifikate holt Node64 neu. Tipp: Läuft der NPM auf einem anderen Host oder einer anderen IP, lässt du ihn weiterlaufen, bis alle Hosts in PROXY64 stehen, und stellst dann die Portweiterleitung im Router um.

API

Alles aus der Oberfläche geht auch per lokaler API mit API-Key, zum Beispiel /api/cdn64/hosts, /api/cdn64/streams, /api/cdn64/access-lists, /api/cdn64/blocklists, /api/cdn64/limits und /api/cdn64/stats. Die vollständige Beschreibung liefert die Node unter /api/openapi.json. Ein Host der Art Statusseite hat "kind": "status" und die status_page_id.

Grenzen

• Keine freie nginx-Konfiguration – dafür die festen Felder unter „Erweitert“.
• Keine Lastverteilung auf mehrere Ziele im Heimnetz (ein Proxy-Host hat genau ein Ziel). Das Load-Balancing von CDN64 über die beiden Edge-Server ist davon unabhängig.
• Keine Rate-Limits je Host. Länder sperrst du je Host über die Ländersperre.
• Kein Import aus dem Nginx Proxy Manager.
• TLS durchreichen geht nur über TCP, nicht über HTTP/3.
• Erreichbarkeit und Zähler „seit Start“ liegen nur im Speicher und beginnen nach einem Neustart neu. Die Statistik in cdn64.db bleibt erhalten.

Fragen oder Ideen? Schau in die FAQ oder auf ipv64.net vorbei.

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