FAQ & Fehlerbehebung

Antworten auf die häufigsten Fragen und schnelle Lösungen für typische Stolpersteine: belegte Ports, ICMP ohne Root, Docker-Socket, Zertifikatswarnungen und Logs.

Deine Frage ist nicht dabei?

Für alle Fragen zu Node64 gibt es das offizielle Forum v64.tech. Dort helfen dir die Community und das ipv64.net-Team – und deine Frage hilft später auch anderen.

Häufige Fragen

docker exec node64 /node64 reset-password

Port 53 ist belegt (DNS64)

Auf vielen Linux-Systemen belegt systemd-resolved mit seinem Stub-Listener (DNSStubListener=yes) Port 53. DNS64 zeigt den Fehler dann auf seiner Seite an und versucht es jede Minute erneut.

So prüfst du, wer den Port belegt:

sudo ss -lunp 'sport = :53'

Du hast zwei Möglichkeiten:

1. Stub-Listener abschalten (typischer Weg unter Ubuntu und Debian mit systemd-resolved). Der Host nutzt danach weiterhin systemd-resolved, nur ohne eigenen Listener auf Port 53:

   sudo mkdir -p /etc/systemd/resolved.conf.d
   printf '[Resolve]\nDNSStubListener=no\n' | sudo tee /etc/systemd/resolved.conf.d/no-stub.conf
   sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
   sudo systemctl restart systemd-resolved

   Spätestens nach einer Minute startet DNS64 von selbst.
2. Anderen Port nehmen: Unter DNS64 → Einstellungen lässt sich der Port ändern. Beachte, dass Geräte im Netz DNS normalerweise auf Port 53 erwarten.

Ein Überblick über alle Ports mit Überschneidungen steht unter Einstellungen → Ports.

DNS64: Namen wie example.com.home.local im Log

Das Gerät hängt seine Suchdomain selbst an – meist nachdem die eigentliche Anfrage gescheitert ist, etwa mit SERVFAIL, weil die Upstreams kurz nicht antworteten. DNS64 hängt nichts an. Im Abfrage-Log steht dazu „Suchdomain vom Gerät angehängt“.

Port 80 oder 443 ist belegt

Die Ports 80 und 443 gehören dem gemeinsamen Eingang von Node64 – genutzt von PROXY64, DNS-over-HTTPS, der Oberfläche unter eigenem Namen und Let's Encrypt (HTTP-01). Node64 öffnet sie nur, solange ein Modul sie braucht. Läuft auf dem Host schon ein anderer Webserver oder Proxy, kommt es erst dann zum Konflikt.

sudo ss -ltnp 'sport = :443'

• Überschneidungen ansehen: Einstellungen → Ports meldet sie, auch wenn ein anderes Programm auf dem Host den Port belegt, und zeigt je Port, ob wirklich etwas lauscht und warum ein Modul ihn nicht öffnen konnte (z. B. „address already in use“).
• Andere Ports nehmen: Die Ports des Eingangs sind einstellbar. Leitet dein Router zum Beispiel 443 auf 8443 weiter, lässt du Node64 auf 8443 lauschen und stellst „HTTPS-Port von außen“ auf 443.
• Den alten Proxy ablösen: PROXY64 kann als Reverse Proxy übernehmen – siehe PROXY64.
• Ohne offene Ports: Mit CDN64 sind Dienste per Tunnel erreichbar, ganz ohne Portfreigabe.

ICMP-Checks (Ping) schlagen fehl

Node64 läuft nicht als Root. Damit Ping-Checks trotzdem funktionieren, braucht der Container eine von zwei Einstellungen:

    sysctls:
      - net.ipv4.ping_group_range=0 65535   # unprivilegiertes Ping, gilt auch für ICMPv6
    # oder:
    # cap_add:
    #   - NET_RAW

Mit network_mode: host lässt Docker keine net.*-sysctls im Container zu – nimm dort cap_add: NET_RAW. Hast du Capabilities mit cap_drop entfernt, startet Node64 zwar, ICMP geht dann aber nicht.

Melden nur IPv6-Pings Fehler? Dann fehlt dem Container wahrscheinlich IPv6 – siehe IPv6 im Container.

Docker-Checks: keine Berechtigung für den Socket

Node64 läuft als Benutzer 65532 und darf den Docker-Socket nur lesen, wenn er in dessen Gruppe ist. Ermittle die Gruppen-ID des Sockets auf dem Host:

stat -c %g /var/run/docker.sock

und trage genau diese Zahl bei group_add ein:

    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    group_add:
      - "996"   # Ausgabe von stat -c %g /var/run/docker.sock

Danach den Container mit docker compose up -d neu erstellen. Wer den Socket nicht direkt durchreichen möchte, nimmt einen docker-socket-proxy – siehe Konfiguration → Docker-Host.

Der Browser warnt vor dem Zertifikat

Rufst du https://<host>:8080 auf, nutzt Node64 anfangs ein selbstsigniertes Zertifikat – die Warnung ist dann normal. Abhilfe:

• Unter Zertifikate ein richtiges Zertifikat anfordern (z. B. Let's Encrypt) und für die Oberfläche auswählen.
• Oder ein eigenes Zertifikat über NODE64_TLS_CERT und NODE64_TLS_KEY einbinden (siehe Konfiguration).

Die Node startet nach Wiederherstellung oder Zurücksetzen nicht wieder

Nach dem Einspielen eines Backups und nach einem Werksreset beendet sich Node64 selbst, damit Docker ihn frisch startet. Das klappt nur mit einer Neustart-Regel:

docker update --restart unless-stopped node64
docker start node64

In Compose-Dateien gehört dafür restart: unless-stopped zum Dienst.

Logs ansehen

• In der Oberfläche: Menüpunkt Logs zeigt die letzten 2000 Zeilen, mit Download.
• Auf dem Host: docker logs -f node64 (oder docker compose logs -f).
• Mehr Details: Unter Einstellungen → Logging das Level für einen Bereich vorübergehend auf debug stellen. Mit „Zurücksetzen nach“ fällt es automatisch wieder zurück.
• Als JSON: NODE64_LOG_FORMAT=json für Log-Sammler.
• Sicher teilen: Passwörter, Tokens und Schlüssel werden im Log immer maskiert.

docker logs --tail 200 node64
docker exec node64 /node64 version
curl http://localhost:8080/api/health

Nicht weitergekommen? Frag in der ipv64.net-Community oder schau ins ipv64.net-Wiki.

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