Como Editar o Arquivo Hosts no Linux: Guia Técnico Completo

O ficheiro `/etc/hosts` no Linux é uma tabela de pesquisa estática que mapeia nomes de host para endereços IP, processada pelo sistema operativo *antes* de qualquer consulta DNS ser enviada. Ao adicionar ou modificar entradas neste ficheiro, pode substituir a resolução DNS para domínios específicos por máquina — sem tocar no seu servidor DNS, router ou definições do registador.

Este mecanismo é controlado pelo Name Service Switch (NSS), configurado em `/etc/nsswitch.conf`. A linha `hosts:` predefinida normalmente apresenta `files dns`, o que significa que o sistema consulta primeiro `/etc/hosts` e depois recorre aos resolvedores DNS definidos em `/etc/resolv.conf`. Compreender esta ordem é fundamental: se um nome de host existir em `/etc/hosts`, a consulta DNS nunca sai da máquina.

O Que É o Ficheiro Hosts e Como Funciona

O ficheiro `/etc/hosts` é anterior ao sistema DNS moderno. Na era inicial da ARPANET, um único ficheiro `HOSTS.TXT` mantido pelo Stanford Research Institute era distribuído a todas as máquinas em rede. O `/etc/hosts` atual é um descendente direto desse conceito — uma camada de substituição local e autoritativa que todos os sistemas operativos compatíveis com POSIX ainda respeitam.

Cada linha sem comentário no ficheiro segue esta sintaxe:

“`

IP_address canonical_hostname [alias1] [alias2] …

“`

• As linhas que começam com `#` são comentários e são ignoradas.
• Os espaços em branco (espaços ou tabulações) separam os campos.
• Um único endereço IP pode ser mapeado para vários nomes de host na mesma linha.
• As entradas IPv4 e IPv6 coexistem no mesmo ficheiro.

Um `/etc/hosts` mínimo predefinido numa instalação Linux recente tem este aspeto:

“`

127.0.0.1 localhost

127.0.1.1 myhostname.local myhostname

::1 localhost ip6-localhost ip6-loopback

ff02::1 ip6-allnodes

ff02::2 ip6-allrouters

“`

A entrada `127.0.1.1` é específica do Debian/Ubuntu e mapeia o FQDN da máquina para um endereço de loopback quando não é atribuído um IP estático. Removê-la pode quebrar ferramentas como `sudo` que dependem da resolução de nomes de host.

Por Que Razão Editaria o Ficheiro Hosts

Os casos de utilização vão desde a simples conveniência do programador até tarefas de infraestrutura críticas para a segurança:

Ambientes de desenvolvimento local e de staging

Aponte um domínio de produção (por exemplo, `myapp.com`) para `127.0.0.1` ou um IP de LAN durante a criação ou teste, sem modificar os registos DNS em produção. Este é o caso de utilização mais comum para programadores que executam um ambiente de VPS Hosting localmente ou num servidor remoto.

Testes de aplicações em múltiplos servidores

Ao migrar um site para um novo servidor, aponte o domínio para o IP do novo servidor apenas na sua máquina local. Pode verificar se o novo ambiente está totalmente funcional antes de atualizar o registo DNS público — eliminando o risco de tempo de inatividade.

Bloqueio de domínios maliciosos ou indesejados

Redirecionar um domínio para `0.0.0.0` (preferível a `127.0.0.1` para bloqueio) faz com que a ligação falhe imediatamente sem aguardar uma ligação recusada no localhost. Projetos como `StevenBlack/hosts` agregam milhões de domínios de anúncios, rastreadores e malware numa única lista de bloqueio em formato hosts.

Redes de contentores e microsserviços

Em ambientes Docker ou LXC sem um resolvedor DNS personalizado, as entradas `/etc/hosts` dentro dos contentores (ou no host) fornecem descoberta de serviços leve. O sinalizador `–add-host` do Docker injeta entradas diretamente no `/etc/hosts` de um contentor em tempo de execução.

Substituição de DNS split-horizon

Em redes corporativas onde o DNS interno e externo retornam registos diferentes para o mesmo nome de host, uma entrada no ficheiro hosts dá-lhe controlo determinístico numa máquina específica.

Testes de validação de certificados SSL

Ao testar uma nova implementação de Certificados SSL num servidor de staging, apontar o domínio para o IP de staging em `/etc/hosts` permite verificar o handshake TLS completo, a cadeia de certificados e o comportamento de redirecionamento HTTPS antes da entrada em produção.

Passo a Passo: Como Editar o Ficheiro Hosts no Linux

Passo 1: Abrir um Terminal

Aceda a um emulador de terminal. Nas distribuições de desktop, o atalho `Ctrl + Alt + T` funciona no GNOME, KDE e XFCE. Num servidor sem interface gráfica, já se encontra numa sessão de shell via SSH.

Confirme o seu utilizador atual e nível de privilégios:

“`bash

whoami

id

“`

Passo 2: Fazer uma Cópia de Segurança do Ficheiro Hosts Atual

Crie sempre uma cópia de segurança com marca temporal antes de modificar qualquer ficheiro do sistema. Um `hosts.backup` genérico pode ser substituído acidentalmente; uma marca temporal é inequívoca:

“`bash

sudo cp /etc/hosts /etc/hosts.bak.$(date +%Y%m%d_%H%M%S)

“`

Verifique se a cópia de segurança foi criada:

“`bash

ls -lh /etc/hosts*

“`

Passo 3: Verificar as Permissões e a Propriedade do Ficheiro

Antes de editar, confirme a propriedade e as permissões atuais do ficheiro:

“`bash

ls -la /etc/hosts

“`

Resultado esperado:

“`

-rw-r–r– 1 root root 221 Jan 10 09:00 /etc/hosts

“`

O ficheiro deve ser propriedade de `root:root` com permissões `644`. Se as permissões forem diferentes, investigue antes de prosseguir — um `/etc/hosts` com permissão de escrita para todos é uma vulnerabilidade de segurança.

Passo 4: Abrir o Ficheiro Hosts com um Editor de Texto

Usando nano (recomendado para a maioria dos utilizadores):

“`bash

sudo nano /etc/hosts

“`

Usando vim:

“`bash

sudo vim /etc/hosts

“`

Usando gedit (GUI, ambiente de trabalho GNOME):

“`bash

sudo gedit /etc/hosts

“`

Usando tee para adições não interativas/com scripts (sem editor necessário):

“`bash

echo "192.168.1.50 staging.myapp.com" | sudo tee -a /etc/hosts

“`

O sinalizador `-a` acrescenta ao ficheiro em vez de o substituir. Este é o método mais seguro para scripts de automação e playbooks Ansible.

Passo 5: Adicionar, Modificar ou Remover Entradas

Navegue até ao final do ficheiro e adicione as suas entradas. Siga estas regras de formatação rigorosamente:

• Uma entrada por linha.
• Endereço IP primeiro, depois um ou mais nomes de host separados por espaços em branco.
• Use `#` inline para anotar entradas para referência futura.

Redirecionar um domínio para um servidor de desenvolvimento local:

“`

127.0.0.1 myproject.local # Local dev – remove before production

“`

Apontar um domínio para um servidor de staging remoto:

“`

203.0.113.45 staging.myapp.com # Staging server – pre-DNS cutover

“`

Bloquear um domínio (método preferido usando 0.0.0.0):

“`

0.0.0.0 ads.example.com

0.0.0.0 tracker.analytics-provider.com

“`

Adicionar uma entrada IPv6:

“`

::1 ipv6-service.local

“`

Mapear múltiplos aliases para um IP (útil para hosts virtuais):

“`

127.0.0.1 app.local api.local static.local

“`

Passo 6: Guardar e Sair do Editor

No nano:

• Guardar: `Ctrl + O`, depois `Enter` para confirmar o nome do ficheiro.
• Sair: `Ctrl + X`.

No vim:

• Regressar ao modo normal: `Esc`
• Guardar e sair: `:wq` depois `Enter`
• Sair sem guardar: `:q!` depois `Enter`

Passo 7: Verificar o Conteúdo do Ficheiro

Confirme que as suas entradas foram escritas corretamente:

“`bash

cat /etc/hosts

“`

Para ficheiros hosts de grande dimensão, use `grep` para encontrar entradas específicas:

“`bash

grep "myproject.local" /etc/hosts

“`

Verifique se há erros de sintaxe — uma entrada com um IP em falta ou um endereço malformado será silenciosamente ignorada pelo resolvedor:

“`bash

sudo python3 -c "

with open('/etc/hosts') as f:

for i, line in enumerate(f, 1):

line = line.strip()

if line and not line.startswith('#'):

parts = line.split()

if len(parts) < 2:

print(f'Line {i} may be malformed: {line}')

"

“`

Passo 8: Limpar a Cache DNS

As alterações a `/etc/hosts` têm efeito imediato para novas ligações na maioria dos sistemas. No entanto, se o seu sistema executar um daemon de cache DNS local, deve limpar a sua cache para ver as alterações.

systemd-resolved (Ubuntu 18.04+, a maioria das distribuições modernas):

“`bash

sudo systemd-resolve –flush-caches

sudo systemd-resolve –statistics # Verify cache was cleared

“`

nscd (Name Service Cache Daemon):

“`bash

sudo systemctl restart nscd

“`

dnsmasq:

“`bash

sudo systemctl restart dnsmasq

“`

NetworkManager com plugin dnsmasq:

“`bash

sudo systemctl restart NetworkManager

“`

Os browsers mantêm a sua própria cache DNS de forma independente. O Chrome e o Firefox armazenam registos DNS em cache durante até 60 segundos. Para limpar a cache DNS interna do Chrome, navegue para `chrome://net-internals/#dns` e clique em “Clear host cache”.

Passo 9: Testar a Resolução

Use `getent` em vez de `ping` para um teste mais fiável da cadeia de resolução NSS:

“`bash

getent hosts myproject.local

“`

`getent` consulta diretamente o Name Service Switch do sistema, respeitando `/etc/nsswitch.conf`, e mostrará exatamente o que o SO resolve — não o que um servidor DNS retorna. Este é o teste definitivo.

Adicionalmente:

“`bash

ping -c 3 myproject.local

“`

“`bash

curl -v http://myproject.local

“`

Se `getent` retornar o IP correto mas `ping` não retornar, o problema está na pilha de rede ou na firewall, não no ficheiro hosts.

Ficheiro Hosts vs. DNS: Quando Usar Cada Um

Para equipas que gerem múltiplos servidores — como uma frota de Servidores Dedicados — a gestão centralizada de DNS é sempre superior à distribuição manual de alterações no ficheiro hosts. O ficheiro hosts é uma ferramenta por máquina, não uma ferramenta de infraestrutura.

Técnicas Avançadas e Casos Especiais

Usar o Ficheiro Hosts com Hosts Virtuais no Apache e Nginx

Ao executar múltiplos sites num único servidor usando hosting virtual, o ficheiro hosts na sua *máquina cliente* deve apontar o domínio para o IP do servidor. O servidor web utiliza então o cabeçalho HTTP `Host:` para encaminhar o pedido para o host virtual correto. A entrada no ficheiro hosts e a configuração do host virtual no servidor devem usar o mesmo nome de host.

Por exemplo, se tiver um host virtual Apache configurado para `myapp.local` num VPS com cPanel, adicione o IP do servidor ao seu ficheiro hosts local:

“`

198.51.100.10 myapp.local

“`

Depois aceda a `http://myapp.local` no seu browser. O Apache lê o cabeçalho `Host: myapp.local` e serve o site correto.

Proteger o Ficheiro Hosts de Modificações Não Autorizadas

O malware frequentemente tem como alvo `/etc/hosts` para redirecionar domínios legítimos (por exemplo, sites bancários) para servidores de phishing. Use `chattr` para tornar o ficheiro imutável:

“`bash

sudo chattr +i /etc/hosts

“`

Isto impede modificações mesmo pelo root até que o sinalizador imutável seja explicitamente removido:

“`bash

sudo chattr -i /etc/hosts # Remove immutability to edit

“`

Verifique o atributo:

“`bash

lsattr /etc/hosts

“`

Controlo de Versões do Seu Ficheiro Hosts

Para equipas ou ambientes de desenvolvimento complexos, acompanhe as alterações de `/etc/hosts` com Git:

“`bash

sudo cp /etc/hosts ~/dotfiles/hosts

cd ~/dotfiles && git add hosts && git commit -m "Add staging.myapp.com entry"

“`

Ferramentas como o etckeeper controlam automaticamente as versões de todo o diretório `/etc` usando Git ou outros backends VCS, fornecendo um registo de auditoria completo das alterações aos ficheiros do sistema.

Ficheiro Hosts no Docker e Kubernetes

No Docker, pode injetar entradas do ficheiro hosts no início do contentor sem modificar o sistema host:

“`bash

docker run –add-host=myservice.local:192.168.1.100 myimage

“`

No Kubernetes, `hostAliases` numa especificação de Pod obtém o mesmo resultado:

“`yaml

spec:

hostAliases:

• ip: "192.168.1.100"

hostnames:

• "myservice.local"

“`

Estas abordagens são preferíveis a modificar o `/etc/hosts` do host quando se trabalha em ambientes contentorizados.

O Debate `0.0.0.0` vs. `127.0.0.1` para Bloqueio

Ambos os endereços são usados para bloquear domínios, mas comportam-se de forma diferente:

• `127.0.0.1`: Encaminha a ligação para a interface de loopback local. Se nada estiver a escutar na porta 80/443 localmente, a ligação é recusada — mas o SO ainda tenta estabelecê-la, causando um breve atraso.
• `0.0.0.0`: Representa um destino inválido na maioria dos sistemas. A ligação falha imediatamente sem tentar um handshake TCP, resultando em carregamentos de página mais rápidos ao bloquear um grande número de domínios de anúncios/rastreadores.

Para casos de utilização de listas de bloqueio, `0.0.0.0` é a escolha tecnicamente superior.

Erros Comuns e Resolução de Problemas

As alterações não têm efeito após a edição:

• Confirme que a entrada está sintaticamente correta (IP primeiro, depois o nome de host).
• Limpe a cache DNS local (consulte o Passo 8).
• Verifique `/etc/nsswitch.conf` — se `dns` aparecer antes de `files` na linha `hosts:`, o DNS é consultado primeiro e o ficheiro hosts é ignorado para entradas em cache.

Erro `sudo: unable to resolve host` após a edição:

• Provavelmente removeu ou corrompeu a linha que mapeia o nome de host da sua máquina para `127.0.1.1` ou `127.0.0.1`. Restaure a cópia de segurança imediatamente: `sudo cp /etc/hosts.bak.TIMESTAMP /etc/hosts`.

Entrada ignorada para uma aplicação específica:

• Algumas aplicações (nomeadamente as que usam `getaddrinfo` com configurações NSS personalizadas, ou as que têm resolvedores ligados estaticamente) ignoram completamente `/etc/nsswitch.conf` e consultam o DNS diretamente. Isto é comum em binários Go compilados com CGO desativado. Verifique com `strace -e trace=network yourapp`.

O ficheiro hosts funciona localmente mas não num contentor Docker:

• A rede do contentor está isolada. O contentor tem o seu próprio `/etc/hosts`. Use `–add-host` ou `hostAliases` conforme descrito acima.

Principais Conclusões Técnicas: Lista de Verificação de Decisão

Antes de editar `/etc/hosts`, percorra esta lista de verificação:

• Verificação de âmbito: Esta alteração é necessária apenas numa máquina? Se várias máquinas precisarem dela, use DNS ou uma ferramenta como Ansible para distribuir a alteração.
• Cópia de segurança primeiro: Crie sempre uma cópia de segurança com marca temporal (`hosts.bak.YYYYMMDD_HHMMSS`) antes de qualquer edição.
• Use `0.0.0.0` para bloqueio: Falha mais rápida, sem sobrecarga de loopback.
• Limpe a cache correta: Identifique se o seu sistema usa `systemd-resolved`, `nscd` ou `dnsmasq` antes de reiniciar o serviço errado.
• Teste com `getent`: Mais fiável do que `ping` para confirmar a resolução NSS.
• Proteja o ficheiro: Use `chattr +i` em sistemas de produção ou sensíveis à segurança.
• Documente as suas entradas: Adicione comentários inline (`# reason – added YYYY-MM-DD`) a cada entrada não predefinida.
• Remova entradas temporárias: As entradas de dev/teste deixadas em ficheiros hosts de produção são uma fonte comum de bugs de encaminhamento difíceis de diagnosticar.

Se estiver a gerir um fluxo de trabalho de desenvolvimento em múltiplos ambientes, considere combinar a gestão local do ficheiro hosts com uma configuração de Painéis de Controlo VPS devidamente configurada para centralizar a gestão de hosts virtuais e reduzir a deriva de configuração por máquina.

Para projetos que envolvem Registo de Domínios e lançamentos faseados, o ficheiro hosts continua a ser a forma mais fiável de realizar um teste completo de ponta a ponta de uma nova configuração de servidor antes de a propagação DNS estar concluída — dando-lhe uma janela de validação sem risco antes de o público ver qualquer alteração.

FAQ

Editar `/etc/hosts` requer uma reinicialização do sistema?

Não. As alterações a `/etc/hosts` têm efeito imediato para novas ligações. Se tiver um daemon de cache DNS local (`systemd-resolved`, `nscd` ou `dnsmasq`), deve limpar a sua cache. Os browsers também mantêm caches DNS independentes que podem precisar de ser limpas manualmente.

Por que razão a minha entrada no ficheiro hosts funciona no terminal mas não no meu browser?

Os browsers armazenam registos DNS em cache de forma independente do resolvedor do SO. O Chrome armazena registos em cache durante até 60 segundos. Navegue para `chrome://net-internals/#dns` e limpe a cache de hosts, ou aguarde que o TTL expire.

Posso usar wildcards em `/etc/hosts`?

Não. O ficheiro `/etc/hosts` não suporta entradas com wildcards. Cada nome de host deve ser listado explicitamente. Se precisar de resolução com wildcards (por exemplo, `*.local`), use um resolvedor DNS local como `dnsmasq` ou `unbound`.

Qual é o número máximo de entradas em `/etc/hosts`?

Não existe um limite codificado imposto pelo kernel ou pela glibc. No entanto, o desempenho degrada-se com ficheiros muito grandes porque o ficheiro é analisado linearmente para cada pesquisa. Ficheiros com dezenas de milhares de entradas (comuns com listas de bloqueio de anúncios) podem adicionar latência mensurável à resolução de nomes de host. Para listas de bloqueio de grande dimensão, um sinkhole DNS dedicado como o Pi-hole é mais eficiente.

É seguro eliminar as entradas predefinidas em `/etc/hosts`?

Não. As entradas predefinidas (`127.0.0.1 localhost`, `::1 localhost` e o mapeamento do próprio nome de host da máquina) são necessárias para o correto funcionamento do sistema. Removê-las pode quebrar `sudo`, ligações de socket locais e aplicações que dependem da resolução de loopback. Apenas adicione ou modifique entradas; nunca remova as predefinições sem uma razão específica e bem compreendida.