O GitHub funciona num servidor só IPv6?

Não diretamente. Na nossa verificação de setembro de 2026, github.com, api.github.com, objects.githubusercontent.com (downloads de releases) e ghcr.io não publicam endereços IPv6, então git clone, a API e o pull de containers do GitHub falham. O raw.githubusercontent.com tem IPv6.

Posso rodar um bot de Discord só com IPv6?

Não: discord.com e o gateway do Discord não tinham endereços IPv6 na nossa verificação. Um bot de Telegram funciona: api.telegram.org responde via IPv6.

Por que servidores só IPv6 são mais baratos?

Endereços IPv4 são escassos e custam dinheiro de verdade aos provedores todo mês; endereços IPv6 são praticamente de graça. Um plano só IPv6 repassa essa economia, ao custo de quebrar tudo que só fala IPv4.

Como verifico se um serviço suporta IPv6?

Rode 'dig +short AAAA hostname'. Sem saída significa sem endereço IPv6. Numa máquina dual-stack, 'curl -6 -sI https://hostname' confirma que ele realmente responde via IPv6.

A EQVPS vende planos só IPv6?

Não. Todo plano da EQVPS acessa a internet via IPv4: os planos NAT saem através de NAT e você os acessa por uma porta SSH pessoal, e os planos dedicados têm o seu próprio IPv4 público. Os planos NAT começam em $3/mês, o que cobre o caso de uso econômico sem as dores de cabeça do só IPv6.

VPS só IPv6: o que funciona e o que quebra em 2026

Servidores só IPv6 são baratos por um motivo simples: endereços IPv4 são escassos e custam dinheiro todo mês, e os IPv6 não. Então a pergunta não é se o só IPv6 é mais barato (é), mas se as coisas que você realmente usa ainda funcionam. Verificamos em setembro de 2026 em vez de repetir respostas de fórum de um ano atrás.

O que testamos, e o resultado

Consultamos os registros IPv6 (AAAA) dos serviços que um servidor típico usa já no primeiro dia. Sem registro AAAA, uma máquina só IPv6 não consegue alcançá-los sem ajuda.

Serviço	IPv6 em 26 set 2026
github.com, api.github.com	❌ não
objects.githubusercontent.com (downloads de releases)	❌ não
ghcr.io (registro de containers do GitHub)	❌ não
raw.githubusercontent.com	✅ sim
Docker Hub (registry-1.docker.io)	✅ sim
PyPI, npm, crates.io, proxy de módulos Go	✅ sim
Espelhos de pacotes Debian / Ubuntu / Alpine	✅ sim
GitLab	✅ sim
Let's Encrypt (ACME)	✅ sim
Telegram Bot API	✅ sim
discord.com e o gateway do Discord	❌ não
APIs da OpenAI, Anthropic, Google Gemini	✅ sim
Hugging Face (site)	✅ sim, mas o host de CDN para arquivos grandes: ❌ não
ollama.com	❌ não (registry.ollama.ai: ✅ sim)
API da Binance	❌ não
API da Coinbase	✅ sim

O padrão: gerenciadores de pacotes, as grandes APIs de IA e o Telegram estão prontos. O GitHub, o serviço de que quase todo servidor precisa, ainda não.

O que isso significa na prática

Num VPS só IPv6 você vai bater na parede exatamente nestes pontos:

git clone https://github.com/... falha. Assim como scripts de instalação que baixam uma release do GitHub com curl e tudo que puxa imagens do ghcr.io.
Bots de Discord não conseguem se conectar ao gateway de jeito nenhum.
Alguns downloads de modelos quebram: o host de arquivos grandes do Hugging Face e o ollama.com não tinham IPv6 na nossa verificação.
Bots de cripto em exchanges só IPv4 não alcançam a API.

E um mais silencioso, do lado de entrada: visitantes em redes só IPv4 não conseguem acessar um site hospedado num servidor só IPv6, a menos que você coloque na frente um proxy ou uma CDN com IPv4.

Teste qualquer serviço em dois 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

Rode isso contra tudo com que o seu projeto conversa antes de escolher um plano.

Contornos, e quanto custam

NAT64/DNS64. Um gateway traduz requisições IPv6 para destinos IPv4. Existem gateways públicos, mas você passa o seu tráfego pela máquina de outra pessoa e depende do uptime dela.
Espelhos e proxies. Espelhe os seus repositórios do GitHub no GitLab, publique imagens no Docker Hub, rode um proxy pequeno numa máquina dual-stack. Funciona, mas é encanamento que você precisa manter vivo.
Uma CDN na frente para o tráfego web de entrada, para que visitantes IPv4 consigam chegar até você.

Cada contorno sozinho é tranquilo. Juntos, eles comem os poucos dólares que o plano só IPv6 economizava.

Quando você realmente precisa de IPv4, e de qual tipo

Para a maioria dos projetos, a resposta honesta é: você quer conectividade IPv4, mas não necessariamente um endereço IPv4 só seu.

Se nada precisa se conectar ao seu servidor (bots, agentes, workers, cron jobs), um plano NAT basta. Ele alcança qualquer serviço, inclusive os só IPv4, através de NAT, e você entra por uma porta SSH pessoal. É a opção econômica: planos NAT a partir de $3/mês.
Se algo precisa se conectar de fora para dentro (um site, um servidor de e-mail, um servidor de jogos, um endpoint de VPN), escolha um plano com IPv4 dedicado.

Não vendemos planos só IPv6 exatamente pelos motivos da tabela acima: a $3 por mês por um NAT com alcance IPv4 completo, a economia não compensa um servidor que não consegue clonar do GitHub. Ainda em dúvida sobre qual dos dois você precisa? Aqui está o teste de uma pergunta só.