IP funciona, mas o nome do computador não? Entenda o motivo

agosto 25, 2026 admin Redes, Sistema Operacional 0

IP funciona no Windows, mas nome do computador não resolve ao acessar compartilhamento de rede
O acesso pelo endereço IP pode funcionar enquanto o nome do computador falha quando existe um problema de resolução de nomes, DNS, cache, arquivo hosts ou configuração da rede.
26 / 100
Desenvolvido por Rank Math SEO
Pontuação de SEO

Existe um problema de rede no Windows que costuma gerar bastante confusão porque, à primeira vista, tudo parece estar funcionando.

Você tenta acessar um computador ou servidor pelo nome:

\\SERVIDOR

e recebe uma mensagem de erro.

Então tenta diretamente pelo endereço IP:

\\192.168.1.20

e o compartilhamento abre imediatamente.

A mesma situação pode acontecer com uma pasta específica:

\\SERVIDOR\Documentos

não funciona, enquanto:

\\192.168.1.20\Documentos

funciona normalmente.

Nesse cenário, muita gente começa pelo caminho errado: reinicia o roteador, troca o cabo de rede, reinstala o adaptador, altera o compartilhamento, recria usuários ou até reinstala a impressora ou o programa que depende daquele servidor.

Porém, existe uma pista extremamente importante diante dos nossos olhos:

o recurso funciona quando usamos diretamente o endereço IP.

Isso muda completamente o diagnóstico.

Se o computador consegue acessar 192.168.1.20, mas não consegue acessar SERVIDOR, precisamos investigar o que acontece antes da conexão com o serviço: como o Windows transforma o nome SERVIDOR em um endereço IP?

Simplificando, temos dois caminhos.

Quando usamos o IP:

\\192.168.1.20
       ↓
conexão com o destino
       ↓
      SMB

Quando usamos o nome:

\\SERVIDOR
     ↓
resolução de nome
     ↓
192.168.1.20
     ↓
    SMB

Se o segundo caminho falha antes de encontrar corretamente 192.168.1.20, o serviço pode estar funcionando perfeitamente e mesmo assim \\SERVIDOR não abrir.

E existe outro detalhe importante: nem todo problema desse tipo é simplesmente “DNS”.

Dependendo da rede e da configuração do Windows, podem participar mecanismos como DNS, sufixos DNS, cache, mDNS, LLMNR, NetBIOS e até o arquivo hosts.

Neste artigo da VMIA, vamos entender como separar cada uma dessas possibilidades e descobrir por que o IP funciona, mas o nome do computador não funciona no Windows.

1. O que muda quando usamos o IP diretamente?

Imagine um computador chamado:

SERVIDOR

com endereço:

192.168.1.20

Quando digitamos:

\\192.168.1.20

já estamos entregando ao Windows o endereço do destino.

Não precisamos primeiro perguntar:

“Qual é o endereço IP de SERVIDOR?”

O sistema pode partir diretamente para a tentativa de comunicação com aquele endereço.

Se o compartilhamento abre, temos uma informação valiosa.

2. O que o acesso pelo IP já demonstra?

Suponha que:

\\192.168.1.20\Documentos

funcione.

Isso sugere que várias etapas importantes estão operacionais naquele momento:

  • existe conectividade IP;
  • o destino está alcançável;
  • o serviço SMB está acessível;
  • o compartilhamento existe;
  • a comunicação necessária conseguiu ocorrer;
  • as credenciais utilizadas podem estar sendo aceitas.

Não significa que absolutamente toda configuração da rede esteja correta.

Mas elimina várias hipóteses.

Agora compare com:

\\SERVIDOR\Documentos

falhando.

A diferença principal entre as duas tentativas é o uso do nome.

É aí que devemos concentrar a investigação.

3. O computador precisa transformar o nome em endereço

Redes IP trabalham com endereços.

Nós, humanos, preferimos nomes.

É muito mais fácil lembrar:

SERVIDOR

do que:

192.168.1.20

Por isso existem mecanismos de resolução de nomes.

Podemos representar o processo assim:

SERVIDOR
   ↓
Quem é SERVIDOR?
   ↓
192.168.1.20
   ↓
Conectar ao serviço

Se a etapa:

SERVIDOR → 192.168.1.20

falha, o restante da conexão pode nem começar corretamente.

4. Esse problema não significa necessariamente falha do SMB

Esse é um dos erros mais comuns.

O usuário tenta:

\\SERVIDOR

recebe erro e conclui:

“O compartilhamento do Windows parou.”

Mas então:

\\192.168.1.20

funciona.

Se o mesmo compartilhamento abre pelo IP, existe uma forte indicação de que o SMB está operacional pelo caminho testado.

O problema pode estar antes do SMB.

5. O post anterior ajuda a entender essa diferença

Podemos pensar no diagnóstico de rede como uma sequência:

Conectividade
      ↓
Resolução de nome
      ↓
Transporte
      ↓
Serviço
      ↓
Autenticação
      ↓
Recurso

Cada teste responde a uma pergunta.

Por isso não existe um único comando capaz de dizer:

“A rede inteira está perfeita.”

Precisamos descobrir em qual etapa aparece a primeira falha.

6. Primeiro teste: descubra o IP real do computador

Antes de investigar DNS ou qualquer outro mecanismo, precisamos saber qual endereço o computador realmente possui.

No computador de destino, abra o Prompt de Comando e execute:

ipconfig

Procure o endereço IPv4 do adaptador utilizado.

Por exemplo:

Endereço IPv4. . . . . . . . . . : 192.168.1.20

Agora sabemos qual endereço esperamos obter ao resolver o nome.

7. Confirme também o nome do computador

No computador de destino:

hostname

Podemos receber:

SERVIDOR

Agora temos o par:

Nome:
SERVIDOR

IP:
192.168.1.20

Essa informação será nossa referência.

8. Teste o endereço IP

No computador cliente:

ping 192.168.1.20

Se responde normalmente, temos uma primeira evidência de conectividade.

Mas, como vimos no artigo anterior da VMIA, ping não testa diretamente SMB.

Por isso podemos avançar.

9. Teste a porta SMB

No PowerShell:

Test-NetConnection 192.168.1.20 -Port 445

Procure:

TcpTestSucceeded : True

Agora temos uma evidência de que a porta TCP 445 está acessível naquele endereço.

Depois teste:

\\192.168.1.20

Se também funciona, nosso cenário fica ainda mais interessante.

10. Agora teste o nome

Execute:

ping SERVIDOR

Existem vários resultados possíveis.

Um deles:

Ping request could not find host SERVIDOR.

Nesse caso, o Windows não conseguiu transformar aquele nome em um endereço para realizar o teste.

Compare:

ping 192.168.1.20
✓

ping SERVIDOR
✗

Essa diferença é uma pista excelente.

11. Mas cuidado: ping pelo nome não testa SMB

Se:

ping SERVIDOR

funciona, isso mostra que o nome foi resolvido para algum endereço e houve resposta ICMP.

Ainda precisamos verificar:

para qual endereço o nome foi resolvido?

Isso é fundamental.

12. O nome pode resolver para o IP errado

Imagine que o computador correto está em:

192.168.1.20

Mas:

ping SERVIDOR

mostra:

Disparando SERVIDOR [192.168.1.35]

Encontramos uma pista ainda melhor.

O nome existe.

O problema é que ele está apontando para outro endereço.

Portanto, não basta perguntar:

“O nome resolve?”

Precisamos perguntar:

“O nome resolve para o endereço correto?”

13. Esse erro pode aparecer depois de mudança de IP

Imagine um computador que ontem utilizava:

192.168.1.20

e hoje recebeu:

192.168.1.35

Algum mecanismo de resolução ou cache pode continuar relacionando o nome ao endereço anterior por algum tempo ou existir um registro desatualizado.

O usuário então encontra comportamentos aparentemente aleatórios.

Por IP correto:

\\192.168.1.35
✓

Por nome:

\\SERVIDOR
✗

O problema não está necessariamente no compartilhamento.

14. Agora entra o DNS

DNS significa Domain Name System.

Uma de suas funções é relacionar nomes e endereços.

Em ambientes que possuem DNS configurado para os dispositivos internos, podemos ter algo conceitualmente parecido com:

servidor.empresa.local
        ↓
192.168.1.20

O cliente consulta o DNS configurado e recebe uma resposta.

Mas redes domésticas e pequenas empresas nem sempre possuem a mesma infraestrutura de DNS interno encontrada em ambientes corporativos.

É aqui que o diagnóstico começa a ficar mais interessante.

15. nslookup é uma ferramenta importante

Podemos executar:

nslookup SERVIDOR

O resultado pode mostrar o servidor DNS consultado e a resposta obtida.

Se existe um registro DNS apropriado, podemos receber o endereço esperado.

Mas existe uma pegadinha:

nslookup não reproduz necessariamente todo o processo de resolução de nomes utilizado por aplicações do Windows.

Portanto, não devemos transformar nslookup em teste absoluto.

16. Por que nslookup pode falhar e ping SERVIDOR funcionar?

Porque o Windows pode recorrer a outros mecanismos de resolução dependendo do nome, ambiente e configuração.

Assim podemos encontrar:

nslookup SERVIDOR
✗

ping SERVIDOR
✓

Isso parece contraditório apenas quando imaginamos que todo nome obrigatoriamente passa pelo mesmo mecanismo.

Não passa necessariamente.

17. E o contrário também merece atenção

Podemos encontrar:

nslookup SERVIDOR
✓

\\SERVIDOR
✗

Nesse caso, saber que o DNS respondeu não prova que todo o restante funciona.

Precisamos verificar:

  • qual IP retornou;
  • se esse IP é o correto;
  • se a porta está disponível;
  • se existe problema de autenticação;
  • se o nome utilizado afeta a aplicação.

Novamente, cada teste responde apenas a uma parte da pergunta.

18. Nomes curtos podem depender do ambiente

Existe diferença entre usar algo como:

SERVIDOR

e um nome completo, por exemplo:

servidor.exemplo.local

O nome curto pode depender de mecanismos adicionais ou da utilização de um sufixo DNS.

Isso explica alguns casos em que o nome completo funciona e o nome curto falha.

19. O que é um sufixo DNS?

Imagine que o computador tenta acessar:

SERVIDOR

e possui configurado um sufixo:

empresa.local

O sistema pode tentar formar:

SERVIDOR.empresa.local

dependendo da configuração.

Assim, um simples nome curto pode depender de informações adicionais do adaptador e da rede.

20. Como visualizar informações DNS no Windows

Execute:

ipconfig /all

Esse comando mostra muito mais informações que o ipconfig simples.

Entre elas, dependendo da configuração:

  • servidores DNS;
  • sufixos DNS;
  • DHCP;
  • gateway;
  • endereço físico;
  • informações do adaptador.

Isso ajuda a entender de onde o computador está obtendo sua configuração.

21. Compare dois computadores

Esse é um excelente método de diagnóstico.

Imagine:

PC-A
\\SERVIDOR
✓

PC-B
\\SERVIDOR
✗

Se ambos estão na mesma rede, compare:

ipconfig /all

nos dois.

Procure diferenças em:

  • DNS;
  • sufixos;
  • adaptadores;
  • perfil de rede;
  • configurações.

Comparar uma máquina funcionando com outra apresentando falha pode economizar muito tempo.

22. Não troque o DNS para 8.8.8.8 automaticamente

Esse é um erro frequente.

O usuário encontra problema para acessar:

\\SERVIDOR

e alguém recomenda:

“Coloque DNS do Google.”

Isso pode piorar a situação em uma rede que depende de DNS interno.

Um DNS público conhece nomes públicos da Internet.

Ele não possui automaticamente registros dos computadores particulares da sua LAN.

23. DNS público não conhece necessariamente SERVIDOR

Imagine uma rede interna:

SERVIDOR → 192.168.1.20

Esse nome pode fazer sentido apenas dentro daquele ambiente.

Perguntar a um DNS público:

“Qual é o endereço de SERVIDOR?”

não significa que ele conhecerá aquele equipamento.

Por isso, mudar DNS sem entender a arquitetura pode quebrar resolução interna.

24. Em domínio, isso se torna ainda mais importante

Ambientes com Active Directory dependem fortemente de DNS adequado.

Configurar clientes para utilizar arbitrariamente DNS público pode gerar problemas muito além de abrir uma pasta.

Podem surgir falhas envolvendo:

  • localização de serviços;
  • autenticação;
  • políticas;
  • recursos internos.

Em redes corporativas, DNS precisa seguir a arquitetura definida pelo administrador.

25. E numa rede doméstica simples?

Em casa, normalmente não existe um servidor DNS corporativo tradicional.

O roteador pode participar do processo de resolução local, e outros mecanismos podem ajudar dispositivos a se encontrarem.

É por isso que precisamos falar sobre mDNS, LLMNR e NetBIOS.

26. O que é mDNS?

mDNS significa Multicast DNS.

Ele permite resolução de determinados nomes em uma rede local sem depender da mesma infraestrutura de DNS central tradicional.

É muito associado a nomes terminados em:

.local

e aparece em vários ecossistemas e dispositivos.

Mas não devemos concluir que qualquer nome curto do Windows obrigatoriamente será resolvido via mDNS.

O mecanismo utilizado depende do contexto.

27. O que é LLMNR?

LLMNR significa Link-Local Multicast Name Resolution.

Ele foi utilizado pelo Windows como um mecanismo para resolver nomes na rede local quando outras formas de resolução não forneciam a resposta necessária.

Em termos simplificados:

Quem conhece SERVIDOR?

pode ser perguntado localmente através de multicast, dependendo da configuração.

28. LLMNR não deve substituir um DNS bem configurado

Em ambientes administrados, depender de mecanismos auxiliares para corrigir uma configuração DNS ruim não é uma boa arquitetura.

Além disso, protocolos de resolução local podem ter implicações de segurança em determinados ambientes.

O ideal é que a rede tenha uma estratégia clara de resolução de nomes.

29. E o NetBIOS?

O Windows historicamente utilizou mecanismos NetBIOS para descoberta e resolução de nomes em redes locais.

Ambientes modernos dependem menos dessa tecnologia do que versões antigas do Windows, mas ela ainda pode aparecer em determinados cenários e configurações.

Isso explica por que alguns tutoriais antigos tratam qualquer problema de nome como:

“Ative NetBIOS.”

Essa não deve ser uma solução automática.

30. Não ative protocolos antigos apenas para “ver se funciona”

Quando um nome não resolve, o objetivo não deve ser ativar indiscriminadamente todos os mecanismos disponíveis.

O correto é descobrir:

  1. qual mecanismo deveria resolver aquele nome;
  2. por que ele não está funcionando;
  3. qual configuração é adequada para aquela rede.

Adicionar protocolos sem necessidade pode mascarar a causa.

31. O arquivo hosts também pode resolver nomes

O Windows possui um arquivo chamado hosts.

Normalmente encontramos esse arquivo em:

C:\Windows\System32\drivers\etc\hosts

Ele permite criar associações locais entre nomes e endereços.

Conceitualmente:

192.168.1.20    SERVIDOR

Agora aquele computador possui uma associação manual.

32. Então basta editar o hosts?

Não necessariamente.

O arquivo hosts pode ser útil em situações específicas e testes controlados.

Mas imagine uma rede com 20 computadores.

Se o servidor mudar de:

192.168.1.20

para:

192.168.1.30

você precisará atualizar manualmente os clientes configurados dessa maneira.

Isso não escala bem.

33. hosts também pode esconder problemas

Imagine que existe uma linha antiga:

192.168.1.20    SERVIDOR

mas o servidor agora está em:

192.168.1.35

O usuário tenta:

\\SERVIDOR

e falha.

Por IP:

\\192.168.1.35

funciona.

O problema pode estar justamente em uma entrada manual esquecida.

Por isso, vale verificar o arquivo quando existem indícios.

34. O cache DNS também entra na história

O Windows mantém um cache para evitar repetir determinadas consultas constantemente.

Podemos visualizar informações armazenadas com:

ipconfig /displaydns

Em determinados diagnósticos, isso pode revelar entradas relevantes.

35. Como limpar o cache DNS?

Quando existe motivo para suspeitar de informação armazenada incorretamente:

ipconfig /flushdns

O Windows limpa o cache do resolvedor DNS.

Mas existe um ponto importante:

não transforme ipconfig /flushdns em solução universal.

36. Limpar o cache não corrige um DNS mal configurado

Se o cliente pergunta ao servidor errado, limpar o cache apenas faz com que ele pergunte novamente ao servidor errado.

Temos:

Cache
↓
limpo
↓
consulta
↓
DNS incorreto
↓
falha novamente

Portanto, o comando pode ajudar em determinados casos, mas não substitui o diagnóstico.

37. Reiniciar o roteador também não deve ser o primeiro passo

Se:

\\192.168.1.20
✓

\\SERVIDOR
✗

e o computador está consultando um DNS inadequado, reiniciar o roteador pode não mudar absolutamente nada.

Antes de reiniciar equipamentos aleatoriamente, descubra o caminho da resolução.

38. O mesmo vale para reinstalar a placa de rede

A conectividade IP está funcionando.

Você acessa:

\\192.168.1.20

normalmente.

Reinstalar o adaptador pode ser uma intervenção desnecessária se a causa está em DNS, cache ou resolução local.

O teste pelo IP já nos deu uma informação que deve orientar o próximo passo.

39. Como descobrir qual DNS o computador está usando?

Execute:

ipconfig /all

Procure:

Servidores DNS

Você pode encontrar algo como:

192.168.1.1

ou endereços de servidores internos ou externos.

Agora pergunte:

esse é o DNS que esse computador deveria utilizar?

40. DHCP pode entregar o DNS automaticamente

Em muitas redes, o cliente recebe por DHCP:

IP
Máscara
Gateway
DNS

Se o DHCP fornece um DNS incorreto, vários computadores podem apresentar o mesmo problema.

Nesse caso, alterar manualmente cada máquina não ataca a origem.

Talvez a correção precise acontecer na configuração DHCP.

41. Configuração manual pode criar diferenças entre máquinas

Imagine:

PC-A
DNS automático
\\SERVIDOR ✓

PC-B
DNS manual
\\SERVIDOR ✗

Agora temos uma excelente pista.

Por isso, comparar ipconfig /all é tão eficiente.

42. VPN também pode alterar resolução de nomes

Quando uma VPN é conectada, ela pode adicionar:

  • servidores DNS;
  • rotas;
  • sufixos;
  • políticas.

Isso pode alterar a forma como determinados nomes são resolvidos.

Um sintoma típico pode ser:

Sem VPN:
\\SERVIDOR ✓

Com VPN:
\\SERVIDOR ✗

ou exatamente o contrário, caso SERVIDOR exista apenas na rede remota.

43. Teste com e sem VPN quando fizer sentido

Não desinstale a VPN imediatamente.

Compare.

VPN desligada
→ resultado A

VPN ligada
→ resultado B

Se a falha acompanha o estado da VPN, temos uma correlação importante.

Depois investigamos DNS e rotas fornecidos por ela.

44. Múltiplos adaptadores também podem complicar o diagnóstico

Um computador pode ter:

  • Ethernet;
  • Wi-Fi;
  • VPN;
  • adaptadores virtuais;
  • máquinas virtuais.

Cada interface pode possuir configurações diferentes.

Então:

ipconfig /all

pode mostrar vários servidores e parâmetros.

Observe o adaptador realmente utilizado para alcançar o destino.

45. Hyper-V e softwares de virtualização criam adaptadores

Ferramentas de virtualização podem adicionar interfaces virtuais.

Isso não significa que elas sejam automaticamente culpadas.

Mas, em problemas complexos de roteamento ou resolução, vale entender quais interfaces estão presentes.

Novamente: não desative tudo sem diagnóstico.

46. IPv6 também pode aparecer na resolução

Um nome pode resolver para mais de um tipo de endereço.

Por exemplo, podem existir registros IPv4 e IPv6.

Isso significa que o diagnóstico moderno não deve assumir que todo nome sempre resulta apenas em:

192.168.x.x

Dependendo do ambiente, IPv6 pode participar.

47. Não desative IPv6 automaticamente

Existe outro conselho comum na Internet:

“Se a rede está estranha, desative IPv6.”

Essa não é uma solução genérica.

Sistemas modernos utilizam IPv6 de várias maneiras.

Desativá-lo sem entender a causa pode criar outros problemas e mascarar a configuração real.

48. Primeiro descubra qual endereço está sendo utilizado

No PowerShell, podemos usar ferramentas de resolução mais detalhadas.

Uma delas é:

Resolve-DnsName SERVIDOR

Quando existe resolução DNS aplicável, o comando fornece informações úteis sobre a consulta.

Para nomes completos:

Resolve-DnsName servidor.exemplo.local

pode ser especialmente útil em ambientes com DNS interno.

49. Resolve-DnsName e nslookup não são exatamente a mesma ferramenta

Ambos ajudam em diagnóstico DNS, mas possuem comportamentos e formatos diferentes.

Para administração moderna do Windows, Resolve-DnsName oferece informações úteis diretamente pelo PowerShell.

Ainda assim, lembre:

estamos testando DNS.

Não todo o sistema de resolução de nomes e muito menos toda a aplicação.

50. Teste também a porta utilizando o nome

Depois de confirmar que o IP funciona:

Test-NetConnection 192.168.1.20 -Port 445

teste:

Test-NetConnection SERVIDOR -Port 445

Agora compare os resultados.

51. Essa comparação é extremamente poderosa

Cenário A

IP:445
True

SERVIDOR:445
False

Investigue resolução do nome.

Cenário B

IP:445
True

SERVIDOR:445
True

mas:

\\SERVIDOR
✗

Agora o problema pode estar em outra camada.

Talvez autenticação, política, alias ou comportamento específico do serviço.

52. Nome resolvido corretamente não encerra o diagnóstico

Suponha:

SERVIDOR → 192.168.1.20

correto.

TCP 445:

True

Mas o compartilhamento continua falhando.

Nesse momento, precisamos subir na cadeia:

Nome ✓
IP ✓
TCP ✓
SMB ?
Autenticação ?
Permissão ?

O diagnóstico de resolução terminou.

Agora começa outro.

53. Credenciais podem se comportar de maneira diferente

O Windows pode tratar conexões e credenciais armazenadas de maneiras que tornam alguns cenários aparentemente inconsistentes.

É possível encontrar situações em que:

\\192.168.1.20

e:

\\SERVIDOR

não produzem exatamente a mesma experiência de autenticação.

Por isso, se o nome já resolve corretamente, investigue também as credenciais.

54. Gerenciador de Credenciais pode conter informações antigas

O Windows possui o Gerenciador de Credenciais.

Ali podem existir credenciais relacionadas a recursos de rede.

Se uma senha mudou, uma credencial armazenada pode causar falhas.

Mas não apague todas as credenciais do computador indiscriminadamente.

Identifique primeiro a entrada relacionada ao recurso.

55. Conexões SMB existentes também podem influenciar

O Windows pode manter conexões de rede durante uma sessão.

O comando:

net use

permite visualizar determinadas conexões de rede.

Isso pode ajudar quando o Windows tenta utilizar credenciais diferentes das esperadas.

56. Mas lembre do nosso cenário principal

Nosso foco é:

IP funciona
Nome falha

Portanto, resolução de nomes continua sendo a primeira suspeita lógica.

Somente depois de comprovar que o nome resolve corretamente devemos avançar para autenticação e outras camadas.

57. Firewall também pode participar?

Sim, dependendo da situação.

Mas se:

\\192.168.1.20
✓

e:

\\SERVIDOR
✗

pelo mesmo computador e serviço, não faz sentido colocar “firewall bloqueando tudo” como primeira hipótese.

A comunicação SMB pelo IP já funciona.

Precisamos investigar a diferença entre as tentativas.

58. O perfil de rede do Windows ainda merece atenção em outros cenários

O Windows classifica conexões como, por exemplo:

  • Pública;
  • Privada;
  • Domínio.

Isso influencia regras de firewall e recursos de descoberta.

Se o problema inclui computadores que não aparecem em Rede, o perfil pode ser relevante.

Mas aparecer ou não na tela “Rede” é diferente de resolver um nome digitado manualmente.

59. Descoberta de rede não é sinônimo de DNS

Esse é outro ponto importante.

O usuário abre:

Explorador de Arquivos → Rede

e não encontra o servidor.

Então conclui:

“DNS não funciona.”

Não necessariamente.

Descoberta de dispositivos e resolução de nomes são problemas relacionados, mas não idênticos.

60. Um computador pode não aparecer em “Rede” e ainda funcionar

É possível que:

Explorador → Rede
SERVIDOR não aparece

mas:

\\SERVIDOR
✓

Isso demonstra que a lista visual de dispositivos não deve ser usada como teste absoluto de conectividade.

61. Também pode acontecer o contrário

Um dispositivo pode aparecer na descoberta, mas o usuário não conseguir abrir determinado recurso.

Novamente:

Descoberta
≠
SMB
≠
autenticação
≠
permissão

São partes diferentes.

62. WSD também não é DNS

Em redes com impressoras, o Windows pode descobrir dispositivos através de tecnologias específicas.

Uma impressora aparecer automaticamente não significa que o nome dela esteja sendo resolvido pelo DNS tradicional.

Isso explica alguns cenários em que a impressora aparece na interface, mas ferramentas DNS não retornam o que o usuário esperava.

63. Impressoras também podem sofrer com resolução de nomes

Imagine uma porta de impressão configurada para:

IMPRESSORA-SALA

em vez de:

192.168.1.80

Se o mecanismo responsável por resolver esse nome falhar, a impressão pode parar mesmo com a impressora conectada e respondendo pelo IP.

64. É por isso que endereçamento previsível ajuda dispositivos de infraestrutura

Impressoras, NAS e outros equipamentos que precisam ser encontrados constantemente se beneficiam de uma estratégia consistente de endereçamento e resolução.

Isso pode envolver:

  • reserva DHCP;
  • DNS interno;
  • nomes corretamente registrados;
  • configuração adequada da porta.

O objetivo não é simplesmente “fixar IP em tudo”.

É criar previsibilidade.

65. Reserva DHCP pode ser melhor que configuração manual em muitos casos

Com reserva DHCP, o roteador ou servidor DHCP associa determinado dispositivo a um endereço previsível.

Isso centraliza o gerenciamento.

Mas a melhor solução depende da arquitetura.

O ponto importante é evitar:

Hoje:
SERVIDOR = 192.168.1.20

Amanhã:
SERVIDOR = 192.168.1.37

sem que os mecanismos de resolução acompanhem a mudança.

66. Um conflito de IP também pode confundir a resolução

Imagine que dois dispositivos disputam:

192.168.1.20

Agora o nome pode apontar corretamente para .20, mas o equipamento que responde naquele momento pode não ser sempre o mesmo.

Sintomas possíveis:

  • acesso intermitente;
  • ping variável;
  • compartilhamento desaparecendo;
  • MAC alternando;
  • conexões indo para equipamento errado.

Nesse caso, resolução de nome pode estar correta e o problema ser endereçamento.

67. Por isso confirme a identidade do IP

Não basta:

ping 192.168.1.20
✓

Precisamos saber:

192.168.1.20 é realmente o SERVIDOR?

Você pode verificar:

  • configuração do próprio servidor;
  • DHCP;
  • roteador;
  • endereço MAC;
  • interface de administração.

68. arp -a pode ajudar em determinadas investigações

O comando:

arp -a

mostra associações conhecidas entre endereços IP e MAC na rede local.

Ele pode ajudar a investigar inconsistências.

Mas, como sempre:

ARP não testa SMB e não resolve sozinho um problema de nome.

É outra peça do quebra-cabeça.

69. Não limpe ARP aleatoriamente

Existem tutoriais que recomendam limpar:

  • DNS;
  • ARP;
  • Winsock;
  • TCP/IP;
  • adaptadores;

tudo de uma vez.

Se funcionar, você não sabe qual alteração resolveu.

Pior: pode alterar uma máquina que tinha apenas um pequeno problema de resolução.

70. Evite o “combo de comandos milagroso”

É comum encontrar scripts com:

ipconfig /flushdns
netsh winsock reset
netsh int ip reset

seguidos de várias outras alterações.

Esses comandos possuem finalidades específicas.

Executá-los como ritual para qualquer falha de nome não é diagnóstico.

Primeiro identifique a camada problemática.

71. Reiniciar o Winsock não corrige um registro DNS errado

Se:

SERVIDOR

está registrado como:

192.168.1.30

quando deveria apontar para:

192.168.1.20

resetar Winsock não corrige o registro.

Precisamos atacar a causa real.

72. Resetar TCP/IP também não deve ser o primeiro passo

Se:

\\192.168.1.20
✓

a pilha TCP/IP está claramente conseguindo realizar aquela comunicação.

Isso não prova que tudo nela esteja perfeito, mas torna um reset completo uma escolha pouco lógica como primeiro teste.

73. Formatar o computador seria ainda mais desproporcional

Imagine formatar o Windows porque:

\\SERVIDOR
✗

quando o problema era simplesmente um DNS incorreto entregue manualmente ao adaptador.

Um diagnóstico de cinco minutos poderia evitar horas de trabalho.

74. O método correto é comparar resultados

Monte uma pequena tabela:

TesteResultado
ping 192.168.1.20✓
TCP 445 pelo IP✓
\\192.168.1.20✓
ping SERVIDOR✗
\\SERVIDOR✗

Essa combinação aponta fortemente para resolução de nomes.

75. Outro cenário

TesteResultado
ping 192.168.1.20✓
ping SERVIDOR✓
Nome resolve para .20✓
TCP 445 pelo nome✓
\\SERVIDOR✗

Agora não devemos continuar insistindo no DNS.

A resolução já foi comprovada.

Precisamos investigar SMB, autenticação, credenciais ou outra característica da aplicação.

76. Terceiro cenário

TesteResultado
ping 192.168.1.20✓
ping SERVIDOR✓
Nome resolve para .35✗
Servidor real é .20✓

Agora temos uma resolução incorreta.

Precisamos descobrir de onde veio .35.

77. Como descobrir de onde veio o endereço errado?

Investigue:

  • DNS;
  • cache;
  • hosts;
  • DHCP;
  • mecanismos locais;
  • VPN;
  • adaptadores;
  • registros antigos.

A origem depende do ambiente.

Não existe uma única resposta para todos os casos.

78. O horário em que o problema começou ajuda

Pergunte:

O nome parou de funcionar depois que trocamos o roteador?

Depois que instalamos VPN?

Depois que o servidor mudou de IP?

Depois que alteramos DNS?

Depois de trocar a rede de pública para privada?

A linha do tempo reduz hipóteses.

79. Troca de roteador é especialmente interessante

Um novo roteador pode fornecer:

  • outro DHCP;
  • outro DNS;
  • outro domínio local;
  • outro comportamento de resolução;
  • outra faixa de IP.

Então um recurso que funcionava como:

\\SERVIDOR

pode parar, enquanto:

\\192.168.1.20

continua funcionando.

O problema parece ser no Windows, mas a mudança ocorreu na infraestrutura.

80. Redes Mesh também podem mudar alguns comportamentos

Dependendo do sistema Mesh, modo de operação e topologia, o DHCP e a resolução local podem estar sob responsabilidade de equipamentos diferentes.

Um Mesh em modo roteador é diferente de um sistema funcionando como ponto de acesso.

Por isso, antes de diagnosticar nomes locais, entenda:

quem é o roteador principal e quem entrega DHCP/DNS?

81. Dois roteadores podem criar uma arquitetura inesperada

Imagine:

Roteador da operadora
192.168.1.1
        ↓
Mesh em modo roteador
192.168.68.1
        ↓
Computadores

Agora existem duas redes.

Dependendo de onde o servidor está conectado, descoberta e resolução local podem se comportar de maneira diferente.

O problema não é necessariamente “Windows não acha o nome”.

A topologia pode estar separando os dispositivos.

82. Compare a sub-rede dos equipamentos

Servidor:

192.168.1.20

Cliente:

192.168.68.50

Agora sabemos que não estão simplesmente na mesma sub-rede IPv4.

Pode existir roteamento entre elas, permitindo acesso pelo IP, enquanto determinados mecanismos de descoberta local não atravessam o limite da mesma maneira.

Isso explica muitos problemas em redes com dois roteadores.

83. Multicast e broadcast não atravessam redes da mesma forma que tráfego roteado

Alguns mecanismos de descoberta e resolução local dependem de tráfego local.

Quando colocamos dispositivos em sub-redes diferentes, não podemos assumir que esses mecanismos atravessarão roteadores automaticamente.

Enquanto isso, o tráfego IP roteado pode continuar funcionando.

Resultado:

IP
✓

Descoberta/nome local
✗

Essa combinação faz sentido tecnicamente.

84. Esse é um cenário comum em Mesh instalado incorretamente

A pessoa instala um Mesh e conecta:

LAN do roteador
↓
WAN do Mesh

mantendo ambos roteando.

Agora cria uma segunda rede.

Internet funciona.

Speedtest funciona.

Mas:

  • impressora desaparece;
  • NAS some;
  • computadores não aparecem;
  • nomes deixam de resolver;
  • compartilhamentos ficam inconsistentes.

A Internet estar funcionando não significa que a LAN esteja organizada corretamente.

85. Modo Access Point pode mudar a arquitetura

Em determinados sistemas Mesh, utilizar modo Access Point permite manter o roteador principal responsável pelo roteamento e DHCP.

Mas isso depende do equipamento e do objetivo da instalação.

Não altere o modo apenas porque leu que “AP é melhor”.

Primeiro desenhe a topologia.

86. Faça um mapa simples da rede

Algo assim:

Internet
   │
Roteador
192.168.1.1
   │
   ├── PC
   │   192.168.1.10
   │
   └── Servidor
       192.168.1.20

ou:

Internet
   │
Roteador
192.168.1.1
   │
Mesh Router
192.168.68.1
   │
PC
192.168.68.10

e o servidor continua na rede anterior.

Visualizar isso frequentemente revela a causa.

87. O endereço do gateway é uma pista

Execute:

ipconfig

Observe:

Gateway Padrão

Faça isso no cliente e, quando possível, no servidor.

Se estão utilizando redes e gateways diferentes, investigue a topologia antes de culpar DNS.

88. “Mas pelo IP funciona entre as redes”

Perfeitamente possível.

Existe roteamento entre elas.

Mas mecanismos locais de descoberta ou resolução podem não atravessar o roteador da mesma maneira.

Esse é um dos melhores exemplos de:

IP funcionando não significa que todo mecanismo de nomes funcionará.

89. VPN pode produzir situação semelhante

Uma VPN pode permitir alcançar:

10.10.10.20

mas não fornecer corretamente o DNS interno necessário para resolver:

SERVIDOR-EMPRESA

Resultado:

\\10.10.10.20
✓

\\SERVIDOR-EMPRESA
✗

Nesse caso, a conectividade da VPN existe.

O problema pode estar na configuração DNS da VPN.

90. Teste o DNS correto diretamente quando necessário

Com nslookup, podemos consultar um servidor DNS específico em diagnósticos apropriados:

nslookup servidor.exemplo.local 192.168.1.5

Assim podemos comparar a resposta daquele servidor com a configuração utilizada pelo cliente.

Esse teste é especialmente útil em ambientes administrados.

91. Não crie registros DNS sem entender o ambiente

Em uma rede corporativa, registros incorretos podem afetar vários usuários.

Se você não administra o DNS, encaminhe as evidências ao responsável.

Por exemplo:

Nome esperado:
servidor.exemplo.local

IP esperado:
192.168.1.20

DNS retorna:
192.168.1.35

Isso é muito mais útil que:

“A rede está ruim.”

92. Um bom chamado técnico contém testes

Em vez de:

“Não consigo acessar o servidor.”

Informe:

\\192.168.1.20
funciona

\\SERVIDOR
não funciona

TCP 445 pelo IP:
True

SERVIDOR resolve para:
192.168.1.35

IP correto:
192.168.1.20

O técnico já recebe uma direção clara.

93. Isso reduz tentativas desnecessárias

Com essas informações, provavelmente não começaremos por:

  • trocar cabo;
  • reinstalar placa;
  • formatar Windows;
  • reiniciar modem;
  • trocar SSD.

O diagnóstico fica concentrado no que realmente mudou entre os dois testes:

o nome.

94. Checklist prático: IP funciona, nome não

Quando encontrar esse problema, siga esta sequência:

  1. Descubra o IP real do destino.
  2. Confirme o hostname.
  3. Teste o IP.
  4. Teste a porta do serviço pelo IP.
  5. Acesse o recurso pelo IP.
  6. Teste o hostname.
  7. Veja para qual IP o hostname resolve.
  8. Consulte DNS quando aplicável.
  9. Confira ipconfig /all.
  10. Verifique DNS e sufixos.
  11. Compare com outro computador.
  12. Verifique VPN.
  13. Analise múltiplos adaptadores.
  14. Verifique hosts quando houver motivo.
  15. Observe cache DNS.
  16. Entenda a topologia da rede.
  17. Só depois faça alterações.

Essa ordem preserva as evidências.

95. Não altere cinco coisas ao mesmo tempo

Imagine:

Troca DNS
↓
Limpa cache
↓
Reseta Winsock
↓
Desativa IPv6
↓
Reinstala placa
↓
Reinicia roteador

Depois funciona.

Qual era a causa?

Não sabemos.

Um diagnóstico melhor muda uma variável por vez.

96. Use uma hipótese

Por exemplo:

Hipótese: o cliente está utilizando DNS incorreto.

Teste:

ipconfig /all

Compare com uma máquina funcionando.

Se encontramos:

PC funcionando:
DNS 192.168.1.5

PC com problema:
DNS 8.8.8.8

temos uma evidência forte.

Agora corrigimos uma variável e repetimos o teste.

97. Outro exemplo de hipótese

Hipótese: existe entrada antiga no hosts.

Verifique o arquivo.

Encontrou:

192.168.1.30 SERVIDOR

mas o servidor atual está em:

192.168.1.20

Agora existe uma causa concreta.

Não precisamos resetar toda a rede.

98. Outro exemplo: VPN

Sem VPN:

SERVIDOR → 192.168.1.20
✓

Com VPN:

SERVIDOR → endereço incorreto
✗

A mudança acompanha a VPN.

Agora investigamos as configurações fornecidas pela conexão.

99. Outro exemplo: dois roteadores

PC:

192.168.68.10

Servidor:

192.168.1.20

IP roteado:

✓

Nome local:

✗

Agora precisamos investigar arquitetura e mecanismos de resolução entre as redes.

100. A grande lição: teste aquilo que muda

Compare:

\\192.168.1.20

com:

\\SERVIDOR

O compartilhamento é o mesmo.

O servidor deveria ser o mesmo.

O cliente é o mesmo.

O que mudou?

A forma de localizar o destino.

Essa diferença deve orientar todo o diagnóstico.

101. Não confunda nome com descoberta

Você pode conhecer perfeitamente o nome:

SERVIDOR

mesmo que ele não apareça no Explorador.

E um dispositivo pode aparecer em Rede sem que determinada aplicação consiga utilizá-lo.

Portanto, trate separadamente:

Descoberta
Resolução
Conectividade
Serviço
Autenticação

102. Não confunda DNS com Internet

Outra associação comum:

“DNS é aquilo que faz os sites abrirem.”

DNS é muito mais amplo.

Ele relaciona nomes e informações em redes.

Em ambientes internos, DNS pode ser essencial para servidores, aplicações e autenticação.

Um computador pode ter Internet funcionando e DNS interno quebrado.

103. Internet funcionando não elimina problema de DNS interno

Exemplo:

google.com
✓

vmia.com.br
✓

SERVIDOR.empresa.local
✗

Os nomes públicos funcionam.

O nome interno não.

Talvez o computador esteja usando um DNS público que resolve Internet perfeitamente, mas não conhece a infraestrutura interna.

104. Isso acontece muito em configurações manuais

Alguém pensa:

“Vou colocar um DNS rápido.”

Configura:

8.8.8.8

Internet continua funcionando.

Depois:

\\SERVIDOR

para de funcionar.

O usuário não associa os dois eventos porque “a Internet está normal”.

Mas a resolução interna mudou.

105. O melhor DNS não é simplesmente o que responde mais rápido

Para uma rede corporativa, o servidor DNS precisa conhecer as informações necessárias para aquele ambiente.

Latência de consulta é apenas uma característica.

Um DNS extremamente rápido que não conhece seus nomes internos não cumpre a função necessária.

106. O mesmo princípio vale para redes domésticas

Mesmo sem Active Directory, mudar componentes da rede pode alterar como nomes locais são descobertos e resolvidos.

Por isso, após trocar:

  • roteador;
  • Mesh;
  • provedor;
  • DHCP;

vale observar se problemas de nomes começaram exatamente nesse momento.

107. O problema pode estar no próprio servidor

Também é possível que o servidor não esteja registrando ou anunciando seu nome como esperado.

Então vários clientes apresentam a mesma falha.

Compare:

PC-A
nome falha

PC-B
nome falha

PC-C
nome falha

Isso sugere uma causa compartilhada.

108. Se apenas um computador falha, pense no cliente

Agora:

PC-A
\\SERVIDOR ✓

PC-B
\\SERVIDOR ✓

PC-C
\\SERVIDOR ✗

O problema provavelmente está mais próximo do PC-C:

  • DNS;
  • cache;
  • VPN;
  • adaptador;
  • configuração local.

Essa comparação é extremamente valiosa.

109. Se todos falham depois de uma mudança, pense na infraestrutura

Exemplo:

Antes da troca do roteador:
todos ✓

Depois:
todos ✗ pelo nome
todos ✓ pelo IP

Isso aponta fortemente para algo alterado na infraestrutura de resolução ou topologia.

A cronologia ajuda novamente.

110. Quando vale chamar um técnico?

Quando o problema envolve uma rede pequena, mas já existem:

  • dois roteadores;
  • Mesh;
  • impressoras;
  • NAS;
  • computadores;
  • VPN;
  • IPs fixos;
  • reservas DHCP;

alterar configurações sem mapear a rede pode criar novos problemas.

Um diagnóstico organizado identifica primeiro quem fornece:

DHCP
DNS
Gateway
Roteamento

e depois verifica como os dispositivos se encontram.

Conclusão: se o IP funciona e o nome não, investigue a resolução antes de mexer no resto

Quando:

\\192.168.1.20

funciona, mas:

\\SERVIDOR

não funciona, você já possui uma das pistas mais importantes do diagnóstico.

O computador consegue alcançar o recurso quando recebe diretamente o endereço IP.

A diferença aparece quando precisamos transformar:

SERVIDOR

em:

192.168.1.20

Por isso, antes de trocar cabo, reinstalar adaptadores, formatar Windows ou reiniciar todos os equipamentos, investigue como aquele nome está sendo resolvido.

Comece confirmando:

hostname

e:

ipconfig

Depois compare:

ping 192.168.1.20

com:

ping SERVIDOR

Teste também o serviço:

Test-NetConnection 192.168.1.20 -Port 445

e:

Test-NetConnection SERVIDOR -Port 445

Consulte:

ipconfig /all

para descobrir DNS, DHCP, sufixos e configurações do adaptador.

Quando apropriado, utilize:

nslookup SERVIDOR

ou:

Resolve-DnsName SERVIDOR

O objetivo é construir uma sequência lógica:

Nome
↓
Resolve para o IP correto?
↓
Porta está acessível?
↓
Serviço funciona?
↓
Autenticação funciona?
↓
Recurso abre?

Essa abordagem evita um erro muito comum no suporte técnico: tratar “a rede” como uma única coisa.

Na realidade, uma rede pode apresentar:

Ethernet/Wi-Fi ✓
IP ✓
Gateway ✓
Internet ✓
SMB pelo IP ✓
Resolução do nome ✗

E quando entendemos exatamente onde aparece o primeiro erro, deixamos de tentar soluções aleatórias e começamos a fazer um verdadeiro diagnóstico.

FAQ — IP funciona, mas o nome do computador não

Por que consigo acessar pelo IP, mas não pelo nome?

Porque acessar pelo nome exige uma etapa adicional de resolução. O Windows precisa descobrir qual endereço corresponde ao nome informado. Se essa etapa falhar ou retornar um endereço incorreto, o IP pode funcionar enquanto o nome falha.

Isso significa que o DNS está com problema?

Pode significar, mas não obrigatoriamente. Dependendo do ambiente, outros mecanismos de resolução local podem participar.

Como descobrir o nome do computador?

No Prompt de Comando:

hostname

Como descobrir o IP?

Execute:

ipconfig

e verifique o endereço IPv4 do adaptador utilizado.

Como descobrir o DNS configurado?

Execute:

ipconfig /all

e procure os servidores DNS associados ao adaptador.

Como testar o nome?

Uma verificação inicial pode ser:

ping SERVIDOR

Observe principalmente para qual endereço o nome foi resolvido.

Como testar DNS?

Você pode utilizar:

nslookup SERVIDOR

ou, no PowerShell:

Resolve-DnsName SERVIDOR

Como testar SMB pelo IP?

No PowerShell:

Test-NetConnection 192.168.1.20 -Port 445

Como testar SMB pelo nome?

Test-NetConnection SERVIDOR -Port 445

Compare os resultados.

Limpar o DNS resolve?

ipconfig /flushdns pode ajudar quando existe informação DNS em cache que precisa ser descartada, mas não corrige um servidor DNS mal configurado ou registro incorreto.

Trocar para o DNS do Google resolve?

Não necessariamente. Em redes que dependem de nomes internos, utilizar um DNS público pode impedir a resolução desses recursos.

Posso colocar o servidor no arquivo hosts?

Tecnicamente é possível criar uma associação local, mas isso não é a melhor solução para todos os ambientes e pode exigir manutenção manual quando o endereço muda.

VPN pode causar esse problema?

Sim. VPNs podem alterar DNS, sufixos e rotas, mudando a forma como nomes são resolvidos.

Dois roteadores podem causar problemas de nomes?

Podem. Se criarem sub-redes diferentes, alguns mecanismos de descoberta e resolução local podem não atravessar essas redes como esperado.

O computador precisa aparecer em “Rede” para funcionar?

Não. A descoberta exibida no Explorador e o acesso direto a um recurso são mecanismos relacionados, mas não equivalentes.

Se o nome resolve corretamente e a porta 445 funciona, o que verificar?

Nesse ponto, investigue o serviço SMB, autenticação, credenciais, permissões e configurações específicas do recurso.

O IP funciona, mas os computadores, impressoras ou servidores somem quando você usa o nome?

A VMIA – Manutenção e Configuração realiza diagnóstico de redes Windows, compartilhamentos, impressoras, roteadores, Wi-Fi Mesh, DHCP, DNS e problemas de comunicação entre equipamentos.

Em vez de apenas reiniciar o roteador ou trocar configurações aleatoriamente, um diagnóstico pode separar problemas de IP, DNS, resolução de nomes, SMB, firewall, DHCP, Mesh, VPN, credenciais e topologia de rede.

VMIA – Manutenção e Configuração
Rua Prof. Sud Menucci, 291 – Vila Mariana – São Paulo – SP
WhatsApp/Telefone: (11) 99779-7772

Site da VMIA
Blog VMIA
WhatsApp VMIA

Se o IP funciona e o nome não, não comece desmontando a rede: descubra primeiro quem deveria transformar aquele nome no endereço correto.

Seja o primeiro a comentar

Faça um comentário

Seu e-mail não será publicado.


*