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. Um rastreamento feito de casa em outubro de 2026 passou por um endereço privado dentro da rede da Starlink antes de qualquer endereço público, o que é compatível com NAT de nível de operadora (CGNAT), mas não prova que seja: o segundo salto, o que mostraria isso diretamente, não respondeu.
Um endereço privado dentro da rede da Starlink aparece antes do primeiro endereço público
Este rastreamento foi feito em outubro de 2026 a partir de um computador na rede de casa. Foi a segunda de duas execuções no mesmo dia, e o segundo salto ficou em silêncio nas duas.
tracepath -n -m 8 1.1.1.1A saída, redigitada com um rótulo no lugar de cada endereço (os rótulos ficam em inglês):
1?: [LOCALHOST] pmtu 1500
1: home router 1.998ms
1: home router 1.792ms
2: no reply
3: private address (RFC 1918), Starlink's side 34.218ms
4: public address, SpaceX (AS14593) 35.767ms (router returned corrupted payload) asymm 7
5: public address, SpaceX (AS14593) 36.125ms
6: public address, owner not checked 35.623ms asymm 7
7: public address, Cloudflare 44.837ms
8: public address, Cloudflare 36.379ms asymm 9
Too many hops: pmtu 1500O salto 1 é o roteador de casa. O salto 2 não devolveu nada. O salto 3 é um endereço privado dentro da rede da Starlink, e o primeiro endereço público é o salto 4, na rede da SpaceX.
A RFC 1918 reserva blocos de endereços privados para uso dentro de uma rede. Esses endereços “have no global meaning” (em tradução nossa, não têm significado global), e as rotas para eles não devem passar de uma rede para outra (seção 3, verificada em outubro de 2026). O salto 3 só tem significado dentro da rede da Starlink. Um salto privado antes do primeiro público é como o CGNAT aparece visto de dentro de casa.
A RFC 6598 reserva 100.64.0.0/10 como “Shared Address Space” (espaço de endereços compartilhado) para o NAT de nível de operadora, e espera que os provedores numerem a partir desse bloco os enlaces entre os seus dispositivos de NAT de nível de operadora e os equipamentos nas instalações dos clientes (resumo e seções 1 e 7, verificados em outubro de 2026). Se o roteador de casa for o equipamento nesse enlace, um endereço desse bloco apareceria no salto logo depois dele. Esse é o salto 2, o que não respondeu.
Com CGNAT, um port forwarding só no seu roteador não consegue receber conexões enviadas ao endereço IPv4 público. A RFC 6888 descreve um NAT de nível de operadora como uma função na rede do provedor que compartilha um endereço IPv4 entre vários assinantes. Os assinantes têm “limited or no control” (controle limitado ou nenhum) sobre ele, enquanto “typically have full control” (normalmente têm controle total) sobre um NAT nas suas próprias instalações (seção 2, verificada em outubro de 2026). Um port forwarding é uma configuração desse segundo tipo de NAT.
Limitação
O rastreamento deixa duas perguntas em aberto.
- Com o salto 2 em silêncio, ele não consegue mostrar se o endereço do salto 2 vem de 100.64.0.0/10.
- Também não consegue mostrar se o próprio roteador de casa tem o endereço público: a RFC 1918 cita as interfaces de roteadores dentro de uma rede como um dos usos de endereços privados, e descreve um projeto que os usa “for all internal links” (em todos os enlaces internos; seções 2 e 5). Um provedor pode numerar os próprios enlaces internos com endereços privados sem fazer NAT nenhum, então um salto 3 privado não prova CGNAT sozinho.
De uma VPS, nenhuma de 8 portas respondeu no endereço IPv4 público
Acompanhei este teste em outubro de 2026; ele rodou de uma VPS, um servidor na nuvem, e não do meu próprio hardware. Um script na 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 deu 6 segundos para cada uma responder. Nenhum port forwarding foi configurado para este teste. Antes das portas de casa, o script se testou contra alvos com respostas conhecidas.
| Alvo | O que verifica | Resultado |
|---|---|---|
| O endereço da própria VPS, porta 443 | a sonda vê uma porta aberta como aberta | conectou |
| O endereço da própria VPS, porta 80 | o mesmo, numa segunda porta | conectou |
| Um resolvedor público conhecido, porta 443 | a VPS alcança outra rede | conectou |
| O endereço da própria VPS, porta 9, sem nada escutando | uma porta vazia não aparece como aberta | sem resposta em até 6 s |
| O endereço IPv4 público da conexão de casa, cada uma das 8 portas | o próprio teste | sem resposta em até 6 s |
A execução levou 56 segundos. A porta vazia e as 8 portas de casa, nove sondagens ao todo, esperaram cada uma os 6 segundos inteiros: 54 dos 56. Cada “sem resposta” foi uma espera real, e não a ferramenta falhando rápido.
Limitação
A execução não mostra onde as conexões pararam, então não consegue distinguir o CGNAT de um roteador de casa que tenha o endereço público e descarte conexões que ninguém de dentro pediu. Com CGNAT, o endereço é compartilhado: a RFC 6888 descreve um NAT de nível de operadora como algo que compartilha um endereço IPv4 entre vários assinantes (seção 2, verificada em outubro de 2026), então a falta de resposta é o resultado esperado, e a execução não diz nada sobre o roteador de casa. Ela também nunca recebeu uma recusa. A porta vazia na VPS esgotou o tempo em vez de recusar, então o que a execução mostra é que nada respondeu em até 6 s.
A porta 25 esgotou o tempo; a 587 conectou
Em outubro de 2026, um computador na rede de casa tentou conexões TCP por IPv4 com o portquiz.net, um servidor público montado para testes de portas. A página inicial dele diz que ele “listens on all TCP ports, allowing you to test any outbound TCP port” (escuta em todas as portas TCP, permitindo testar qualquer porta TCP de saída; verificada em outubro de 2026). Cada conexão tinha um tempo limite de 10 segundos. A varredura usou o /dev/tcp do bash, e as portas 25 e 445 foram testadas de novo com o socket.create_connection do Python e timeout=10.
| Porta | Resultado |
|---|---|
| 25 (SMTP) | esgotou o tempo após 10,3 s |
| 445 (SMB) | esgotou o tempo após 10,3 s |
| 465 (SMTPS) | conectou |
| 587 (envio de e-mail) | conectou |
| 80 | conectou |
| 8080 | conectou |
As duas portas de envio de e-mail, 465 e 587, conectaram. A porta 25 e a porta 445, não.
Limitação
O teste não mostra onde as portas 25 e 445 foram descartadas: no roteador de casa, na rede da Starlink ou na própria rede do portquiz.net. A porta 25 também não é o mesmo teste que as outras: a mesma página inicial diz que o portquiz.net usa algumas portas para serviços reais, e cita a 22 e a 25. O teste rodou só por IPv4; o portquiz.net não tem endereço IPv6.
Ainda não testado
- Por que o salto 2 não responde. Um rastreamento em que ele responda mostraria o que fica logo depois do roteador de casa, e um endereço de 100.64.0.0/10 ali é justamente o uso para o qual a RFC 6598 reserva esse bloco.
- Onde as portas 25 e 445 são descartadas. Isso exige o mesmo teste a partir de outra rede.
- IPv6 de entrada. Nada nesta página mostra se uma conexão por IPv6 consegue chegar a um servidor em casa.
A página de ajuda da Starlink What IP address does Starlink provide? descreve a política padrão de IPv4 dela em termos gerais: a configuração IPv4 padrão “uses Carrier-Grade Network Address Translation (CGNAT) using private address space from the 100.64.0.0/10 prefix” (usa NAT de nível de operadora, o CGNAT, com espaço de endereços privado do prefixo 100.64.0.0/10), e essa política “does not allow inbound traffic” (não permite tráfego de entrada). A mesma página diz que os clientes que precisam de tráfego de entrada “should consider using a third-party router, and if IPv4 inbound traffic is needed, a Starlink service plan with the public IPv4 option” (devem considerar usar um roteador de terceiros e, se for preciso tráfego IPv4 de entrada, um plano de serviço da Starlink com a opção de IPv4 público), que é uma opção dos planos Priority (verificada em outubro de 2026). Isso é o que a Starlink afirma sobre o serviço dela, não um resultado do rastreamento desta página, e esta página não testa nenhum dos dois caminhos. O que cada caminho envolve está na página sobre deixar a internet fixa.
Uma forma de contornar a falta de um endereço IPv4 público é uma conexão que começa dentro da sua rede. A documentação da Cloudflare sobre o Cloudflare Tunnel diz que o conector dele, o cloudflared, abre só conexões de saída para a rede da Cloudflare, então um servidor pode servir tráfego pela Cloudflare sem um endereço IP roteável publicamente (página atualizada pela última vez em agosto de 2026, verificada em outubro de 2026). Esta página não testa isso.
Veja o que esses resultados significam se você está escolhendo uma conexão para um homelab.
Fontes
- RFC 1918: Address Allocation for Private Internets, IETF, acessado em
- RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space, IETF, acessado em
- RFC 6888: Common Requirements for Carrier-Grade NATs (CGNs), IETF, acessado em
- Cloudflare Tunnel, Cloudflare, acessado em
- portquiz.net home page, portquiz.net, acessado em
- What IP address does Starlink provide?, Starlink, acessado em
- A Starlink tem um programa de indicação?, Starlink, acessado em
Registro de testes
- Teste De uma VPS, uma conexão TCP com cada uma de 8 portas no endereço IPv4 público da conexão de casa, com controles. Nenhuma respondeu em até 6 s.
- Teste Dois rastreamentos da rota de saída a partir de um computador na rede de casa, e conexões TCP de saída para o portquiz.net em seis portas.
Guias relacionados
- 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.
- Starlink plans and prices in the US, and why yours can differ (em inglês)
You can compare the monthly prices in Starlink's US broadband label files, read in October 2026: they price plans named Residential, at $120 a month, and Residential Lite, at $80, Roam at two prices, and Local and Global Priority as an access fee plus data blocks.
Todos os guias desta seção
- Servidor de jogos na Starlink com uma VPS grátis de retransmissão
Sim, para um jogo que usa TCP, como o Minecraft Java Edition: a página de ajuda da Starlink diz que a configuração IPv4 padrão dela usa NAT de nível de operadora (CGNAT) e “does not allow inbound traffic” (em tradução nossa, não permite tráfego de entrada; outubro de 2026), então os jogadores se conectam, em vez disso, a uma VM na nuvem com um endereço IPv4 público, e uma retransmissão nela passa cada conexão por uma tailnet até o servidor de jogos em casa.
- 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.
- 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.