Windows verbindet sich, aber iPhone oder iPad nicht
Notiere die vollständige Fehlermeldung, Clientversion, Serverbuild und ob du über WLAN, Mobilfunk oder VPN testest. InitialConnection-13, Door und NetherNet allein belegen kein Zertifikatsproblem. Prüfe zuerst die Einrichtung für Vanilla-BDS oder Geyser.
Dokumentiert: NetherNet trennt HTTP-/HTTPS-Signaling vom UDP-Spielverkehr. TLS schützt das Signaling; es ersetzt den UDP-Weg nicht. Mojang dokumentiert HTTP-Signaling. Daraus folgt keine allgemeine HTTPS-Pflicht für alle iOS- und iPadOS-Versionen. Siehe die Protokolldokumentation.
Berichteter Workaround: In BDS-23108 scheiterte ein iOS-26.52-Client an BDS 1.26.52.3 über direktes HTTP und konnte über HTTPS bei unverändertem Spielendpunkt beitreten. Der Test änderte auch Signaling-Hostname und Netzwerkpfad und isoliert daher die Ursache nicht. itzg #680, am 29. Oktober 2026 weiterhin offen, meldet TLS-Alert 40 auf ARM64/Box64 mit BDS 1.26.51.1 und iOS 26.51. Diese Berichte belegen nicht denselben Fehler bei jedem 26.60-Client.
Öffentliche IP ohne gemieteten Server finden
Betreibst du Minecraft auf deinem PC oder NAS zu Hause, brauchst du keinen gemieteten Server für eine öffentliche IP: Entscheidend ist dein Internetanschluss. Wenn du nur auf einem fremden Server spielen möchtest, brauchst du dessen Beitrittsadresse vom Betreiber, nicht deine eigene IP.
- Öffne auf einem Gerät im gleichen Heimnetz wie der Minecraft-Rechner die IPv4-Anzeige von ipify. Nutze für diesen Vergleich keinen VPN-/Proxy-Ausgang und keinen Mobilfunk-Hotspot. Die angezeigte Adresse ist die vom Dienst gesehene Ausgangs-IPv4.
- Vergleiche sie mit der WAN-/Internet-IPv4 im Router. Bei einer FRITZ!Box findest du sie unter Internet → Online-Monitor, je nach FRITZ!OS unter Verbindungsdetails. Die LAN-Adresse deines PCs aus
ipconfig, etwa192.168.178.20, ist nicht diese Adresse. - Stimmen beide überein und ist die Router-Adresse öffentlich, kannst du sie für die IPv4-Beispiele verwenden. Richte anschließend die passenden TCP-/UDP-Weiterleitungen ein und teste einen vollständigen Beitritt von außerhalb.
Alternativ auf Linux/macOS oder in einer Shell mit curl:
curl -4 --fail --max-time 10 https://api.ipify.org
Unter Windows PowerShell funktioniert auch:
Invoke-RestMethod -Uri 'https://api.ipify.org'
Eine angezeigte IP beweist keine Erreichbarkeit. Weichen die Adressen ab, können ein weiterer Router, VPN oder Provider-NAT dazwischenliegen. Eine Router-WAN-Adresse aus 100.64.0.0–100.127.255.255 weist auf CGNAT hin; private Bereiche wie 10.x.x.x, 172.16.x.x–172.31.x.x und 192.168.x.x sind ebenfalls keine öffentliche IPv4. Bei DS-Lite fehlt häufig eine eigene öffentliche IPv4. Kläre beim Anbieter eine eingehend erreichbare Adresse oder nutze einen passenden Tunnel-/IPv6-Weg. Siehe die Router-Diagnose von FRITZ!.
Bei wechselnder öffentlicher IP aktualisierst du DNS beziehungsweise DDNS und die angekündigte UDP-Adresse. Ein Hostname allein aktualisiert keine fest eingetragene IP in der Serverkonfiguration. Die öffentliche IPv6 eines anderen Geräts oder die WAN-IPv6 des Routers ist nicht automatisch die richtige IPv6 des Minecraft-Rechners. Bei Hosting oder Tunneln verwendest du die vom Anbieter zugewiesenen Endpunkte statt der IP deines Heimanschlusses.
Den passenden HTTPS-Weg wählen
| Einrichtung | Geeigneter Weg | Was zusätzlich nötig bleibt |
|---|---|---|
| Geyser mit Zertifikatsdateien | Eingebautes HTTPS | Erreichbares Spiel-UDP und Zertifikatserneuerung |
| Selbst betriebenes Geyser oder BDS | HTTPS-Reverse-Proxy vor dem Signaling | Richtiges Weiterleitungsziel, Zertifikatsname und separater UDP-Weg |
| Geyser mit Warden | Externes HTTPS-Signaling | Funktionierende Spielverbindung; tatsächlichen Beitritt testen |
| Private Tailscale-Gruppe | Tailnet-Verbindung, optional ts.net-Zertifikat | Spieler benötigen Zugriff auf Tailnet und angekündigtes Spielziel |
Die folgenden Beispiele verwenden ein Domain-Zertifikat: Spieler tragen play.example.com ein, nicht die Server-IP. Richte deren DNS-Einträge auf den HTTPS-Endpunkt. Veröffentliche einen AAAA-Eintrag nur bei funktionierendem IPv6-Weg.
Was Caddy hier übernimmt
Caddy ist ein Webserver, der hier als Reverse Proxy arbeitet: Er nimmt die HTTPS-Anfrage des Spiels entgegen und leitet sie intern per HTTP an Geyser oder BDS weiter. Den UDP-Spielverkehr verbinden die Clients weiterhin direkt mit dem Minecraft-Server.
Caddy kann das Zertifikat für deinen Hostnamen automatisch beschaffen und erneuern. Dafür müssen die Domain und die Zertifikatsprüfung wie unten beschrieben eingerichtet sein. Du installierst Caddy als eigenen Dienst auf dem Serverrechner; Spieler installieren nichts zusätzlich. Die Caddyfile ist seine Konfigurationsdatei, bei der Linux-Paketinstallation üblicherweise /etc/caddy/Caddyfile.
Wähle einen HTTPS-Weg: Hast du bereits Zertifikatsdateien für Geyser, verwende den nächsten Abschnitt. Soll Caddy die Zertifikate verwalten, folge dem Caddy-Beispiel für Geyser oder BDS. Nutzt du Geyser mit Warden, übernimmt Warden das HTTPS-Signaling; dafür brauchst du Caddy nicht.
Geyser: Zertifikat direkt verwenden
Ergänze diese Werte in der vorhandenen bedrock.signaling-Konfiguration. Behalte NetherNet-Transport und erreichbare UDP-Ankündigung aus dem Hauptguide:
bedrock:
signaling:
mode: builtin
builtin:
https:
certificate: /path/to/fullchain.pem
private-key: /path/to/privkey.pem
password: ''
Beschaffe zuerst ein vertrauenswürdiges Zertifikat für den Hostnamen. Der Geyser-Prozess muss Kette und Schlüssel lesen können; Container-Pfade müssen im Container existieren. Schütze den privaten Schlüssel. Starte nach der Einrichtung neu und plane Zertifikatserneuerung samt Neustart oder erneutem Laden des Zertifikats ein. Die offizielle Geyser-HTTPS-Anleitung erklärt Ausstellung und Plattformdetails.
Geyser: Caddy vor das HTTP-Signaling setzen
Für Caddy und Geyser auf demselben Host im selben Netzwerk-Namensraum nutzt du öffentliches TCP 19132 für Caddy, privates TCP 19133 für Signaling und UDP 19132 für das Spiel. Ersetze DEINE_OEFFENTLICHE_IP vor dem Speichern. Übernimm diese Werte in die vorhandene Datei und behalte die Anmeldungseinstellungen:
bedrock:
address: 0.0.0.0
port: 19133
clone-remote-port: false
transport: nethernet
webrtc-port: 19132
signaling:
mode: builtin
advertise-addresses:
- "DEINE_OEFFENTLICHE_IP:19132"
advanced:
bedrock:
signaling-trusted-proxies:
- 127.0.0.1
Verwende nach der Caddy-Installation diese Caddyfile:
{
servers {
protocols h1 h2
}
}
play.example.com:19132 {
reverse_proxy 127.0.0.1:19133
}
Halte TCP 19133 von außen unzugänglich. Lass Geysers Bind-Adresse auf 0.0.0.0; begrenze den Zugriff durch Firewall oder Container-Freigaben. Läuft Caddy in einem anderen Container, zeigt 127.0.0.1 nicht auf Geyser: Nutze dessen Dienstadresse und vertraue nur der tatsächlichen Quelladresse des Proxys. Vertraue nicht jedem Absender von X-Forwarded-For.
Prüfe mit caddy validate --config /etc/caddy/Caddyfile, starte Geyser neu und lade Caddy über deinen Dienstmanager neu. Erlaube öffentlich TCP 19132 und Spiel-UDP 19132. protocols h1 h2 verhindert, dass HTTP/3 denselben UDP-Port wie das Spiel belegt. Ausstellung und Erneuerung benötigen außerdem eine funktionierende ACME-Prüfung: Mache für die HTTP-Prüfung TCP 80 erreichbar oder konfiguriere eine unterstützte DNS-Prüfung. DNS-Validierung erzeugt keinen Spielweg durch CGNAT.
BDS: HTTPS-Proxy mit separatem UDP-Bereich
Nutze für BDS die BDS-Konfiguration mit transport=nethernet, internem Signaling auf TCP 19132 und einem erreichbar angekündigten UDP-Bereich, etwa 19140–19149 für zehn Verbindungen.
Für Caddy auf dem Docker-Host veröffentlichst du das BDS-Signaling nur auf dessen Loopback-Adresse und behältst die Spielfreigaben im vorhandenen BDS-Compose-Dienst:
ports:
- "127.0.0.1:19132:19132/tcp"
- "19140-19149:19140-19149/udp"
Behalte dort SERVER_UDP_PORTS: "DEINE_OEFFENTLICHE_IP:19140-19149:19140-19149" und MAX_PLAYERS: "10" und ersetze die IP. Behalte das Datenvolume. Erstelle den Dienst nach geänderten Freigaben mit docker compose up -d bds neu; verwende deinen tatsächlichen Dienstnamen.
Nutze diese alternative Caddyfile anstelle des vorherigen Geyser-Blocks:
play.example.com:443 {
reverse_proxy 127.0.0.1:19132
}
Spieler tragen play.example.com mit Port 443 ein. Erlaube beziehungsweise leite TCP 443 zu Caddy und UDP 19140–19149 zu BDS weiter, zusätzlich zum für die Zertifikatserneuerung nötigen Prüfweg. HTTPS- und Spielports müssen nicht gleich sein. Begrenze bei nativem BDS den Zugriff auf dessen internen TCP-Listener durch die Host-Firewall. Läuft Caddy im Container, passe das Zielnetz an, statt Host-Loopback zu verwenden.
Diese Anordnung terminiert HTTPS für Signaling. Sie schreibt keine SDP-/ICE-Kandidaten um und leitet keinen Spielverkehr weiter: Kündigt BDS eine unerreichbare Adresse an, korrigiere BDS-Ankündigung und UDP-Zuordnungen. Leite GET /v1/join und POST /v1/join/{networkId} samt Inhalten unverändert weiter, ohne Browser-Login, CAPTCHA oder Umleitungen.
Warden Cloud, playit.gg und Tailscale
Warden Cloud: HTTPS-Signaling für Geyser
Warden Cloud ist ein externer Dienst für die erste Kontaktaufnahme zwischen Bedrock und Geyser. Geyser registriert sich dort; Spieler tragen die zugewiesene Warden-Adresse in Minecraft ein und benötigen keine zusätzliche App. Warden stellt das HTTPS-Zertifikat bereit und erneuert es.
Der Spielverkehr läuft anschließend direkt zum Geyser-Server. Warden ist kein Tunnel für diesen Verkehr und verbirgt die Server-IP nicht. UDP-Portweiterleitung ist der bevorzugte Weg; ohne sie kann Warden beim direkten Verbindungsaufbau durch NAT helfen („assisted joins“), sofern beide Netze das zulassen. Teste deshalb einen vollständigen Beitritt. Für Vanilla-BDS nutze den HTTPS-Proxy aus dem vorherigen Abschnitt.
Für Geyser übernimmst du in der vorhandenen Konfiguration:
bedrock:
transport: nethernet
signaling:
mode: nxs
Behalte deine UDP-Einstellungen. Starte vollständig neu und verwende den in der Konsole angezeigten Warden-Hostnamen samt Port, häufig 443. Eine erfolgreiche Registrierung beweist noch keinen erfolgreichen Spielbeitritt; teste ihn vom tatsächlichen Spielernetz aus.
playit.gg: öffentlicher Tunnel zum Heimserver
playit.gg leitet Verbindungen von einer öffentlichen Adresse zu deinem Minecraft-Rechner weiter. Dafür installierst du den playit-Agenten auf dem Serverrechner; Spieler benötigen keine zusätzliche App. Das ist eine Option, wenn du im Router keine Ports weiterleiten kannst.
Wähle einen Tunnel, der die benötigten TCP- und UDP-Wege abdeckt. Bei Geyser brauchst du einen UDP-Spielport, bei BDS den konfigurierten UDP-Bereich. Ein reiner TCP-/UDP-Tunnel stellt noch kein HTTPS-Zertifikat bereit. Die HTTPS-Tunnel-Anleitung beschreibt lokale TLS-Terminierung durch Caddy und benötigt Premium. Auch NetherNet wird auf der playit-Website derzeit als Premium-Funktion geführt. Prüfe vor der Einrichtung den passenden Tunneltyp und Tarif.
Die ältere Bedrock-Anleitung empfiehlt noch den Rückwechsel zu RakNet. Das funktioniert für Clients ab 26.60 nicht. Mit Geyser kannst du Warden für HTTPS-Signaling und einen passenden playit-UDP-Tunnel für den Spielverkehr kombinieren. Trage dafür unter bedrock.signaling.advertise-addresses den von playit zugewiesenen öffentlichen UDP-Hostnamen beziehungsweise die IP samt externem Port ein. Das lokale Tunnelziel muss zu Geysers webrtc-port passen; bei webrtc-port: 0 ist das bedrock.port.
Tailscale: privates Netzwerk für deine Spielergruppe
Tailscale verbindet Geräte über ein privates VPN-Netz, das Tailnet. In der einfachen Variante installieren sowohl der Serverbetreiber als auch die Spieler Tailscale auf ihren Geräten und erhalten Zugriff auf dieses Netz. Das eignet sich für eine feste Gruppe auf unterstützten Geräten; der Server erhält dadurch keine öffentliche Beitrittsadresse für beliebige Spieler.
Die Spieler verwenden eine erreichbare Tailscale-Adresse des Serverrechners. Auch die von NetherNet angekündigte UDP-Adresse muss über dieses Netz erreichbar sein. Die VPN-Verschlüsselung ersetzt kein HTTPS-Zertifikat: Mit tailscale cert kannst du eines für den vollständigen *.ts.net-Namen des Rechners beziehen. Bindest du die Dateien selbst in Geyser ein, musst du Erneuerung und erneutes Laden einrichten.
Funktioniert der Beitritt über Tailscale, aber nicht über die öffentliche Adresse, vergleiche beide Netzwerkwege. Der erfolgreiche VPN-Test allein zeigt noch nicht, ob beim öffentlichen Weg TLS oder Routing die Ursache ist.
Zertifikat, Signaling und Spiel nacheinander testen
Teste von außerhalb mit dem tatsächlichen Spieler-Hostnamen und Port:
curl --fail --max-time 10 https://play.example.com:443/v1/join
openssl s_client -connect play.example.com:443 -servername play.example.com -verify_hostname play.example.com -verify_return_error </dev/null
Für Geysers eingebautes HTTPS und das Geyser/Caddy-Beispiel verwendest du 19132 statt 443. Bei Warden verwendest du dessen zugewiesenen Hostnamen und Port; beim BDS/Caddy-Beispiel deinen Hostnamen mit Port 443. Umgehe die Zertifikatsprüfung nicht mit curl -k, um funktionierendes TLS zu belegen. Nutze danach den Verbindungstest und teste einen vollständigen Minecraft-Beitritt auf dem betroffenen iPhone oder iPad. Vergleiche denselben Client über Mobilfunk und WLAN, danach eine andere Plattform. Teste bei BDS auch einen zweiten gleichzeitigen Spieler.
| Symptom | Nächste Prüfung / Aussagekraft |
|---|---|
| Zertifikatsname falsch oder Aussteller nicht vertrauenswürdig | Spieler-Hostname, vollständige Kette, Gültigkeit und DNS-Ziel |
| HTTP im Browser funktioniert, iOS erreicht das Signaling nicht | TLS-Logs und verwendeten Hostnamen vergleichen |
| HTTPS liefert HTML, Umleitung, 404 oder Anmeldeseite | Proxy-Routing und vorgeschaltete Zugangskontrolle für die Signaling-Pfade |
| GET funktioniert, Beitritt scheitert | Beitritts-POST und Serverlogs, dann Spiel-UDP prüfen; GET allein reicht nicht |
| Server sichtbar, Beitritt läuft in Timeout | Angekündigte ICE-Adresse, vollständiger UDP-Weg und HTTP/3-Portkonflikt |
| Erst der zweite BDS-Spieler scheitert | Größe des UDP-Bereichs und Weiterleitung jedes reservierten Ports |
| Geyser startet HTTPS nach Erneuerung nicht | Pfade, Rechte, zusammenpassende Schlüssel/Kette, Passwort und erneutes Laden |
Für Geyser-spezifische HTTP-500-, native Bibliotheks- und Datenkanalfehler nutze die versionsbezogenen Troubleshooting-Berichte. Behalte bei der Netzwerkdiagnose Welt- und Identitätsdateien.
Quellen
Quellenstand: 29. Oktober 2026.