Los servidores solo IPv6 son baratos por una razón sencilla: las direcciones IPv4 escasean y cuestan dinero cada mes, las IPv6 no. Así que la pregunta no es si el solo IPv6 es más barato (lo es), sino si lo que usas de verdad sigue funcionando. Lo comprobamos en septiembre de 2026 en lugar de repetir respuestas de foros de hace un año.
Qué probamos y qué salió
Consultamos los registros IPv6 (AAAA) de los servicios que un servidor típico usa el primer día. Sin registro AAAA, una máquina solo IPv6 no puede llegar sin ayuda.
| Servicio | IPv6 a 26/09/2026 |
|---|---|
| github.com, api.github.com | ❌ no |
| objects.githubusercontent.com (descargas de versiones) | ❌ no |
| ghcr.io (registro de contenedores de GitHub) | ❌ no |
| raw.githubusercontent.com | ✅ sí |
| Docker Hub (registry-1.docker.io) | ✅ sí |
| PyPI, npm, crates.io, proxy de módulos de Go | ✅ sí |
| Espejos de paquetes de Debian / Ubuntu / Alpine | ✅ sí |
| GitLab | ✅ sí |
| Let's Encrypt (ACME) | ✅ sí |
| API de bots de Telegram | ✅ sí |
| discord.com y la pasarela de Discord | ❌ no |
| APIs de OpenAI, Anthropic, Google Gemini | ✅ sí |
| Hugging Face (web) | ✅ sí, pero su CDN de archivos grandes: ❌ no |
| ollama.com | ❌ no (registry.ollama.ai: ✅ sí) |
| API de Binance | ❌ no |
| API de Coinbase | ✅ sí |
El patrón: los gestores de paquetes, las grandes APIs de IA y Telegram están listos. GitHub, el servicio que necesita casi cualquier servidor, todavía no.
Qué significa en la práctica
En un VPS solo IPv6 te toparás justo aquí:
git clone https://github.com/...falla. También los scripts de instalación que descargan una versión de GitHub y todo lo que tire imágenes deghcr.io.- Los bots de Discord no pueden conectarse a la pasarela en absoluto.
- Algunas descargas de modelos fallan: la CDN de archivos grandes de Hugging Face y ollama.com no tenían IPv6 en nuestra comprobación.
- Los bots cripto en exchanges solo IPv4 no llegan a la API.
Y un problema más discreto en la entrada: los visitantes desde redes solo IPv4 no pueden abrir un sitio alojado en un servidor solo IPv6, salvo que pongas delante un proxy o una CDN con IPv4.
Prueba cualquier servicio en dos segundos
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
Pásalo por todo aquello con lo que habla tu proyecto antes de elegir plan.
Las soluciones y lo que cuestan
- NAT64/DNS64. Una pasarela traduce las peticiones IPv6 a destinos IPv4. Las hay públicas, pero tu tráfico pasa por la máquina de otro y dependes de su disponibilidad.
- Espejos y proxies. Replica tus repositorios de GitHub en GitLab, sube las imágenes a Docker Hub, pon un proxy pequeño en una máquina de doble pila. Funciona, pero es fontanería que tienes que mantener viva.
- Una CDN delante para el tráfico web entrante, para que los visitantes con IPv4 te alcancen.
Cada solución por separado está bien. Juntas se comen los pocos dólares que ahorraba el plan solo IPv6.
Cuándo necesitas IPv4 de verdad, y de qué tipo
Para la mayoría de proyectos la respuesta honesta es: necesitas conectividad IPv4, pero no necesariamente tu propia dirección IPv4.
- Si nada tiene que conectarse a tu servidor (bots, agentes, workers, tareas programadas), basta con un plan NAT. Llega a cualquier servicio, incluidos los que solo hablan IPv4, a través de NAT, y tú entras por un puerto SSH personal. Es la opción económica: planes NAT desde $3/mes.
- Si algo tiene que conectarse hacia dentro (una web, un servidor de correo, un servidor de juegos, un punto de acceso VPN), elige un plan con IPv4 dedicada.
No vendemos planes solo IPv6 justo por los motivos de la tabla: con NAT y acceso IPv4 completo por $3 al mes, el ahorro no compensa un servidor que no puede clonar desde GitHub. ¿Aún no sabes cuál de los dos necesitas? Aquí tienes la prueba de una sola pregunta.
Comentarios
Aún no hay comentarios. Sé el primero.