O Wi-Fi diz conectado, nada carrega: resolvedores do Mac obsoletos

Faça ping a um endereço literal e ele responde. Abra um site pelo nome e nada acontece, enquanto o ícone de rede insiste que a ligação está bem. Num Mac que acaba de entrar numa VPN, essa combinação quase sempre significa que as consultas apontam para um servidor que já não é acessível, não que a rede tenha caído. Os endereços foram fixados ao serviço Wi-Fi num momento anterior e nada os removeu desde então. Diagnostique por eliminação e depois apague as entradas fixadas.

A reparação é uma eliminação e não um esvaziamento, e a diferença importa porque os comandos que a maioria tenta primeiro fazem outra coisa completamente.

Conectado é uma afirmação sobre a ligação

O macOS mantém uma configuração de resolvedor por serviço de rede. Os valores do DHCP são uma fonte, os escritos à mão outra, e os que um perfil empurra ou um cliente escreve são uma terceira. Os fixados têm precedência sobre o que a rede oferece, e nada na pilha os revalida. Por isso um servidor que desapareceu fica na lista até uma pessoa o remover ou o serviço ser reconstruído de raiz.

É por isso que um túnel que conclui o seu handshake não muda nada numa consulta que já estava mal encaminhada. A VPN acrescentou um resolvedor; não auditou o que estava a falhar.

Separe os nomes dos pacotes

Chegue primeiro a um anfitrião pelo endereço literal. Quando carrega, os pacotes estão bem e a culpa é do resolvedor. Quando não carrega, pare aí e trate o problema como de encaminhamento, porque as alterações de DNS só acrescentarão uma variável a um quadro já confuso.

Um nome que falha enquanto o endereço correspondente funciona é a impressão digital. Repare também no âmbito: se falhar tudo, aponta para uma entrada global avariada, enquanto se falharem apenas os anfitriões dentro do túnel, aponta para outro responsável e uma correção mais estreita.

Apague os servidores fixados

Nas Definições de Rede, abra os detalhes do serviço Wi-Fi e mude para o separador DNS. Remova cada linha de servidor, confirme a alteração e depois percorra os domínios de pesquisa à procura de valores que nunca acrescentou. Deixe a lista vazia, volte a ligar o serviço e confirme que o endereço fornecido pelo DHCP reaparece sozinho. Uma lista vazia é o estado temporário que prova que os valores fixados eram o problema.

As versões mais antigas escondem o mesmo painel um nível mais abaixo, atrás de um botão Avançado, com comportamento idêntico e o mesmo resultado.

Leia o estado, não o painel

scutil --dns | head -40 imprime os resolvedores que o macOS usa de facto, agrupados por âmbito, e um nslookup rápido de um nome interno conhecido mostra se chega alguma resposta. Compare as duas saídas: um painel limpo com um servidor obsoleto ainda listado significa que outro escritor é dono dessa definição. É outro erro, com outra correção.

Quando ambos parecem limpos e os nomes continuam a falhar, a avaria mudou de sítio e já não está a depurar a configuração de DNS.

Quem volta a pôr as entradas

Os servidores que regressam depois de apagados têm uma origem. Verifique a Gestão de Dispositivos quanto a um perfil de configuração, porque os perfis podem transportar DNS e são reavaliados segundo o seu próprio calendário. Verifique as preferências do cliente quanto a uma opção de definir DNS ao ligar, e decida se ainda merece o seu lugar nesta máquina. Se a VPN precisa mesmo de um resolvedor privado, limite-o aos domínios que possui em vez de escrever na lista global que toda a rede futura herda.

Registe o resolvedor pretendido e os domínios a que deve responder. Após a próxima atualização do cliente, verifique um nome público e um privado, o que é mais rápido do que repetir a volta pelas definições e apanha a regressão enquanto a máquina ainda está nas suas mãos.

Tudo o resto é teatro de manutenção: comandos que parecem deliberados, não mudam nada de mensurável e deixam a mesma consulta avariada para a pessoa seguinte.