Tenho Wi-Fi, mas não tenho Internet. Onde está o problema?

Ligado a quê, exatamente?

Abrimos o computador, ligamo-nos ao Wi-Fi e tentamos visitar um site. A página fica a carregar. Experimentamos outra. Nada.

O nome da rede está certo. O sinal parece bom. Então, porque é que não conseguimos navegar?

A resposta começa numa distinção simples: estar ligado ao Wi-Fi não garante acesso à Internet. A ligação sem fios permite comunicar com a rede local. Ainda é preciso que exista um caminho funcional até ao serviço que queremos usar.

Numa rede doméstica, o equipamento a que chamamos router costuma acumular várias funções: fornece Wi-Fi, liga os dispositivos entre si e encaminha tráfego para outras redes. Uma dessas funções pode continuar a funcionar enquanto outra falha.

Em vez de começar por mudar definições, prefiro dividir o problema em perguntas pequenas: acontece só neste computador? Chegamos ao router? Conseguimos contactar um endereço externo? O DNS responde?

Vamos seguir essa ordem num computador com Windows, numa rede doméstica típica. Os exemplos de conectividade usam IPv4; uma rede pode também ter IPv6, que tem de ser analisado separadamente quando os resultados não coincidem.

Primeiro: é só um site ou é tudo?

Antes de abrir o terminal, experimentar dois ou três sites diferentes. Se apenas um falha, ainda não temos motivos para concluir que estamos sem Internet: pode existir um problema nesse site ou no acesso a ele.

Depois, testar outro dispositivo na mesma rede Wi-Fi. O telemóvel serve, com um cuidado: desligar temporariamente os dados móveis, para garantir que a comparação usa mesmo o Wi-Fi. No fim, podemos voltar a ligá-los.

Se o telemóvel consegue navegar e o computador não, começamos por investigar o computador ou a forma como está ligado. Se vários dispositivos falham, ganham força as hipóteses de um problema partilhado, no router ou no acesso do operador. Esta comparação é uma pista, não identifica sozinha a causa.

O guia de diagnóstico de Wi-Fi da Microsoft também recomenda comparar o comportamento noutro dispositivo.

O computador recebeu uma configuração de rede?

Abrir o Terminal, o PowerShell ou a Linha de Comandos e executar:

ipconfig /all

Este comando apresenta a configuração das ligações de rede. Pode haver várias: Wi-Fi, Ethernet, VPN e adaptadores virtuais. Procurar a ligação Wi-Fi que estamos efetivamente a usar.

Para já, interessam quatro elementos:

Elemento	Para que serve
Endereço IPv4	Identifica a ligação do computador naquela rede IPv4.
Máscara de sub-rede	Ajuda a determinar que destinos pertencem à mesma sub-rede.
Gateway predefinida	É o próximo destino usado para chegar a outras redes quando não existe uma rota mais específica. Em casa, costuma ser o router.
Servidores DNS	Respondem a consultas sobre nomes, incluindo os endereços associados aos sites.

Um exemplo simplificado, com rótulos adaptados para facilitar a leitura:

Endereço IPv4:          192.168.1.50
Máscara de sub-rede:    255.255.255.0
Gateway predefinida:    192.168.1.1
Servidor DNS:          192.168.1.1

Estes valores são ilustrativos. Não devem ser copiados para a configuração do computador. É perfeitamente possível que a nossa rede use outros endereços.

O DNS e a gateway podem ter o mesmo endereço porque o router pode receber as consultas DNS dos dispositivos e encaminhá-las para outro servidor. As funções continuam a ser diferentes.

A documentação de ipconfig explica os dados apresentados; a introdução da Microsoft ao endereçamento TCP/IP desenvolve os conceitos de endereço, máscara e gateway.

E se o endereço começar por 169.254?

Numa rede doméstica configurada para obter o endereço automaticamente, um IPv4 como 169.254.23.8 é uma pista de que o computador pode não ter recebido a configuração esperada por DHCP.

O DHCP é o mecanismo que normalmente fornece essa configuração de forma automática. Os endereços 169.254.x.x são de ligação local: não servem para encaminhar tráfego IPv4 pela Internet, conforme a RFC 3927.

Isso orienta-nos para a configuração IPv4 local, mas não demonstra que toda a comunicação falhou: pode existir, por exemplo, conectividade por IPv6. Também não prova que o router esteja avariado.

Conseguimos chegar ao router?

Consultar a gateway apresentada na ligação Wi-Fi. Se for 192.168.1.1, executar:

ping 192.168.1.1

Se a nossa gateway tiver outro endereço, substituí-lo no comando.

O ping envia pedidos de eco através de um protocolo chamado ICMP e espera uma resposta. Receber uma resposta de eco da gateway indica que conseguimos comunicar com ela naquele momento. Ainda não demonstra que conseguimos chegar à Internet.

Se surgir uma mensagem como Request timed out, o pedido ficou sem resposta dentro do tempo previsto. Pode existir um problema de comunicação, mas também pode haver filtragem destes pedidos. Um erro de destino inacessível também não é uma resposta de eco bem-sucedida.

É por isso que um ping sem resposta é uma pista, não um diagnóstico fechado. A documentação do comando descreve este teste de conectividade IP e as mensagens de tempo esgotado.

E um endereço fora da nossa rede?

Podemos agora testar um endereço IPv4 público, sem depender da tradução de um nome:

ping 1.1.1.1

O endereço 1.1.1.1 pertence ao serviço público de DNS da Cloudflare. Neste comando estamos apenas a testar respostas ICMP desse endereço; não estamos a fazer uma consulta DNS nem a alterar o servidor DNS do computador.

Se recebermos respostas de eco, há comunicação IPv4 de ida e volta até esse destino. É um resultado útil, mas não garante que todos os sites ou serviços funcionem.

Se o router responde e este destino não, vale a pena investigar o caminho para fora da rede. Continuam a existir várias hipóteses, incluindo filtragem do próprio teste. Não chega para atribuir a falha ao operador.

O DNS consegue resolver um nome?

Quando escrevemos um endereço como www.microsoft.com, precisamos de obter os endereços IP associados ao nome. É aqui que entra o DNS, o sistema de nomes de domínio.

Para fazer uma consulta:

nslookup www.microsoft.com

Sem um segundo argumento, o nslookup consulta o servidor DNS predefinido da ferramenta. Procurar os endereços devolvidos para o nome consultado: a simples apresentação do endereço do servidor DNS não significa que a consulta tenha sido bem-sucedida.

Se há comunicação com o IP externo, mas esta consulta falha, temos motivos para investigar a resolução de nomes. Não temos ainda uma prova de que basta mudar o DNS.

Numa rede doméstica, podemos comparar com uma consulta direta ao DNS público da Cloudflare:

nslookup www.microsoft.com 1.1.1.1

Este segundo comando não altera as definições do Windows. Se funcionar e o primeiro falhar, ajuda a concentrar a investigação no servidor predefinido ou no caminho até ele. Numa rede profissional, consultas a servidores externos podem ser bloqueadas por política.

A documentação de nslookup explica estes dois argumentos.

Há ainda um limite: o browser pode usar DNS sobre HTTPS e um fornecedor diferente do usado neste teste. A Mozilla explica esse funcionamento no Firefox. Uma consulta bem-sucedida no terminal não garante, por si só, que a resolução no browser esteja a funcionar da mesma forma.

Juntar as pistas antes de mudar definições

Os resultados ajudam a escolher o próximo passo:

O que observamos	O que faz sentido investigar
Só um site falha	O site e o acesso a esse destino.
Só um dispositivo falha	A ligação e a configuração desse dispositivo.
Surge um IPv4 de ligação local inesperado	A obtenção da configuração IPv4 por DHCP.
A gateway responde, mas o destino externo não	O caminho para fora da rede e eventuais filtros do teste.
O IP externo responde, mas a consulta DNS falha	A resolução de nomes e o acesso ao servidor DNS.
Os testes funcionam, mas o browser continua a falhar	O browser, o DNS que utiliza, proxy, VPN ou o serviço de destino.

Podemos experimentar outro browser para perceber se o comportamento se mantém. Se houver uma VPN ou proxy, convém verificar como participa na ligação; numa rede gerida, essa análise deve envolver o responsável técnico.

Reiniciar o router pode ajudar em algumas situações, mas interrompe a ligação dos restantes utilizadores. Se o fizermos, devemos distinguir um reinício de uma reposição de fábrica: carregar em Reset pode apagar configurações. A própria Microsoft reserva a reposição da rede do Windows para uma fase posterior do diagnóstico, devido às alterações que provoca.

Uma pergunta mais útil do que «a Internet está avariada?»

Nem sempre vamos conseguir resolver a falha sozinhos. Ainda assim, podemos chegar ao apoio técnico com informação muito melhor: que dispositivos falham, que configuração existe e que testes tiveram resposta.

Em vez de dizer apenas «tenho Wi-Fi, mas não tenho Internet», já conseguimos explicar: «acontece nos dois computadores; chegamos ao router, mas não recebemos resposta do destino externo». Isso reduz as hipóteses e evita recomeçar a investigação do zero.

O objetivo destes comandos é tornar o problema mais pequeno e compreensível. Quando sabemos até onde a comunicação funciona, a próxima ação deixa de depender tanto da sorte.