Deixar a internet fixa: a Starlink dá IP público?

Sem um endereço IPv4 público no seu roteador, um port forwarding nele não basta

Se o seu roteador tem um endereço IPv4 público, um port forwarding (redirecionamento de portas) nele manda as conexões vindas da internet para uma máquina em casa. Se não tem, um dispositivo mais acima na rede que faz tradução de endereços de rede (NAT), seu ou do seu provedor, fica com esse endereço, e um port forwarding no seu roteador só chega à internet se esse NAT também redirecionar a porta. Onde o NAT de cima é o NAT de nível de operadora de um provedor, a RFC 6269 diz “If a CGN is present, the port must also be opened in the CGN. CGN makes subscribers dependent on their service provider for this functionality.” (Se houver um CGN, a porta também precisa ser aberta no CGN. O CGN deixa os assinantes dependentes do provedor de serviço para essa funcionalidade; seção 5.2.1, verificada em outubro de 2026.) A RFC 6888 acrescenta que os assinantes têm “limited or no control” (controle limitado ou nenhum) sobre um NAT de nível de operadora (seção 2, verificada em outubro de 2026).

A página 1 deste site, o guia sobre hospedar um servidor sem um endereço IPv4 público, testou uma conexão Starlink de casa. O rastreamento da rota de saída dela é compatível com CGNAT, mas não o prova, já que o segundo salto nunca respondeu. De um computador na rede de casa, conexões de saída por IPv4 na porta 25 esgotaram o tempo, e não se vê onde foram descartadas. A página 1 também testou portas de entrada a partir de uma VPS (servidor virtual privado), um servidor na nuvem.

A página de ajuda da própria Starlink What IP address does Starlink provide? diz “Starlink WiFi routers do not support port forwarding or firewall rules for IPv4 or IPv6.” (Os roteadores Wi-Fi da Starlink não têm suporte a port forwarding nem a regras de firewall para IPv4 ou IPv6.) A mesma página diz “Outbound ports TCP/25 (SMTP) and TCP/445 (SMB) are blocked for all customers per information security best practices.” (As portas de saída TCP/25, SMTP, e TCP/445, SMB, são bloqueadas para todos os clientes, segundo boas práticas de segurança da informação.) As duas linhas foram verificadas em outubro de 2026.

O que depende de um endereço IPv4 público em casa:

• um servidor ao qual outras pessoas se conectam, como um servidor de jogos, um site ou uma área de trabalho remota;
• um aplicativo que abre portas no roteador sozinho;
• um servidor de e-mail que recebe mensagens de outros servidores;
• qualquer coisa presa a um endereço que não muda, como uma lista de permissões (allowlist) ou um registro de DNS (abaixo).

Um aplicativo abre portas pedindo ao roteador nas suas instalações, o CPE nos termos da RFC 6269. Os roteadores domésticos abrem portas de entrada “either manually, or with a protocol such as” (seja manualmente, seja com um protocolo como o) UPnP IGD, diz a RFC, e, com um NAT de nível de operadora no caminho, “CPE and CGN will need to cooperate in order for port forwarding functionality to work” (o CPE e o CGN vão precisar cooperar para que o port forwarding funcione; seção 5.2.1). Um protocolo para isso, o Port Control Protocol (PCP), “allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall” (permite que um host IPv6 ou IPv4 controle como os pacotes IPv6 ou IPv4 que chegam são traduzidos e encaminhados por um tradutor de endereços de rede, o NAT, ou por um firewall simples; RFC 6887, resumo, verificada em outubro de 2026). O REQ-9 da RFC 6888 diz “A CGN MUST implement a protocol giving subscribers explicit control over NAT mappings. That protocol SHOULD be the Port Control Protocol” (um CGN DEVE implementar um protocolo que dê aos assinantes controle explícito sobre os mapeamentos de NAT. Esse protocolo DEVERIA ser o Port Control Protocol): um requisito para quem constrói um CGN, que não diz nada sobre o que um provedor específico usa.

Em outubro de 2026, a verificação de rede do Tailscale, tailscale netcheck, num computador da rede de casa não listou nenhum dos serviços de mapeamento de portas que ela procura (UPnP, NAT-PMP e PCP). A referência da CLI do Tailscale diz “If any fields are blank, it means Tailscale wasn't able to measure that network property” (se algum campo estiver em branco, o Tailscale não conseguiu medir essa propriedade da rede; validada pela última vez em julho de 2026, verificada em outubro de 2026), então um campo vazio não mostra que esse serviço não existe.

O e-mail entre servidores trafega pela porta 25. A RFC 6409 diz “Message relay is unaffected, and continues to use SMTP over port 25” (a retransmissão de mensagens não muda e continua usando SMTP pela porta 25), enquanto os programas de e-mail enviam as mensagens “normally over port 587” (normalmente pela porta 587; resumo, verificada em outubro de 2026). Um servidor de e-mail em casa recebe as mensagens dos outros servidores na porta 25.

Veja se o seu roteador tem um endereço IPv4 público hoje

O que a troca tira de você depende do que a sua conexão dá hoje, e o seu próprio roteador mostra isso.

1. Desligue qualquer rede virtual privada (VPN), proxy ou exit node no dispositivo que você usar para isso. Depois compare o endereço WAN ou de internet na página de status do seu roteador com o endereço IPv4 público que um serviço de consulta informa para a sua conexão. Se forem iguais, o roteador tem um endereço IPv4 público, e um port forwarding nele pode receber conexões.
2. Se forem diferentes, um NAT entre o seu roteador e a internet tem o endereço público, e o próprio endereço WAN do roteador diz de quem é. Dentro de 100.64.0.0/10, o bloco que a RFC 6598 reserva como espaço de endereços compartilhado para o NAT de nível de operadora, ele é do provedor. Dentro de 10.0.0.0/8, 172.16.0.0/12 ou 192.168.0.0/16, os blocos privados da RFC 1918, é outro NAT, um roteador seu ou do provedor. Nos dois casos, um port forwarding no seu roteador só chega à internet se esse NAT também redirecionar a porta, e “diferentes”, sozinho, não diz se ele redireciona.

Os dois passos se apoiam nas RFCs acima (verificadas em outubro de 2026); esta página não fez a comparação em nenhuma conexão.

Quem precisa acessar o servidor decide o substituto

Sem um endereço IPv4 público no seu roteador, um servidor em casa precisa de outra forma de entrada. Esta página descreve cinco a partir das páginas dos próprios fornecedores e não testa nenhuma.

Forma de entrada	Quem consegue acessar o servidor
A opção de IPv4 público da Starlink	Quem consegue acessar o servidorQualquer pessoa, nas portas que o seu próprio roteador redireciona
Uma VPS de retransmissão	Quem consegue acessar o servidorQualquer pessoa, nas portas que a VPS redireciona
Um túnel de saída (Cloudflare Tunnel)	Quem consegue acessar o servidorQualquer pessoa com um navegador, para um serviço web; para outros serviços, só os visitantes que rodam o cliente da Cloudflare
Uma VPN mesh (Tailscale ou Headscale)	Quem consegue acessar o servidorSó os dispositivos que você adiciona a ela
IPv6 de entrada, com o seu próprio roteador	Quem consegue acessar o servidorNão informado na página de ajuda da Starlink, que manda os clientes que precisam de tráfego de entrada para um roteador de terceiros

O que a Starlink diz que a opção de IPv4 público muda

A página de ajuda What IP address does Starlink provide? cita duas políticas de IPv4, “default” (padrão) e “public” (pública). A política “default”, diz ela, “does not allow inbound traffic” (não permite tráfego de entrada). Onde “IPv4 inbound traffic is needed” (é preciso tráfego IPv4 de entrada), ela aponta para “a Starlink service plan with the public IPv4 option” (um plano de serviço da Starlink com a opção de IPv4 público; verificada em outubro de 2026).

A página de ajuda da Starlink sobre definir um IP público diz “The ability to update the IP policy to a Public IP is only available to the Local and Global Priority service plans.” (A possibilidade de mudar a política de IP para um IP público só está disponível nos planos de serviço Local Priority e Global Priority; verificada em outubro de 2026.)

A página de ajuda da Starlink sobre indicações lista oito planos elegíveis, todos Residential ou Roam, e nenhum plano Priority (outubro de 2026); o texto em português dela chama essas famílias de Residencial, Viagem e Prioritário.

Esta página não testou a opção de IPv4 público.

Uma VPS de retransmissão, para um servidor que outras pessoas acessam

Uma VPS de retransmissão é uma VPS com IP público próprio que passa as conexões dos visitantes por um túnel até um servidor em casa. Esta página não testou nenhuma. A página do servidor de jogos testa uma: a retransmissão TCP de uma VM na nuvem do nível gratuito, para um servidor de Minecraft em casa numa conexão Starlink.

A conexão começa em casa: o servidor de casa mantém um túnel aberto até a VPS, por exemplo com o WireGuard. O Quick Start do WireGuard diz que um peer atrás de NAT “must keep the NAT/firewall mapping valid, by periodically sending keepalive packets” (precisa manter válido o mapeamento do NAT ou do firewall, enviando pacotes de keepalive periodicamente), que “A sensible interval that works with a wide variety of firewalls is 25 seconds” (um intervalo razoável, que funciona com uma grande variedade de firewalls, é de 25 segundos) e que isso permite ao peer “receive incoming connections long after network traffic has gone silent” (receber conexões de entrada muito depois que o tráfego de rede silenciou; seção “NAT and Firewall Traversal Persistence”, verificada em outubro de 2026). Na VPS, as portas que você escolher são redirecionadas pelo túnel, ou um proxy reverso repassa as requisições web: a diretiva reverse_proxy do Caddy “Proxies requests to one or more backends” (faz proxy das requisições para um ou mais backends; verificada em outubro de 2026).

Os visitantes se conectam ao IP público da VPS, e o seu provedor de VPS transporta o tráfego. O que a VPS redireciona fica aberto para a internet, então redirecione só a porta que você quer publicar.

Um túnel de saída, para serviços web

Um túnel de saída liga um servidor em casa à rede de um fornecedor a partir de dentro, e os visitantes chegam ao servidor por esse fornecedor. Nenhum foi testado para esta página.

A página da Cloudflare sobre o Cloudflare Tunnel diz que ele liga recursos à Cloudflare “without a publicly routable IP address” (sem um endereço IP roteável publicamente), que o conector dele, o cloudflared, “creates outbound-only connections” (cria só conexões de saída), e que ele pode ligar “HTTP web servers, SSH servers, remote desktops, and other protocols” (servidores web HTTP, servidores SSH, áreas de trabalho remotas e outros protocolos; página atualizada pela última vez em agosto de 2026, verificada em outubro de 2026). A página dela sobre protocolos para aplicações publicadas diz que uma rota de aplicação publicada instrui a Cloudflare “to proxy requests for your public hostname to a service running privately behind cloudflared” (a fazer proxy das requisições para o seu hostname público até um serviço que roda de forma privada atrás do cloudflared), e que “Non-HTTP services require installing cloudflared on the client for end users to connect” (serviços que não são HTTP exigem instalar o cloudflared no cliente para os usuários finais se conectarem): para TCP e SSH, os usuários finais rodam cloudflared access tcp ou cloudflared access ssh (verificada em outubro de 2026).

Então um visitante de um serviço web só precisa de um navegador. Para SSH, uma área de trabalho remota ou outro serviço que não seja HTTP, cada visitante precisa do cliente da Cloudflare. A rede da Cloudflare transporta o tráfego.

Uma VPN mesh, para os seus próprios dispositivos

Uma VPN mesh liga os seus próprios dispositivos entre si, então só os dispositivos que você adiciona conseguem acessar um servidor em casa, não os visitantes. Esta página também não testa nenhuma.

O Tailscale é uma. O Headscale se descreve como “an open source, self-hosted implementation of the Tailscale control server” (uma implementação de código aberto e auto-hospedada do servidor de controle do Tailscale), com escopo de “a single Tailscale network (tailnet), suitable for a personal use” (uma única rede Tailscale, a tailnet, adequada para uso pessoal; verificada em outubro de 2026); tailnet é a palavra do Tailscale para uma rede dessas. A página do Tailscale sobre tipos de conexão diz “All connections start as relayed through a DERP server” (todas as conexões começam retransmitidas por um servidor DERP), os servidores de retransmissão do Tailscale, e “In most environments, Tailscale successfully establishes direct connections, but some network configurations (hard NAT) can prevent this” (na maioria dos ambientes, o Tailscale consegue estabelecer conexões diretas, mas algumas configurações de rede, o hard NAT, podem impedir isso; validada pela última vez em junho de 2026, verificada em outubro de 2026). Quando não se forma um caminho direto, os servidores de retransmissão do Tailscale transportam o tráfego. O post de 2020 How NAT traversal works diz “you can't reconfigure the ISP's CGNAT” (você não consegue reconfigurar o CGNAT do provedor) e “Aside from the port mapping protocols, everything from our current bag of tricks works fine in a CGNAT world” (fora os protocolos de mapeamento de portas, tudo o que temos hoje no nosso saco de truques funciona bem num mundo com CGNAT; agosto de 2020, verificado em outubro de 2026).

A verificação do Tailscale na rede de casa, em outubro de 2026, também viu que o NAT na frente dela mantinha o mesmo mapeamento qualquer que fosse o destino (MappingVariesByDestIP: false). A referência da CLI do Tailscale contrapõe isso a “a difficult NAT that varies the device's IP address depending on the destination” (um NAT difícil, que varia o endereço IP do dispositivo conforme o destino). A verificação mostra o NAT no momento em que rodou, sem nenhuma conexão entre dois dispositivos para observar, então não mostra se um caminho direto se formaria.

O que a Starlink diz sobre IPv6

A página de ajuda da Starlink What IP address does Starlink provide? diz “Starlink supports native IPv6 across all Starlink routers, kit versions, and service plans.” (A Starlink tem suporte a IPv6 nativo em todos os roteadores Starlink, versões de kit e planos de serviço.) Ela também diz “Each Starlink is allocated one IPv4 address via DHCPv4 and a delegated /56 IPv6 prefix via DHCPv6-PD.” (Cada Starlink recebe um endereço IPv4 por DHCPv4 e um prefixo IPv6 /56 delegado por DHCPv6-PD.) Sobre o tráfego de entrada: “Customers needing inbound traffic should consider using a third-party router, and if IPv4 inbound traffic is needed, a Starlink service plan with the public IPv4 option.” (Os clientes que precisam de tráfego de entrada 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.) A nota dela sobre port forwarding, citada acima, cita o IPv6 além do IPv4. E, como afirmação geral, ela diz “As Starlink continues to expand and upgrades its global internet service, users may experience changes such as publicly routable addresses and non-CGNAT configurations.” (À medida que a Starlink continua a se expandir e melhora o seu serviço global de internet, os usuários podem ver mudanças como endereços roteáveis publicamente e configurações sem CGNAT.) Tudo isso foi verificado em outubro de 2026.

São afirmações da Starlink, e esta página não testa nenhuma delas. Esta página não mostra se uma conexão por IPv6 chega a um servidor em casa.

O que a página de ajuda da Starlink diz sobre IP fixo

Na página de ajuda da Starlink What IP address does Starlink provide?, o parágrafo sobre a opção de IPv4 público diz “Although truly static IPs are not available, a reservation system retains the public IPv4 address and IPv6 prefix even when the system is off or rebooted. However, relocating the Starlink or software updates may change these addresses.” (Embora IPs realmente fixos não estejam disponíveis, um sistema de reserva mantém o endereço IPv4 público e o prefixo IPv6 mesmo quando o sistema é desligado ou reiniciado. Porém, mudar a Starlink de lugar ou atualizações de software podem mudar esses endereços; verificada em outubro de 2026.)

Um endereço que muda quebra o que estiver preso a ele: uma lista de permissões, um registro de DNS, um cliente remoto configurado para um endereço. Com um substituto, os visitantes usam algo que não muda com o endereço da casa. Por uma VPS de retransmissão, é o IP público da VPS; a página inicial do WireGuard diz “the server discovers the endpoint of its peers by examining from where correctly authenticated data originates” (o servidor descobre o endpoint dos seus peers examinando de onde vêm os dados corretamente autenticados) e “Thus, there is full IP roaming on both ends” (assim, há roaming completo de IP nas duas pontas; verificada em outubro de 2026), o que esta página não testou. Pelo Cloudflare Tunnel, é o hostname público que a Cloudflare encaminha para o seu serviço.

O DNS dinâmico mantém um nome apontado para um endereço que muda. Sem um endereço IPv4 público no seu roteador, o único endereço IPv4 público para o qual esse nome pode apontar é o do NAT de cima, que só passa uma conexão adiante se redirecionar a porta (RFC 6269, seção 5.2.1, para um NAT de nível de operadora).

O que a Acceptable Use Policy da Starlink diz sobre servidores

A Acceptable Use Policy da Starlink, a política de uso aceitável, na versão de outubro de 2026, não menciona rodar um servidor. Ela também não menciona hospedagem nem conexões de entrada.

A política lista 13 exemplos de violações. O último é “any conduct that SpaceX, in its discretion, reasonably determines to be a misuse of the Services or Starlink Kit” (qualquer conduta que a SpaceX, a critério dela, determine razoavelmente ser um mau uso dos Serviços ou do Starlink Kit), o que deixa essa decisão com a SpaceX. Sob “EXCESSIVE USE OF NETWORK RESOURCES” (uso excessivo de recursos de rede), ela diz “SpaceX reserves the right to engage in reasonable network management to protect the overall network” (a SpaceX se reserva o direito de fazer um gerenciamento de rede razoável para proteger a rede como um todo).

Manter a conexão que você tem, ou trocar com um plano

A sua verificação decide qual é o seu caso.

1. Se o passo 1 não mostrou endereço IPv4 público no seu roteador e o passo 2 aponta para o NAT do seu provedor, hoje um port forwarding no seu roteador só chega à internet onde esse NAT também redireciona a porta (RFC 6269, seção 5.2.1). Sem esse redirecionamento por parte do provedor, você não tem port forwarding de entrada por IPv4 hoje, e a troca não tira isso de você. Se o passo 2 aponta para um roteador seu mais acima, verifique esse roteador primeiro.
2. Se só os seus próprios dispositivos precisam acessar os seus serviços, esse é o caso da VPN mesh. A documentação do Tailscale o descreve, e esta página não o testou.
3. Se outras pessoas precisam acessar um servidor em casa, planeje o substituto antes de trocar: uma VPS de retransmissão ou um túnel de saída, pela documentação deles e não testados aqui, ou a opção de IPv4 público de um plano Priority, pelas páginas de ajuda da Starlink.
4. Se você roda em casa um servidor de e-mail que envia mensagens direto para outros servidores, mantenha a conexão em que ele roda. O e-mail entre servidores usa a porta 25 (RFC 6409), e a página de ajuda da Starlink diz que a TCP/25 de saída é “blocked for all customers” (bloqueada para todos os clientes). No teste da página 1, conexões de saída por IPv4 na porta 25 esgotaram o tempo a partir de um computador na rede de casa, e não se vê onde foram descartadas. O e-mail por uma VPS de retransmissão não é testado aqui.

Ainda não testado aqui

As cinco formas de entrada: a opção de IPv4 público da Starlink, uma VPS de retransmissão, um túnel de saída, uma VPN mesh e o IPv6 de entrada.

Se uma retransmissão continua funcionando quando o endereço da conexão de casa muda. A página inicial do WireGuard diz que ele acompanha um peer cujo endereço muda; nada aqui testa isso.

O e-mail enviado por uma retransmissão.

Onde as conexões de saída na porta 25 são descartadas, o que a página 1 deixa em aberto.