Как да редактирате файла Hosts в Linux: Пълно техническо ръководство

Файлът `/etc/hosts` в Linux е статична таблица за търсене, която съпоставя имена на хостове с IP адреси, обработвана от операционната система *преди* да бъде изпратена каквато и да е DNS заявка. Чрез добавяне или промяна на записи в този файл можете да замените DNS резолюцията за конкретни домейни на база отделна машина — без да докосвате DNS сървъра, рутера или настройките на регистратора.

Този механизъм се контролира от Name Service Switch (NSS), конфигуриран в `/etc/nsswitch.conf`. Стандартният ред `hosts:` обикновено гласи `files dns`, което означава, че системата първо се обръща към `/etc/hosts`, след което прибягва до DNS резолвърите, дефинирани в `/etc/resolv.conf`. Разбирането на този ред е от съществено значение: ако дадено име на хост съществува в `/etc/hosts`, DNS заявката никога не напуска машината.

Какво представлява файлът hosts и как работи

Файлът `/etc/hosts` предшества изцяло съвременната DNS система. В ранната ера на ARPANET единичен файл `HOSTS.TXT`, поддържан от Stanford Research Institute, се разпространяваше до всяка свързана в мрежата машина. Днешният `/etc/hosts` е пряк наследник на тази концепция — локален, авторитетен слой за замяна, който всяка POSIX-съвместима операционна система все още зачита.

Всеки ред без коментар в файла следва следния синтаксис:

“`

IP_address canonical_hostname [alias1] [alias2] …

“`

• Редовете, започващи с `#`, са коментари и се игнорират.
• Празното пространство (интервали или табулации) разделя полетата.
• Един IP адрес може да бъде съпоставен с множество имена на хостове на същия ред.
• IPv4 и IPv6 записи съществуват съвместно в един и същи файл.

Минималният стандартен `/etc/hosts` при нова инсталация на Linux изглежда така:

“`

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

“`

Записът `127.0.1.1` е специфичен за Debian/Ubuntu и съпоставя FQDN на машината с адрес за обратна връзка, когато не е зададен статичен IP. Премахването му може да наруши работата на инструменти като `sudo`, които разчитат на резолюция на имена на хостове.

Защо бихте редактирали файла hosts

Случаите на употреба варират от обикновено удобство за разработчици до задачи от критично значение за сигурността на инфраструктурата:

Локални среди за разработка и тестване

Насочете производствен домейн (напр. `myapp.com`) към `127.0.0.1` или LAN IP по време на изграждане или тестване, без да променяте живите DNS записи. Това е най-честият случай на употреба за разработчици, работещи с VPS Hosting среда локално или на отдалечен сървър.

Тестване на приложения с множество сървъри

При мигриране на сайт към нов сървър, насочете домейна към IP адреса на новия сървър само на вашата локална машина. Можете да проверите дали новата среда е напълно функционална, преди да актуализирате публичния DNS запис — елиминирайки риска от престой.

Блокиране на злонамерени или нежелани домейни

Пренасочването на домейн към `0.0.0.0` (предпочитано пред `127.0.0.1` за блокиране) кара връзката да се провали незабавно, без да чака отказана връзка на localhost. Проекти като `StevenBlack/hosts` обединяват милиони домейни за реклами, тракери и злонамерен софтуер в един списък за блокиране в hosts формат.

Мрежи от контейнери и микроуслуги

В Docker или LXC среди без персонализиран DNS резолвър, записите `/etc/hosts` вътре в контейнерите (или на хоста) осигуряват лесно откриване на услуги. Флагът `–add-host` на Docker инжектира записи директно в `/etc/hosts` на контейнера по време на изпълнение.

Замяна на split-horizon DNS

В корпоративни мрежи, където вътрешният и външният DNS връщат различни записи за едно и също име на хост, записът в hosts файла ви дава детерминистичен контрол върху конкретна машина.

Тестване на валидиране на SSL сертификати

При тестване на ново внедряване на SSL Certificates на тестов сървър, насочването на домейна към тестовия IP в `/etc/hosts` ви позволява да проверите пълното TLS ръкостискане, веригата от сертификати и поведението при пренасочване към HTTPS преди пускането в производство.

Стъпка по стъпка: Как да редактирате файла hosts в Linux

Стъпка 1: Отворете терминал

Отворете терминален емулатор. При настолни дистрибуции, клавишната комбинация `Ctrl + Alt + T` работи в GNOME, KDE и XFCE. На сървър без графичен интерфейс вече сте в шел сесия чрез SSH.

Потвърдете текущия потребител и нивото на привилегии:

“`bash

whoami

id

“`

Стъпка 2: Направете резервно копие на текущия файл hosts

Винаги създавайте резервно копие с времеви печат преди да промените системен файл. Общо `hosts.backup` може да бъде случайно презаписано; времевият печат е недвусмислен:

“`bash

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

“`

Проверете дали резервното копие е създадено:

“`bash

ls -lh /etc/hosts*

“`

Стъпка 3: Проверете правата и собствеността на файла

Преди редактиране потвърдете текущата собственост и правата на файла:

“`bash

ls -la /etc/hosts

“`

Очакван резултат:

“`

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

“`

Файлът трябва да е собственост на `root:root` с права `644`. Ако правата се различават, проучете преди да продължите — `/etc/hosts` с права за запис от всички е уязвимост в сигурността.

Стъпка 4: Отворете файла hosts с текстов редактор

Използване на nano (препоръчително за повечето потребители):

“`bash

sudo nano /etc/hosts

“`

Използване на vim:

“`bash

sudo vim /etc/hosts

“`

Използване на gedit (GUI, GNOME десктоп):

“`bash

sudo gedit /etc/hosts

“`

Използване на tee за неинтерактивни/скриптирани добавяния (без нужда от редактор):

“`bash

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

“`

Флагът `-a` добавя към файла, вместо да го презаписва. Това е най-безопасният метод за скриптове за автоматизация и Ansible playbooks.

Стъпка 5: Добавяне, промяна или премахване на записи

Преминете към края на файла и добавете вашите записи. Спазвайте стриктно следните правила за форматиране:

• По един запис на ред.
• Първо IP адресът, след това едно или повече имена на хостове, разделени с празно пространство.
• Използвайте `#` вградено, за да анотирате записите за бъдещи справки.

Пренасочване на домейн към локален сървър за разработка:

“`

127.0.0.1 myproject.local # Local dev – remove before production

“`

Насочване на домейн към отдалечен тестов сървър:

“`

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

“`

Блокиране на домейн (предпочитан метод с използване на 0.0.0.0):

“`

0.0.0.0 ads.example.com

0.0.0.0 tracker.analytics-provider.com

“`

Добавяне на IPv6 запис:

“`

::1 ipv6-service.local

“`

Съпоставяне на множество псевдоними с един IP (полезно за виртуални хостове):

“`

127.0.0.1 app.local api.local static.local

“`

Стъпка 6: Запазете и излезте от редактора

В nano:

• Запазване: `Ctrl + O`, след това `Enter` за потвърждение на името на файла.
• Изход: `Ctrl + X`.

В vim:

• Връщане в нормален режим: `Esc`
• Запазване и изход: `:wq` след това `Enter`
• Изход без запазване: `:q!` след това `Enter`

Стъпка 7: Проверете съдържанието на файла

Потвърдете, че записите са записани правилно:

“`bash

cat /etc/hosts

“`

За големи hosts файлове използвайте `grep` за намиране на конкретни записи:

“`bash

grep "myproject.local" /etc/hosts

“`

Проверете за синтактични грешки — запис с липсващ IP или неправилно форматиран адрес ще бъде мълчаливо игнориран от резолвъра:

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

"

“`

Стъпка 8: Изчистете DNS кеша

Промените в `/etc/hosts` влизат в сила незабавно за нови връзки на повечето системи. Въпреки това, ако системата ви работи с локален DNS кеширащ демон, трябва да изчистите кеша му, за да видите промените.

systemd-resolved (Ubuntu 18.04+, повечето съвременни дистрибуции):

“`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 с dnsmasq плъгин:

“`bash

sudo systemctl restart NetworkManager

“`

Браузърите поддържат собствен DNS кеш независимо. Chrome и Firefox кешират DNS записи до 60 секунди. За да изчистите вътрешния DNS кеш на Chrome, отидете на `chrome://net-internals/#dns` и кликнете върху „Clear host cache”.

Стъпка 9: Тествайте резолюцията

Използвайте `getent` вместо `ping` за по-надежден тест на веригата за NSS резолюция:

“`bash

getent hosts myproject.local

“`

`getent` заявява директно Name Service Switch на системата, зачитайки `/etc/nsswitch.conf`, и ще ви покаже точно какво разрешава операционната система — не какво връща DNS сървър. Това е окончателният тест.

Допълнително:

“`bash

ping -c 3 myproject.local

“`

“`bash

curl -v http://myproject.local

“`

Ако `getent` връща правилния IP, но `ping` не го прави, проблемът е в мрежовия стек или защитната стена, а не в hosts файла.

Hosts файл срещу DNS: Кога да използвате кое

За екипи, управляващи множество сървъри — като флот от Dedicated Servers — централизираното управление на DNS винаги е по-добро от ръчното разпространение на промени в hosts файла. Hosts файлът е инструмент за отделна машина, а не инструмент за инфраструктура.

Разширени техники и гранични случаи

Използване на hosts файла с виртуални хостове в Apache и Nginx

При работа с множество уебсайтове на един сървър чрез виртуален хостинг, hosts файлът на вашата *клиентска машина* трябва да насочва домейна към IP адреса на сървъра. След това уеб сървърът използва HTTP хедъра `Host:`, за да насочи заявката към правилния виртуален хост. Записът в hosts файла и конфигурацията на виртуалния хост на сървъра трябва да използват едно и също име на хост.

Например, ако имате Apache виртуален хост, конфигуриран за `myapp.local` на VPS с cPanel, добавете IP адреса на сървъра към локалния hosts файл:

“`

198.51.100.10 myapp.local

“`

След това отворете `http://myapp.local` в браузъра си. Apache чете хедъра `Host: myapp.local` и обслужва правилния сайт.

Защита на hosts файла от неоторизирана промяна

Злонамереният софтуер често атакува `/etc/hosts`, за да пренасочи легитимни домейни (напр. банкови сайтове) към фишинг сървъри. Използвайте `chattr`, за да направите файла неизменяем:

“`bash

sudo chattr +i /etc/hosts

“`

Това предотвратява промяна дори от root, докато флагът за неизменяемост не бъде изрично премахнат:

“`bash

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

“`

Проверете атрибута:

“`bash

lsattr /etc/hosts

“`

Контрол на версиите на hosts файла

За екипи или сложни среди за разработка, проследявайте промените в `/etc/hosts` с Git:

“`bash

sudo cp /etc/hosts ~/dotfiles/hosts

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

“`

Инструменти като etckeeper автоматично управляват версиите на цялата директория `/etc` с Git или други VCS бекенди, осигурявайки пълна одитна следа на промените в системните файлове.

Hosts файл в Docker и Kubernetes

В Docker можете да инжектирате записи от hosts файла при стартиране на контейнера, без да променяте хост системата:

“`bash

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

“`

В Kubernetes, `hostAliases` в спецификацията на Pod постига същия резултат:

“`yaml

spec:

hostAliases:

• ip: "192.168.1.100"

hostnames:

• "myservice.local"

“`

Тези подходи са за предпочитане пред промяната на `/etc/hosts` на хоста при работа в контейнеризирани среди.

Дебатът `0.0.0.0` срещу `127.0.0.1` за блокиране

И двата адреса се използват за блокиране на домейни, но се държат по различен начин:

• `127.0.0.1`: Насочва връзката към локалния loopback интерфейс. Ако нищо не слуша на порт 80/443 локално, връзката се отказва — но операционната система все пак се опитва да я установи, причинявайки кратко закъснение.
• `0.0.0.0`: Представлява невалидна дестинация на повечето системи. Връзката се проваля незабавно, без да се опитва TCP ръкостискане, което води до по-бързо зареждане на страниците при блокиране на голям брой домейни за реклами/тракери.

За случаи на употреба с блокиращи списъци, `0.0.0.0` е технически по-добрият избор.

Чести грешки и отстраняване на проблеми

Промените не влизат в сила след редактиране:

• Потвърдете, че записът е синтактично правилен (първо IP, след това името на хоста).
• Изчистете локалния DNS кеш (вижте Стъпка 8).
• Проверете `/etc/nsswitch.conf` — ако `dns` се появява преди `files` в реда `hosts:`, DNS се заявява първо и hosts файлът се заобикаля за кешираните записи.

Грешка `sudo: unable to resolve host` след редактиране:

• Вероятно сте премахнали или повредили реда, съпоставящ името на хоста на вашата машина с `127.0.1.1` или `127.0.0.1`. Незабавно възстановете резервното копие: `sudo cp /etc/hosts.bak.TIMESTAMP /etc/hosts`.

Записът се игнорира за конкретно приложение:

• Някои приложения (по-специално тези, използващи `getaddrinfo` с персонализирани NSS конфигурации, или тези със статично свързани резолвъри) заобикалят изцяло `/etc/nsswitch.conf` и заявяват DNS директно. Това е характерно за Go бинарни файлове, компилирани с деактивиран CGO. Проверете с `strace -e trace=network yourapp`.

Hosts файлът работи локално, но не в Docker контейнер:

• Контейнерната мрежа е изолирана. Контейнерът има собствен `/etc/hosts`. Използвайте `–add-host` или `hostAliases` както е описано по-горе.

Ключови технически изводи: Контролен списък за вземане на решения

Преди да редактирате `/etc/hosts`, преминете през този контролен списък:

• Проверка на обхвата: Необходима ли е тази промяна само на една машина? Ако множество машини се нуждаят от нея, използвайте DNS или инструмент като Ansible за разпространение на промяната.
• Първо резервно копие: Винаги създавайте резервно копие с времеви печат (`hosts.bak.YYYYMMDD_HHMMSS`) преди всяко редактиране.
• Използвайте `0.0.0.0` за блокиране: По-бързо отказване, без overhead от loopback.
• Изчистете правилния кеш: Установете дали системата ви използва `systemd-resolved`, `nscd` или `dnsmasq` преди да рестартирате грешната услуга.
• Тествайте с `getent`: По-надеждно от `ping` за потвърждаване на NSS резолюцията.
• Защитете файла: Използвайте `chattr +i` на производствени или чувствителни към сигурността системи.
• Документирайте записите си: Добавяйте вградени коментари (`# reason – added YYYY-MM-DD`) към всеки запис, различен от стандартния.
• Премахвайте временните записи: Записи за разработка/тестване, оставени в производствени hosts файлове, са честа причина за трудно диагностицируеми грешки при маршрутизиране.

Ако управлявате работен процес за разработка в множество среди, помислете за съчетаване на локалното управление на hosts файла с правилно конфигурирана настройка на VPS Control Panels, за да централизирате управлението на виртуалните хостове и да намалите отклоненията в конфигурацията на отделните машини.

За проекти, включващи Domain Registration и поетапно пускане в производство, hosts файлът остава най-надеждният начин за извършване на пълен end-to-end тест на нова сървърна конфигурация преди завършване на DNS разпространението — давайки ви прозорец за валидиране без риск, преди публиката да види каквато и да е промяна.

ЧЗВ

Изисква ли редактирането на `/etc/hosts` рестартиране на системата?

Не. Промените в `/etc/hosts` влизат в сила незабавно за нови връзки. Ако имате локален DNS кеширащ демон (`systemd-resolved`, `nscd` или `dnsmasq`), трябва да изчистите кеша му. Браузърите също поддържат независими DNS кешове, които може да се наложи да бъдат изчистени ръчно.

Защо записът в hosts файла ми работи в терминала, но не и в браузъра?

Браузърите кешират DNS записи независимо от OS резолвъра. Chrome кешира записи до 60 секунди. Отидете на `chrome://net-internals/#dns` и изчистете кеша на хостовете, или изчакайте TTL да изтече.

Мога ли да използвам заместващи символи в `/etc/hosts`?

Не. Файлът `/etc/hosts` не поддържа записи със заместващи символи. Всяко име на хост трябва да бъде изброено изрично. Ако имате нужда от резолюция със заместващи символи (напр. `*.local`), използвайте локален DNS резолвър като `dnsmasq` или `unbound`.

Какъв е максималният брой записи в `/etc/hosts`?

Няма твърдо кодирано ограничение, наложено от ядрото или glibc. Въпреки това производителността се влошава при много големи файлове, тъй като файлът се анализира линейно при всяко търсене. Файлове с десетки хиляди записи (характерни за списъци за блокиране на реклами) могат да добавят измеримо закъснение при резолюцията на имена на хостове. За големи блокиращи списъци, специализиран DNS sinkhole като Pi-hole е по-ефективен.

Безопасно ли е да изтриете стандартните записи в `/etc/hosts`?

Не. Стандартните записи (`127.0.0.1 localhost`, `::1 localhost` и съпоставянето на собственото име на хоста на машината) са необходими за правилната работа на системата. Премахването им може да наруши работата на `sudo`, локалните socket връзки и приложенията, разчитащи на loopback резолюция. Само добавяйте или променяйте записи; никога не премахвайте стандартните без конкретна, добре разбрана причина.