Port forwarding é frágil porque depende de cadeia de mapeamentos estáticos. Aqui estão as seis razões mais comuns que ele quebra da noite para o dia.
A maioria ISPs residenciais usa DHCP com prazos de lease de 24h–7d. Quando o lease renova, você *pode* receber novo IP. A regra de port forward no roteador aponta para seu **IP LAN**, mas usuários *externos* batem no **velho IP WAN**.
Correção: Dynamic DNS (DDNS) — No-IP, DuckDNS, script Cloudflare DDNS — para que `seuhost.ddns.net` sempre resolva para IP WAN atual.
Servidor DHCP do roteador deu novo IP privado ao seu servidor/PC (ex.: 192.168.1.50 → .55). A regra de port forward ainda aponta para o IP LAN antigo.
Correção: **Reserva DHCP** (lease estático) no roteador: vincule endereço MAC a IP fixo. Ou defina IP estático no dispositivo *fora* do pool DHCP.
Correção: Backup config (`/backup` ou export web UI). Desative auto-update se instável. UPS para roteador.
Windows Defender, AV terceiros (Norton, Bitdefender), ou `ufw`/`iptables` no Linux começaram bloquear porta de entrada após update.
Correção: Adicione regra de entrada para porta TCP/UDP na máquina *destino*. Teste com `nmap -p PORTA IP_LAN` de outro dispositivo LAN.
Correção: `netstat -anob` (Win) / `ss -tulpn` (Linux) para ver quem possui a porta. Atualize regra de forward para novo IP LAN.
ISP moveu você para **Carrier-Grade NAT (CGNAT)** (comum Starlink, 5G home, fibra em algumas regiões). Você compartilha IP público com centenas de usuários — **portas de entrada impossíveis**. Ou ISP começou bloquear portas "suspeitas" (25, 80, 443, 8080, 3389, 22).
Correção: Solicite **IP público estático** da ISP (geralmente custo extra). Ou use **Tailscale Funnel / Cloudflare Tunnel / ngrok / VPN VPS reverse proxy** para contornar CGNAT completamente.
Tecnologia Eletrônica © [www.351231.com]