Alternativas ao Cloudflare Tunnel, FRP e Tailscale Funnel para redes domésticas com CGNAT

Esta pesquisa compara formas de publicar sites, APIs, painéis, SSH, jogos e outros serviços executados em uma rede doméstica que está atrás de CGNAT. O foco não é apenas encontrar “outro Cloudflare Tunnel”, mas distinguir três problemas que costumam ser misturados: oferecer um endereço público sem instalar cliente no visitante, permitir acesso privado apenas a dispositivos autorizados e operar um túnel próprio por meio de uma VPS com IP público.

Nota terminológica: interpretei “Fast Reverse” como FRP, Fast Reverse Proxy, o projeto fatedier/frp. Não encontrei um produto independente amplamente reconhecido chamado apenas “Fast Reverse” que correspondesse ao contexto.

Resumo executivo

Não existe uma alternativa universalmente melhor. A escolha depende de quem precisa acessar o serviço e de quais protocolos ele usa.

• Melhor solução autohospedada completa: Pangolin com Newt em uma VPS. Reúne proxy HTTPS público, autenticação por identidade, acesso privado por cliente e, no modo self-hosted, recursos TCP/UDP brutos. É mais pesado que FRP ou rathole, mas oferece painel, políticas, certificados, balanceamento e verificações de saúde. A Community Edition é AGPL-3 e inclui os recursos centrais. (Pangolin, tipos de recurso)
• Melhor solução simples e sob controle próprio: WireGuard entre a casa e uma VPS, com Caddy, Nginx ou HAProxy na VPS. É a arquitetura mais transparente e durável para domínio próprio, HTTP(S), TCP e UDP. Em troca, o administrador assume firewall, roteamento, TLS, observabilidade e atualizações.
• Melhor substituto direto e versátil do FRP: o próprio FRP continua muito competitivo. A documentação atual cobre TCP, UDP, HTTP, HTTPS, STCP, SUDP e XTCP, além de QUIC/KCP/WebSocket no transporte, autenticação, TLS, balanceamento e health checks. Trocar FRP só faz sentido para reduzir complexidade, ganhar uma interface de identidade ou diminuir a dependência do projeto. (visão geral do FRP, tipos de proxy)
• Melhor túnel mínimo para TCP ou UDP: rathole, se a simplicidade e o consumo baixo importarem mais que painel e roteamento HTTP. Ele usa token obrigatório por serviço e oferece TLS ou Noise, mas a última release estável publicada no GitHub continua sendo a 0.5.0, de outubro de 2023; houve transição de mantenedores em 2025. Deve passar por teste e acompanhamento antes de uso crítico. (repositório, discussão de manutenção)
• Melhor serviço hospedado para compartilhar aplicações de forma geral: zrok é a opção mais interessante quando se deseja código aberto, plano hospedado e possibilidade de migração para self-hosting. Ele diferencia compartilhamentos públicos e privados, suporta HTTP(S), TCP e UDP e é construído sobre OpenZiti. Em agosto de 2026, porém, é importante manter clientes e servidor atualizados: o projeto publicou vários avisos de segurança em abril e maio de 2026. (zrok, avisos de segurança)
• Melhor serviço hospedado para desenvolvimento e integrações: ngrok possui ecossistema maduro, HTTPS automático, políticas de tráfego, inspeção e TCP. Entretanto, domínio próprio só está no plano pay-as-you-go e o plano gratuito limita transferência, requisições e conexões. (preços e limites)
• Melhor solução para servidor de jogo ou UDP sem administrar VPS: playit.gg. O agente cria um proxy público sem encaminhamento de portas, há presença em São Paulo e suporte a túneis de jogos e UDP; HTTPS, SSH e TCP genéricos ficam no Premium. É especializado e não deve ser tratado como proxy geral para painéis administrativos. (site oficial, documentação)
• Melhor acesso privado para os próprios dispositivos: Tailscale, NetBird ou Twingate. Nessa situação não é necessário publicar nada na Internet. NetBird é a alternativa mais equilibrada entre serviço gerenciado e self-hosting; seu Reverse Proxy público existe, mas ainda está em beta. Twingate é muito bom para acesso privado por identidade, mas não é um Funnel público. (NetBird Reverse Proxy, Twingate Resources)
• Headscale não substitui o Funnel. Ele substitui parte do plano de controle do Tailscale para uma rede privada; as releases atuais rejeitam políticas com a capacidade funnel, porque essa infraestrutura não está implementada. Para publicar um serviço, ainda será preciso uma VPS e um proxy, ou outra ferramenta. (Headscale, release com a limitação)

Para um homelab comum, a recomendação principal é manter administração, SSH, bancos, hipervisores e painéis somente na rede privada e publicar apenas os aplicativos realmente destinados ao público. Uma combinação prática é NetBird ou Tailscale para administração e Pangolin, WireGuard + VPS ou um SaaS de túnel para os poucos serviços públicos.

Metodologia e critérios

A pesquisa foi concluída em 7 de agosto de 2026. Foram consultadas prioritariamente documentações, repositórios, páginas de preços e páginas de segurança mantidas pelos próprios projetos. Preços só aparecem quando estavam publicamente verificáveis. Não foram usados rankings comerciais como prova de funcionalidade.

Cada opção foi avaliada pelos seguintes critérios:

1. Modelo de acesso: público sem cliente, privado com cliente ou ambos.
2. Protocolos: HTTP(S), TCP genérico, UDP e acesso a sub-redes.
3. Compatibilidade com CGNAT: conexão iniciada de dentro para fora, relay ou VPS pública.
4. Domínio e TLS: domínio próprio, certificado automático, terminação no edge ou no serviço.
5. Autenticação: Basic Auth, OAuth/OIDC, políticas por identidade, ACL ou apenas segredo de túnel.
6. Operação: painel, arquivos declarativos, reinício automático, métricas e logs.
7. Disponibilidade: múltiplos conectores, balanceamento, health check e pontos únicos de falha.
8. Privacidade: quem opera o relay e em qual ponto o tráfego pode ser descriptografado.
9. Maturidade: atividade recente, releases, documentação e alertas de segurança.
10. Custo total: serviço, VPS, domínio, tempo de operação e eventual tráfego excedente.

As classificações “melhor”, “maduro” e “adequado” são recomendações desta pesquisa, não garantias dos fornecedores. Latência e capacidade precisam ser medidas entre a residência, o nó público e os usuários reais.

Antes da lista: o que o CGNAT realmente muda

No CGNAT, vários clientes do provedor compartilham um IPv4 público. O roteador doméstico não controla a tradução feita no núcleo da operadora, portanto encaminhar uma porta no roteador geralmente não cria um caminho da Internet até a casa.

As soluções desta pesquisa contornam isso de uma destas formas:

• o agente doméstico abre uma conexão de saída para um serviço de edge;
• a casa mantém um túnel para uma VPS com IP público;
• cliente e servidor tentam comunicação ponto a ponto e usam relay quando o NAT impede o caminho direto;
• o acesso permanece privado e todos os participantes instalam um cliente de rede overlay.

O túnel não “remove” o CGNAT. Ele coloca um intermediário alcançável antes dele. Esse intermediário passa a influenciar latência, banda, disponibilidade, privacidade e custo.

IPv6 público pode eliminar parte do problema, mas não elimina firewall, autenticação nem a necessidade de proteger o serviço. Antes de contratar uma solução, vale verificar se o provedor oferece IPv6, IPv4 público dinâmico ou IP fixo por preço razoável.

Como confirmar se a conexão está realmente atrás de CGNAT

Não basta ver um endereço privado no computador, porque ele normalmente está atrás do NAT do próprio roteador mesmo quando a Internet possui IPv4 público. A comparação correta é entre o endereço IPv4 da interface WAN do roteador e o endereço visto por um serviço externo.

1. Abra a página de status da conexão no roteador e anote o IPv4 WAN/Internet, sem publicar esse valor.
2. Consulte o IPv4 visto externamente, por exemplo com curl -4 https://ifconfig.co ou outro serviço conhecido.
3. Se os dois endereços forem iguais, há em princípio um IPv4 público no roteador; o problema pode ser firewall, encaminhamento ou modem duplo.
4. Se forem diferentes e a WAN estiver em 100.64.0.0/10, há um forte sinal de CGNAT. A faixa compartilhada 100.64.0.0/10 foi reservada para esse uso pela RFC 6598.
5. WAN em 10.0.0.0/8, 172.16.0.0/12 ou 192.168.0.0/16 também indica NAT anterior, mas pode ser um modem/roteador do próprio assinante. Verifique se existe outro equipamento e se ele pode trabalhar em bridge.
6. Um tracert/traceroute com saltos privados ajuda a investigar, mas não prova CGNAT sozinho; operadoras podem usar endereços privados internamente sem traduzir a conexão do assinante daquela forma.

Teste uma porta apenas depois de confirmar que o serviço está escutando e que os firewalls local e do roteador permitem a porta. Sites de “port check” retornam fechado tanto para CGNAT quanto para aplicação parada, firewall ou encaminhamento errado.

Alternativas que evitam o túnel

Antes de implantar um novo plano de controle, pergunte ao ISP:

• se pode remover o assinante do CGNAT gratuitamente;
• se oferece IPv4 público dinâmico, que funciona com DDNS;
• quanto custa IPv4 fixo e se há bloqueio de portas;
• se delega prefixo IPv6 e qual seu tamanho;
• se a ONU/modem pode operar em bridge.

IPv4 público dinâmico + DDNS é a rota mais simples quando o endereço muda, mas expõe diretamente o IP residencial e exige encaminhamento, firewall e proteção DDoS. IPv6 público permite conectividade fim a fim sem NAT; cada serviço ainda precisa de regra explícita no firewall e os clientes precisam ter IPv6 funcional. IPv4 fixo facilita DNS, allowlists e certificados, porém não protege a origem e pode custar mais que uma VPS.

Para um site público, uma VPS continua útil mesmo quando há IPv6 em casa: oculta a origem, recebe tráfego IPv4, centraliza TLS e permite trocar o backend doméstico sem mudar o endereço público.

A distinção decisiva: público, privado e híbrido

Uma rede privada costuma ser a melhor resposta para serviços administrativos. Colocar Proxmox, SSH, banco de dados, Home Assistant administrativo ou o painel do roteador em uma URL pública, ainda que “escondida”, aumenta a superfície de ataque. Para esses casos, o visitante precisar instalar um cliente é uma proteção útil, não um defeito.

Referências atuais: Cloudflare Tunnel, FRP e Tailscale Funnel

Cloudflare Tunnel

O cloudflared abre conexões exclusivamente de saída para a rede Cloudflare pela porta 7844, usando QUIC sobre UDP ou HTTP/2 sobre TCP. Cada instância mantém quatro conexões distribuídas por pelo menos dois datacenters, e réplicas adicionais podem fornecer failover. (opções de conectividade, disponibilidade)

Para HTTP, o visitante usa o navegador normalmente. Para TCP, SSH, RDP e SMB publicados, o usuário final precisa executar cloudflared; conexões TCP longas são recomendadas pelo caminho Client-to-Tunnel. Cloudflare Tunnel não é uma passagem pública arbitrária de UDP e não atende protocolos iniciados pelo servidor, como SIP/VoIP, pelo modelo comum de aplicações publicadas. (protocolos)

Pontos fortes: edge global, TLS, integração com Access/WAF e alta disponibilidade simples. Pontos de dependência: DNS e plano de controle da Cloudflare, terminação e políticas no edge, e limitações de protocolo. Ele continua sendo uma referência forte para aplicações web; a pesquisa não recomenda substituí-lo apenas por preferência estética.

FRP, o “Fast Reverse Proxy”

FRP exige um frps em endereço público e um frpc na rede doméstica. Suporta TCP, UDP, HTTP, HTTPS, TCPMUX, STCP, SUDP e XTCP. O transporte entre cliente e servidor pode usar TCP, QUIC, KCP ou WebSocket; há multiplexação, grupos de balanceamento, health checks, autenticação por token ou OIDC, TLS e interface de administração. (visão geral, recursos, repositório)

É uma base muito competente para CGNAT. Suas desvantagens são operacionais: a proteção do serviço público, certificados, proxy HTTP, firewall da VPS e segregação entre usuários continuam sob responsabilidade do administrador. O Basic Auth embutido vale apenas para proxy HTTP e não substitui um provedor de identidade completo.

Tailscale Funnel

Funnel publica um serviço do nó Tailscale para a Internet, cria certificado HTTPS e usa exclusivamente nomes no domínio *.ts.net da tailnet. Só pode escutar nas portas 443, 8443 e 10000, exige TLS e impõe limites de banda não configuráveis. Serve e Funnel não podem usar simultaneamente a mesma porta: Serve é privado; Funnel é público. (documentação do Funnel)

Funnel é excelente para uma publicação pequena e simples, mas não oferece domínio próprio, UDP público nem o controle de uma VPS. As melhores alternativas variam justamente conforme a limitação que incomoda.

Comparação rápida das principais alternativas

Legenda: “público” significa acesso por pessoas sem cliente da ferramenta; “privado” exige identidade ou cliente; “VPS” indica infraestrutura pública administrada pelo usuário.

As células resumem o produto principal, não todas as combinações possíveis. Qualquer rede privada pode alimentar um proxy público em uma VPS; isso é uma arquitetura composta, não um recurso “Funnel” automático.

Alternativas autohospedadas com VPS

1. Pangolin com Newt: a alternativa mais completa

Pangolin combina proxy reverso e VPN por identidade. Newt é o conector recomendado para uma rede remota e cria túnel sem configuração de NAT. Recursos públicos HTTPS recebem domínio, certificado e políticas; recursos privados exigem o cliente Pangolin; recursos públicos TCP/UDP brutos são ligados a portas da VPS no modo self-hosted. (sites Newt, TCP e UDP) As releases oficiais mostram atividade forte: Pangolin 1.21.1 foi publicado em 30 de julho de 2026 e Newt 1.15.0 em 19 de julho de 2026. (releases do Pangolin, releases do Newt)

Vantagens:

• painel unificado para sites, recursos, usuários e funções;
• TLS automático e autenticação SSO/OIDC para HTTP;
• recursos privados por host ou CIDR;
• vários conectores no mesmo local para redundância;
• balanceamento e health checks em sites Newt;
• Community Edition gratuita e AGPL-3.

Limitações:

• requer uma VPS Linux, domínio e portas públicas;
• a instalação recomendada envolve vários componentes e é mais complexa que um binário de FRP;
• TCP/UDP público bruto não recebe as mesmas políticas de identidade dos recursos HTTP; deve ser protegido pelo próprio protocolo ou por firewall;
• a documentação de instalação pede 80/TCP, 443/TCP, 51820/UDP e 21820/UDP, além das portas brutas escolhidas. (instalação rápida)

Veredito: melhor escolha quando se quer uma plataforma de acesso, não apenas um cano de rede. Para uma residência com vários serviços e usuários, é a alternativa mais próxima de combinar Cloudflare Tunnel, Funnel e uma VPN privada em um único sistema.

2. WireGuard + VPS + proxy: a arquitetura de referência

A casa inicia um peer WireGuard para a VPS pública e usa PersistentKeepalive para conservar o mapeamento de NAT. A documentação oficial sugere 25 segundos como intervalo sensato em redes atrás de NAT. (WireGuard Quick Start)

Na VPS:

• Caddy, Nginx, Traefik ou HAProxy termina HTTPS e encaminha para o IP WireGuard doméstico;
• nftables/iptables pode fazer DNAT de TCP ou UDP para jogos e serviços brutos;
• o DNS do domínio aponta para a VPS;
• firewall permite somente portas publicadas e a porta WireGuard;
• logs, limites e proteção contra força bruta ficam na borda pública.

Vantagens: padrão aberto, independência de fornecedor, E2E possível, domínio próprio, qualquer protocolo IP e facilidade para trocar de proxy. Limitações: não há painel ou identidade embutidos; erro de roteamento ou firewall pode expor mais do que o pretendido; a VPS e o link doméstico são pontos únicos de falha.

Veredito: melhor para quem administra Debian/Ubuntu e quer compreender cada camada. É a opção mais sustentável para tráfego contínuo e protocolos fora de HTTP, desde que haja disciplina operacional.

3. FRP: ainda o canivete suíço

FRP oferece o conjunto mais amplo entre os túneis pequenos. Pode encaminhar DNS UDP, SSH TCP, sites por domínio, HTTPS passthrough, serviços privados STCP/SUDP e tentativa P2P XTCP. Também permite restringir portas no servidor, emitir métricas Prometheus e autenticar o frpc. (exemplo completo, configuração do servidor)

Recomendação: continuar com FRP se ele já funciona. Adicionar Caddy ou Traefik à frente de HTTP, usar TLS entre frpc e frps, token forte ou OIDC, firewall mínimo e serviço systemd costuma ser mais simples que migrar.

4. rathole: desempenho e configuração pequena

rathole é escrito em Rust, usa configuração separada no cliente e servidor e exige token por serviço. Cada serviço pode ser tcp ou udp; TLS e Noise protegem o transporte de controle/dados, e hot reload permite alterar serviços. O projeto se apresenta como túnel seguro e de baixo consumo. (README oficial)

Ele não é um proxy HTTP com domínios, certificados e autenticação de visitantes. Normalmente, coloca-se Caddy/HAProxy na frente de aplicações web. Para UDP, cada serviço recebe porta pública própria e continua dependendo da autenticação do protocolo de aplicação.

Veredito: excelente para uma ou poucas portas TCP. Para produção, fixar versão, testar reconexão e observar o ritmo de releases é obrigatório.

5. sish: SSH como protocolo de túnel

sish transforma um servidor SSH em plataforma multiusuário para túneis HTTP(S), WebSocket e TCP. Pode rotear por subdomínio, usar domínio próprio com prova por fingerprint SSH, fazer SNI proxy e balancear conexões com o mesmo alias ou porta. A release 2.23.0, de 5 de junho de 2026, confirma atividade recente. (repositório, releases, documentação avançada)

É atraente quando OpenSSH e chaves já fazem parte da operação. O administrador precisa endurecer contas, chaves, limites, DNS wildcard, certificados e exposição do painel/serviço SSH.

6. inlets: produto comercial com servidor sob seu controle

inlets oferece túneis HTTP L7 e TCP L4, múltiplos serviços por túnel, balanceamento e integração com Kubernetes. O cliente se autentica por token. O produto atual é comercial: o plano Personal verificado custa US$ 25/mês e inclui até cinco túneis e servidores hospedados no Inlets Cloud; também se pode operar o exit server. (documentação, preços, FAQ)

Veredito: interessante para suporte e uso comercial previsível, menos atraente para homelab econômico em comparação com uma VPS pequena e software aberto.

7. boringproxy: boa ideia, manutenção que exige cautela

boringproxy combina túnel por SSH, interface web, domínio próprio e escolha de terminação TLS no servidor, cliente ou aplicativo. (repositório)

A última release pública identificada é a 0.10.0, de janeiro de 2023. Isso não prova abandono, mas é um sinal suficiente para não recomendá-lo como primeira escolha para um serviço exposto em 2026 sem auditoria de commits, dependências e vulnerabilidades. (releases)

8. bore, Chisel e wstunnel: peças de infraestrutura

• bore é um túnel TCP mínimo escrito em Rust. É fácil de compreender, mas não oferece roteamento HTTP, identidade, UDP ou certificados por domínio. (repositório)
• Chisel transporta TCP/UDP por HTTP e protege a sessão com SSH; o modo reverso permite que a casa disponibilize portas na VPS. É útil em redes restritivas e como bloco de construção, não como edge completo. (repositório)
• wstunnel encapsula TCP/UDP, SOCKS e sockets Unix em WebSocket ou HTTP/2, oferece TLS/mTLS e modo reverso. A versão 10.5.5 foi publicada em maio de 2026, indicando atividade recente. (repositório)

Entre os três, wstunnel é o mais flexível em firewalls estritos; bore é o mais simples; Chisel fica no meio. Em todos os casos, Caddy/HAProxy e um mecanismo de autenticação continuam necessários para uma aplicação web pública segura.

9. SSH reverso puro: mínimo e universal

O comando conceitual é ssh -N -R porta-remota:host-local:porta-local usuario@vps. Por padrão, o OpenSSH liga o encaminhamento remoto ao loopback da VPS; GatewayPorts controla se outros hosts podem alcançá-lo. A opção clientspecified permite que o cliente escolha o endereço, e deve ser usada com restrições de usuário, chave e PermitListen. (manual de sshd_config)

Para ficar estável, é comum usar autossh ou systemd, keepalives, conta sem shell, chave exclusiva e proxy reverso na VPS. OpenSSH encaminha TCP, não UDP.

Veredito: ótimo plano de contingência ou solução para uma única porta; frágil como plataforma multiusuário sem automação adicional.

Serviços gerenciados sem VPS própria

10. zrok e OpenZiti

zrok oferece compartilhamento público de web, compartilhamento privado de recursos TCP/UDP, arquivos, drives, endereço reservado e self-hosting. O plano gratuito verificado oferece 5 GB por dia, 25 ambientes, 50 backends e 50 frontends privados; instância própria usa licença Apache-2.0 sem esses limites. (preços, repositório)

OpenZiti é a camada zero trust inferior, com identidades criptográficas, políticas, edge routers e túnel E2E. É mais poderosa e complexa; zrok é a experiência simplificada. (OpenZiti)

Ponto de segurança atual: o repositório zrok lista avisos críticos e altos publicados em abril e maio de 2026, incluindo SSRF, travessia de caminho em WebDAV/drive e DoS. Isso não significa evitar o projeto, mas exige conferir versões corrigidas antes de implantar, especialmente quando houver compartilhamento de arquivos. (security advisories)

11. Packetriot

Packetriot cria túneis reversos seguros para HTTP(S) e TCP, entrega hostname persistente, permite domínio próprio inclusive no nível gratuito e gerencia certificados Let's Encrypt. O cliente oferece proteção por senha, Basic Auth, OpenID Connect com 2FA e regras de firewall. (site, cliente, CLI)

Ele é particularmente adequado para um pequeno site doméstico que precisa permanecer no ar sem VPS. Não há UDP documentado no produto principal. Como em qualquer SaaS, disponibilidade e dados de conexão dependem da rede do fornecedor.

12. ngrok

ngrok fornece endpoints HTTP(S), TCP e TLS, certificados automáticos, políticas de tráfego, OAuth/OIDC, mTLS em planos compatíveis, inspeção e balanceamento por pool. O plano gratuito, em agosto de 2026, permite até três endpoints, 1 GB/mês, 20 mil requisições HTTP e 5 mil conexões TCP; TCP exige verificação de cartão. Domínio próprio fica no pay-as-you-go, cuja base é US$ 20/mês com crédito de uso. (preços e limites, cobrança)

Veredito: melhor experiência para desenvolvimento e webhooks; pode ficar caro ou excessivamente dependente do edge para hospedagem doméstica contínua.

13. Pinggy

Pinggy pode funcionar usando apenas o cliente SSH ou sua CLI. Suporta HTTP(S), TCP, UDP, TLS e TLSTCP, Basic Auth, allowlist de IP, depurador de requisições e execução como serviço. O plano gratuito encerra o túnel após 60 minutos; domínio e portas persistentes ficam no Pro. (site, CLI, uso por SSH)

É uma das alternativas mais completas para experimentar protocolos sem instalar um servidor. Como a página de preços não expôs um valor numérico verificável nesta coleta, esta pesquisa não registra preço do Pro.

14. LocalXpose

LocalXpose anuncia HTTP, HTTPS, TLS, TCP e UDP, regiões múltiplas, domínio e wildcard próprios, controles de acesso e certificados Let's Encrypt. O gratuito serve para uso leve; portas TCP/UDP reservadas e domínio persistente dependem de plano pago. (site e recursos, documentação)

É tecnicamente abrangente, mas os limites e preços devem ser conferidos no momento da contratação. Para dados sensíveis, também se deve verificar onde o TLS termina e quais metadados o edge retém.

15. localhost.run

Um comando OpenSSH cria uma URL HTTPS sem download ou cadastro: ssh -R 80:localhost:8080 localhost.run. O serviço gera certificado e aceita domínio próprio; a assinatura de domínio custa US$ 9/mês quando cobrada anualmente e inclui até cinco túneis simultâneos. (introdução, domínios, CLI)

É excelente para demos e testes. Embora haja modos TLS e usos TCP avançados, a experiência principal é HTTP; não é substituto de uma rede privada nem oferece UDP.

16. Serveo

Serveo voltou a oferecer documentação ativa e túneis anônimos por SSH, além de conexão WireGuard em certos fluxos. Túneis anônimos exibem página intermediária contra phishing. (documentação)

O serviço é útil para compartilhamento rápido, mas a história de disponibilidade intermitente do nome Serveo e o caráter anônimo recomendam não usá-lo como infraestrutura permanente. Essa é uma avaliação prudencial; a presença atual foi confirmada pela documentação oficial acessível em agosto de 2026.

17. playit.gg

playit.gg foi construído para jogos. O agente doméstico se conecta à rede global e jogadores usam o endereço público sem instalar cliente. O site anuncia suporte a TCP/UDP customizado, 19 datacenters e presença em São Paulo; Premium custa US$ 3/mês e libera recursos como HTTPS, SSH, TCP genérico, TCP+UDP, regiões e domínio externo. (site, Premium, HTTPS e domínio externo)

Veredito: primeira opção a testar para Minecraft, Valheim, Terraria e outros jogos compatíveis, sobretudo quando UDP e latência regional importam. Para serviços web, Packetriot, zrok, Pangolin ou um proxy em VPS são mais apropriados.

18. Loophole e Tunnelmole

Loophole documenta HTTP/HTTPS, Basic Auth, hostname em loophole.site, aplicação local ou em outro host da LAN e criptografia até o cliente. A própria FAQ informa que TCP, domínio próprio real e self-hosting ainda não estão disponíveis. A documentação continua com nomenclatura beta e região somente na Europa. (visão geral, FAQ)

Tunnelmole é open source, oferece URL HTTP/HTTPS e pode ter o servidor self-hosted. O cliente é MIT e o serviço é AGPLv3. Não é uma solução TCP/UDP; foi projetado para servidores web de desenvolvimento. Ele coleta telemetria anônima por padrão, desativável por variável de ambiente. (documentação, servidor)

Ambos são ferramentas de nicho. Não devem ocupar a primeira posição em um homelab de produção enquanto alternativas mais completas estiverem disponíveis.

Redes overlay e acesso privado

19. NetBird

NetBird constrói uma malha WireGuard com políticas, DNS, routing peers e relay quando P2P não é possível. Há serviço cloud e versão self-hosted. O guia atual de self-hosting usa um netbird-server combinado e identidade embutida; a instalação avançada continua disponível para IdP externo. (self-hosting, cloud versus self-hosted)

O Reverse Proxy lançado em 2026 publica serviços internos com TLS sem abrir portas na residência, mas está em beta. Além de HTTP, a documentação atual cobre TCP, UDP e TLS passthrough. HTTP pode receber SSO/OIDC, senha, PIN, headers/tokens e restrições por IP/país; recursos L4 não ganham a tela de autenticação web e precisam de controles de rede/aplicação. No self-hosted, exige uma instância netbird-proxy e Traefik como proxy externo suportado, portanto ainda há um nó publicamente alcançável fora do CGNAT. (Reverse Proxy)

Veredito: melhor alternativa geral ao Tailscale para acesso privado e promissora para publicação pública. Para produção pública crítica, aguardar maturação do Reverse Proxy ou colocá-lo atrás de uma arquitetura testada.

20. Twingate

Twingate usa Connectors dentro da rede doméstica e clientes nos dispositivos autorizados. Connectors fazem apenas conexões de saída, usam NAT traversal ou relays, encaminham TCP e UDP e podem ser duplicados para balanceamento/failover. Recursos são endereços privados com restrições por porta e identidade. (arquitetura dos Connectors, requisitos de rede, Resources)

Ele não oferece uma URL pública para visitantes anônimos. É concorrente de Tailscale privado, não do Funnel. Para administração de homelab por poucas pessoas, essa limitação é desejável.

21. ZeroTier

ZeroTier cria rede virtual entre dispositivos e tenta conexões UDP P2P. Quando NAT ou firewall bloqueia hole punching, pode usar relay TCP; a própria documentação alerta que esse fallback é lento e permite operar relay próprio. (downloads, TCP relay)

Não existe publicação HTTP pública automática. Para isso, um membro ZeroTier em uma VPS precisa executar Caddy/Nginx/HAProxy e encaminhar para o nó doméstico. É uma boa malha para dispositivos heterogêneos e cenários que se beneficiam de comportamento semelhante a uma LAN.

22. Netmaker

Netmaker automatiza redes WireGuard, gateways, egress e acesso remoto. Um Remote Access Gateway gera configurações WireGuard para dispositivos sem netclient; a documentação recomenda que esse gateway tenha IP público e não esteja atrás de NAT. Há gateways HA com seleção e failover. (remote access, gateways, repositório)

Ele é excelente para site-to-site e uma malha autohospedada, mas não substitui um proxy público. A VPS Netmaker pode acumular a função de gateway e proxy, desde que firewall e responsabilidades sejam separados.

23. Headscale

Headscale é uma implementação autohospedada do servidor de controle Tailscale. Usa os clientes Tailscale para rede privada, ACLs/grants, MagicDNS, subnet routers e DERP. (repositório, documentação)

Não há Funnel: a release 0.28.0 rejeita políticas com a capacidade funnel. Portanto, Headscale + Tailscale Serve entrega serviço privado; para Internet pública, adicione VPS + proxy ou outra solução. A documentação de reverse proxy do próprio Headscale é comunitária e declara não ser verificada pelos autores. (limitações na release, aviso da documentação de proxy)

24. Tailscale sem Funnel

Mesmo quando Funnel não serve, Tailscale continua útil. tailscale serve publica somente dentro da tailnet, subnet routers alcançam a LAN e uma VPS na mesma tailnet pode hospedar Caddy e encaminhar para o endereço Tailscale doméstico. Essa composição permite domínio próprio e portas públicas, mas o tráfego público termina na VPS, não no Funnel.

Veredito: se a rede Tailscale já existe, acrescentar uma VPS como edge costuma ser a migração de menor risco.

Domínio, TLS e privacidade: onde o tráfego é aberto

“Criptografado” pode significar coisas diferentes:

1. Visitante até o edge: HTTPS protege o caminho público, mas o fornecedor pode terminar TLS e encaminhar HTTP no túnel.
2. Edge até a casa: o túnel pode ser criptografado, mas o edge já viu o conteúdo.
3. TLS passthrough: o certificado e a chave ficam na casa; o edge roteia por SNI ou TCP sem descriptografar a aplicação.
4. Criptografia overlay E2E: cliente autorizado e destino usam identidades e o relay não recebe as chaves, como em OpenZiti e malhas WireGuard.

Para site público comum, terminação no edge é aceitável e permite WAF, OAuth e inspeção. Para dados altamente sensíveis, prefira TLS passthrough ou rede privada E2E. Verifique também logs, cabeçalhos com IP do cliente, retenção e região do provedor.

Domínio próprio é mais fácil em HTTP porque vários sites compartilham 443 por Host/SNI. TCP e UDP genéricos normalmente exigem uma porta pública por serviço; SRV ajuda alguns clientes, mas não todos. Certificado automático não autentica o usuário: ele autentica o servidor e cifra a conexão.

Segurança mínima para qualquer opção

Não publique o que pode permanecer privado

Mantenha na overlay:

• SSH e RDP administrativos;
• Proxmox, Unraid, Portainer, Cockpit e painéis de roteador;
• PostgreSQL, MySQL, Redis, MongoDB e interfaces de backup;
• métricas, logs e dashboards sem necessidade pública;
• câmeras e dispositivos IoT.

Publique somente aplicações desenhadas para receber tráfego não confiável. Um túnel atravessa o firewall deliberadamente; CGNAT deixa de ser barreira naquele caminho.

Controles obrigatórios

• autenticação forte no gateway ou na aplicação, preferencialmente OIDC e MFA;
• atualização automática ou rotina curta para agente, VPS, proxy e aplicação;
• usuário sem privilégios e container sem acesso desnecessário ao Docker socket;
• firewall allowlist na VPS e nenhuma porta de administração pública;
• segredo distinto por agente/túnel e rotação após suspeita;
• rate limiting, limite de corpo, timeouts e proteção de login;
• logs com cuidado para não registrar tokens, cookies e corpos sensíveis;
• backup da configuração, chaves, DNS e procedimento de revogação;
• monitoramento externo e alerta quando agente ou túnel cair.

Para TCP/UDP bruto, não existe a camada de autenticação HTTP do proxy. SSH deve usar chaves, Minecraft deve ter allowlist quando possível, banco de dados não deve ser público, e protocolos legados devem ficar atrás de VPN privada.

Alta disponibilidade e desempenho

Um túnel pode ter até cinco pontos de falha: energia/rede da casa, agente, provedor residencial, nó público e DNS/edge. Duplicar somente o agente não resolve queda de energia ou de Internet na residência.

Práticas úteis:

• executar dois conectores em hosts diferentes quando Pangolin, Cloudflare ou Twingate permitirem;
• usar health checks antes de enviar tráfego a um backend;
• manter uma segunda rota administrativa privada;
• escolher VPS ou região perto dos usuários, não apenas perto da casa;
• medir upload residencial, jitter e perda, especialmente em jogos e mídia;
• testar reconexão após troca de IP, reinício do roteador e expiração de token;
• evitar transcoding ou grandes downloads por SaaS com franquia baixa;
• para HA real, considerar segundo link residencial ou réplica do serviço fora de casa.

Cloudflare cria quatro conexões por cloudflared; Pangolin aceita múltiplos sites/conectores; Twingate agrupa Connectors; FRP e Pangolin podem balancear backends; Netmaker oferece gateways HA. Soluções mínimas como SSH reverso, rathole e bore precisam de supervisão externa e desenho manual de redundância.

Custos verificados e custo oculto

Valores observados em 7 de agosto de 2026, sujeitos a mudança:

O custo oculto de self-hosting é o tráfego da VPS, backup, tempo de atualização e resposta a incidentes. O custo oculto do SaaS é lock-in de domínio/endpoint, limites de banda, mudança de plano e indisponibilidade fora do controle do usuário.

Matriz de decisão aprofundada

As notas abaixo vão de 1 a 5 e representam a avaliação desta pesquisa para um homelab, não benchmark do fabricante. “Controle” considera a capacidade de operar o plano de dados e migrar; “facilidade” considera chegar a um serviço funcional; “público” avalia publicação sem cliente; “privado” avalia identidade e segmentação; “L4” considera TCP/UDP; “operação” avalia painel, health check e redundância.

Como interpretar:

• Se público + privado + painel são obrigatórios, Pangolin lidera.
• Se qualquer protocolo + controle vale mais que facilidade, WireGuard/FRP lideram.
• Se zero manutenção de VPS é o requisito principal, Packetriot, zrok ou ngrok são mais coerentes.
• Se ninguém de fora precisa entrar, descarte toda a coluna pública e escolha uma overlay.
• Se UDP é obrigatório, elimine logo os produtos HTTP-only e os túneis OpenSSH tradicionais.

Topologias recomendadas

Topologia A: dois planos separados

É a recomendação mais segura para a maioria das residências:

Administradores ── cliente NetBird/Tailscale ── rede privada ── painéis e SSH

Visitantes ── HTTPS ── VPS/Pangolin ── Newt de saída ── aplicação pública

O comprometimento de uma aplicação pública não concede automaticamente rota a toda a LAN. O conector público deve alcançar apenas as portas dos backends publicados, idealmente em VLAN ou rede Docker separada. A overlay administrativa deve usar identidades diferentes das credenciais de publicação.

Topologia B: VPS como borda universal

Internet ── DNS/TLS/Caddy na VPS ── WireGuard ── proxy/serviço em casa
                       └──────────── DNAT TCP/UDP ────────────┘

É a arquitetura mais portátil. O domínio aponta para a VPS; a residência pode trocar de ISP sem alterar DNS. Caddy atende sites; firewall/DNAT lida com protocolos brutos. A VPN deve usar endereços estreitos, e a VPS não deve rotear livremente para toda a LAN. Se o backend aceitar Proxy Protocol, preserve IP real somente entre pares confiáveis.

Topologia C: SaaS sem infraestrutura pública própria

Internet ── edge Packetriot/zrok/ngrok ── agente de saída ── aplicação

É a mais simples, mas a aplicação depende do fornecedor para DNS, relay e disponibilidade. Use domínio próprio quando possível para facilitar migração. Guarde uma configuração alternativa e saiba reduzir TTL antes de mudar de serviço.

Topologia D: acesso estritamente privado

Dispositivo autorizado ── WireGuard/overlay ── serviço interno
                         (P2P ou relay cifrado)

Não há DNS público nem porta de aplicação na Internet. É a escolha correta para administração, dados pessoais e serviços que não foram endurecidos para tráfego hostil. Quando P2P falha sob CGNAT simétrico, o relay pode aumentar latência; mesmo assim, a exposição permanece limitada a identidades autorizadas.

Migração sem ficar preso ao fornecedor

O ativo mais importante é o domínio, não o hostname gratuito do túnel. Para serviços permanentes:

• use um subdomínio próprio com CNAME/A quando o plano permitir;
• mantenha TLS e autenticação documentados fora do painel do provedor;
• versione configurações do proxy e listas de recursos sem segredos;
• evite links absolutos internos para domínios *.ngrok, *.ts.net ou equivalentes;
• exporte logs e inventário de túneis;
• prepare um health endpoint e um teste de ponta a ponta reutilizável;
• saiba qual DNS precisa mudar e quanto tempo o TTL pode manter o caminho antigo.

Para migrar de Cloudflare Tunnel para Pangolin/Packetriot/ngrok, mantenha o backend igual e mude primeiro um subdomínio de teste. Para migrar de FRP/rathole para WireGuard, estabeleça a interface privada, valide o proxy pela VPS e só então remova a porta pública antiga. Para sair de Tailscale/NetBird/Twingate, migre um grupo de dispositivos e uma rota por vez; duas overlays simultâneas podem criar colisão de DNS e rotas, portanto use prefixos distintos durante a transição.

Escolhas por cenário

Um site público permanente com domínio próprio

1. Pangolin + Newt, se autenticação e painel forem valiosos.
2. WireGuard + Caddy em VPS, se controle e portabilidade forem prioridade.
3. Packetriot, se não quiser administrar VPS.
4. zrok, para começar hospedado e preservar rota de self-hosting.
5. ngrok, quando políticas e ferramentas de desenvolvimento justificarem o preço.

Painéis e administração apenas para você

1. NetBird ou Tailscale Serve.
2. Twingate, se identidade e acesso por recurso forem prioridade.
3. Headscale, se o controle do plano de coordenação justificar a operação.
4. ZeroTier, para uma LAN virtual simples e multiplataforma.

Não use Funnel para esse cenário: Funnel torna o serviço público.

Jogos e serviços UDP públicos

1. playit.gg, pela especialização e região em São Paulo.
2. WireGuard + DNAT em VPS, para controle de portas e protocolo.
3. Pangolin raw TCP/UDP self-hosted, pela administração unificada.
4. FRP UDP, quando já houver VPS e FRP.
5. Pinggy ou LocalXpose, para teste rápido; confirme região e limites.

Streaming de vídeo, áudio e bibliotecas grandes

Streaming muda a decisão porque tráfego contínuo consome franquia rapidamente e o upload residencial costuma ser o gargalo. Um stream de 20 Mbit/s transfere cerca de 9 GB por hora; mesmo um plano gratuito aparentemente generoso pode terminar em minutos ou horas.

1. Para uso pessoal, mantenha Jellyfin, Navidrome ou serviço equivalente em Tailscale, NetBird ou WireGuard privado. O caminho pode ser direto quando o NAT permite, evitando relay e cobrança de saída.
2. Para poucos usuários conhecidos sem cliente, use WireGuard + VPS e proxy TCP/HTTPS, mas confirme a franquia de saída da VPS e se o tráfego faz ida e volta pela região escolhida.
3. Para audiência pública, hospedar a origem em casa tende a ser frágil. Uma CDN ou armazenamento/servidor próximo da audiência é tecnicamente mais adequado que um túnel residencial.
4. Evite planos gratuitos com poucos gigabytes, como o ngrok Free de 1 GB/mês, para mídia contínua. O zrok Free publica 5 GB/dia, ainda insuficiente para sessões longas de vídeo em bitrate alto. (ngrok, zrok)
5. Teste Range Requests, WebSocket, timeouts, tamanho máximo de resposta e conexões longas. Um túnel que abre a página pode falhar ao buscar uma parte distante do vídeo ou manter transcodificação prolongada.

Inferência prática: para mídia privada, uma overlay com conexão direta é preferível. Para mídia pública, mover o conteúdo para fora da residência costuma dar melhor resultado do que tentar escolher o “túnel mais rápido”.

Câmeras, Home Assistant e automação

Use rede privada para interfaces administrativas e RTSP. Se um webhook público for necessário, publique somente um endpoint estreito com autenticação e limite de requisição, não o painel inteiro. Pangolin autenticado, Cloudflare Access, zrok com OAuth ou ngrok Traffic Policy podem cumprir esse papel; Tailscale/NetBird devem permanecer como plano administrativo separado.

SSH ou uma porta TCP ocasional

1. rede privada Tailscale/NetBird/Twingate;
2. rathole ou SSH reverso em VPS;
3. FRP;
4. Pinggy/localhost.run para sessão temporária.

Rede inteira e site-to-site

1. WireGuard puro, se houver poucas redes;
2. NetBird para políticas e self-hosting simplificado;
3. Netmaker para topologia WireGuard e gateways;
4. Tailscale/Headscale ou ZeroTier conforme clientes e administração;
5. OpenZiti quando identidade por aplicação e serviços “dark” justificarem a complexidade.

Recomendações práticas

Arquitetura recomendada para um homelab doméstico

Use duas vias separadas:

1. Via privada: NetBird ou Tailscale para SSH, administração, banco, NAS e monitoramento.
2. Via pública: Pangolin + Newt em VPS para os sites e APIs que precisam receber visitantes.

Essa separação evita transformar um único proxy público em chave para toda a rede. Também permite desligar a publicação sem perder acesso administrativo.

Se preferir menos componentes, Pangolin pode cumprir os dois papéis. Se preferir tecnologias menores, use WireGuard + Caddy/HAProxy e mantenha as regras em arquivos versionados.

Roteiro de prova de conceito

1. Liste cada serviço, protocolo, porta, público-alvo e requisito de domínio.
2. Classifique como público, privado ou desnecessário remotamente.
3. Crie uma VPS pequena na região com menor latência medida.
4. Implemente primeiro um serviço descartável e sem dados sensíveis.
5. Teste TLS, autenticação, IP real, upload, WebSocket, arquivos grandes e reconexão.
6. Reinicie roteador, agente e VPS separadamente e meça o tempo de recuperação.
7. Faça varredura externa das portas e confirme que só as planejadas respondem.
8. Ative logs, alertas e backup antes de migrar o serviço real.
9. Mantenha o túnel antigo por alguns dias como retorno, sem publicar simultaneamente o mesmo backend se isso duplicar risco.
10. Documente como revogar credencial e desativar DNS em um incidente.

Critérios de descarte rápido

Descarte uma opção se:

• não suporta o protocolo necessário;
• obriga domínio de fornecedor quando o endereço precisa ser permanente;
• não permite MFA/OIDC para um painel público sensível;
• não informa limites de banda ou retenção de dados aceitáveis;
• a release e dependências estão sem manutenção verificável;
• o relay fica longe demais para o perfil de latência;
• o serviço não oferece exportação ou uma rota clara de migração.

Conclusão

Para redes domésticas atrás de CGNAT, a melhor alternativa não é um produto isolado, mas uma arquitetura adequada ao tipo de acesso.

Pangolin + Newt em uma VPS é a recomendação geral desta pesquisa porque cobre publicação HTTPS, autenticação, acesso privado e TCP/UDP bruto sem exigir que todos os casos sejam montados manualmente. WireGuard + proxy em VPS é a opção mais transparente e independente. FRP continua sendo a ferramenta técnica mais versátil e não precisa ser trocada quando já está bem configurada. zrok é o serviço hospedado/open source mais interessante; Packetriot é forte para sites persistentes; playit.gg é a escolha especializada para jogos e UDP.

Para administração, use NetBird, Tailscale, Twingate, ZeroTier, Netmaker ou Headscale como redes privadas. Elas não são equivalentes ao Funnel: isso é justamente o que reduz a exposição. Headscale, em particular, não implementa Funnel e precisa ser combinado com uma VPS/proxy para publicação pública.

A regra final é simples: público só o que foi construído para ser público; o restante fica atrás de identidade, cliente e política de acesso.

Fontes consultadas

Referências e arquitetura

• Cloudflare Tunnel: opções de conectividade
• Cloudflare Tunnel: protocolos de aplicações publicadas
• Cloudflare Tunnel: disponibilidade e failover
• FRP: visão geral
• FRP: recursos
• FRP: repositório oficial
• Tailscale Funnel
• WireGuard Quick Start
• OpenSSH: sshd_config

Túneis autohospedados e híbridos

• Pangolin
• Pangolin: sites e Newt
• Pangolin: tipos de recurso
• Pangolin: TCP e UDP públicos
• Pangolin: instalação self-hosted
• rathole
• sish
• inlets
• inlets: preços
• boringproxy
• bore
• Chisel
• wstunnel

Serviços hospedados

• zrok
• zrok: preços e limites
• zrok: segurança
• OpenZiti
• Packetriot
• Packetriot: documentação do cliente
• ngrok: preços e limites
• Pinggy
• Pinggy CLI
• LocalXpose
• localhost.run
• Serveo
• playit.gg
• playit.gg: documentação
• Loophole
• Tunnelmole

Redes privadas e overlays

• NetBird: cloud versus self-hosted
• NetBird Reverse Proxy
• Twingate Connectors
• Twingate Resources
• ZeroTier TCP Relay
• Netmaker: Remote Access Gateway
• Netmaker: gateways e HA
• Headscale
• Headscale v0.28.0 e limitação do Funnel

Nota sobre atualidade

Pesquisa concluída em 7 de agosto de 2026. Planos, limites, regiões, licenças, versões e recursos de beta podem mudar rapidamente. Confirme preços, documentação e avisos de segurança nas fontes oficiais antes de publicar serviços ou contratar planos.