Werkt GitHub op een server met alleen IPv6?

Niet rechtstreeks. Bij onze controle in september 2026 publiceerden github.com, api.github.com, objects.githubusercontent.com (release-downloads) en ghcr.io geen IPv6-adressen, dus git clone, de API en container-pulls van GitHub mislukken. raw.githubusercontent.com heeft wel IPv6.

Kan ik een Discord-bot op alleen IPv6 draaien?

Nee: discord.com en de Discord-gateway hadden bij onze controle geen IPv6-adressen. Een Telegram-bot werkt prima: api.telegram.org antwoordt via IPv6.

Waarom zijn servers met alleen IPv6 goedkoper?

IPv4-adressen zijn schaars en kosten providers elke maand echt geld; IPv6-adressen zijn praktisch gratis. Een plan met alleen IPv6 geeft die besparing door, ten koste van alles wat alleen IPv4 spreekt.

Hoe controleer ik of een dienst IPv6 ondersteunt?

Draai 'dig +short AAAA hostname'. Geen uitvoer betekent geen IPv6-adres. Op een dual-stack-machine bevestigt 'curl -6 -sI https://hostname' dat hij echt via IPv6 antwoordt.

Verkoopt EQVPS plannen met alleen IPv6?

Nee. Elk EQVPS-plan bereikt internet via IPv4: NAT-plannen gaan via NAT naar buiten en je bereikt ze op een persoonlijke SSH-poort, dedicated plannen hebben een eigen publiek IPv4. NAT-plannen beginnen bij $3/mnd, wat het budgetscenario dekt zonder de kopzorgen van alleen IPv6.

VPS met alleen IPv6: wat werkt en wat breekt in 2026

Servers met alleen IPv6 zijn goedkoop om een simpele reden: IPv4-adressen zijn schaars en kosten elke maand geld, IPv6-adressen niet. De vraag is dus niet of alleen IPv6 goedkoper is (dat is het), maar of de dingen die je echt gebruikt nog werken. We hebben het in september 2026 gecontroleerd in plaats van forumantwoorden van een jaar oud te herhalen.

Wat we testten, en de uitkomst

We zochten de IPv6-records (AAAA) op van diensten die een typische server op dag één aanspreekt. Geen AAAA-record betekent dat een machine met alleen IPv6 ze niet zonder hulp kan bereiken.

Dienst	IPv6 op 26 sep 2026
github.com, api.github.com	❌ nee
objects.githubusercontent.com (release-downloads)	❌ nee
ghcr.io (container registry van GitHub)	❌ nee
raw.githubusercontent.com	✅ ja
Docker Hub (registry-1.docker.io)	✅ ja
PyPI, npm, crates.io, Go-moduleproxy	✅ ja
Pakketmirrors van Debian / Ubuntu / Alpine	✅ ja
GitLab	✅ ja
Let's Encrypt (ACME)	✅ ja
Telegram Bot API	✅ ja
discord.com en de Discord-gateway	❌ nee
API's van OpenAI, Anthropic, Google Gemini	✅ ja
Hugging Face (site)	✅ ja, maar de CDN-host voor grote bestanden: ❌ nee
ollama.com	❌ nee (registry.ollama.ai: ✅ ja)
Binance API	❌ nee
Coinbase API	✅ ja

Het patroon: pakketbeheerders, grote AI-API's en Telegram zijn er klaar voor. GitHub, de ene dienst die bijna elke server nodig heeft, nog steeds niet.

Wat dat in de praktijk betekent

Op een VPS met alleen IPv6 loop je precies op deze plekken tegen een muur:

git clone https://github.com/... mislukt. Net als installatiescripts die met curl een GitHub-release ophalen, en alles wat images van ghcr.io trekt.
Discord-bots kunnen helemaal geen verbinding maken met de gateway.
Sommige modeldownloads breken: de host voor grote bestanden van Hugging Face en ollama.com hadden bij onze controle geen IPv6.
Cryptobots op beurzen met alleen IPv4 bereiken de API niet.

En een stillere aan de inkomende kant: bezoekers op netwerken met alleen IPv4 kunnen een site op een server met alleen IPv6 niet bereiken, tenzij je er een proxy of CDN met IPv4 voor zet.

Test elke dienst in twee seconden

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

Draai dit tegen alles waar je project mee praat, voordat je een plan kiest.

Omwegen, en wat ze kosten

NAT64/DNS64. Een gateway vertaalt IPv6-verzoeken naar IPv4-bestemmingen. Er bestaan publieke, maar dan loopt je verkeer via de machine van een ander en ben je afhankelijk van hun uptime.
Mirrors en proxy's. Spiegel je GitHub-repo's naar GitLab, push images naar Docker Hub, draai een kleine proxy op een dual-stack-machine. Werkbaar, maar het is loodgieterswerk dat je in leven moet houden.
Een CDN ervoor voor inkomend webverkeer, zodat IPv4-bezoekers je kunnen bereiken.

Elke omweg op zich is prima. Samen vreten ze de paar dollar op die een plan met alleen IPv6 bespaarde.

Wanneer je echt IPv4 nodig hebt, en welk soort

Voor de meeste projecten is het eerlijke antwoord: je wilt IPv4-connectiviteit, maar niet per se een eigen IPv4-adres.

Hoeft niets verbinding te maken met je server (bots, agents, workers, cronjobs), dan volstaat een NAT-plan. Dat bereikt elke dienst, ook die met alleen IPv4, via NAT, en jij komt binnen via een persoonlijke SSH-poort. Dat is de budgetoptie: NAT-plannen vanaf $3/mnd.
Moet er iets van buitenaf verbinding maken (een website, een mailserver, een gameserver, een VPN-endpoint), neem dan een plan met dedicated IPv4.

We verkopen geen plannen met alleen IPv6, precies om de redenen in de tabel hierboven: voor $3 per maand voor NAT met volledig IPv4-bereik is de besparing geen server waard die niet van GitHub kan clonen. Twijfel je nog welke van de twee je nodig hebt? Hier is de test met één vraag.