Открываешь конфиг сервера — там 0.0.0.0. Смотришь таблицу маршрутов — снова 0.0.0.0. Настраиваешь WireGuard — AllowedIPs = 0.0.0.0/0. Заглядываешь в hosts-файл на каком-нибудь блокировщике рекламы — и там тоже он.
Новички в этот момент думают, что что-то сломалось. Опытные админы молча кивают и идут дальше. Потому что 0.0.0.0 — это не баг и не ошибка. Это одна из самых многозначных записей в сетевом мире, которая может означать совершенно разные вещи в зависимости от контекста.
В этой статье разберём все случаи: что значит 0.0.0.0 как адрес, как маска, как маршрут по умолчанию, как параметр VPN и как инструмент блокировки в DNS. С примерами, командами и без академической нудятины.
Что такое 0.0.0.0
Формально — это IPv4-адрес, в котором все четыре октета равны нулю. Но в отличие от обычных IP-адресов, он не маршрутизируемый (non-routable) и не привязан к конкретному устройству или интерфейсу.
По стандарту RFC 1122 адрес 0.0.0.0 относится к категории «специальных». Его нельзя назначить сетевому интерфейсу как постоянный адрес, нельзя отправить на него пакет через интернет, и никакой реальный хост не должен использовать его как источник или назначение в обычном трафике.
Но при этом он везде. Почему? Потому что в разных контекстах он означает разные вещи:
- «Любой адрес» — когда сервис слушает 0.0.0.0, он принимает подключения на всех интерфейсах
- «Адрес не задан» — когда устройство ещё не получило IP (DHCP-запрос до получения аренды)
- «Весь интернет» — в маршрутизации 0.0.0.0/0 означает маршрут по умолчанию
- «Заблокировано» — в hosts-файле 0.0.0.0 используется для блокировки доменов
Один адрес, четыре совершенно разных смысла. Разберём каждый.
0.0.0.0 как адрес: когда сервис слушает «на всём»
Самый частый случай, с которым сталкиваются разработчики и системные администраторы — это адрес 0.0.0.0 в параметрах запуска сервиса.
Когда вы запускаете веб-сервер, он должен «слушать» на каком-то адресе и порту. Если указать конкретный IP — например, 192.168.1.10:80 — сервер будет принимать запросы только на этот адрес. Если указать 0.0.0.0:80 — сервер слушает на всех сетевых интерфейсах сразу: и на локальном, и на внешнем, и на VPN-адресе.
HTTP и 0.0.0.0:80
В конфигурации Nginx:
server {
listen 0.0.0.0:80;
server_name example.com;
}
Это значит: «принимай HTTP-запросы на порт 80 с любого IP-адреса, который есть на этом сервере». На практике большинство дистрибутивов Linux и конфигурации веб-серверов используют именно такую запись — она удобнее, чем перечислять все IP вручную.
Краткая запись без явного указания адреса делает то же самое:
server {
listen 80;
}
Nginx по умолчанию подставляет 0.0.0.0.
HTTPS и 0.0.0.0:443
server {
listen 0.0.0.0:443 ssl;
server_name example.com;
}
Аналогично для HTTPS — слушаем на всех интерфейсах, порт 443.
Проверить, на чём слушает процесс
# Linux ss -tlnp | grep :80 netstat -tlnp | grep :80
Если в столбце Local Address видите 0.0.0.0:80 — сервис слушает на всех интерфейсах. Если 127.0.0.1:80 — только локально.
А это безопасно?
Зависит от того, что слушает на 0.0.0.0. Веб-сервер, который должен быть доступен из интернета — да, нормально. База данных MySQL или Redis, которую вы случайно запустили на 0.0.0.0 вместо 127.0.0.1 — это уже повод для ночного кошмара и срочного патча.
Правило простое: всё, что не должно быть доступно извне, должно слушать на 127.0.0.1, а не на 0.0.0.0. Firewall тоже не помешает, но не заменяет правильный bind.
Маска 0.0.0.0 и сеть 0.0.0.0: что это означает в маршрутизации
Здесь начинается самое интересное. В контексте маршрутизации маска 0.0.0.0 означает «никаких ограничений» — то есть подходит любой IP-адрес.
В CIDR-нотации это записывается как 0.0.0.0/0 — ноль значащих бит в маске. Для сравнения:
| Запись | Маска | Покрывает | Пример |
|---|---|---|---|
| 192.168.1.0/24 | 255.255.255.0 | 254 хоста | Локальная подсеть офиса |
| 10.0.0.0/8 | 255.0.0.0 | ~16 млн хостов | Крупная корпоративная сеть |
| 0.0.0.0/0 | 0.0.0.0 | Все IPv4-адреса | Default route, весь интернет |
Маска 0.0.0.0 (или /0) — это «совпадает с чем угодно». Именно поэтому она используется для маршрута по умолчанию.
0.0.0.0/0 как default route: куда идёт весь трафик
Маршрут по умолчанию (default route) — это инструкция для роутера или операционной системы: «если не знаешь, куда отправить пакет — отправь сюда». Записывается как 0.0.0.0/0 с указанием шлюза.
Как это работает
Когда система получает пакет для отправки, она смотрит в таблицу маршрутов сверху вниз — от самых конкретных маршрутов к самым общим. Если ни один конкретный маршрут не совпал — срабатывает 0.0.0.0/0, и пакет уходит на шлюз по умолчанию.
# Посмотреть таблицу маршрутов на Linux ip route show # Типичный вывод: default via 192.168.1.1 dev eth0 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100
Строка default via 192.168.1.1 — это и есть 0.0.0.0/0. Пакет в интернет? Идёт на 192.168.1.1 (роутер). Пакет в 192.168.1.0/24? Уходит напрямую в локальную сеть.
Добавить маршрут по умолчанию вручную
# Linux ip route add default via 192.168.1.1 # Или в старом синтаксисе route add default gw 192.168.1.1
В MikroTik
/ip route add dst-address=0.0.0.0/0 gateway=192.168.1.1
Посмотреть текущий default route
# Linux ip route show 0.0.0.0/0 # MikroTik /ip route print where dst-address=0.0.0.0/0
Если default route отсутствует — хост не знает, куда слать трафик за пределы известных подсетей. Интернет не работает. Это одна из первых вещей, которую проверяют при диагностике «не пингуется 8.8.8.8».
CIDR-нотация: 0.0.0.0/0 и 0.0.0.0/32 — в чём разница
Путаница с CIDR возникает постоянно, поэтому разберём главные варианты с нулями.
0.0.0.0/0 — весь интернет
Ноль значащих бит в маске. Совпадает с любым IPv4-адресом. Используется как default route и в VPN для full tunnel (об этом ниже).
0.0.0.0/32 — один конкретный хост
Тридцать два значащих бита. Это маска одного хоста — только адрес 0.0.0.0 ровно. В нормальной маршрутизации такая запись не имеет смысла, потому что 0.0.0.0 как хост не существует. Если вы видите 0.0.0.0/32 в конфиге — скорее всего, это ошибка конфигурации (об этом в кейсах).
0.0.0.0/8, /16, /24 — редкие случаи
Диапазоны, начинающиеся с 0.x.x.x. В RFC 1122 адреса сети 0.0.0.0/8 зарезервированы и не используются в публичном интернете. В частных сетях такое тоже лучше не трогать — путаницы больше, чем пользы.
| Запись | Значение | Применение |
|---|---|---|
| 0.0.0.0/0 | Все адреса | Default route, VPN full tunnel |
| 0.0.0.0/32 | Только 0.0.0.0 | Обычно ошибка конфига |
| 0.0.0.0/8 | Сеть 0.x.x.x | Зарезервировано, не использовать |
0.0.0.0 в DNS и файле hosts: блокировка рекламы и защита
Файл hosts — это локальная таблица соответствий «домен → IP», которую операционная система проверяет раньше, чем идти к DNS-серверу. Находится по пути /etc/hosts на Linux/macOS и C:\Windows\System32\drivers\etc\hosts на Windows.
Зачем туда пишут 0.0.0.0
Классический способ заблокировать домен — прописать его в hosts с адресом 127.0.0.1 (localhost). Браузер пойдёт по этому адресу, ничего не найдёт, запрос провалится. Блокировка работает.
Но у 127.0.0.1 есть нюанс: если на localhost что-то слушает (например, локальный сервер разработки), браузер может получить ответ и показать что-то неожиданное. Поэтому многие блокировщики рекламы и защитные hosts-файлы используют 0.0.0.0 вместо 127.0.0.1.
0.0.0.0 ads.example.com 0.0.0.0 tracker.somesite.net 0.0.0.0 doubleclick.net
Запрос к ads.example.com? Система смотрит в hosts, видит 0.0.0.0, пытается соединиться с этим адресом — и немедленно получает отказ. Соединение с 0.0.0.0 не проходит никуда. Это быстрее и чище, чем перенаправление на localhost.
Популярные hosts-файлы для блокировки
Проекты вроде StevenBlack/hosts содержат десятки тысяч записей вида 0.0.0.0 домен для блокировки рекламных сетей, трекеров и вредоносных доменов. Устанавливаешь такой файл — и реклама пропадает на уровне DNS без каких-либо браузерных расширений.
DNS-сервер на 0.0.0.0
В конфигурации локального DNS-резолвера (например, dnsmasq или bind9) адрес 0.0.0.0 в параметре listen означает «слушать на всех интерфейсах»:
# dnsmasq.conf listen-address=0.0.0.0
Или при запуске:
dnsmasq --listen-address=0.0.0.0
Та же логика, что и с веб-сервером: 0.0.0.0 = принимаем запросы отовсюду.
AllowedIPs = 0.0.0.0/0 в VPN: full tunnel и split tunnel
Один из самых частых вопросов при настройке WireGuard: «что значит AllowedIPs = 0.0.0.0/0 и зачем это нужно?» Отвечаем.
Как работает AllowedIPs в WireGuard
Параметр AllowedIPs в конфиге WireGuard выполняет две функции одновременно:
- Routing: трафик, назначение которого попадает в AllowedIPs, уходит через VPN-туннель
- Фильтрация входящего: через туннель принимается только трафик из этих адресов
Full tunnel: AllowedIPs = 0.0.0.0/0
Если указать 0.0.0.0/0 — весь трафик (все IPv4-адреса) идёт через VPN. Это называется full tunnel: и рабочий трафик, и личный браузинг, и стриминг — всё через туннель.
[Peer] PublicKey = <ключ сервера> Endpoint = vpn.example.com:51820 AllowedIPs = 0.0.0.0/0
Когда использовать: корпоративный VPN, где нужно, чтобы весь трафик сотрудника шёл через офис; обход блокировок, когда нужно выводить весь трафик через другой IP.
Split tunnel: конкретные подсети
Если нужно пускать через VPN только трафик к определённым ресурсам — указываем конкретные подсети:
[Peer] PublicKey = <ключ сервера> Endpoint = vpn.example.com:51820 AllowedIPs = 10.0.0.0/8, 192.168.100.0/24
Теперь через VPN идёт только трафик в 10.x.x.x и 192.168.100.x. Всё остальное — напрямую. Это split tunnel: экономит полосу и не замедляет личный трафик.
Сравнение режимов
| Параметр | Full tunnel (0.0.0.0/0) | Split tunnel (конкретные IP) |
|---|---|---|
| Весь трафик через VPN | ✅ Да | ❌ Нет |
| Нагрузка на VPN-сервер | Высокая | Низкая |
| Скорость личного трафика | Ограничена VPN | Максимальная |
| Анонимность внешнего IP | ✅ Полная | ❌ Только для VPN-ресурсов |
| Корпоративное применение | Контроль трафика сотрудников | Доступ к внутренним ресурсам |
А что с IPv6?
Если используете full tunnel и хотите закрыть весь трафик, не забудьте про IPv6. Полная запись для WireGuard:
AllowedIPs = 0.0.0.0/0, ::/0
Без ::/0 IPv6-трафик будет обходить туннель и раскрывать реальный IP.
5 практических кейсов
Кейс 1: Почему сайт слушает 0.0.0.0 — и это нормально
Развернули новый сервер, запустили Nginx, проверяете:
ss -tlnp | grep nginx
Видите 0.0.0.0:80 и 0.0.0.0:443. Не паникуйте — это правильно. Nginx слушает на всех интерфейсах: и на внешнем IP (доступен из интернета), и на внутреннем (доступен из локальной сети).
Если хотите ограничить — меняете listen в конфиге:
# Только для внешнего IP
server {
listen 1.2.3.4:80;
}
# Только локально
server {
listen 127.0.0.1:80;
}
Для базы данных — обязательно ограничивайте. MySQL, PostgreSQL, Redis на 0.0.0.0 без firewall — прямой путь к взлому.
# Проверить, на чём слушает MySQL ss -tlnp | grep :3306 # Исправить в my.cnf bind-address = 127.0.0.1
Кейс 2: Настроить full tunnel VPN через WireGuard
Задача: весь трафик клиента должен идти через VPN-сервер.
На сервере (например, 10.0.0.1 — VPN-адрес сервера):
[Interface] Address = 10.0.0.1/24 ListenPort = 51820 PrivateKey = <приватный ключ сервера> PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE [Peer] PublicKey = <публичный ключ клиента> AllowedIPs = 10.0.0.2/32
На клиенте:
[Interface] Address = 10.0.0.2/24 PrivateKey = <приватный ключ клиента> DNS = 1.1.1.1 [Peer] PublicKey = <публичный ключ сервера> Endpoint = vpn.example.com:51820 AllowedIPs = 0.0.0.0/0, ::/0 PersistentKeepalive = 25
AllowedIPs = 0.0.0.0/0 — весь IPv4-трафик через туннель. ::/0 — весь IPv6. Включаем:
wg-quick up wg0
Проверяем внешний IP — должен быть IP VPN-сервера:
curl ifconfig.me
Кейс 3: Блокировка рекламы через hosts с 0.0.0.0
Быстрый способ заблокировать рекламные домены без браузерного расширения — скачать готовый hosts-файл и применить.
# Скачать hosts-файл (пример: StevenBlack) curl -o /tmp/hosts https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts # Добавить к существующему /etc/hosts (не заменять целиком!) sudo cat /tmp/hosts >> /etc/hosts # Сбросить DNS-кеш на Linux (systemd) sudo systemd-resolve --flush-caches # На macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
После этого браузеры перестанут разрешать домены из списка — запросы будут падать на 0.0.0.0 и немедленно отклоняться.
Кейс 4: Настройка и диагностика маршрута по умолчанию
Классика: сервер не выходит в интернет. Начинаем с маршрутов.
# Смотрим таблицу маршрутов ip route show # Если default route отсутствует — добавляем ip route add default via 192.168.1.1 # Делаем постоянным (Ubuntu/Debian, netplan) # В /etc/netplan/00-installer-config.yaml: # routes: # - to: default # via: 192.168.1.1 # Применяем netplan sudo netplan apply
В MikroTik — диагностика и добавление:
# Смотрим маршруты /ip route print # Нет default route? Добавляем /ip route add dst-address=0.0.0.0/0 gateway=192.168.1.1 # Проверяем /ip route print where dst-address=0.0.0.0/0
Кейс 5: Почему 0.0.0.0/32 ломает сеть — ошибка конфигурации
Это реальная история. Администратор настраивал маршрутизацию, ошибся и добавил маршрут 0.0.0.0/32 via 10.0.0.1 вместо 0.0.0.0/0.
Что произошло: маршрут 0.0.0.0/32 — это маршрут к одному хосту 0.0.0.0. Default route так и не появился. Весь трафик, которому не нашёлся конкретный маршрут, никуда не пошёл. Интернет лёг.
# Диагностика: ищем кривые маршруты ip route show | grep "0.0.0.0/32" # Удаляем ошибочный маршрут ip route del 0.0.0.0/32 # Добавляем правильный ip route add default via 192.168.1.1
Вывод: /0 и /32 — противоположные крайности. /0 — весь интернет. /32 — один хост. Перепутать их легко при быстрой печати, последствия — немедленные.
Побочные эффекты и частые ошибки
Ошибка 1: База данных на 0.0.0.0
MySQL, Redis, MongoDB — если они слушают на 0.0.0.0 и нет firewall, база открыта для всего интернета. Проверяйте bind-адреса после каждой установки.
Ошибка 2: AllowedIPs = 0.0.0.0/0 без NAT на сервере
Настроили full tunnel WireGuard, но забыли включить маскарадинг (NAT) на сервере. Клиент отправляет трафик в туннель, сервер получает пакеты, но не знает, куда их отправить дальше. Интернет не работает. Решение — PostUp с iptables MASQUERADE, как в кейсе 2.
Ошибка 3: 0.0.0.0/32 вместо 0.0.0.0/0
Описано в кейсе 5. Всегда дважды проверяй маску при вводе default route.
Ошибка 4: Думать, что 0.0.0.0 в логах — это атака
Иногда в логах приложений видишь соединения от 0.0.0.0. Это не взлом — это внутренние события, связанные с bind и локальными сокетами. Паниковать не надо, разобраться — стоит.
Итог: рецепт от IT-Аптеки
Адрес 0.0.0.0 — это не ошибка и не случайность. Это многозначный инструмент, который IT-специалисты используют каждый день, часто даже не задумываясь об этом. Разобрав его один раз, ты перестаёшь удивляться, почему он появляется везде.
Быстрая шпаргалка:
- Сервис слушает 0.0.0.0:80 — принимает подключения на всех интерфейсах. Нормально для веб-серверов, опасно для баз данных.
- 0.0.0.0/0 в таблице маршрутов — маршрут по умолчанию. Весь неизвестный трафик уходит на шлюз.
- Маска 0.0.0.0 — означает «любой адрес», равнозначна /0 в CIDR.
- 0.0.0.0 в hosts-файле — блокировка домена. Запрос никуда не уходит.
- AllowedIPs = 0.0.0.0/0 в WireGuard — full tunnel, весь трафик через VPN.
- 0.0.0.0/32 — маршрут к несуществующему хосту. Почти всегда ошибка конфигурации.
Если у вас остались вопросы, что-то пошло не так или хотите разобрать свой кейс — пишите в комментарии. Подпишитесь на наш Telegram-канал — там выходят практические гайды, скрипты и разборы ошибок без воды.
Author: over_dude
Оставайтесь на связи
Рецепты от IT-боли. Без воды, без рекламы, без маркетинговой шелухи.
Подписаться на IT-Аптеку →
