Cómo editar el archivo Hosts en Linux: Guía técnica completa

El archivo `/etc/hosts` en Linux es una tabla de búsqueda estática que asigna nombres de host a direcciones IP, procesada por el sistema operativo *antes* de que se envíe cualquier consulta DNS. Al agregar o modificar entradas en este archivo, puede anular la resolución DNS para dominios específicos en cada máquina de forma individual, sin necesidad de modificar su servidor DNS, enrutador ni la configuración del registrador.

Este mecanismo está controlado por el Name Service Switch (NSS), configurado en `/etc/nsswitch.conf`. La línea predeterminada `hosts:` generalmente dice `files dns`, lo que significa que el sistema consulta primero `/etc/hosts` y luego recurre a los resolvedores DNS definidos en `/etc/resolv.conf`. Comprender este orden es fundamental: si un nombre de host existe en `/etc/hosts`, la consulta DNS nunca sale de la máquina.

Qué es el archivo Hosts y cómo funciona

El archivo `/etc/hosts` es anterior al sistema DNS moderno. En los primeros tiempos de ARPANET, un único archivo `HOSTS.TXT` mantenido por el Stanford Research Institute se distribuía a todas las máquinas conectadas en red. El `/etc/hosts` actual es un descendiente directo de ese concepto: una capa de anulación local y autoritativa que todos los sistemas operativos compatibles con POSIX siguen respetando.

Cada línea que no es un comentario en el archivo sigue esta sintaxis:

“`

IP_address canonical_hostname [alias1] [alias2] …

“`

• Las líneas que comienzan con `#` son comentarios y se ignoran.
• Los espacios en blanco (espacios o tabulaciones) separan los campos.
• Una sola dirección IP puede asignarse a múltiples nombres de host en la misma línea.
• Las entradas IPv4 e IPv6 coexisten en el mismo archivo.

Un archivo `/etc/hosts` predeterminado mínimo en una instalación nueva de Linux tiene este aspecto:

“`

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

“`

La entrada `127.0.1.1` es específica de Debian/Ubuntu y asigna el FQDN de la máquina a una dirección de loopback cuando no se ha asignado una IP estática. Eliminarla puede romper herramientas como `sudo` que dependen de la resolución de nombres de host.

Por qué editaría el archivo Hosts

Los casos de uso van desde la simple comodidad del desarrollador hasta tareas de infraestructura críticas para la seguridad:

Entornos de desarrollo local y staging

Apunte un dominio de producción (por ejemplo, `myapp.com`) a `127.0.0.1` o a una IP de LAN mientras construye o prueba, sin modificar los registros DNS en producción. Este es el caso de uso más común para desarrolladores que ejecutan un entorno de VPS Hosting localmente o en un servidor remoto.

Pruebas de aplicaciones en múltiples servidores

Al migrar un sitio a un nuevo servidor, apunte el dominio a la IP del nuevo servidor únicamente en su máquina local. Puede verificar que el nuevo entorno funciona correctamente antes de actualizar el registro DNS público, eliminando el riesgo de tiempo de inactividad.

Bloqueo de dominios maliciosos o no deseados

Redirigir un dominio a `0.0.0.0` (preferible a `127.0.0.1` para bloquear) hace que la conexión falle de inmediato sin esperar a que se rechace una conexión en localhost. Proyectos como `StevenBlack/hosts` agregan millones de dominios de anuncios, rastreadores y malware en una única lista de bloqueo en formato hosts.

Redes de contenedores y microservicios

En entornos Docker o LXC sin un resolvedor DNS personalizado, las entradas `/etc/hosts` dentro de los contenedores (o en el host) proporcionan un descubrimiento de servicios ligero. El indicador `–add-host` de Docker inyecta entradas directamente en el `/etc/hosts` de un contenedor en tiempo de ejecución.

Anulación de DNS split-horizon

En redes corporativas donde el DNS interno y externo devuelven registros diferentes para el mismo nombre de host, una entrada en el archivo hosts le proporciona control determinista en una máquina específica.

Pruebas de validación de certificados SSL

Al probar un nuevo despliegue de Certificados SSL en un servidor de staging, apuntar el dominio a la IP de staging en `/etc/hosts` le permite verificar el handshake TLS completo, la cadena de certificados y el comportamiento de redirección HTTPS antes del lanzamiento.

Paso a paso: cómo editar el archivo Hosts en Linux

Paso 1: Abrir una terminal

Acceda a un emulador de terminal. En distribuciones de escritorio, el atajo `Ctrl + Alt + T` funciona en GNOME, KDE y XFCE. En un servidor sin interfaz gráfica, ya se encuentra en una sesión de shell a través de SSH.

Confirme su usuario actual y nivel de privilegios:

“`bash

whoami

id

“`

Paso 2: Hacer una copia de seguridad del archivo Hosts actual

Siempre cree una copia de seguridad con marca de tiempo antes de modificar cualquier archivo del sistema. Una copia genérica `hosts.backup` puede sobrescribirse accidentalmente; una marca de tiempo es inequívoca:

“`bash

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

“`

Verifique que se creó la copia de seguridad:

“`bash

ls -lh /etc/hosts*

“`

Paso 3: Verificar los permisos y la propiedad del archivo

Antes de editar, confirme la propiedad y los permisos actuales del archivo:

“`bash

ls -la /etc/hosts

“`

Salida esperada:

“`

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

“`

El archivo debe ser propiedad de `root:root` con permisos `644`. Si los permisos son diferentes, investigue antes de continuar: un archivo `/etc/hosts` con permisos de escritura para todos es una vulnerabilidad de seguridad.

Paso 4: Abrir el archivo Hosts con un editor de texto

Usando nano (recomendado para la mayoría de los usuarios):

“`bash

sudo nano /etc/hosts

“`

Usando vim:

“`bash

sudo vim /etc/hosts

“`

Usando gedit (GUI, escritorio GNOME):

“`bash

sudo gedit /etc/hosts

“`

Usando tee para adiciones no interactivas/automatizadas (sin necesidad de editor):

“`bash

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

“`

El indicador `-a` agrega contenido al archivo en lugar de sobrescribirlo. Este es el método más seguro para scripts de automatización y playbooks de Ansible.

Paso 5: Agregar, modificar o eliminar entradas

Navegue hasta el final del archivo y agregue sus entradas. Siga estas reglas de formato estrictamente:

• Una entrada por línea.
• La dirección IP primero, luego uno o más nombres de host separados por espacios en blanco.
• Use `#` en línea para anotar entradas como referencia futura.

Redirigir un dominio a un servidor de desarrollo local:

“`

127.0.0.1 myproject.local # Local dev – remove before production

“`

Apuntar un dominio a un servidor de staging remoto:

“`

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

“`

Bloquear un dominio (método preferido usando 0.0.0.0):

“`

0.0.0.0 ads.example.com

0.0.0.0 tracker.analytics-provider.com

“`

Agregar una entrada IPv6:

“`

::1 ipv6-service.local

“`

Asignar múltiples alias a una IP (útil para hosts virtuales):

“`

127.0.0.1 app.local api.local static.local

“`

Paso 6: Guardar y salir del editor

En nano:

• Guardar: `Ctrl + O`, luego `Enter` para confirmar el nombre del archivo.
• Salir: `Ctrl + X`.

En vim:

• Volver al modo normal: `Esc`
• Guardar y salir: `:wq` luego `Enter`
• Salir sin guardar: `:q!` luego `Enter`

Paso 7: Verificar el contenido del archivo

Confirme que sus entradas se escribieron correctamente:

“`bash

cat /etc/hosts

“`

Para archivos hosts grandes, use `grep` para encontrar entradas específicas:

“`bash

grep "myproject.local" /etc/hosts

“`

Compruebe si hay errores de sintaxis: una entrada con una IP faltante o una dirección mal formada será ignorada silenciosamente por el 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}')

"

“`

Paso 8: Vaciar la caché DNS

Los cambios en `/etc/hosts` surten efecto de inmediato para nuevas conexiones en la mayoría de los sistemas. Sin embargo, si su sistema ejecuta un demonio de caché DNS local, debe vaciar su caché para ver los cambios.

systemd-resolved (Ubuntu 18.04+, la mayoría de las distribuciones 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 con el plugin dnsmasq:

“`bash

sudo systemctl restart NetworkManager

“`

Los navegadores mantienen su propia caché DNS de forma independiente. Chrome y Firefox almacenan en caché los registros DNS hasta 60 segundos. Para borrar la caché DNS interna de Chrome, navegue a `chrome://net-internals/#dns` y haga clic en “Clear host cache”.

Paso 9: Probar la resolución

Use `getent` en lugar de `ping` para una prueba más confiable de la cadena de resolución NSS:

“`bash

getent hosts myproject.local

“`

`getent` consulta directamente el Name Service Switch del sistema, respetando `/etc/nsswitch.conf`, y le mostrará exactamente lo que resuelve el sistema operativo, no lo que devuelve un servidor DNS. Esta es la prueba definitiva.

Adicionalmente:

“`bash

ping -c 3 myproject.local

“`

“`bash

curl -v http://myproject.local

“`

Si `getent` devuelve la IP correcta pero `ping` no lo hace, el problema está en la pila de red o en el firewall, no en el archivo hosts.

Archivo Hosts vs. DNS: cuándo usar cada uno

Para equipos que gestionan múltiples servidores, como una flota de Servidores Dedicados, la gestión centralizada de DNS es siempre superior a distribuir cambios en el archivo hosts manualmente. El archivo hosts es una herramienta por máquina, no una herramienta de infraestructura.

Técnicas avanzadas y casos especiales

Uso del archivo Hosts con hosts virtuales en Apache y Nginx

Al ejecutar múltiples sitios web en un único servidor mediante hosting virtual, el archivo hosts en su *máquina cliente* debe apuntar el dominio a la IP del servidor. El servidor web utiliza entonces la cabecera HTTP `Host:` para enrutar la solicitud al host virtual correcto. La entrada del archivo hosts y la configuración del host virtual del servidor deben usar el mismo nombre de host.

Por ejemplo, si tiene un host virtual de Apache configurado para `myapp.local` en un VPS con cPanel, agregue la IP del servidor a su archivo hosts local:

“`

198.51.100.10 myapp.local

“`

Luego acceda a `http://myapp.local` en su navegador. Apache lee la cabecera `Host: myapp.local` y sirve el sitio correcto.

Protección del archivo Hosts contra modificaciones no autorizadas

El malware frecuentemente apunta a `/etc/hosts` para redirigir dominios legítimos (por ejemplo, sitios bancarios) a servidores de phishing. Use `chattr` para hacer el archivo inmutable:

“`bash

sudo chattr +i /etc/hosts

“`

Esto impide la modificación incluso por root hasta que el indicador de inmutabilidad se elimine explícitamente:

“`bash

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

“`

Verifique el atributo:

“`bash

lsattr /etc/hosts

“`

Control de versiones del archivo Hosts

Para equipos o entornos de desarrollo complejos, realice un seguimiento de los cambios en `/etc/hosts` con Git:

“`bash

sudo cp /etc/hosts ~/dotfiles/hosts

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

“`

Herramientas como etckeeper controlan automáticamente las versiones de todo el directorio `/etc` usando Git u otros backends VCS, proporcionando un registro de auditoría completo de los cambios en los archivos del sistema.

Archivo Hosts en Docker y Kubernetes

En Docker, puede inyectar entradas del archivo hosts al iniciar el contenedor sin modificar el sistema host:

“`bash

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

“`

En Kubernetes, `hostAliases` en la especificación de un Pod logra el mismo resultado:

“`yaml

spec:

hostAliases:

• ip: "192.168.1.100"

hostnames:

• "myservice.local"

“`

Estos enfoques son preferibles a modificar el `/etc/hosts` del host cuando se trabaja en entornos contenerizados.

El debate `0.0.0.0` vs. `127.0.0.1` para bloqueo

Ambas direcciones se usan para bloquear dominios, pero se comportan de manera diferente:

• `127.0.0.1`: Enruta la conexión a la interfaz de loopback local. Si nada está escuchando en el puerto 80/443 localmente, la conexión se rechaza, pero el sistema operativo aún intenta establecerla, causando un breve retraso.
• `0.0.0.0`: Representa un destino no válido en la mayoría de los sistemas. La conexión falla de inmediato sin intentar un handshake TCP, lo que resulta en cargas de página más rápidas al bloquear grandes cantidades de dominios de anuncios y rastreadores.

Para casos de uso de listas de bloqueo, `0.0.0.0` es la opción técnicamente superior.

Errores comunes y solución de problemas

Los cambios no surten efecto después de editar:

• Confirme que la entrada es sintácticamente correcta (IP primero, luego el nombre de host).
• Vacíe la caché DNS local (consulte el Paso 8).
• Compruebe `/etc/nsswitch.conf`: si `dns` aparece antes que `files` en la línea `hosts:`, el DNS se consulta primero y el archivo hosts se omite para las entradas en caché.

Error `sudo: unable to resolve host` después de editar:

• Probablemente eliminó o dañó la línea que asigna el nombre de host de su máquina a `127.0.1.1` o `127.0.0.1`. Restaure la copia de seguridad de inmediato: `sudo cp /etc/hosts.bak.TIMESTAMP /etc/hosts`.

Entrada ignorada para una aplicación específica:

• Algunas aplicaciones (especialmente las que usan `getaddrinfo` con configuraciones NSS personalizadas, o las que tienen resolvedores enlazados estáticamente) omiten `/etc/nsswitch.conf` por completo y consultan el DNS directamente. Esto es común en binarios de Go compilados con CGO deshabilitado. Verifique con `strace -e trace=network yourapp`.

El archivo hosts funciona localmente pero no en un contenedor Docker:

• La red del contenedor está aislada. El contenedor tiene su propio `/etc/hosts`. Use `–add-host` o `hostAliases` como se describe anteriormente.

Conclusiones técnicas clave: lista de verificación para la toma de decisiones

Antes de editar `/etc/hosts`, revise esta lista de verificación:

• Verificación de alcance: ¿Es este cambio necesario solo en una máquina? Si varias máquinas lo necesitan, use DNS o una herramienta como Ansible para distribuir el cambio.
• Copia de seguridad primero: Siempre cree una copia de seguridad con marca de tiempo (`hosts.bak.YYYYMMDD_HHMMSS`) antes de cualquier edición.
• Use `0.0.0.0` para bloquear: Fallo más rápido, sin sobrecarga de loopback.
• Vacíe la caché correcta: Identifique si su sistema usa `systemd-resolved`, `nscd` o `dnsmasq` antes de reiniciar el servicio incorrecto.
• Pruebe con `getent`: Más confiable que `ping` para confirmar la resolución NSS.
• Proteja el archivo: Use `chattr +i` en sistemas de producción o sensibles a la seguridad.
• Documente sus entradas: Agregue comentarios en línea (`# reason – added YYYY-MM-DD`) a cada entrada no predeterminada.
• Elimine las entradas temporales: Las entradas de dev/test que permanecen en los archivos hosts de producción son una fuente común de errores de enrutamiento difíciles de diagnosticar.

Si gestiona un flujo de trabajo de desarrollo en múltiples entornos, considere combinar la gestión local del archivo hosts con una configuración de Paneles de Control VPS correctamente configurada para centralizar la gestión de hosts virtuales y reducir la deriva de configuración por máquina.

Para proyectos que implican Registro de Dominios y lanzamientos escalonados, el archivo hosts sigue siendo la forma más confiable de realizar una prueba completa de extremo a extremo de una nueva configuración de servidor antes de que se complete la propagación DNS, ofreciéndole una ventana de validación sin riesgos antes de que el público vea cualquier cambio.

Preguntas frecuentes

¿Editar `/etc/hosts` requiere reiniciar el sistema?

No. Los cambios en `/etc/hosts` surten efecto de inmediato para nuevas conexiones. Si tiene un demonio de caché DNS local (`systemd-resolved`, `nscd` o `dnsmasq`), debe vaciar su caché. Los navegadores también mantienen cachés DNS independientes que pueden necesitar borrarse manualmente.

¿Por qué la entrada de mi archivo hosts funciona en la terminal pero no en mi navegador?

Los navegadores almacenan en caché los registros DNS de forma independiente al resolvedor del sistema operativo. Chrome almacena en caché los registros hasta 60 segundos. Navegue a `chrome://net-internals/#dns` y borre la caché de hosts, o espere a que expire el TTL.

¿Puedo usar comodines en `/etc/hosts`?

No. El archivo `/etc/hosts` no admite entradas con comodines. Cada nombre de host debe listarse explícitamente. Si necesita resolución con comodines (por ejemplo, `*.local`), use un resolvedor DNS local como `dnsmasq` o `unbound`.

¿Cuál es el número máximo de entradas en `/etc/hosts`?

No existe un límite codificado impuesto por el kernel o glibc. Sin embargo, el rendimiento se degrada con archivos muy grandes porque el archivo se analiza linealmente en cada búsqueda. Los archivos con decenas de miles de entradas (comunes en listas de bloqueo de anuncios) pueden agregar una latencia medible a la resolución de nombres de host. Para listas de bloqueo grandes, un sumidero DNS dedicado como Pi-hole es más eficiente.

¿Es seguro eliminar las entradas predeterminadas en `/etc/hosts`?

No. Las entradas predeterminadas (`127.0.0.1 localhost`, `::1 localhost` y la asignación del nombre de host de la propia máquina) son necesarias para el correcto funcionamiento del sistema. Eliminarlas puede romper `sudo`, las conexiones de socket locales y las aplicaciones que dependen de la resolución de loopback. Solo agregue o modifique entradas; nunca elimine las predeterminadas sin una razón específica y bien entendida.