{"id":143,"date":"2017-04-06T10:05:03","date_gmt":"2017-04-06T13:05:03","guid":{"rendered":"https:\/\/www.linuxpro.com.br\/2017\/04\/sobre-o-arquivo-hosts\/"},"modified":"2026-09-08T02:28:46","modified_gmt":"2026-09-08T05:28:46","slug":"sobre-o-arquivo-hosts","status":"publish","type":"post","link":"https:\/\/www.linuxpro.com.br\/en\/2017\/04\/sobre-o-arquivo-hosts\/","title":{"rendered":"Entendendo o arquivo \/etc\/hosts"},"content":{"rendered":"

\"Mascote<\/p>\n

Nota (2026):<\/strong> post de 2017, revisado. Uma corre\u00e7\u00e3o importante: o texto original sugeria dom\u00ednios .dev<\/code> para desenvolvimento local. N\u00e3o use.<\/strong> O .dev<\/code> virou um TLD real do Google e est\u00e1 na lista de HSTS preload<\/em> \u2014 os navegadores for\u00e7am HTTPS nele, e o seu site local em HTTP simplesmente deixa de abrir. O certo hoje \u00e9 .test<\/code> ou .localhost<\/code>. A explica\u00e7\u00e3o est\u00e1 na se\u00e7\u00e3o sobre nomes.<\/div>\n

O \/etc\/hosts<\/code> \u00e9 a lista de nomes que a sua m\u00e1quina resolve sozinha, sem perguntar a ningu\u00e9m. Uma linha ali tem preced\u00eancia sobre o DNS inteiro da internet \u2014 o que faz dele uma ferramenta \u00f3tima para desenvolvimento e testes, e uma armadilha das boas quando algu\u00e9m esquece uma linha l\u00e1 dentro.<\/p>\n

<\/p>\n

O formato<\/h2>\n

Cada linha mapeia um endere\u00e7o IP para um ou mais nomes. O #<\/code> comenta:<\/p>\n

endere\u00e7o_IP      nome_can\u00f4nico      [apelido...]\n<\/code><\/pre>\n
Um arquivo t\u00edpico:<\/p>\n
127.0.0.1       localhost\n127.0.1.1       minha-maquina\n192.168.0.10    servidor.local     servidor\n\n# IPv6\n::1             localhost ip6-localhost ip6-loopback\n<\/code><\/pre>\n
O 127.0.0.1<\/code> \u00e9 o loopback: sua pr\u00f3pria m\u00e1quina. O 127.0.1.1<\/code>, que aparece no Debian e no Ubuntu, existe para o hostname da m\u00e1quina resolver mesmo sem rede configurada \u2014 n\u00e3o \u00e9 engano nem duplicata.<\/p>\n
Para ver o seu:<\/p>\n
cat \/etc\/hosts\n<\/code><\/pre>\n
E para editar, precisa de privil\u00e9gio, porque \u00e9 arquivo de sistema:<\/p>\n
sudo nano \/etc\/hosts\n<\/code><\/pre>\n
Como testar (e por que n\u00e3o com ping)<\/h2>\n
A ferramenta certa \u00e9 o getent<\/code>, porque ele consulta exatamente a mesma cadeia de resolu\u00e7\u00e3o que os programas usam:<\/p>\n
getent hosts servidor.local\n# 192.168.0.10    servidor.local servidor\n<\/code><\/pre>\n
Aqui mora uma confus\u00e3o cl\u00e1ssica, com uma reviravolta moderna. Historicamente, dig<\/code> e nslookup<\/code> falam direto com o servidor DNS<\/strong> e ignoram o \/etc\/hosts<\/code> \u2014 da\u00ed o conselho, repetido h\u00e1 anos, de que testar com dig<\/code> n\u00e3o serve.<\/p>\n
S\u00f3 que nas distribui\u00e7\u00f5es com systemd-resolved<\/strong> (Ubuntu moderno, Fedora) o dig<\/code> consulta o stub em 127.0.0.53<\/code>, e o resolved responde a partir do \/etc\/hosts<\/code>. Ou seja: ali o dig<\/code> enxerga<\/em> o arquivo. Para ver o que o DNS externo realmente responde, aponte um servidor explicitamente:<\/p>\n
getent hosts site.exemplo         # o que a maquina resolve (le \/etc\/hosts)\ndig +short @8.8.8.8 site.exemplo  # o que o DNS externo responde\ncurl -I http:\/\/site.exemplo       # o teste de verdade, ponta a ponta\n<\/code><\/pre>\n
O getent<\/code> continua sendo a resposta certa para “o que esta m\u00e1quina realmente resolve”, porque \u00e9 o \u00fanico que percorre a mesma cadeia que os programas usam.<\/p>\n
Quem decide a ordem: o nsswitch.conf<\/h2>\n
O \/etc\/hosts<\/code> ter prioridade sobre o DNS n\u00e3o \u00e9 lei da natureza \u2014 \u00e9 configura\u00e7\u00e3o, e ela vive em outro arquivo:<\/p>\n
grep hosts \/etc\/nsswitch.conf\n# algo como: hosts: files mdns4_minimal [NOTFOUND=return] dns mymachines\n<\/code><\/pre>\n
A linha exata varia: o Debian puro traz apenas files dns<\/code>, e o Fedora traz files myhostname resolve [!UNAVAIL=return] dns<\/code>. O que importa \u00e9 a posi\u00e7\u00e3o relativa.<\/p>\n
L\u00ea-se da esquerda para a direita. files<\/code> \u00e9 o \/etc\/hosts<\/code>, e por vir primeiro \u00e9 consultado antes do dns<\/code>. Se algu\u00e9m inverter essa ordem, o arquivo perde a preced\u00eancia \u2014 \u00e9 o primeiro lugar para olhar quando uma entrada aparentemente correta \u00e9 ignorada.<\/p>\n
Nas distribui\u00e7\u00f5es que usam systemd-resolved<\/strong> (Ubuntu moderno, Fedora), o \/etc\/resolv.conf<\/code> costuma apontar para 127.0.0.53<\/code> e o cache fica com o servi\u00e7o. Isso n\u00e3o muda a preced\u00eancia do \/etc\/hosts<\/code>, que continua sendo consultado antes \u2014 mas muda o lugar de investigar o resto:<\/p>\n
resolvectl status              # quais servidores DNS estao em uso\nresolvectl query site.exemplo  # como o resolved resolve esse nome\nsudo resolvectl flush-caches   # limpar o cache do resolvedor\n<\/code><\/pre>\n
Nomes para desenvolvimento local: use .test<\/h2>\n
Aqui est\u00e1 o erro mais comum, e a raz\u00e3o desta revis\u00e3o. Durante anos se usou .dev<\/code> para projeto local:<\/p>\n
127.0.0.1    meuapp.dev      # NAO FACA ISSO\n<\/code><\/pre>\n
A cronologia costuma ser contada errado, e ela importa. O .dev<\/code> \u00e9 um TLD do Google desde 2014<\/strong>, mas o que quebrou o uso local n\u00e3o foi a venda de dom\u00ednios: foi o HSTS preload<\/strong>. Em setembro de 2017 o TLD inteiro entrou na lista embutida do Chromium e, a partir do Chrome 63, em dezembro de 2017, qualquer endere\u00e7o .dev<\/code> passou a ser for\u00e7ado para HTTPS antes mesmo de sair uma requisi\u00e7\u00e3o. O registro p\u00fablico s\u00f3 abriu em fevereiro de 2019 \u2014 ou seja, o .dev<\/code> j\u00e1 estava invi\u00e1vel para desenvolvimento local mais de um ano antes de existir um \u00fanico site .dev<\/code> no mundo.<\/p>\n
E n\u00e3o h\u00e1 contorno: a entrada cobre o TLD inteiro com include_subdomains<\/code>, a lista vem embutida no Chrome, no Firefox e no Edge, e dom\u00ednio em HSTS preload tamb\u00e9m n\u00e3o oferece o bot\u00e3o de “prosseguir mesmo assim” na tela de erro de certificado. Seu servidor local em HTTP simplesmente nunca \u00e9 alcan\u00e7ado.<\/p>\n
Use os nomes que a RFC 6761<\/a> reserva justamente para isso e que nunca ser\u00e3o vendidos como dom\u00ednio:<\/p>\n
127.0.0.1    meuapp.test\n127.0.0.1    api.meuapp.test\n127.0.0.1    blog.meuapp.test\n<\/code><\/pre>\n
S\u00e3o reservados .test<\/code>, .example<\/code>, .invalid<\/code> e .localhost<\/code>. Para desenvolvimento, .test<\/code> \u00e9 o indicado. E h\u00e1 um b\u00f4nus no .localhost<\/code>: onde existe systemd-resolved<\/strong> ou o m\u00f3dulo myhostname<\/code> no nsswitch.conf<\/code>, qualquer *.localhost<\/code> j\u00e1 vai para o loopback automaticamente \u2014 meuapp.localhost<\/code> funciona sem editar arquivo nenhum. Isso vem do systemd, n\u00e3o da glibc: numa m\u00e1quina sem nenhum dos dois, n\u00e3o funciona. Confira com getent hosts meuapp.localhost<\/code>.<\/p>\n
Usos que valem no dia a dia<\/h2>\n
Testar um servidor antes de virar o DNS.<\/strong> \u00c9 o uso mais \u00fatil: voc\u00ea aponta o dom\u00ednio real para o servidor novo s\u00f3 na sua m\u00e1quina, confere que est\u00e1 tudo certo, e s\u00f3 ent\u00e3o muda o DNS para valer.<\/p>\n
203.0.113.50    www.meusite.com.br    meusite.com.br\n<\/code><\/pre>\n
O navegador vai ao servidor novo enquanto o mundo inteiro continua indo ao antigo. Terminado o teste, apague a linha<\/strong> \u2014 esquec\u00ea-la ali \u00e9 a origem cl\u00e1ssica do “o site mudou para todo mundo, menos para mim”.<\/p>\n
Bloquear dom\u00ednios.<\/strong> Apontar um nome para 0.0.0.0<\/code> faz a conex\u00e3o falhar imediatamente:<\/p>\n
0.0.0.0    dominio-indesejado.com\n<\/code><\/pre>\n
Com uma ressalva importante no Linux: conectar a 0.0.0.0<\/code> cai no seu pr\u00f3prio 127.0.0.1<\/code>. Se voc\u00ea roda um servidor web local, o “bloqueio” vai exibir o seu<\/em> site em vez de falhar. S\u00f3 h\u00e1 recusa imediata quando n\u00e3o h\u00e1 nada escutando naquela porta.<\/p>\n
Funciona para bloqueio pontual. Para bloqueio amplo, uma lista gigante no \/etc\/hosts<\/code> penaliza toda resolu\u00e7\u00e3o de nome da m\u00e1quina \u2014 a\u00ed o caminho \u00e9 um resolvedor com filtro, como Pi-hole ou dnsmasq.<\/p>\n
Encurtar nomes de m\u00e1quinas da rede local<\/strong>, para n\u00e3o decorar IP:<\/p>\n
192.168.0.10    nas\n192.168.0.20    impressora\n192.168.0.30    servidor-web    web\n<\/code><\/pre>\n
Com isso, ssh web<\/code> e ping nas<\/code> passam a funcionar. Combina bem com o ~\/.ssh\/config<\/code> do post sobre chaves SSH<\/a>.<\/p>\n
Quando n\u00e3o funciona<\/h2>\n
Tr\u00eas causas explicam quase todos os casos:<\/p>\n