IP 169.254 no Windows mostrando falha de DHCP, APIPA e diagnóstico de rede com ipconfig. — IP 169.254 no Windows pode aparecer quando o computador não consegue obter uma configuração IPv4 válida pelo servidor DHCP.

66 / 100

Desenvolvido por Rank Math SEO

Pontuação de SEO

Você liga o computador, conecta o cabo de rede ou entra normalmente no Wi-Fi, mas percebe que a Internet não funciona. O ícone de rede pode indicar uma conexão sem acesso à Internet, alguns recursos da rede local deixam de responder e, ao executar o comando ipconfig, aparece um endereço estranho começando com 169.254.

Um endereço como 169.254.83.17 não surgiu por acaso. Na maioria das situações, ele é uma pista extremamente importante: o Windows tentou conseguir um endereço IPv4 automaticamente por DHCP, não recebeu uma configuração adequada e passou a utilizar um endereço automático local.

Esse mecanismo é conhecido como APIPA — Automatic Private IP Addressing.

Para quem utiliza o computador apenas no dia a dia, o IP 169.254 pode parecer simplesmente mais um erro de Internet. Para um técnico, porém, ele ajuda a reduzir drasticamente o campo de investigação. Em vez de começar alterando DNS, reinstalando navegador ou reiniciando aleatoriamente equipamentos, podemos investigar uma pergunta muito mais específica:

Por que este computador não está conseguindo receber sua configuração IPv4 pelo DHCP?

A resposta pode estar no próprio Windows, no adaptador de rede, no Wi-Fi, no cabo, no switch, no roteador, em uma rede Mesh, em uma VLAN ou no servidor DHCP.

Neste guia da VMIA, vamos entender o que realmente significa um endereço 169.254 no Windows, como funciona o DHCP, por que o APIPA existe e como localizar o ponto da rede responsável pela falha.

O que significa um endereço IP 169.254 no Windows?

Em uma rede doméstica comum, o computador normalmente recebe automaticamente informações como:

endereço IPv4;
máscara de sub-rede;
gateway padrão;
servidores DNS.

Essas informações geralmente são fornecidas por um servidor DHCP (Dynamic Host Configuration Protocol).

Em muitas residências e pequenos escritórios, quem desempenha essa função é o próprio roteador.

Por exemplo, uma rede pode utilizar:

192.168.1.0/24

O roteador pode estar configurado como:

192.168.1.1

E distribuir automaticamente endereços como:

192.168.1.100
192.168.1.101
192.168.1.102

Quando um notebook entra nessa rede, ele não precisa saber previamente qual endereço está disponível. O DHCP realiza essa configuração automaticamente.

O problema começa quando o computador solicita essa configuração e não consegue obtê-la.

O Windows não simplesmente desativa o adaptador. Ele pode atribuir automaticamente um endereço da faixa reservada para IPv4 Link-Local, tradicionalmente associada ao APIPA no Windows.

É daí que aparece o famoso:

169.254.x.x

Portanto, encontrar um IP 169.254 é muito diferente de simplesmente descobrir que “a Internet está fora”.

É um indício de que precisamos investigar a configuração IPv4 automática e o caminho até o DHCP.

O IP 169.254 significa que a placa de rede está quebrada?

Não necessariamente.

Esse é um erro comum durante o diagnóstico.

Se o Windows apresenta um endereço 169.254, existe uma série de possibilidades antes de concluir que o adaptador de rede apresentou defeito físico.

O problema pode estar em:

comunicação com o roteador;
servidor DHCP indisponível;
cabo defeituoso;
porta do switch;
configuração da placa;
driver;
serviço DHCP Client do Windows;
configuração incorreta do roteador;
rede Mesh;
VLAN;
pool DHCP;
conflito de equipamentos na rede.

Por isso, trocar imediatamente a placa de rede raramente é uma boa primeira tentativa.

O endereço APIPA deve ser tratado como sintoma, não como causa.

Antes do 169.254: entenda como o computador recebe um IP

Para entender por que o problema acontece, precisamos acompanhar o que ocorre quando um computador entra em uma rede.

Imagine um notebook que acabou de se conectar ao Wi-Fi.

Ele ainda não possui um endereço IPv4 válido daquela rede e precisa descobrir quem pode fornecer um.

De forma simplificada, uma concessão DHCP inicial costuma seguir quatro etapas conhecidas pela sigla:

DORA

Discover → Offer → Request → Acknowledge

Vamos entender cada uma.

1. DHCP Discover

O computador entra na rede e procura um servidor DHCP.

É como se perguntasse:

“Existe algum servidor DHCP nesta rede que possa me fornecer uma configuração?”

Como o computador ainda não conhece completamente a rede, essa descoberta utiliza mecanismos de broadcast no segmento local.

2. DHCP Offer

Se existir um servidor DHCP acessível e funcionando, ele pode responder oferecendo uma configuração.

Por exemplo:

IP: 192.168.1.117
Máscara: 255.255.255.0
Gateway: 192.168.1.1
DNS: conforme definido pelo administrador ou roteador.

É a proposta de concessão.

3. DHCP Request

O computador solicita formalmente a configuração oferecida.

É como responder:

“Quero utilizar esse endereço que você ofereceu.”

4. DHCP Acknowledge

Finalmente, o servidor confirma a concessão.

O computador passa a utilizar aquela configuração pelo período determinado pelo lease, ou tempo de concessão DHCP.

Podemos resumir:

Computador
↓
DHCP Discover
↓
Servidor DHCP
↓
DHCP Offer
↓
Computador
↓
DHCP Request
↓
Servidor DHCP
↓
DHCP ACK
↓
IP configurado

Quando tudo funciona corretamente, o usuário nem percebe que esse processo aconteceu.

Onde o processo pode falhar?

Praticamente em qualquer ponto do caminho.

Imagine:

Computador → Wi-Fi → Access Point → Switch → Roteador/DHCP

Se o computador envia a solicitação, mas ela não chega ao servidor DHCP, não haverá oferta.

Da mesma maneira, o servidor pode responder, mas algum problema de rede pode impedir que a resposta chegue corretamente ao cliente.

Isso explica por que simplesmente olhar para o ícone do Wi-Fi pode enganar.

O computador pode estar perfeitamente associado ao ponto de acesso e, ainda assim, não conseguir obter uma configuração IPv4 válida.

Estar conectado ao Wi-Fi não significa automaticamente que o DHCP está funcionando.

Wi-Fi conectado e IP 169.254: como isso é possível?

Essa situação confunde muitos usuários.

O Windows mostra:

Conectado ao Wi-Fi

mas o endereço IPv4 é:

169.254.x.x

Isso acontece porque são etapas diferentes.

Primeiro, o computador estabelece comunicação com a rede sem fio. Depois, protocolos de camada superior precisam fornecer a configuração necessária para a comunicação IP.

Assim, é perfeitamente possível ter:

Wi-Fi conectado
↓
DHCP falhou
↓
IP 169.254
↓
Sem acesso IPv4 normal à rede

É justamente por isso que o diagnóstico não deve parar na frase “o Wi-Fi está conectado”.

Como descobrir se o Windows realmente recebeu um APIPA

A maneira mais simples é utilizar o ipconfig.

Abra o Prompt de Comando e execute:

ipconfig

Procure o adaptador utilizado.

Pode aparecer algo semelhante a:

Adaptador de Rede sem Fio Wi-Fi:

   Endereço IPv4 de Configuração Automática. . : 169.254.83.17
   Máscara de Sub-rede . . . . . . . . . . . : 255.255.0.0

Isso já oferece uma pista importante.

Mas para um diagnóstico melhor, utilize:

ipconfig /all

Esse comando apresenta informações muito mais completas.

O que observar no ipconfig /all?

O ipconfig /all é uma das ferramentas mais importantes para investigar esse tipo de problema.

Procure informações como:

DHCP habilitado;
endereço IPv4;
máscara;
gateway padrão;
servidor DHCP;
servidores DNS;
endereço físico (MAC);
estado da mídia;
tempo de concessão.

Se aparecer:

DHCP habilitado: Sim

e ao mesmo tempo:

IPv4: 169.254.x.x

temos um forte indício de que o computador está configurado para obter IP automaticamente, mas não conseguiu completar adequadamente o processo DHCP.

Um detalhe fundamental: verifique o gateway padrão

Esse é um dos pontos mais úteis do diagnóstico.

Em uma configuração doméstica normal, esperamos encontrar algo como:

IPv4: 192.168.1.105
Máscara: 255.255.255.0
Gateway: 192.168.1.1

Quando o computador cai em APIPA, é comum não existir um gateway padrão IPv4 funcional associado àquela configuração.

Sem um gateway adequado, o computador não possui a rota normal para alcançar redes externas.

Por isso, alterar apenas o DNS normalmente não resolve esse cenário.

Trocar o DNS resolve um IP 169.254?

Na maioria dos casos, não.

Esse é um dos erros mais frequentes em tutoriais genéricos de Internet.

DNS e DHCP são serviços diferentes.

O DNS ajuda a converter nomes como:

vmia.com.br

em endereços IP.

Mas antes de utilizar normalmente um DNS localizado fora do segmento local, o computador precisa possuir uma configuração de rede funcional.

Se a máquina está com:

169.254.x.x

sem gateway adequado, trocar o DNS para um servidor público não corrige a causa da falha de DHCP.

O primeiro objetivo deve ser descobrir:

Por que o computador não recebeu a configuração correta?

IP 169.254 também não significa necessariamente problema da operadora

Outro erro comum é ligar imediatamente para a operadora.

Imagine a seguinte situação:

celular conectado ao Wi-Fi funciona;
Smart TV funciona;
outro notebook funciona;
apenas um computador apresenta 169.254.

Nesse cenário, a conexão da operadora provavelmente não é o primeiro ponto a investigar.

O problema está mais provavelmente no caminho entre aquele dispositivo e o serviço DHCP.

Agora considere outra situação:

todos os computadores recebem 169.254;
celulares não conseguem obter IP;
dispositivos novos não entram corretamente na rede.

Nesse caso, o roteador ou o serviço DHCP passa a ser um suspeito muito mais forte.

Comparar dispositivos é uma das técnicas mais simples e eficientes para reduzir o campo de investigação.

Primeiro diagnóstico: o problema acontece em um ou em todos os dispositivos?

Antes de executar dezenas de comandos, responda a essa pergunta.

Somente um computador apresenta 169.254

Investigue primeiro:

Windows;
adaptador;
driver;
configuração IPv4;
serviço DHCP Client;
cabo;
porta específica;
perfil/configuração daquela conexão.

Vários dispositivos apresentam o problema

Investigue:

roteador;
servidor DHCP;
switch;
Access Point;
Mesh;
VLAN;
configuração da rede;
pool de endereços.

Essa divisão evita perder tempo.

O cabo de rede também pode causar IP 169.254?

Sim.

Se estivermos falando de Ethernet, não devemos analisar apenas software.

Um cabo danificado pode apresentar comportamento intermitente ou impedir a comunicação adequada.

Também podem existir problemas em:

conectores RJ45;
tomada de rede;
patch panel;
switch;
porta LAN do roteador;
adaptador Ethernet.

Porém, existe uma distinção importante.

Se o Windows mostrar:

Cabo de rede desconectado

o cenário é diferente daquele em que existe link Ethernet, mas o DHCP falha.

Por isso, verificar o estado físico da conexão vem antes de executar comandos de reparo.

O perigo de colocar IP fixo imediatamente

Imagine que o computador esteja recebendo:

169.254.45.20

O usuário descobre que a rede utiliza:

192.168.1.x

e configura manualmente:

IP: 192.168.1.200
Máscara: 255.255.255.0
Gateway: 192.168.1.1
DNS: 8.8.8.8

A Internet volta.

Problema resolvido?

Não necessariamente.

Você pode ter apenas contornado a falha.

Se o DHCP continua sem funcionar para aquele computador, ainda existe uma causa a ser encontrada.

Além disso, escolher manualmente um endereço sem conhecer o planejamento da rede pode provocar conflito de IP.

O IP fixo é extremamente útil quando utilizado de maneira planejada, principalmente para equipamentos que precisam manter endereços previsíveis. Porém, utilizá-lo apenas para esconder uma falha de DHCP pode dificultar o diagnóstico.

IP fixo e reserva DHCP não são a mesma coisa

Essa diferença merece atenção.

No IP estático configurado no dispositivo, o próprio equipamento recebe manualmente seus parâmetros de rede.

Em uma reserva DHCP, o dispositivo continua solicitando configuração ao servidor DHCP, mas o servidor reserva determinado endereço para aquele cliente, geralmente associando-o ao identificador esperado, como o endereço MAC.

Isso permite manter o gerenciamento centralizado no DHCP.

Para impressoras, computadores, servidores domésticos e determinados dispositivos de rede, uma reserva DHCP pode ser muito útil.

Mas novamente:

uma reserva DHCP não resolve um servidor DHCP que deixou de responder.

APIPA não é um endereço “inventado” pelo Windows

É importante esclarecer outro ponto.

A faixa 169.254.0.0/16 está associada ao mecanismo de endereçamento IPv4 link-local.

Portanto, quando o Windows utiliza um endereço 169.254, ele não está escolhendo um número completamente aleatório sem qualquer regra.

O objetivo é permitir comunicação local limitada entre dispositivos compatíveis mesmo quando uma configuração IPv4 convencional não está disponível.

Mas isso não substitui uma configuração completa de rede.

Dois computadores com 169.254 conseguem conversar?

Em determinadas condições, sim.

Se dois dispositivos estiverem no mesmo segmento físico/lógico e utilizarem endereços IPv4 link-local adequados, pode existir comunicação local entre eles.

Isso é justamente parte da finalidade do mecanismo.

Porém, isso não significa que terão acesso normal à Internet.

A diferença é fundamental:

Comunicação local ≠ acesso à Internet

Um computador pode comunicar-se com outro equipamento local e continuar incapaz de alcançar serviços externos.

A primeira conclusão do diagnóstico

Quando encontramos um endereço 169.254.x.x, não devemos perguntar apenas:

“Por que minha Internet não funciona?”

A pergunta tecnicamente mais útil é:

“Por que este dispositivo não conseguiu obter a configuração IPv4 que deveria receber?”

Essa mudança aparentemente pequena transforma completamente o diagnóstico.

Em vez de trocar DNS, navegador, antivírus ou realizar uma formatação desnecessária, começamos a investigar o caminho correto:

Windows → adaptador → conexão → rede local → servidor DHCP

Na primeira parte, vimos que um endereço IPv4 começando com 169.254 normalmente aparece quando o Windows está configurado para receber um endereço automaticamente, mas não consegue obter uma configuração IPv4 adequada por DHCP. O sistema então pode utilizar o endereçamento IPv4 link-local, conhecido no Windows pelo mecanismo APIPA.

Agora começa a etapa mais importante: descobrir onde o processo está falhando.

Em vez de executar vários comandos aleatoriamente, vamos seguir o caminho lógico da comunicação:

Windows → adaptador → Wi-Fi/Ethernet → rede local → roteador/servidor DHCP

Essa sequência permite separar um problema do computador de uma falha na infraestrutura da rede.

1. Comece verificando a configuração completa com ipconfig /all

Abra o Prompt de Comando e execute:

ipconfig /all

Não observe apenas o endereço IPv4.

Analise também:

DHCP habilitado;
endereço IPv4;
máscara de sub-rede;
gateway padrão;
servidor DHCP;
servidores DNS;
endereço físico;
estado da mídia;
informações da concessão DHCP.

Se o computador estiver configurado para DHCP, mas apresentar algo semelhante a:

IPv4: 169.254.83.17
Máscara: 255.255.0.0
Gateway:

já temos uma pista muito forte de que ele não recebeu a configuração IPv4 esperada da rede.

2. Verifique se o adaptador está realmente configurado para DHCP

Antes de culpar o roteador, confirme se o próprio Windows está configurado corretamente.

Pressione:

Windows + R

Digite:

ncpa.cpl

Pressione Enter.

Clique com o botão direito sobre o adaptador utilizado e escolha:

Propriedades

Selecione:

Protocolo IP Versão 4 (TCP/IPv4)

Clique em:

Propriedades

Em uma rede que utiliza DHCP, normalmente esperamos:

Obter um endereço IP automaticamente

e, quando a rede também distribui DNS automaticamente:

Obter o endereço dos servidores DNS automaticamente

Se existir um IP estático antigo configurado manualmente, o comportamento poderá ser completamente diferente.

Esse problema é comum em notebooks utilizados em diferentes ambientes.

Por exemplo, alguém configura manualmente:

192.168.0.50

em uma empresa.

Depois leva o notebook para casa, onde a rede utiliza:

192.168.1.x

A configuração anterior deixa de fazer sentido.

Por isso, sempre confira as propriedades IPv4 antes de avançar.

3. Force uma nova tentativa de DHCP

Se a configuração estiver correta, podemos solicitar uma nova concessão.

Abra o Prompt de Comando como administrador e execute:

ipconfig /release

Depois:

ipconfig /renew

O primeiro comando libera a configuração DHCP existente quando aplicável.

O segundo solicita uma nova configuração.

Depois execute novamente:

ipconfig /all

Se tudo funcionar, o endereço 169.254 deverá ser substituído por um IP compatível com a rede.

Por exemplo:

IPv4: 192.168.1.117
Máscara: 255.255.255.0
Gateway: 192.168.1.1

4. O ipconfig /renew demora e termina com erro

Esse comportamento é extremamente útil para o diagnóstico.

Se o comando permanece algum tempo tentando renovar a configuração e depois apresenta erro, isso reforça a suspeita de que o computador não está conseguindo completar a comunicação com o DHCP.

Nesse momento, não adianta simplesmente repetir o comando dez vezes.

Precisamos descobrir onde a comunicação está sendo interrompida.

5. Teste outro dispositivo na mesma rede

Esse é um dos testes mais importantes de todo o processo.

Pegue:

outro notebook;
celular;
tablet;
outro computador.

Conecte-o à mesma rede.

Depois observe se esse dispositivo consegue receber um endereço válido.

Se outros dispositivos recebem IP normalmente

O servidor DHCP provavelmente está funcionando.

A investigação passa a se concentrar no computador problemático.

Se vários dispositivos recebem 169.254 ou não conseguem obter IP

A suspeita muda para:

roteador;
servidor DHCP;
Access Point;
switch;
Mesh;
VLAN;
configuração da infraestrutura.

Esse teste simples pode economizar muito tempo.

6. Faça um teste cruzado com o mesmo computador

Agora podemos inverter o teste.

Se o notebook apresenta 169.254 no Wi-Fi de casa, conecte-o, quando possível, a outra rede.

Por exemplo:

hotspot do celular;
outra rede Wi-Fi;
outra porta Ethernet;
outro roteador.

Se ele recebe IP normalmente em outra rede, isso indica que:

o adaptador e o Windows conseguem utilizar DHCP em pelo menos outro ambiente.

A investigação então volta para a rede original.

Por outro lado, se o notebook apresenta problemas de DHCP em todas as redes, aumenta a suspeita sobre:

Windows;
driver;
adaptador;
serviços;
pilha de rede;
softwares de terceiros.

7. Verifique o serviço Cliente DHCP do Windows

O Windows possui um serviço responsável por tarefas relacionadas à configuração dinâmica da rede.

Pressione:

Windows + R

Digite:

services.msc

Procure:

Cliente DHCP

O serviço normalmente deve estar em funcionamento.

Se estiver parado ou apresentando comportamento anormal, o Windows poderá ter dificuldades para obter e renovar configurações de rede.

Evite alterar serviços aleatoriamente. Primeiro confirme o estado e investigue por que determinado serviço deixou de funcionar.

8. Reiniciar o adaptador pode ajudar?

Sim, principalmente quando o problema está relacionado ao estado do adaptador ou do driver.

Abra:

ncpa.cpl

Clique com o botão direito no adaptador.

Escolha:

Desabilitar

Aguarde alguns segundos.

Depois escolha:

Habilitar

O Windows fará uma nova tentativa de estabelecer a conexão.

Em Wi-Fi, também pode ser útil desconectar-se da rede e conectar novamente.

Depois verifique:

ipconfig /all

9. Esquecer a rede Wi-Fi pode resolver?

Em problemas específicos de Wi-Fi, sim.

O Windows armazena um perfil para cada rede sem fio conhecida.

Esse perfil contém informações necessárias para aquela conexão.

Se houver alguma inconsistência, remover o perfil e conectar novamente pode ajudar.

No Windows 11, acesse:

Configurações → Rede e Internet → Wi-Fi → Gerenciar redes conhecidas

Selecione a rede e escolha:

Esquecer

Depois conecte novamente e informe a senha.

Isso força o Windows a recriar o perfil daquela rede.

10. Wi-Fi conectado não significa DHCP funcionando

Esse conceito merece ser reforçado.

O computador pode autenticar corretamente no Wi-Fi e continuar sem receber configuração DHCP.

Podemos representar assim:

Notebook
↓
✅ conectado ao Access Point
↓
❌ DHCP não responde
↓
169.254.x.x

Portanto, não devemos concluir que toda a comunicação está funcionando apenas porque o Windows mostra:

Conectado

11. Verifique o driver da placa de rede

Drivers corrompidos, incompatíveis ou com comportamento anormal também podem causar problemas.

Abra o:

Gerenciador de Dispositivos

Expanda:

Adaptadores de rede

Localize a placa utilizada.

Observe se existe:

símbolo de alerta;
dispositivo desconhecido;
erro de inicialização;
adaptador desabilitado.

Em alguns casos, atualizar o driver diretamente pelo fabricante do notebook, placa-mãe ou adaptador pode ser mais adequado do que depender apenas de drivers genéricos.

Também é importante lembrar que driver mais novo não significa automaticamente driver melhor. Uma versão recém-instalada pode introduzir problemas em determinados equipamentos.

Se a falha começou imediatamente após uma atualização, investigar a versão anterior também pode fazer sentido.

12. Cuidado ao desinstalar o adaptador

Um procedimento comum é remover o adaptador pelo Gerenciador de Dispositivos para que o Windows o detecte novamente.

Isso pode ajudar em determinados casos, mas deve ser feito com cuidado.

Antes de remover drivers de rede, principalmente em computadores que dependem exclusivamente daquela conexão, tenha uma forma de reinstalar o driver.

Caso contrário, você pode transformar um problema de DHCP em um computador completamente sem conectividade.

13. Ethernet: verifique o link antes do DHCP

Se o problema acontece pelo cabo de rede, observe primeiro o estado físico da conexão.

O Windows pode indicar:

Cabo de rede desconectado

Nesse caso, executar ipconfig /renew não corrige um cabo desconectado.

Verifique:

cabo;
conector;
porta LAN;
switch;
tomada de rede;
adaptador.

Se possível, faça testes cruzados:

Mesmo computador + outro cabo

Mesmo cabo + outro computador

Mesmo computador + outra porta do roteador

Essa metodologia ajuda a isolar o componente defeituoso.

14. O switch pode impedir o DHCP?

Sim.

Em uma rede simples, um switch comum normalmente apenas encaminha o tráfego Ethernet necessário entre os dispositivos.

Mas existem cenários em que o caminho até o DHCP pode ser interrompido.

Isso pode acontecer devido a:

porta defeituosa;
configuração incorreta;
VLAN;
recursos de segurança;
problemas de cabeamento;
loops ou instabilidade da rede;
switch gerenciável configurado incorretamente.

Faça um teste importante:

Se possível, conecte temporariamente o computador diretamente ao roteador.

Se o DHCP voltar a funcionar, algum componente intermediário merece investigação.

15. Redes Mesh podem complicar o diagnóstico

Uma rede Mesh adiciona novos elementos ao caminho.

Dependendo da arquitetura, podemos ter:

Notebook → nó Mesh → nó principal → roteador → DHCP

ou:

Notebook → Mesh principal funcionando como roteador/DHCP

A configuração incorreta do modo de operação pode causar comportamentos difíceis de interpretar.

É importante saber se o equipamento Mesh está funcionando como:

roteador;
Access Point;
bridge.

Se dois equipamentos estiverem configurados para desempenhar funções de roteamento ou DHCP de forma inadequada, a rede poderá apresentar problemas.

Por isso, em redes Mesh, não basta perguntar:

“O Wi-Fi está funcionando?”

Precisamos entender quem realmente está entregando DHCP.

16. Dois servidores DHCP podem causar problemas?

Sim.

Imagine uma rede em que o modem/roteador da operadora possui DHCP habilitado e um segundo roteador também foi conectado incorretamente à mesma rede LAN com seu próprio DHCP ativo.

Agora dois equipamentos podem responder às solicitações dos clientes.

Dependendo da configuração, dispositivos diferentes podem receber:

gateways diferentes;
DNS diferentes;
faixas IP diferentes.

O comportamento pode parecer aleatório.

Um computador funciona.

Outro não.

Uma impressora muda de endereço.

Um terceiro dispositivo recebe uma configuração inesperada.

Por isso, descobrir quem é o servidor DHCP é uma etapa importante em redes com vários roteadores.

17. Como descobrir quem forneceu o DHCP

Depois que o computador consegue obter uma configuração válida, execute:

ipconfig /all

Procure:

Servidor DHCP

Pode aparecer, por exemplo:

Servidor DHCP: 192.168.1.1

Isso ajuda a identificar qual equipamento está entregando a configuração.

Em uma rede simples, normalmente será o roteador.

Em ambientes empresariais, pode ser um servidor dedicado ou outro equipamento de infraestrutura.

18. O pool DHCP pode acabar?

Sim.

O servidor DHCP normalmente possui uma faixa de endereços disponíveis.

Por exemplo:

192.168.1.100 até 192.168.1.199

Isso fornece um conjunto limitado de endereços para concessão.

Se muitos dispositivos utilizarem a rede e a configuração não estiver adequada, o servidor poderá ficar sem endereços disponíveis para novos clientes.

Isso é mais comum em ambientes com:

muitos smartphones;
dispositivos IoT;
câmeras;
computadores;
impressoras;
visitantes;
leases muito longos.

Nesse cenário, alguns dispositivos antigos podem continuar funcionando enquanto novos equipamentos têm dificuldade para obter IP.

19. Reiniciar o roteador resolve?

Pode resolver temporariamente, mas não devemos transformar isso em diagnóstico.

Reiniciar um roteador pode:

limpar estados temporários;
reiniciar o serviço DHCP;
recuperar processos travados;
restabelecer interfaces.

Se o problema desaparece depois da reinicialização e retorna frequentemente, existe algo a investigar.

Pode haver:

firmware instável;
pool inadequado;
excesso de dispositivos;
configuração incorreta;
defeito do equipamento.

A pergunta correta não é apenas:

“Reiniciar resolveu?”

Mas:

“Por que preciso reiniciar o roteador constantemente para o DHCP voltar?”

20. Firewall pode bloquear DHCP?

Dependendo da configuração, softwares de segurança, firewalls de terceiros, VPNs e filtros de rede podem interferir no tráfego.

Isso é especialmente relevante quando:

o problema começou após instalar uma VPN;
um pacote de segurança foi instalado;
existe software corporativo;
filtros de rede foram adicionados;
adaptadores virtuais apareceram.

Não significa que devemos desinstalar imediatamente o antivírus ou desligar permanentemente o firewall.

O objetivo é observar a linha do tempo:

O que mudou antes do problema começar?

Essa pergunta frequentemente revela a causa.

21. VPN e adaptadores virtuais

Programas de VPN e virtualização podem criar adaptadores adicionais.

Exemplos incluem interfaces utilizadas por:

VPN;
Hyper-V;
VMware;
VirtualBox;
containers;
softwares de segurança.

Esses adaptadores não significam necessariamente que exista um problema.

Porém, configurações incorretas de bridge, métricas ou filtros podem complicar o diagnóstico.

Por isso, ao executar:

ipconfig /all

identifique corretamente qual adaptador físico está sendo utilizado.

Não confunda o IPv4 de uma interface virtual com o endereço do Wi-Fi ou Ethernet real.

22. Resetar a pilha de rede deve ser o primeiro passo?

Não.

Comandos de reset podem ser úteis, mas prefiro utilizá-los depois dos testes básicos.

Antes, descubra:

O DHCP está habilitado?
Outros dispositivos funcionam?
Esse computador funciona em outra rede?
O link físico está ativo?
O serviço Cliente DHCP funciona?
O driver parece normal?

Se tudo isso estiver correto, podemos considerar reparos adicionais.

Entre os comandos utilizados em diagnósticos de rede estão:

netsh winsock reset

netsh int ip reset

Depois desses procedimentos, normalmente é necessário reiniciar o Windows.

Mas existe um princípio importante:

não execute comandos apenas porque aparecem em uma lista de “10 comandos para consertar a Internet”.

Cada comando deve ter um motivo.

23. DNS ainda não é nossa prioridade

Suponha que o computador continue apresentando:

169.254.72.41

e não tenha gateway IPv4 adequado.

Alterar:

8.8.8.8

ou:

1.1.1.1

não corrige o processo DHCP.

Primeiro precisamos restaurar uma configuração IP funcional.

Depois, caso a Internet continue sem resolver nomes, investigamos DNS.

Essa separação evita diagnósticos confusos.

24. Um IP fixo pode ser usado como teste?

Em mãos técnicas, sim.

Uma configuração manual temporária pode ajudar a determinar se existe comunicação IP com a rede quando o DHCP falha.

Por exemplo, se sabemos com certeza que:

Rede: 192.168.1.0/24
Roteador: 192.168.1.1

podemos selecionar cuidadosamente um endereço livre para realizar um teste.

Se, com configuração manual, o computador consegue:

alcançar o roteador;
comunicar-se com dispositivos;
acessar a Internet;

mas volta para 169.254 quando retorna ao DHCP, temos uma pista muito forte:

a conectividade IP pode funcionar, mas a obtenção automática da configuração está falhando.

Esse é um teste diagnóstico, não uma desculpa para deixar um endereço aleatório configurado permanentemente.

25. Não escolha qualquer IP para esse teste

Configurar:

192.168.1.50

sem saber se esse endereço já pertence a outro dispositivo pode gerar conflito.

Antes de utilizar IP manual, o técnico deve conhecer:

faixa da rede;
máscara;
gateway;
pool DHCP;
endereços reservados;
dispositivos com IP estático.

Uma configuração feita sem essas informações pode criar um segundo problema enquanto tentamos resolver o primeiro.

26. Monte uma árvore de diagnóstico

Até aqui já conseguimos criar uma sequência prática.

O computador apresenta 169.254

↓

Outros dispositivos funcionam?

SIM

↓

Teste o mesmo computador em outra rede.

Funciona em outra rede?

SIM

↓

Investigue a rede original, perfil, porta, Access Point e regras específicas.

Não funciona em nenhuma rede?

↓

Investigue Windows, adaptador, driver, DHCP Client, filtros e pilha de rede.

Agora outro cenário:

Nenhum dispositivo consegue DHCP

↓

Investigue:

roteador → servidor DHCP → pool → switch → VLAN → Mesh → configuração da infraestrutura

Essa metodologia é muito mais eficiente do que simplesmente reiniciar tudo.

27. O 169.254 é uma pista, não o defeito

Essa é provavelmente a ideia mais importante deste artigo.

Quando você vê:

169.254.x.x

não encontrou necessariamente o defeito.

Você encontrou uma evidência do que deixou de acontecer corretamente.

O computador deveria receber uma configuração adequada.

Não recebeu.

Agora precisamos localizar onde a negociação falhou.

É justamente essa forma de pensar que diferencia uma tentativa aleatória de um diagnóstico técnico.

Próxima etapa: quando o problema está escondido na infraestrutura

Depois dos testes desta Parte 2, já conseguimos separar muitos problemas do Windows daqueles relacionados à rede.

Mas existem casos mais difíceis.

O DHCP pode funcionar para alguns dispositivos e falhar para outros. Uma rede Mesh pode estar operando em modo inadequado. Uma VLAN pode impedir broadcasts. Um roteador pode ter um pool esgotado. Um segundo servidor DHCP pode distribuir parâmetros errados. Uma reserva pode estar configurada incorretamente.

IP 169.254 no Windows: DHCP, Mesh, VLAN e diagnóstico avançado

Nas duas primeiras partes deste guia, vimos que o endereço 169.254.x.x deve ser tratado como uma pista. O Windows está mostrando que não conseguiu obter a configuração IPv4 esperada automaticamente e passou a utilizar um endereço IPv4 link-local.

Também construímos uma sequência de diagnóstico que separa problemas do computador daqueles relacionados à infraestrutura:

Windows → adaptador → Wi-Fi/Ethernet → switch/AP/Mesh → roteador → servidor DHCP

Agora vamos aprofundar os casos em que reiniciar o adaptador, renovar o IP ou testar outro cabo não resolve. São situações nas quais precisamos entender melhor o caminho percorrido pelos pacotes DHCP e descobrir exatamente onde a comunicação está sendo interrompida.

DHCP usa UDP: por que isso importa?

O DHCP utiliza principalmente:

UDP 67 — servidor DHCP;
UDP 68 — cliente DHCP.

Quando um computador entra em uma rede sem possuir ainda uma configuração IPv4 válida, ele precisa encontrar quem pode fornecer uma.

É por isso que a descoberta inicial possui características diferentes de uma conexão convencional entre dois dispositivos que já conhecem seus respectivos endereços.

Simplificando:

Cliente
   ↓
DHCP Discover
   ↓
Servidor DHCP
   ↓
DHCP Offer
   ↓
Cliente
   ↓
DHCP Request
   ↓
Servidor DHCP
   ↓
DHCP ACK

Se interrompermos esse fluxo em qualquer ponto, o computador poderá não obter a configuração esperada.

Descobrir em qual etapa do DORA ocorre a falha

Nas partes anteriores, utilizamos o DORA:

Discover → Offer → Request → Acknowledge

Agora podemos utilizá-lo como ferramenta de diagnóstico.

Caso 1: Discover sai, mas não existe Offer

O cliente está tentando localizar um servidor DHCP, porém nenhuma oferta retorna.

Possíveis causas:

servidor DHCP desligado;
DHCP desabilitado no roteador;
problema no switch;
VLAN incorreta;
falha no Access Point;
problema no Mesh;
bloqueio de tráfego;
ausência de DHCP Relay quando necessário;
falha do próprio servidor.

Nesse cenário, o Windows pode continuar tentando até recorrer ao endereço link-local.

Caso 2: Discover e Offer aparecem, mas o processo não termina

Aqui o servidor está respondendo.

Isso muda bastante o diagnóstico.

Se existe um DHCP Offer, significa que a solicitação chegou a um servidor capaz de oferecer configuração.

Precisamos então investigar as etapas seguintes:

Request → ACK

Problemas de comunicação, políticas do servidor, configurações incorretas ou situações específicas da infraestrutura podem impedir a conclusão da concessão.

Essa é uma das razões pelas quais capturar o tráfego pode ser tão útil em casos difíceis.

Como o Wireshark ajuda no diagnóstico do DHCP

O Wireshark permite visualizar pacotes que entram e saem da interface de rede.

Em um diagnóstico avançado, podemos iniciar uma captura e observar a negociação DHCP.

Um filtro útil é:

bootp

Embora o protocolo seja DHCP, o Wireshark tradicionalmente utiliza o filtro bootp para esse tráfego em muitos contextos.

Durante uma tentativa bem-sucedida, esperamos encontrar mensagens correspondentes a:

DHCP Discover
DHCP Offer
DHCP Request
DHCP ACK

Isso transforma um problema aparentemente abstrato em algo observável.

Exemplo: Discover aparece repetidamente e nenhum Offer retorna

Imagine uma captura mostrando:

DHCP Discover
DHCP Discover
DHCP Discover
DHCP Discover

e nenhuma oferta.

Isso indica que o computador está efetivamente tentando localizar um DHCP.

Agora sabemos que não devemos começar reinstalando o navegador ou alterando o DNS.

Precisamos descobrir:

Por que nenhuma resposta DHCP está chegando até esse cliente?

Essa pergunta leva a uma investigação muito mais precisa.

O que acontece em redes com VLAN?

Em redes simples, todos os dispositivos podem estar no mesmo domínio de broadcast.

Em ambientes mais estruturados, entretanto, podemos separar os equipamentos utilizando VLANs.

Por exemplo:

VLAN 10 — computadores
VLAN 20 — visitantes
VLAN 30 — câmeras
VLAN 40 — IoT

Essa separação melhora organização, segurança e controle.

Mas também muda o comportamento do DHCP.

Broadcast DHCP não atravessa roteadores normalmente

Esse conceito é fundamental.

As mensagens iniciais utilizadas pelo cliente DHCP dependem de comunicação no segmento local.

Roteadores não encaminham broadcasts indiscriminadamente entre redes.

Imagine:

Cliente
192.168.20.x
      ↓
VLAN 20
      ↓
Roteador
      ↓
Servidor DHCP
192.168.10.10

Se o servidor DHCP estiver em outra sub-rede, precisamos de um mecanismo para encaminhar adequadamente as solicitações.

É aí que entra o DHCP Relay.

O que é DHCP Relay?

O DHCP Relay permite encaminhar solicitações DHCP entre diferentes redes.

Em vez de exigir um servidor DHCP físico em cada VLAN, o equipamento de camada 3 pode encaminhar as solicitações para um servidor central.

Podemos representar assim:

PC
↓
VLAN 20
↓
Gateway / DHCP Relay
↓
Servidor DHCP
↓
Resposta
↓
Relay
↓
PC

Se o relay estiver configurado incorretamente, uma VLAN pode ficar completamente sem DHCP enquanto outras continuam funcionando.

Esse comportamento é extremamente útil para o diagnóstico.

Uma VLAN funciona e outra recebe 169.254

Considere:

VLAN 10: computadores recebem IP normalmente.

VLAN 20: computadores recebem 169.254.

O servidor DHCP não pode ser descartado completamente, mas sabemos que ele está pelo menos funcionando para outra rede.

Precisamos investigar:

escopo DHCP da VLAN 20;
gateway;
relay;
regras de firewall;
configuração das portas;
tagging/untagging;
configuração do switch;
disponibilidade de endereços.

Esse é um excelente exemplo de como o endereço 169.254 aponta para uma investigação muito maior.

O que é um escopo DHCP?

Um servidor DHCP precisa saber quais endereços pode distribuir para determinada rede.

Podemos ter, por exemplo:

Rede: 192.168.10.0/24

Pool DHCP:
192.168.10.100
até
192.168.10.200

Além do endereço IP, o servidor pode fornecer parâmetros como:

máscara;
gateway;
DNS;
domínio;
tempo de concessão.

Se o escopo estiver desativado, incorreto ou sem endereços disponíveis, novos clientes podem não conseguir obter configuração.

Pool DHCP esgotado: um problema silencioso

Imagine um pequeno escritório com um roteador configurado para distribuir somente:

192.168.1.100
até
192.168.1.120

Temos apenas 21 endereços nesse intervalo.

Agora adicione:

computadores;
celulares;
tablets;
impressoras;
Smart TVs;
câmeras;
dispositivos IoT;
notebooks de visitantes.

Rapidamente a quantidade de clientes pode crescer.

Se não houver endereços disponíveis para novas concessões, novos dispositivos podem apresentar dificuldades para entrar corretamente na rede.

O curioso é que os equipamentos que já possuem concessões válidas podem continuar funcionando.

O usuário então observa:

“Minha televisão funciona, meu celular funciona, mas o notebook novo não entra na rede.”

Isso não significa necessariamente que o notebook esteja com defeito.

Lease DHCP: o endereço não é entregue para sempre

Uma concessão DHCP possui um tempo de validade.

Esse período é chamado de lease.

O cliente normalmente tenta renovar sua concessão antes que ela expire.

Por isso, um equipamento pode manter o mesmo endereço durante bastante tempo sem que o usuário perceba nenhuma renegociação.

Em ambientes com muitos dispositivos temporários, tempos de concessão exageradamente longos podem contribuir para um uso pouco eficiente do pool.

O administrador deve dimensionar o DHCP conforme a realidade da rede.

Reserva DHCP pode causar 169.254?

Uma reserva bem configurada não deveria provocar esse comportamento por si só.

Porém, configurações incorretas podem gerar problemas.

Uma reserva normalmente associa um cliente a determinado endereço.

Em redes domésticas, frequentemente utiliza-se o endereço MAC para identificar o equipamento.

Por exemplo:

MAC do dispositivo
↓
Reserva DHCP
↓
192.168.1.50

Quando o cliente solicita configuração, o servidor procura entregar o endereço reservado.

Se houver inconsistências na configuração ou conflitos com o planejamento de endereçamento, o comportamento precisa ser investigado.

MAC aleatório no Wi-Fi pode confundir reservas DHCP

Windows, Android, iOS e outros sistemas podem utilizar mecanismos de endereços MAC privados ou aleatórios em redes Wi-Fi.

Isso melhora aspectos de privacidade, mas pode interferir em uma estratégia de reserva DHCP baseada em um MAC diferente daquele que o administrador esperava.

Imagine:

Reserva criada para: MAC A

mas o dispositivo entra na rede utilizando:

MAC B

O servidor pode tratá-lo como outro cliente.

Isso não significa automaticamente que ele receberá 169.254, mas é um detalhe importante quando reservas, filtros de acesso e políticas dependem do endereço físico.

Dois DHCPs na mesma rede: um problema particularmente traiçoeiro

Agora chegamos a uma situação que pode produzir sintomas extremamente inconsistentes.

Imagine:

Roteador da operadora
DHCP: 192.168.1.x

+

Segundo roteador
DHCP: 192.168.0.x

Se os equipamentos forem conectados de maneira inadequada no mesmo domínio de broadcast, clientes podem receber respostas diferentes.

Um notebook pode receber:

192.168.1.120
Gateway 192.168.1.1

Outro:

192.168.0.105
Gateway 192.168.0.1

O problema parece aleatório porque depende de qual servidor responde e de como a rede foi montada.

Como detectar DHCP inesperado

Uma das primeiras verificações é:

ipconfig /all

Observe:

Servidor DHCP

Gateway padrão

Compare vários computadores.

Se equipamentos conectados à mesma LAN estiverem recebendo configurações inesperadamente diferentes, investigue imediatamente a existência de:

segundo roteador;
repetidor configurado incorretamente;
equipamento Mesh em modo roteador;
servidor DHCP instalado em computador ou servidor;
dispositivo de laboratório conectado à rede.

Roteador da operadora + roteador próprio

Esse cenário é extremamente comum em residências e pequenos escritórios.

O usuário recebe um modem/roteador da operadora e depois instala:

TP-Link;
ASUS;
D-Link;
Ubiquiti;
equipamento Mesh;
outro roteador.

Existem diversas formas corretas de montar essa infraestrutura, mas é necessário definir claramente as funções.

Por exemplo:

Equipamento da operadora em modo roteador + Mesh em Access Point

ou:

Equipamento da operadora em bridge + roteador próprio realizando NAT e DHCP

O problema aparece quando ninguém sabe exatamente quem está fazendo o quê.

Mesh em modo roteador ou Access Point?

Essa diferença é fundamental.

Em modo roteador, o sistema Mesh pode assumir funções como:

roteamento;
NAT;
DHCP;
gateway.

Em modo Access Point, normalmente o roteador principal continua responsável por grande parte dessas funções.

Portanto, ao diagnosticar DHCP em uma rede Mesh, descubra primeiro:

Qual equipamento deveria fornecer o endereço IP?

Sem responder a essa pergunta, ficamos tentando resolver o problema às cegas.

Duplo NAT é igual a dois DHCPs?

Não necessariamente.

Esses conceitos são relacionados à arquitetura da rede, mas não são sinônimos.

É possível ter:

Internet
↓
Roteador A
192.168.1.0/24
↓
WAN do Roteador B
↓
Roteador B
192.168.2.0/24
↓
Clientes

Nesse cenário, cada roteador pode fornecer DHCP para sua própria LAN.

Isso não significa automaticamente que dois servidores DHCP estejam competindo no mesmo domínio de broadcast.

Por outro lado, conectar equipamentos incorretamente pode colocar dois DHCPs disputando clientes na mesma LAN.

Por isso, precisamos entender a topologia antes de concluir que “dois roteadores sempre causam conflito”.

DHCP Snooping pode bloquear um servidor DHCP

Em switches gerenciáveis de ambientes corporativos, podemos encontrar o recurso DHCP Snooping.

Ele ajuda a proteger a rede contra servidores DHCP não autorizados.

Portas podem ser classificadas conforme a política da infraestrutura.

Se o recurso estiver configurado incorretamente, respostas legítimas de DHCP podem ser descartadas.

Esse é um caso muito mais avançado, mas demonstra novamente que um cliente com 169.254 não significa necessariamente problema no Windows.

Firewall entre VLANs também pode interferir

Quando DHCP depende de relay ou atravessa componentes de camada 3, regras de firewall precisam permitir a comunicação necessária.

Uma alteração de política pode produzir um cenário interessante:

Ontem tudo funcionava.

Uma regra é modificada.

Hoje todos os computadores de uma VLAN recebem 169.254.

Nesse caso, reinstalar drivers em vinte computadores seria perda de tempo.

A causa está na infraestrutura.

Event Viewer pode ajudar?

Sim.

O Visualizador de Eventos pode fornecer informações adicionais sobre problemas relacionados à rede e serviços do Windows.

Pressione:

Windows + R

Digite:

eventvwr.msc

Analise registros relacionados ao sistema e componentes de rede.

Não procure apenas uma mensagem contendo “169.254”.

O objetivo é correlacionar:

horário da falha → adaptador → serviço → eventos → tentativa de conexão

Logs são muito mais úteis quando analisados dentro de uma linha do tempo.

PowerShell também pode ajudar no diagnóstico

Além do tradicional ipconfig, o PowerShell possui comandos úteis para analisar interfaces.

Por exemplo:

Get-NetIPConfiguration

Esse comando apresenta informações sobre a configuração das interfaces.

Também podemos consultar adaptadores:

Get-NetAdapter

E configurações IPv4:

Get-NetIPAddress -AddressFamily IPv4

Essas ferramentas são particularmente úteis para técnicos que precisam analisar várias interfaces de maneira organizada.

Test-NetConnection depois que o IP voltar

Depois que o computador recebe uma configuração válida, podemos avançar para testes de conectividade.

Por exemplo:

Test-NetConnection 192.168.1.1

Depois podemos testar um destino externo.

A ordem importa.

Primeiro:

configuração IP

Depois:

gateway

Depois:

Internet

Depois:

DNS

Isso cria um diagnóstico por camadas.

Não confunda falha de DHCP com falha de DNS

Considere dois computadores.

Computador A

IP: 169.254.30.80
Gateway: ausente

Computador B

IP: 192.168.1.120
Gateway: 192.168.1.1
DNS: configuração incorreta

Os dois podem apresentar:

Sem Internet

Mas as causas são completamente diferentes.

No primeiro, investigamos a obtenção da configuração IP.

No segundo, a conectividade IP pode estar funcionando e apenas a resolução de nomes estar com problema.

O sintoma para o usuário é parecido.

O diagnóstico técnico não é.

Quando o problema é realmente o roteador?

Alguns sinais aumentam bastante essa possibilidade:

vários dispositivos deixam de obter IP;
DHCP volta após reiniciar o roteador;
novos dispositivos não conseguem conectar enquanto antigos continuam funcionando;
painel do roteador mostra erros;
pool DHCP está esgotado;
firmware apresenta instabilidade;
serviço DHCP está desabilitado;
problema retorna frequentemente.

Nessas situações, vale revisar a configuração do equipamento e verificar se existe firmware atualizado disponibilizado pelo fabricante.

Quando o problema provavelmente está no computador?

A suspeita aumenta quando:

somente um computador apresenta 169.254;
outros dispositivos funcionam na mesma porta/rede;
o computador falha em várias redes;
Cliente DHCP apresenta problema;
driver está corrompido;
adaptador apresenta erros;
VPN ou software de segurança alterou a pilha de rede;
problema começou após atualização ou instalação de software.

Novamente, não existe um único comando mágico.

Existe um processo de eliminação.

Quando formatar o Windows?

Quase nunca deve ser a primeira resposta para um IP 169.254.

Antes de considerar uma reinstalação do sistema, devemos investigar:

configuração IPv4;
serviço DHCP;
adaptador;
driver;
Winsock;
pilha TCP/IP;
softwares de terceiros;
infraestrutura;
comportamento em outra rede.

Formatar o computador sem descobrir a causa pode ser ainda pior quando o problema está no roteador.

Você reinstala todo o Windows, conecta novamente e recebe:

169.254.x.x

O defeito nunca esteve no sistema operacional.

Checklist técnico para IP 169.254

Antes de partir para medidas invasivas, siga uma sequência:

Execute ipconfig /all.
Confirme que DHCP está habilitado.
Verifique o estado físico da interface.
Teste outro dispositivo na mesma rede.
Teste o computador em outra rede.
Execute ipconfig /release.
Execute ipconfig /renew.
Verifique o Cliente DHCP.
Analise driver e adaptador.
Teste outro cabo ou porta quando utilizar Ethernet.
Identifique quem deveria fornecer DHCP.
Verifique o pool DHCP.
Procure outros servidores DHCP.
Analise Mesh, roteadores e VLANs.
Utilize captura de pacotes se o problema persistir.

A sequência pode variar conforme o ambiente, mas o princípio permanece:

teste antes de alterar.

O diagnóstico ideal: descobrir quem interrompeu o DORA

Em casos avançados, o objetivo final é responder:

O cliente enviou DHCP Discover?

Se não enviou, investigue o cliente.

O servidor respondeu com DHCP Offer?

Se não respondeu, investigue o caminho e o servidor.

O cliente enviou DHCP Request?

Se não enviou, investigue o comportamento do cliente e a oferta recebida.

O servidor enviou DHCP ACK?

Se não enviou, investigue servidor, políticas, escopo e infraestrutura.

Quando conseguimos responder essas quatro perguntas, o misterioso IP 169.254 deixa de ser misterioso.

Ele passa a ser apenas o resultado visível de uma negociação que não foi concluída.

Conclusão: 169.254 é o começo do diagnóstico

O endereço 169.254.x.x não deve ser tratado apenas como “Internet sem funcionar”.

Ele é uma informação técnica extremamente útil.

Ele nos direciona para uma pergunta específica:

Por que este dispositivo não conseguiu obter a configuração IPv4 esperada automaticamente?

A partir daí podemos investigar de maneira estruturada:

PC → adaptador → cabo/Wi-Fi → Access Point → switch → VLAN → roteador → DHCP

Em redes domésticas, a solução pode ser relativamente simples.

Em redes maiores, podemos precisar analisar:

escopos;
leases;
reservas;
VLANs;
DHCP Relay;
firewall;
DHCP Snooping;
múltiplos servidores;
topologia Mesh.

Independentemente do tamanho da rede, o princípio é o mesmo:

não tente corrigir antes de descobrir onde a comunicação falhou.

FAQ — IP 169.254 no Windows

O que significa IP 169.254?

Normalmente significa que o Windows está utilizando um endereço IPv4 link-local porque não obteve a configuração IPv4 esperada automaticamente para aquela rede.

IP 169.254 significa que minha Internet caiu?

Não necessariamente. Ele indica um problema na obtenção da configuração IPv4 esperada. A conexão da operadora pode continuar funcionando para outros dispositivos.

Trocar o DNS resolve?

Normalmente não. Se o computador não possui uma configuração IPv4 e gateway adequados, alterar apenas o DNS não corrige a falha de DHCP.

Reiniciar o roteador pode resolver?

Pode restaurar temporariamente um serviço DHCP travado, mas, se o problema for recorrente, é importante descobrir a causa.

Posso colocar IP fixo?

Pode ser utilizado de forma planejada ou como parte de um diagnóstico técnico. Configurar um endereço aleatório apenas para contornar o DHCP pode provocar conflito de IP ou esconder o problema real.

IP fixo é melhor que DHCP?

Não existe uma resposta universal. Para a maioria dos dispositivos clientes, DHCP facilita o gerenciamento. Equipamentos que precisam de endereços previsíveis podem utilizar reservas DHCP ou configurações estáticas planejadas.

Uma rede Mesh pode causar problemas de DHCP?

Pode, principalmente quando a topologia ou os modos roteador/Access Point estão configurados incorretamente. É essencial saber qual equipamento deveria atuar como servidor DHCP.

Dois roteadores podem causar conflito de DHCP?

Podem, se ambos estiverem fornecendo DHCP inadequadamente para o mesmo segmento. Porém, duas redes roteadas distintas podem possuir seus próprios servidores DHCP sem que isso represente erro.

O Wireshark consegue mostrar uma falha DHCP?

Sim. Uma captura pode revelar se ocorreram as etapas Discover, Offer, Request e ACK, ajudando a localizar onde a negociação deixou de funcionar.

Preciso formatar o Windows?

Na maioria dos casos, não. Formatação deve ser considerada apenas depois de excluir problemas de configuração, driver, adaptador, serviços, softwares e infraestrutura.

Precisa descobrir por que sua rede não recebe IP?

A VMIA – Manutenção e Configuração realiza diagnóstico de problemas de rede em computadores, notebooks, roteadores, Wi-Fi e sistemas Mesh.

Problemas envolvendo IP 169.254, DHCP, IP fixo, conflitos de endereço, Wi-Fi, roteadores, impressoras em rede e Windows podem exigir mais do que simplesmente reiniciar os equipamentos.

Um diagnóstico correto identifica se a falha está no computador, no adaptador, no roteador ou na própria configuração da rede antes que alterações desnecessárias sejam realizadas.

A VMIA oferece atendimento técnico com agendamento, incluindo suporte remoto quando o problema permite diagnóstico à distância e atendimento presencial para situações que exigem análise da infraestrutura.