
0.0.0.0 — это служебный IPv4-адрес, который означает «никакой конкретный адрес» и поэтому в зависимости от места трактуется по-разному: у сервера — «слушать на всех сетевых интерфейсах», в таблице маршрутов — «любая сеть назначения», у клиента без DHCP — «адрес ещё не получен». Отправить пакет на 0.0.0.0 как на обычный хост нельзя.
Что означает IP-адрес 0.0.0.0
Формально весь блок 0.0.0.0/8 зарезервирован под значение «этот хост в этой сети». Требования к узлам в RFC 1122 разрешают использовать 0.0.0.0 только как адрес отправителя — пока устройство загружается и ещё не знает собственного IP. Реестр специальных адресов RFC 6890 подтверждает: адрес назначения из этого блока недопустим, маршрутизаторы такие пакеты не пересылают.
На практике же 0.0.0.0 встречается в пяти ситуациях, и в каждой смысл свой:
- Адрес привязки сервера (
0.0.0.0:80) — сокет принимает соединения на всех IPv4-адресах машины. - Маршрут по умолчанию (
0.0.0.0/0) — «всё, что не попало в более точные маршруты». - Адрес, которого ещё нет — клиент DHCP, роутер без подключения к провайдеру.
- «Пустая» запись в файле hosts — способ заблокировать домен.
- Правило «откуда угодно» в файрволах и облачных группах безопасности.
Общее у них одно: 0.0.0.0 — не адрес конкретного компьютера, а заглушка или шаблон. В двоичном виде это 32 нулевых бита, и именно поэтому в роли маски 0.0.0.0 совпадает с любым адресом. Подробнее о том, как маска отделяет сеть от узла, — в статье про маску подсети и префиксы /8–/32.
0.0.0.0 при запуске сервера: слушать на всех интерфейсах
Это самое частое место встречи с адресом. Когда программа открывает серверный сокет, она указывает, на каком локальном адресе ждать соединений. Варианты:
127.0.0.1— только локальные подключения с этой же машины;192.168.1.10(конкретный адрес) — только через этот интерфейс;0.0.0.0— через любой IPv4-интерфейс: loopback, локальную сеть, внешний адрес, VPN-туннель, Docker-мост.
Отсюда классическая ситуация разработчика: приложение запущено, с ноутбука открывается http://localhost:3000, а с телефона в той же Wi-Fi-сети — нет. Причина почти всегда в том, что сервер слушает 127.0.0.1. Например, dev-сервер Vite по умолчанию привязан к localhost и открывается в сеть флагом --host, а Flask — ключом --host=0.0.0.0.
Обратная ситуация опаснее: сервис, который должен быть внутренним, слушает 0.0.0.0 на машине с публичным IP. Именно поэтому базы данных по умолчанию осторожны:
- PostgreSQL —
listen_addresses = 'localhost'вpostgresql.conf; - MySQL/MariaDB в пакетах большинства дистрибутивов —
bind-address = 127.0.0.1; - Redis —
bind 127.0.0.1 -::1плюсprotected-mode yes.
Если вы меняете эти значения на 0.0.0.0 или *, порт должен закрывать файрвол. Как оценить последствия открытого порта — в разборе чем опасны открытые порты сервера.
Примеры в конфигах
# nginx: без адреса — все IPv4-интерфейсы
listen 80;
# явно то же самое
listen 0.0.0.0:80;
# только локально, например для внутреннего бэкенда
listen 127.0.0.1:8080;
# Python: встроенный сервер только для своей машины
python3 -m http.server 8000 --bind 127.0.0.1
# Docker: -p без адреса публикует порт на всех интерфейсах хоста
docker run -p 8080:80 nginx
# так порт доступен только с самого хоста
docker run -p 127.0.0.1:8080:80 nginx
С Docker есть отдельная ловушка: опубликованный порт пробрасывается правилами iptables, которые Docker добавляет сам, и такой трафик не проходит через правила ufw или firewalld в привычном месте. Об этом прямо предупреждает документация Docker по файрволам. Если сервис в контейнере нужен только nginx на той же машине, публикуйте его на 127.0.0.1. Структура server-блоков и директивы listen подробно разобраны в руководстве по настройке nginx.
А что с IPv6
Аналог 0.0.0.0 в IPv6 — :: (неуказанный адрес, RFC 4291). Сокет на [::]:80 в Linux по умолчанию принимает и IPv4-соединения (dual-stack), если не выставлен net.ipv6.bindv6only=1 или опция ipv6only=on в nginx. Поэтому сервис, «спрятанный» на IPv4, может оказаться открытым по IPv6 — проверяйте оба стека.
Как проверить, на каком адресе слушает сервис
Linux. Команда ss из пакета iproute2 показывает слушающие TCP-сокеты с процессами (для чужих процессов нужен sudo):
sudo ss -tlnp
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=812,fd=6))
LISTEN 0 244 127.0.0.1:5432 0.0.0.0:* users:(("postgres",pid=640,fd=5))
LISTEN 0 511 [::]:80 [::]:* users:(("nginx",pid=812,fd=7))
Здесь nginx открыт для всех, а PostgreSQL — только локально. Запись *:80 означает то же, что «все адреса». Столбец Peer Address со значением 0.0.0.0:* — просто «удалённой стороны пока нет». На старых системах без ss работает sudo netstat -tlnp.
Windows. В командной строке:
netstat -ano | findstr LISTENING
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 1044
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
TCP 127.0.0.1:9229 0.0.0.0:0 LISTENING 15320
Последний столбец — PID; имя процесса покажет tasklist /FI "PID eq 15320". В PowerShell удобнее:
Get-NetTCPConnection -State Listen | Select-Object LocalAddress, LocalPort, OwningProcess | Sort-Object LocalPort
macOS. sudo lsof -nP -iTCP -sTCP:LISTEN — звёздочка в *:8080 означает все интерфейсы.
Локальный вывод говорит, что сервис готов принимать соединения извне. Доходят ли они реально, решают ещё файрвол и NAT. Проверьте снаружи: сканер портов enterno.io обращается к серверу из интернета и показывает, какие порты открыты на самом деле. Пошаговые варианты для разных ОС — в статье как проверить открытые порты.
Маршрут 0.0.0.0/0 — маршрут по умолчанию
В таблице маршрутизации запись с сетью 0.0.0.0 и маской 0.0.0.0 (префикс /0) совпадает с любым адресом назначения. Поскольку выбирается самый длинный совпавший префикс, этот маршрут срабатывает последним — для всего, что не описано точнее. Обычно он указывает на шлюз провайдера или домашний роутер.
# Linux: default — это и есть 0.0.0.0/0
ip route show default
default via 192.168.1.1 dev eth0 proto dhcp metric 100
# Windows
route print -4
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.10 25
В выводе старой команды route -n в Linux 0.0.0.0 встречается ещё и в колонке Gateway: там он значит «шлюза нет, сеть подключена напрямую». В Windows то же самое подписано как «On-link».
Та же запись 0.0.0.0/0 в правилах файрвола и облачных security group означает «с любого адреса интернета». Правило «TCP 22 из 0.0.0.0/0» открывает SSH всему миру — для административных портов лучше перечислить конкретные адреса. Посчитать диапазон по префиксу поможет IP-калькулятор.
0.0.0.0 в DHCP и на роутере: адрес ещё не получен
Компьютер, подключаясь к сети, не знает своего адреса. Поэтому первое сообщение DHCPDISCOVER по RFC 2131 уходит от 0.0.0.0 на широковещательный 255.255.255.255 — это та самая законная роль адреса отправителя. Как проходит обмен целиком, описано в статье что такое DHCP.
Если процесс застрял, 0.0.0.0 становится симптомом:
- На странице статуса роутера WAN IP = 0.0.0.0 — роутер не получил адрес от провайдера: кабель, неверный тип подключения (PPPoE вместо IPoE и наоборот), привязка по MAC у провайдера или авария на линии.
- У клиента шлюз или маска 0.0.0.0 — DHCP-ответ не пришёл. Windows в этом случае обычно назначает себе адрес 169.254.x.x (APIPA), что тоже признак отсутствия DHCP.
Лечение: ipconfig /release и ipconfig /renew в Windows, sudo dhclient -r && sudo dhclient или перезапуск подключения через nmcli в Linux, проверка кабеля и настроек WAN на роутере.
0.0.0.0 в файле hosts
Блок-листы рекламы и трекеров часто выглядят так:
0.0.0.0 ads.example.com
0.0.0.0 tracker.example.net
Файл лежит в C:\Windows\System32\drivers\etc\hosts (Windows) или /etc/hosts (Linux, macOS); после правки сбросьте DNS-кэш: ipconfig /flushdns в Windows, sudo resolvectl flush-caches в Linux с systemd-resolved, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder в macOS.
Почему 0.0.0.0, а не 127.0.0.1? С 127.0.0.1 браузер идёт на вашу же машину, и если там запущен веб-сервер, запрос попадёт в него. С 0.0.0.0 поведение зависит от ОС: в Windows соединение с таким адресом отклоняется сразу, а в Linux и macOS ядро подключается к локальному хосту — так же, как с 127.0.0.1. Значит, на рабочей машине разработчика с локальным сервером на 80-м порту разницы может и не быть.
0.0.0.0 и 127.0.0.1: в чём разница
| Признак | 0.0.0.0 | 127.0.0.1 |
|---|---|---|
| Официальное значение | «Этот хост», неуказанный адрес | Loopback — сама машина |
| Как адрес привязки сервера | Все IPv4-интерфейсы, доступ из сети | Только локальные подключения |
| Как адрес назначения | Не должен использоваться; Linux и macOS подменяют на локальный хост, Windows отклоняет | Всегда своя машина |
| В таблице маршрутов | 0.0.0.0/0 — маршрут по умолчанию | 127.0.0.0/8 — интерфейс lo |
| В файле hosts | Заблокировать домен | Заблокировать или направить на локальный сервер |
| Аналог в IPv6 | :: | ::1 |
Уязвимость «0.0.0.0 Day»
В 2024 году исследователи компании Oligo Security описали проблему, которую назвали 0.0.0.0 Day. Браузеры защищали от обращений публичных сайтов к localhost и 127.0.0.1, но не к 0.0.0.0. А поскольку в Linux и macOS соединение с 0.0.0.0 фактически уходит на локальную машину, страница в интернете могла отправлять запросы к сервисам, запущенным на компьютере посетителя: dev-серверам, локальным панелям, API инструментов разработки. Windows затронута не была — там такое соединение не устанавливается.
После раскрытия производители браузеров начали блокировать обращения к 0.0.0.0 со стороны сайтов, в Chrome — в рамках механизма Private Network Access. Практический вывод для разработчика не зависит от версии браузера: не держите локальные сервисы на 0.0.0.0 без необходимости, привязывайте их к 127.0.0.1 и не оставляйте локальные API без авторизации в расчёте на то, что «снаружи их всё равно не видно».
Как проверить
- Посмотрите локально, какие сервисы слушают 0.0.0.0:
sudo ss -tlnpв Linux илиnetstat -ano | findstr LISTENINGв Windows. - Для каждого сервиса на 0.0.0.0 ответьте, должен ли он быть доступен из сети. Если нет — перепривяжите к 127.0.0.1 в конфиге.
- Проверьте сервер снаружи через сканер портов: лишний открытый порт видно сразу.
- Пересмотрите правила файрвола и облачные группы безопасности с источником 0.0.0.0/0 — особенно для SSH, RDP и баз данных.
Частые вопросы
0.0.0.0 — это мой IP-адрес?
Нет. Если система или роутер показывают вам 0.0.0.0 как свой адрес, значит, адрес не получен: нет ответа от DHCP или провайдера. Настоящий локальный адрес покажут ipconfig в Windows или ip -4 addr в Linux.
Можно ли открыть в браузере http://0.0.0.0:8000?
В Linux и macOS обычно открывается локальный сервер, как с localhost. В Windows соединение не устанавливается, и Chrome показывает ошибку вида ERR_ADDRESS_INVALID. Надёжнее всегда использовать http://127.0.0.1:8000 или http://localhost:8000.
Опасно ли, что сервер слушает 0.0.0.0?
Для веб-сервера на 80 и 443 портах — это норма. Для базы данных, Redis, панели администратора или отладочного порта — риск, если нет файрвола. Решение — привязка к 127.0.0.1 или внутреннему адресу.
Что значит маска 0.0.0.0?
Маска из одних нулей не фиксирует ни одного бита сети, поэтому под неё подходит любой адрес. В записи CIDR это /0, и в паре с сетью 0.0.0.0 она образует маршрут по умолчанию.
Чем 0.0.0.0 отличается от 255.255.255.255?
0.0.0.0 — «никакой конкретный адрес» или «этот хост», а 255.255.255.255 — ограниченная широковещательная рассылка всем узлам текущей сети. В DHCP они работают в паре: запрос уходит от первого на второй.