Servere med kun IPv6 er billige af en simpel grund: IPv4-adresser er knappe og koster penge hver måned, det gør IPv6-adresser ikke. Spørgsmålet er altså ikke, om kun IPv6 er billigere (det er det), men om de ting, du faktisk bruger, stadig virker. Vi tjekkede i september 2026 i stedet for at gentage årgamle forumsvar.
Hvad vi testede, og resultatet
Vi slog IPv6-posterne (AAAA) op for tjenester, som en typisk server rører ved allerede første dag. Ingen AAAA-post betyder, at en maskine med kun IPv6 ikke kan nå dem uden hjælp.
| Tjeneste | IPv6 pr. 26. sep. 2026 |
|---|---|
| github.com, api.github.com | ❌ nej |
| objects.githubusercontent.com (download af udgivelser) | ❌ nej |
| ghcr.io (GitHubs containerregister) | ❌ nej |
| raw.githubusercontent.com | ✅ ja |
| Docker Hub (registry-1.docker.io) | ✅ ja |
| PyPI, npm, crates.io, Gos modulproxy | ✅ ja |
| Pakkespejle for Debian / Ubuntu / Alpine | ✅ ja |
| GitLab | ✅ ja |
| Let's Encrypt (ACME) | ✅ ja |
| Telegram Bot API | ✅ ja |
| discord.com og Discords gateway | ❌ nej |
| API'er fra OpenAI, Anthropic, Google Gemini | ✅ ja |
| Hugging Face (website) | ✅ ja, men CDN-værten til store filer: ❌ nej |
| ollama.com | ❌ nej (registry.ollama.ai: ✅ ja) |
| Binance API | ❌ nej |
| Coinbase API | ✅ ja |
Mønsteret: pakkehåndteringer, store AI-API'er og Telegram er klar. GitHub, den ene tjeneste, næsten alle servere har brug for, er det stadig ikke.
Hvad det betyder i praksis
På en VPS med kun IPv6 løber du panden mod muren præcis disse steder:
git clone https://github.com/...fejler. Det samme gør installationsscripts, der henter en GitHub-udgivelse med curl, og alt, der trækker images fraghcr.io.- Discord-bots kan slet ikke forbinde til gatewayen.
- Nogle modeldownloads går i stykker: Hugging Faces vært til store filer og ollama.com havde ingen IPv6 ved vores tjek.
- Kryptobots på børser med kun IPv4 kan ikke nå API'et.
Og et mere stille problem på den indgående side: besøgende på net med kun IPv4 kan ikke nå et site, der ligger på en server med kun IPv6, medmindre du sætter en proxy eller et CDN med IPv4 foran.
Test en vilkårlig tjeneste på to sekunder
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
Kør det mod alt, dit projekt taler med, før du vælger en plan.
Løsninger, og hvad de koster
- NAT64/DNS64. En gateway oversætter IPv6-forespørgsler til IPv4-destinationer. Der findes offentlige, men så går din trafik gennem en andens maskine, og du er afhængig af deres oppetid.
- Spejle og proxyer. Spejl dine GitHub-repositorier til GitLab, skub images til Docker Hub, kør en lille proxy på en dual-stack-maskine. Det kan lade sig gøre, men det er VVS-arbejde, der skal holdes i live.
- Et CDN foran til indgående webtrafik, så IPv4-besøgende kan nå dig.
Hver løsning for sig er fin. Tilsammen æder de de få dollars, som planen med kun IPv6 sparede.
Hvornår du virkelig har brug for IPv4, og hvilken slags
For de fleste projekter er det ærlige svar: du vil have IPv4-forbindelse, men ikke nødvendigvis din egen IPv4-adresse.
- Skal intet forbinde til din server (bots, agenter, workers, cron-job), er en NAT-plan nok. Den når alle tjenester, også dem med kun IPv4, via NAT, og du kommer ind via en personlig SSH-port. Det er budgetmuligheden: NAT-planer fra $3/md..
- Skal noget forbinde udefra (en hjemmeside, en mailserver, en spilserver, et VPN-endpoint), så tag en plan med dedikeret IPv4.
Vi sælger ikke planer med kun IPv6, netop af grundene i tabellen ovenfor: til $3 om måneden for NAT med fuld IPv4-rækkevidde er besparelsen ikke en server værd, der ikke kan klone fra GitHub. Stadig i tvivl om, hvilken af de to du har brug for? Her er testen med ét spørgsmål.
Kommentarer
Ingen kommentarer endnu. Vær den første.