Jak edytować plik Hosts w Linux: Kompletny przewodnik techniczny

Plik `/etc/hosts` w systemie Linux to statyczna tabela przeglądowa, która mapuje nazwy hostów na adresy IP, przetwarzana przez system operacyjny *przed* wysłaniem jakiegokolwiek zapytania DNS. Dodając lub modyfikując wpisy w tym pliku, możesz nadpisać rozwiązywanie DNS dla określonych domen na poziomie pojedynczej maszyny — bez modyfikowania serwera DNS, routera ani ustawień rejestratora.

Mechanizm ten jest kontrolowany przez Name Service Switch (NSS), skonfigurowany w `/etc/nsswitch.conf`. Domyślna linia `hosts:` zazwyczaj brzmi `files dns`, co oznacza, że system najpierw sprawdza `/etc/hosts`, a następnie przechodzi do resolverów DNS zdefiniowanych w `/etc/resolv.conf`. Zrozumienie tej kolejności jest kluczowe: jeśli nazwa hosta istnieje w `/etc/hosts`, zapytanie DNS nigdy nie opuszcza maszyny.

Czym jest plik hosts i jak działa

Plik `/etc/hosts` poprzedza współczesny system DNS. We wczesnej erze ARPANET pojedynczy plik `HOSTS.TXT` utrzymywany przez Stanford Research Institute był dystrybuowany do każdej podłączonej do sieci maszyny. Dzisiejszy `/etc/hosts` jest bezpośrednim następcą tej koncepcji — lokalną, autorytatywną warstwą nadpisywania, którą honoruje każdy system operacyjny zgodny z POSIX.

Każda linia niebędąca komentarzem w pliku ma następującą składnię:

“`

IP_address canonical_hostname [alias1] [alias2] …

“`

• Linie zaczynające się od `#` są komentarzami i są ignorowane.
• Białe znaki (spacje lub tabulatory) oddzielają pola.
• Jeden adres IP może być mapowany na wiele nazw hostów w tej samej linii.
• Wpisy IPv4 i IPv6 współistnieją w tym samym pliku.

Minimalny domyślny plik `/etc/hosts` na świeżej instalacji systemu Linux wygląda następująco:

“`

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

“`

Wpis `127.0.1.1` jest specyficzny dla Debian/Ubuntu i mapuje FQDN maszyny na adres pętli zwrotnej, gdy nie jest przypisany statyczny adres IP. Jego usunięcie może zepsuć narzędzia takie jak `sudo`, które polegają na rozwiązywaniu nazwy hosta.

Dlaczego warto edytować plik hosts

Przypadki użycia obejmują zarówno prostą wygodę dla deweloperów, jak i zadania krytyczne dla bezpieczeństwa infrastruktury:

Lokalne środowiska deweloperskie i stagingowe

Wskaż domenę produkcyjną (np. `myapp.com`) na `127.0.0.1` lub adres IP w sieci LAN podczas budowania lub testowania, bez modyfikowania aktywnych rekordów DNS. Jest to najczęstszy przypadek użycia dla deweloperów uruchamiających środowisko VPS Hosting lokalnie lub na zdalnym serwerze.

Testowanie aplikacji wieloserwerowych

Podczas migracji witryny na nowy serwer wskaż domenę na adres IP nowego serwera tylko na swojej lokalnej maszynie. Możesz zweryfikować, że nowe środowisko działa poprawnie, zanim zaktualizujesz publiczny rekord DNS — eliminując ryzyko przestoju.

Blokowanie złośliwych lub niechcianych domen

Przekierowanie domeny na `0.0.0.0` (preferowane zamiast `127.0.0.1` do blokowania) powoduje natychmiastowe niepowodzenie połączenia bez oczekiwania na odmowę połączenia na localhost. Projekty takie jak `StevenBlack/hosts` agregują miliony domen reklamowych, śledzących i złośliwego oprogramowania w jedną listę blokad w formacie hosts.

Sieć kontenerów i mikroserwisów

W środowiskach Docker lub LXC bez niestandardowego resolvera DNS, wpisy `/etc/hosts` wewnątrz kontenerów (lub na hoście) zapewniają lekkie wykrywanie usług. Flaga `–add-host` Dockera wstrzykuje wpisy bezpośrednio do `/etc/hosts` kontenera w czasie uruchamiania.

Nadpisywanie split-horizon DNS

W sieciach korporacyjnych, gdzie wewnętrzny i zewnętrzny DNS zwracają różne rekordy dla tej samej nazwy hosta, wpis w pliku hosts daje deterministyczną kontrolę na konkretnej maszynie.

Testowanie walidacji certyfikatów SSL

Podczas testowania nowego wdrożenia certyfikatów SSL na serwerze stagingowym, wskazanie domeny na adres IP stagingu w `/etc/hosts` pozwala zweryfikować pełne uzgadnianie TLS, łańcuch certyfikatów i zachowanie przekierowania HTTPS przed uruchomieniem produkcyjnym.

Krok po kroku: jak edytować plik hosts w systemie Linux

Krok 1: Otwórz terminal

Uruchom emulator terminala. Na dystrybucjach desktopowych skrót `Ctrl + Alt + T` działa w środowiskach GNOME, KDE i XFCE. Na serwerze bez interfejsu graficznego jesteś już w sesji powłoki przez SSH.

Potwierdź swojego bieżącego użytkownika i poziom uprawnień:

“`bash

whoami

id

“`

Krok 2: Utwórz kopię zapasową bieżącego pliku hosts

Zawsze twórz kopię zapasową z sygnaturą czasową przed modyfikacją jakiegokolwiek pliku systemowego. Ogólna kopia `hosts.backup` może zostać przypadkowo nadpisana; sygnatura czasowa jest jednoznaczna:

“`bash

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

“`

Zweryfikuj, czy kopia zapasowa została utworzona:

“`bash

ls -lh /etc/hosts*

“`

Krok 3: Sprawdź uprawnienia i własność pliku

Przed edycją potwierdź bieżącą własność i uprawnienia pliku:

“`bash

ls -la /etc/hosts

“`

Oczekiwany wynik:

“`

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

“`

Plik powinien być własnością `root:root` z uprawnieniami `644`. Jeśli uprawnienia są inne, zbadaj sprawę przed kontynuowaniem — plik `/etc/hosts` z możliwością zapisu przez wszystkich jest luką bezpieczeństwa.

Krok 4: Otwórz plik hosts w edytorze tekstu

Używając nano (zalecane dla większości użytkowników):

“`bash

sudo nano /etc/hosts

“`

Używając vim:

“`bash

sudo vim /etc/hosts

“`

Używając gedit (GUI, pulpit GNOME):

“`bash

sudo gedit /etc/hosts

“`

Używając tee do nieinteraktywnych/skryptowych dodań (bez edytora):

“`bash

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

“`

Flaga `-a` dołącza do pliku zamiast go nadpisywać. Jest to najbezpieczniejsza metoda dla skryptów automatyzacji i playbooków Ansible.

Krok 5: Dodaj, zmodyfikuj lub usuń wpisy

Przejdź na koniec pliku i dodaj swoje wpisy. Ściśle przestrzegaj następujących zasad formatowania:

• Jeden wpis na linię.
• Najpierw adres IP, następnie jedna lub więcej nazw hostów oddzielonych białymi znakami.
• Używaj `#` w linii, aby opatrzyć wpisy adnotacjami do przyszłego użytku.

Przekieruj domenę na lokalny serwer deweloperski:

“`

127.0.0.1 myproject.local # Local dev – remove before production

“`

Wskaż domenę na zdalny serwer stagingowy:

“`

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

“`

Zablokuj domenę (preferowana metoda z użyciem 0.0.0.0):

“`

0.0.0.0 ads.example.com

0.0.0.0 tracker.analytics-provider.com

“`

Dodaj wpis IPv6:

“`

::1 ipv6-service.local

“`

Mapuj wiele aliasów na jeden adres IP (przydatne dla wirtualnych hostów):

“`

127.0.0.1 app.local api.local static.local

“`

Krok 6: Zapisz i wyjdź z edytora

W nano:

• Zapisz: `Ctrl + O`, następnie `Enter` aby potwierdzić nazwę pliku.
• Wyjdź: `Ctrl + X`.

W vim:

• Powróć do trybu normalnego: `Esc`
• Zapisz i wyjdź: `:wq` następnie `Enter`
• Wyjdź bez zapisywania: `:q!` następnie `Enter`

Krok 7: Zweryfikuj zawartość pliku

Potwierdź, że wpisy zostały zapisane poprawnie:

“`bash

cat /etc/hosts

“`

W przypadku dużych plików hosts użyj `grep` aby znaleźć konkretne wpisy:

“`bash

grep "myproject.local" /etc/hosts

“`

Sprawdź błędy składniowe — wpis z brakującym adresem IP lub nieprawidłowym adresem będzie po cichu ignorowany przez resolver:

“`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}')

"

“`

Krok 8: Wyczyść pamięć podręczną DNS

Zmiany w `/etc/hosts` wchodzą w życie natychmiast dla nowych połączeń na większości systemów. Jednak jeśli system uruchamia lokalnego demona buforowania DNS, musisz wyczyścić jego pamięć podręczną, aby zobaczyć zmiany.

systemd-resolved (Ubuntu 18.04+, większość nowoczesnych dystrybucji):

“`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 z wtyczką dnsmasq:

“`bash

sudo systemctl restart NetworkManager

“`

Przeglądarki utrzymują własną pamięć podręczną DNS niezależnie. Chrome i Firefox buforują rekordy DNS przez maksymalnie 60 sekund. Aby wyczyścić wewnętrzną pamięć podręczną DNS Chrome, przejdź do `chrome://net-internals/#dns` i kliknij „Clear host cache”.

Krok 9: Przetestuj rozwiązywanie nazw

Używaj `getent` zamiast `ping` do bardziej niezawodnego testu łańcucha rozwiązywania NSS:

“`bash

getent hosts myproject.local

“`

`getent` odpytuje bezpośrednio Name Service Switch systemu, respektując `/etc/nsswitch.conf`, i pokaże dokładnie to, co rozwiązuje system operacyjny — nie to, co zwraca serwer DNS. Jest to rozstrzygający test.

Dodatkowo:

“`bash

ping -c 3 myproject.local

“`

“`bash

curl -v http://myproject.local

“`

Jeśli `getent` zwraca poprawny adres IP, ale `ping` nie, problem leży w stosie sieciowym lub zaporze ogniowej, a nie w pliku hosts.

Plik hosts a DNS: kiedy używać którego

Dla zespołów zarządzających wieloma serwerami — takich jak flota serwerów dedykowanych — scentralizowane zarządzanie DNS jest zawsze lepsze niż ręczne dystrybuowanie zmian w pliku hosts. Plik hosts jest narzędziem per-maszyna, a nie narzędziem infrastrukturalnym.

Zaawansowane techniki i przypadki brzegowe

Używanie pliku hosts z wirtualnymi hostami w Apache i Nginx

Podczas uruchamiania wielu witryn na jednym serwerze przy użyciu wirtualnego hostingu, plik hosts na *maszynie klienta* musi wskazywać domenę na adres IP serwera. Serwer WWW następnie używa nagłówka HTTP `Host:` do kierowania żądania do właściwego wirtualnego hosta. Wpis w pliku hosts i konfiguracja wirtualnego hosta serwera muszą używać tej samej nazwy hosta.

Na przykład, jeśli masz wirtualny host Apache skonfigurowany dla `myapp.local` na VPS z cPanel, dodaj adres IP serwera do lokalnego pliku hosts:

“`

198.51.100.10 myapp.local

“`

Następnie wejdź na `http://myapp.local` w przeglądarce. Apache odczytuje nagłówek `Host: myapp.local` i serwuje właściwą witrynę.

Ochrona pliku hosts przed nieautoryzowaną modyfikacją

Złośliwe oprogramowanie często atakuje `/etc/hosts` w celu przekierowania legalnych domen (np. witryn bankowych) na serwery phishingowe. Użyj `chattr` aby uczynić plik niezmiennym:

“`bash

sudo chattr +i /etc/hosts

“`

Zapobiega to modyfikacji nawet przez roota, dopóki flaga niezmienności nie zostanie jawnie usunięta:

“`bash

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

“`

Sprawdź atrybut:

“`bash

lsattr /etc/hosts

“`

Kontrola wersji pliku hosts

Dla zespołów lub złożonych środowisk deweloperskich śledź zmiany `/etc/hosts` za pomocą Git:

“`bash

sudo cp /etc/hosts ~/dotfiles/hosts

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

“`

Narzędzia takie jak etckeeper automatycznie kontrolują wersje całego katalogu `/etc` przy użyciu Git lub innych backendów VCS, zapewniając pełną ścieżkę audytu zmian plików systemowych.

Plik hosts w Docker i Kubernetes

W Docker możesz wstrzykiwać wpisy pliku hosts przy uruchamianiu kontenera bez modyfikowania systemu hosta:

“`bash

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

“`

W Kubernetes `hostAliases` w specyfikacji Poda osiąga ten sam rezultat:

“`yaml

spec:

hostAliases:

• ip: "192.168.1.100"

hostnames:

• "myservice.local"

“`

Podejścia te są preferowane zamiast modyfikowania `/etc/hosts` hosta podczas pracy w środowiskach kontenerowych.

Debata `0.0.0.0` vs. `127.0.0.1` przy blokowaniu

Oba adresy są używane do blokowania domen, ale zachowują się inaczej:

• `127.0.0.1`: Kieruje połączenie do lokalnego interfejsu pętli zwrotnej. Jeśli nic nie nasłuchuje lokalnie na porcie 80/443, połączenie jest odrzucane — ale system operacyjny nadal próbuje je nawiązać, powodując krótkie opóźnienie.
• `0.0.0.0`: Reprezentuje nieprawidłowy cel na większości systemów. Połączenie kończy się niepowodzeniem natychmiast bez próby uzgadniania TCP, co skutkuje szybszym ładowaniem stron podczas blokowania dużej liczby domen reklamowych/śledzących.

W przypadkach użycia list blokad `0.0.0.0` jest technicznie lepszym wyborem.

Typowe błędy i rozwiązywanie problemów

Zmiany nie wchodzą w życie po edycji:

• Potwierdź, że wpis jest składniowo poprawny (najpierw adres IP, potem nazwa hosta).
• Wyczyść lokalną pamięć podręczną DNS (patrz Krok 8).
• Sprawdź `/etc/nsswitch.conf` — jeśli `dns` pojawia się przed `files` w linii `hosts:`, DNS jest odpytywany jako pierwszy, a plik hosts jest pomijany dla buforowanych wpisów.

Błąd `sudo: unable to resolve host` po edycji:

• Prawdopodobnie usunąłeś lub uszkodziłeś linię mapującą nazwę hosta maszyny na `127.0.1.1` lub `127.0.0.1`. Natychmiast przywróć kopię zapasową: `sudo cp /etc/hosts.bak.TIMESTAMP /etc/hosts`.

Wpis ignorowany przez konkretną aplikację:

• Niektóre aplikacje (zwłaszcza te używające `getaddrinfo` z niestandardowymi konfiguracjami NSS lub te ze statycznie linkowanymi resolverami) całkowicie omijają `/etc/nsswitch.conf` i odpytują DNS bezpośrednio. Jest to powszechne w binariach Go skompilowanych z wyłączonym CGO. Zweryfikuj za pomocą `strace -e trace=network yourapp`.

Plik hosts działa lokalnie, ale nie w kontenerze Docker:

• Sieć kontenerów jest izolowana. Kontener ma własny plik `/etc/hosts`. Użyj `–add-host` lub `hostAliases` jak opisano powyżej.

Kluczowe wnioski techniczne: lista kontrolna decyzji

Przed edycją `/etc/hosts` przejdź przez tę listę kontrolną:

• Sprawdzenie zakresu: Czy ta zmiana jest potrzebna tylko na jednej maszynie? Jeśli wiele maszyn jej potrzebuje, użyj DNS lub narzędzia takiego jak Ansible do dystrybucji zmiany.
• Najpierw kopia zapasowa: Zawsze twórz kopię zapasową z sygnaturą czasową (`hosts.bak.YYYYMMDD_HHMMSS`) przed każdą edycją.
• Używaj `0.0.0.0` do blokowania: Szybsze niepowodzenie, brak narzutu pętli zwrotnej.
• Wyczyść właściwą pamięć podręczną: Zidentyfikuj, czy system używa `systemd-resolved`, `nscd` czy `dnsmasq` przed ponownym uruchomieniem niewłaściwej usługi.
• Testuj za pomocą `getent`: Bardziej niezawodne niż `ping` do potwierdzania rozwiązywania NSS.
• Chroń plik: Używaj `chattr +i` na systemach produkcyjnych lub wrażliwych na bezpieczeństwo.
• Dokumentuj swoje wpisy: Dodawaj komentarze w linii (`# reason – added YYYY-MM-DD`) do każdego wpisu niebędącego domyślnym.
• Usuwaj tymczasowe wpisy: Wpisy dev/test pozostawione w produkcyjnych plikach hosts są częstym źródłem trudnych do zdiagnozowania błędów routingu.

Jeśli zarządzasz przepływem pracy deweloperskiej w wielu środowiskach, rozważ połączenie lokalnego zarządzania plikiem hosts z odpowiednio skonfigurowanym panelem sterowania VPS, aby scentralizować zarządzanie wirtualnymi hostami i zmniejszyć dryf konfiguracji per-maszyna.

W projektach obejmujących rejestrację domen i stopniowe wdrożenia, plik hosts pozostaje najbardziej niezawodnym sposobem przeprowadzenia pełnego testu end-to-end nowej konfiguracji serwera przed zakończeniem propagacji DNS — dając okno walidacji bez ryzyka, zanim publiczność zobaczy jakąkolwiek zmianę.

FAQ

Czy edycja `/etc/hosts` wymaga restartu systemu?

Nie. Zmiany w `/etc/hosts` wchodzą w życie natychmiast dla nowych połączeń. Jeśli masz lokalnego demona buforowania DNS (`systemd-resolved`, `nscd` lub `dnsmasq`), musisz wyczyścić jego pamięć podręczną. Przeglądarki również utrzymują niezależne pamięci podręczne DNS, które mogą wymagać ręcznego wyczyszczenia.

Dlaczego wpis w pliku hosts działa w terminalu, ale nie w przeglądarce?

Przeglądarki buforują rekordy DNS niezależnie od resolvera systemu operacyjnego. Chrome buforuje rekordy przez maksymalnie 60 sekund. Przejdź do `chrome://net-internals/#dns` i wyczyść pamięć podręczną hostów lub poczekaj na wygaśnięcie TTL.

Czy mogę używać symboli wieloznacznych w `/etc/hosts`?

Nie. Plik `/etc/hosts` nie obsługuje wpisów z symbolami wieloznacznymi. Każda nazwa hosta musi być wymieniona jawnie. Jeśli potrzebujesz rozwiązywania z symbolami wieloznacznymi (np. `*.local`), użyj lokalnego resolvera DNS takiego jak `dnsmasq` lub `unbound`.

Jaka jest maksymalna liczba wpisów w `/etc/hosts`?

Nie ma sztywno zakodowanego limitu wymuszanego przez jądro ani glibc. Jednak wydajność spada przy bardzo dużych plikach, ponieważ plik jest parsowany liniowo przy każdym wyszukiwaniu. Pliki z dziesiątkami tysięcy wpisów (powszechne w listach blokowania reklam) mogą dodawać mierzalne opóźnienie do rozwiązywania nazw hostów. W przypadku dużych list blokad dedykowany DNS sinkhole, taki jak Pi-hole, jest bardziej wydajny.

Czy bezpiecznie jest usuwać domyślne wpisy w `/etc/hosts`?

Nie. Domyślne wpisy (`127.0.0.1 localhost`, `::1 localhost` i mapowanie własnej nazwy hosta maszyny) są wymagane do prawidłowego działania systemu. Ich usunięcie może zepsuć `sudo`, lokalne połączenia gniazd i aplikacje polegające na rozwiązywaniu pętli zwrotnej. Tylko dodawaj lub modyfikuj wpisy; nigdy nie usuwaj domyślnych bez konkretnego, dobrze zrozumianego powodu.