GitHub fonctionne-t-il sur un serveur IPv6 uniquement ?

Pas directement. Lors de notre vérification en septembre 2026, github.com, api.github.com, objects.githubusercontent.com (téléchargement des versions) et ghcr.io ne publiaient aucune adresse IPv6 : git clone, l'API et le téléchargement de conteneurs depuis GitHub échouent. raw.githubusercontent.com dispose bien de l'IPv6.

Puis-je faire tourner un bot Discord en IPv6 uniquement ?

Non — discord.com et la passerelle Discord n'avaient pas d'adresse IPv6 lors de notre vérification. Un bot Telegram, en revanche, fonctionne : api.telegram.org répond en IPv6.

Pourquoi les serveurs IPv6 uniquement sont-ils moins chers ?

Les adresses IPv4 sont rares et coûtent de l'argent aux hébergeurs chaque mois, alors que les adresses IPv6 sont pratiquement gratuites. Une offre IPv6 uniquement vous répercute cette économie — au prix de tout casser ce qui ne parle qu'IPv4.

Comment vérifier si un service supporte l'IPv6 ?

Lancez 'dig +short AAAA hostname'. Aucune sortie signifie aucune adresse IPv6. Sur une machine double pile, 'curl -6 -sI https://hostname' confirme qu'il répond réellement en IPv6.

EQVPS vend-il des offres IPv6 uniquement ?

Non. Toutes les offres EQVPS accèdent à Internet en IPv4 : les offres NAT sortent par NAT et vous y accédez via un port SSH personnel, et les offres avec IP dédiée ont leur propre IPv4 publique. Les offres NAT commencent à 3 $/mois, ce qui couvre le besoin économique sans les maux de tête de l'IPv6 uniquement.

VPS IPv6 uniquement : ce qui marche et ce qui casse en 2026

Les serveurs IPv6 uniquement sont bon marché pour une raison simple : les adresses IPv4 sont rares et coûtent de l'argent chaque mois, les adresses IPv6 non. La question n'est donc pas de savoir si l'IPv6 uniquement est moins cher — il l'est — mais si ce que vous utilisez vraiment fonctionne encore. Nous avons vérifié en septembre 2026 au lieu de répéter des réponses de forum vieilles d'un an.

Ce que nous avons testé, et le résultat

Nous avons consulté les enregistrements IPv6 (AAAA) des services qu'un serveur typique contacte dès le premier jour. Pas d'enregistrement AAAA, et une machine IPv6 uniquement ne peut pas les joindre sans aide.

Service	IPv6 au 26/09/2026
github.com, api.github.com	❌ non
objects.githubusercontent.com (téléchargement des versions)	❌ non
ghcr.io (registre de conteneurs de GitHub)	❌ non
raw.githubusercontent.com	✅ oui
Docker Hub (registry-1.docker.io)	✅ oui
PyPI, npm, crates.io, proxy de modules Go	✅ oui
Miroirs de paquets Debian / Ubuntu / Alpine	✅ oui
GitLab	✅ oui
Let's Encrypt (ACME)	✅ oui
API Telegram Bot	✅ oui
discord.com et la passerelle Discord	❌ non
API OpenAI, Anthropic, Google Gemini	✅ oui
Hugging Face (site)	✅ oui — mais son CDN pour gros fichiers : ❌ non
ollama.com	❌ non (registry.ollama.ai : ✅ oui)
API Binance	❌ non
API Coinbase	✅ oui

La tendance : les gestionnaires de paquets, les grandes API d'IA et Telegram sont prêts. GitHub — le service dont presque chaque serveur a besoin — ne l'est toujours pas.

Ce que cela signifie en pratique

Sur un VPS IPv6 uniquement, vous buterez précisément ici :

git clone https://github.com/... échoue. Tout comme les scripts d'installation qui récupèrent une version sur GitHub, et tout ce qui tire des images de ghcr.io.
Les bots Discord ne peuvent pas du tout se connecter à la passerelle.
Certains téléchargements de modèles cassent : le CDN de gros fichiers de Hugging Face et ollama.com n'avaient pas d'IPv6 lors de notre vérification.
Les bots crypto sur des plateformes IPv4 uniquement ne peuvent pas joindre l'API.

Et un problème plus discret côté entrée : les visiteurs sur des réseaux IPv4 uniquement ne peuvent pas atteindre un site hébergé sur un serveur IPv6 uniquement, sauf si vous placez devant un proxy ou un CDN disposant de l'IPv4.

Tester n'importe quel service en deux secondes

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

Passez tout ce avec quoi votre projet communique à la moulinette avant de choisir une offre.

Les contournements, et leur coût

NAT64/DNS64. Une passerelle traduit les requêtes IPv6 vers des destinations IPv4. Il en existe de publiques, mais votre trafic passe alors par la machine de quelqu'un d'autre et vous dépendez de sa disponibilité.
Miroirs et proxys. Miroitez vos dépôts GitHub sur GitLab, poussez vos images sur Docker Hub, faites tourner un petit proxy sur une machine double pile. Faisable, mais c'est de la tuyauterie à entretenir.
Un CDN devant pour le trafic web entrant, afin que les visiteurs en IPv4 puissent vous joindre.

Chaque solution, prise seule, est acceptable. Ensemble, elles avalent les quelques dollars qu'une offre IPv6 uniquement vous faisait économiser.

Quand vous avez vraiment besoin d'IPv4 — et de quel type

Pour la plupart des projets, la réponse honnête est : il vous faut la connectivité IPv4, mais pas forcément votre propre adresse IPv4.

Si rien ne doit se connecter vers votre serveur — bots, agents, workers, tâches planifiées —, une offre NAT suffit. Elle atteint tous les services, y compris ceux qui ne parlent qu'IPv4, via le NAT, et vous y accédez par un port SSH personnel. C'est l'option économique : offres NAT dès 3 $/mois.
Si quelque chose doit se connecter vers l'intérieur — un site web, un serveur mail, un serveur de jeu, un point d'accès VPN —, prenez une offre avec IPv4 dédiée.

Nous ne vendons pas d'offres IPv6 uniquement précisément pour les raisons du tableau : à 3 $ par mois pour du NAT avec accès complet à l'IPv4, l'économie ne vaut pas un serveur incapable de cloner depuis GitHub. Vous ne savez toujours pas lequel des deux il vous faut ? Voici le test en une question.