Reine IPv6-Server sind aus einem einfachen Grund billig: IPv4-Adressen sind knapp und kosten jeden Monat Geld, IPv6-Adressen nicht. Die Frage ist also nicht, ob IPv6-only günstiger ist – das ist es –, sondern ob das, was du tatsächlich nutzt, noch funktioniert. Wir haben es im September 2026 geprüft, statt alte Forenantworten zu wiederholen.
Was wir getestet haben – und das Ergebnis
Wir haben die IPv6-Einträge (AAAA) der Dienste nachgeschlagen, die ein typischer Server am ersten Tag anspricht. Kein AAAA-Eintrag heißt: Eine reine IPv6-Maschine kommt ohne Hilfe nicht hin.
| Dienst | IPv6 am 26.09.2026 |
|---|---|
| github.com, api.github.com | ❌ nein |
| objects.githubusercontent.com (Release-Downloads) | ❌ nein |
| ghcr.io (Container-Registry von GitHub) | ❌ nein |
| raw.githubusercontent.com | ✅ ja |
| Docker Hub (registry-1.docker.io) | ✅ ja |
| PyPI, npm, crates.io, Go-Modul-Proxy | ✅ ja |
| Paketspiegel von Debian / Ubuntu / Alpine | ✅ ja |
| GitLab | ✅ ja |
| Let's Encrypt (ACME) | ✅ ja |
| Telegram Bot API | ✅ ja |
| discord.com und das Discord-Gateway | ❌ nein |
| APIs von OpenAI, Anthropic, Google Gemini | ✅ ja |
| Hugging Face (Website) | ✅ ja – aber das CDN für große Dateien: ❌ nein |
| ollama.com | ❌ nein (registry.ollama.ai: ✅ ja) |
| Binance-API | ❌ nein |
| Coinbase-API | ✅ ja |
Das Muster: Paketmanager, große KI-APIs und Telegram sind bereit. GitHub – der Dienst, den fast jeder Server braucht – noch nicht.
Was das in der Praxis bedeutet
Auf einem reinen IPv6-VPS stößt du genau an diesen Stellen an Grenzen:
git clone https://github.com/...schlägt fehl. Ebenso Installationsskripte, die ein GitHub-Release per curl holen, und alles, was Images vonghcr.iozieht.- Discord-Bots kommen gar nicht ans Gateway.
- Manche Modell-Downloads brechen: Das Große-Dateien-CDN von Hugging Face und ollama.com hatten bei unserer Prüfung kein IPv6.
- Krypto-Bots an reinen IPv4-Börsen erreichen die API nicht.
Und eine leisere Stelle auf der Eingangsseite: Besucher aus reinen IPv4-Netzen erreichen eine Seite auf einem reinen IPv6-Server nicht, außer du stellst einen Proxy oder ein CDN mit IPv4 davor.
Jeden Dienst in zwei Sekunden testen
dig +short AAAA github.com # empty output = no IPv6
dig +short AAAA api.telegram.org # addresses = IPv6 available
curl -6 -sI https://pypi.org | head -1 # on a dual-stack box: proves it answers over v6
Lass das gegen alles laufen, womit dein Projekt spricht – bevor du einen Tarif wählst.
Workarounds und ihr Preis
- NAT64/DNS64. Ein Gateway übersetzt IPv6-Anfragen an IPv4-Ziele. Öffentliche Gateways gibt es, aber dein Traffic läuft dann über fremde Hardware, und du hängst von deren Verfügbarkeit ab.
- Spiegel und Proxys. Spiegel deine GitHub-Repos auf GitLab, leg Images auf Docker Hub ab, betreib einen kleinen Proxy auf einer Dual-Stack-Maschine. Machbar, aber das ist Klempnerarbeit, die du am Laufen halten musst.
- Ein CDN davor für eingehenden Web-Traffic, damit IPv4-Besucher dich erreichen.
Jede Lösung für sich ist in Ordnung. Zusammen fressen sie die paar Dollar auf, die ein reiner IPv6-Tarif gespart hat.
Wann du IPv4 wirklich brauchst – und welche Art
Für die meisten Projekte lautet die ehrliche Antwort: Du brauchst IPv4-Konnektivität, aber nicht unbedingt eine eigene IPv4-Adresse.
- Wenn sich nichts zu deinem Server verbinden muss – Bots, Agenten, Worker, Cronjobs –, reicht ein NAT-Tarif. Er erreicht jeden Dienst, auch reine IPv4-Dienste, über NAT, und du kommst über einen persönlichen SSH-Port hinein. Das ist die Sparvariante: NAT-Tarife ab $3/Monat.
- Wenn sich etwas hinein verbinden muss – eine Website, ein Mailserver, ein Gameserver, ein VPN-Endpunkt –, nimm einen Tarif mit eigener IPv4.
Reine IPv6-Tarife verkaufen wir genau aus den Gründen in der Tabelle nicht: Bei $3 im Monat für NAT mit voller IPv4-Reichweite ist die Ersparnis keinen Server wert, der nicht von GitHub klonen kann. Noch unsicher, welche der beiden Varianten du brauchst? Hier ist der Ein-Fragen-Test.
Kommentare
Noch keine Kommentare. Sei der Erste.