A Starlink serve para homelab? Um veredito de cinco testes
Na única conexão Starlink doméstica testada, pacotes de 1500 bytes passaram em IPv4 e IPv6 em outubro de 2026, e o tempo de ida e volta (RTT) por IPv4 teve picos em quatro segundos fixos de cada minuto em um de dois testes de uma hora, com 901 de 143.462 pings perdidos nos dois; as formas de contornar o NAT de nível de operadora (CGNAT), como um túnel que começa dentro da sua rede, não foram testadas aqui. Mas não para servir a internet diretamente por IPv4 sem um endereço IPv4 público: de uma VPS, em outubro de 2026, nenhuma de 8 portas respondeu no endereço IPv4 público dessa conexão, e um rastreamento feito de dentro é compatível com CGNAT sem provar que seja; com CGNAT, um port forwarding (redirecionamento de portas) no seu próprio roteador não consegue receber essas conexões. Cada resultado vem de uma conexão doméstica, atrás do próprio roteador de casa, em outubro de 2026; o IPv6 de entrada também não foi testado aqui.
O que um homelab precisa e o que os testes encontraram
Cada resultado abaixo vem de um dos três guias do site, que trazem os comandos, a saída e os limites completos.
| O que um homelab precisa | O que foi testado | Resultado | Até onde vão os dados | Guia |
|---|---|---|---|---|
| Alcançar um servidor em casa a partir da internet por IPv4 | De uma VPS, uma conexão TCP com cada uma de 8 portas no endereço IPv4 público da conexão de casa, 6 segundos cada, sem port forwarding configurado | nenhuma respondeu | não mostra onde as conexões pararam | De fora |
| Saber se o endereço IPv4 público é compartilhado (CGNAT) | um rastreamento da rota de saída a partir de um computador na rede de casa | um endereço privado na rede da Starlink veio antes do primeiro público | o segundo salto não respondeu, então é compatível com CGNAT e não o prova | O rastreamento |
| Abrir conexões de saída nas portas de e-mail e de compartilhamento de arquivos | TCP de saída por IPv4 até um servidor público de teste de portas, tempo limite de 10 segundos | 25 e 445 esgotaram o tempo; 465, 587, 80 e 8080 conectaram | não se sabe onde 25 e 445 foram descartadas | Portas de saída |
| Levar os pacotes de um túnel | pings de 1500 bytes com don't fragment ligado até três hosts de teste públicos, em IPv4 e IPv6 | todos os pings chegaram ao host e voltaram | nada maior pôde ser testado; nenhum túnel rodou | MTU do caminho |
| Uma conexão estável para acesso remoto | pings, cinco por segundo, para dois resolvedores de DNS públicos por família de endereços, duas sessões de uma hora | o IPv4 teve picos aos 12, 27, 42 e 57 segundos de cada minuto em uma sessão; 901 de 143.462 pings perdidos nas duas | leituras em milissegundos inteiros, duas horas numa conexão | Picos de ping |
| Alcançar um servidor em casa por IPv6 | não testado | Ainda não testado |
De fora, nada respondeu no endereço IPv4 público
Em outubro de 2026, um script numa VPS tentou uma conexão TCP com cada uma de 8 portas no endereço IPv4 público da conexão de casa, entre elas 22, 80 e 443, e esperou 6 segundos por cada uma. Nenhuma respondeu. Antes disso, o script se testou contra alvos com respostas conhecidas, e nenhum port forwarding foi configurado para o teste.
De dentro, um rastreamento a partir de um computador na rede de casa passou por um endereço privado na rede da Starlink antes do primeiro público. Isso é compatível com NAT de nível de operadora (CGNAT), que a RFC 6888 descreve como uma função na rede do provedor que compartilha um endereço IPv4 entre vários assinantes (seção 2, verificada em outubro de 2026). O segundo salto não respondeu, então o rastreamento não prova isso.
Os assinantes têm “limited or no control” (em tradução nossa, controle limitado ou nenhum) sobre um NAT de nível de operadora, diz a RFC, então, com CGNAT, um port forwarding no seu próprio roteador não consegue receber conexões enviadas ao endereço IPv4 público. Mas não se sabe onde as conexões do teste de fora pararam, e o CGNAT e um roteador de casa que descarta conexões que ninguém de dentro pediu pareceriam iguais vistos da VPS. A página 1 traz o teste de fora e o rastreamento completos.
As portas de saída 25 e 445 esgotaram o tempo
A partir de um computador na rede de casa, as conexões TCP por IPv4 até um servidor público montado para testes de portas esgotaram o tempo na porta 25 (SMTP) e na porta 445 (SMB), cada uma depois de 10,3 segundos. As portas 465 e 587, as de envio de e-mail, conectaram, e a 80 e a 8080 também.
Não se sabe onde as portas 25 e 445 foram descartadas: no roteador de casa, na rede da Starlink ou na própria rede do servidor de teste. O servidor de teste usa a porta 25 para um dos seus próprios serviços, então essa porta não é o mesmo teste que as outras. Os detalhes estão na seção de portas de saída da página 1.
Pacotes de 1500 bytes passaram em IPv4 e IPv6
Em duas leituras com poucos minutos de intervalo, em outubro de 2026, pings de 1500 bytes com don't fragment ligado foram de um computador ligado por cabo à rede de casa até três hosts de teste públicos e voltaram, em IPv4 e em IPv6, e nenhum salto informou uma MTU menor. Nada maior pôde ser testado, porque a própria MTU de enlace do computador é de 1500 bytes.
Nenhum túnel rodou. Um túnel acrescenta os próprios cabeçalhos a cada pacote: o driver do WireGuard no Linux conta 80 bytes deles e começa uma interface nova em 1420 bytes (device.c, Linux 6.18, verificado em outubro de 2026). A seção de túneis do guia de MTU do caminho traz essa conta e a do Tailscale, e nada disso foi testado nesta conexão.
Em uma de duas horas, o RTT por IPv4 teve picos em quatro segundos fixos
Pings saíram cinco vezes por segundo de um computador ligado por cabo à rede de casa para dois resolvedores de DNS públicos por família de endereços, uma hora de cada vez, em duas sessões em outubro de 2026. Na segunda sessão, o RTT por IPv4 mudou mais, e teve picos, aos 12, 27, 42 e 57 segundos de cada minuto. Na primeira sessão, e em IPv6, a regra do teste não encontrou esse padrão.
De 143.462 pings nas duas sessões, 901 ficaram sem resposta. Os enviados nos quatro segundos se perderam com uma frequência 1,9 vezes a dos enviados nos outros segundos.
Pesquisadores que mediram a Starlink a partir de vários locais relatam mudanças nos mesmos quatro segundos, e a explicação delas é deles; o guia de latência os cita. Os RTTs foram lidos em milissegundos inteiros, então um degrau de um ou dois milissegundos pode passar despercebido, e o teste cobre uma conexão em duas horas. Nenhum jogo, chamada ou área de trabalho remota foi testado.
Formas de contornar o CGNAT, não testadas aqui
As formas de contornar o CGNAT, cada uma pela sua própria documentação e nenhuma testada aqui, estão na página sobre deixar a internet fixa. A Acceptable Use Policy da Starlink para os EUA, a política de uso aceitável, na versão de outubro de 2026, não menciona rodar um servidor. Uma retransmissão TCP por uma VM na nuvem é testada na página do servidor de jogos.
As ofertas têm página própria
As ofertas da Starlink e o crédito de indicação de US$ 100 nos EUA estão na página de ofertas e créditos. A página sobre instalação diz se você mesmo pode instalar a Starlink, e a página sobre mudança de plano diz se você pode mudar de plano depois.
A página sobre apartamentos diz se dá para ter Starlink em apartamento.
O que estes testes não mostram
IPv6 de entrada. Nenhum teste tentou alcançar um servidor em casa por IPv6.
Qualquer forma de contornar o CGNAT, como um túnel que começa dentro da sua rede.
Velocidade de upload e uso de dados.
Clima, quedas de energia e disponibilidade ao longo de semanas.
Outras conexões, outros roteadores e o modo bypass do roteador da Starlink.
Fontes
- RFC 6888: Common Requirements for Carrier-Grade NATs (CGNs), IETF, acessado em
- Cloudflare Tunnel, Cloudflare, acessado em
- Acceptable Use Policy (US), Starlink, acessado em
- drivers/net/wireguard/device.c, Linux 6.18, Linux kernel, acessado em
- A Starlink tem um programa de indicação?, Starlink, acessado em
Registro de testes
Guias relacionados
- Dá para hospedar um servidor na Starlink sem IPv4 público?
Não diretamente por IPv4: sem um endereço IPv4 público, as conexões vindas da internet chegam ao NAT do seu provedor, e um port forwarding (redirecionamento de portas) no seu próprio roteador não alcança esse NAT.
- Tamanho da MTU da Starlink: MTU do caminho medida em 1500 bytes
A MTU do caminho a partir de uma conexão Starlink doméstica foi de 1500 bytes tanto em IPv4 quanto em IPv6, em todos os caminhos testados.
- Picos de ping na Starlink: latência segundo a segundo em casa
Em uma de duas sessões de uma hora, o tempo de ida e volta (RTT) por IPv4 mudou mais, e teve picos, aos 12, 27, 42 e 57 segundos de cada minuto; na outra sessão, e em IPv6, a regra do teste não encontrou esse padrão.