Debian/Ubuntu: как исправить curl error 6 Could not resolve host и проблемы с DNS

Ошибка curl: (6) Could not resolve host в Debian и Ubuntu выглядит простой, но причин у неё несколько: от опечатки в имени хоста до сломанного /etc/resolv.conf, проблем с systemd-resolved, неверных DNS-серверов или некорректной сетевой конфигурации. Хорошая новость в том, что такая неисправность обычно находится быстро, если идти по понятному маршруту, а не менять настройки вслепую.

Ниже разберём практический сценарий диагностики: как понять, где именно ломается резолвинг имён, чем отличаются dig, nslookup и getent hosts, как проверить состояние systemd-resolved, когда стоит трогать /etc/resolv.conf, а когда лучше этого не делать, и какие изменения безопасны для продакшн-сервера.

Сразу отмечу важный момент: curl error 6 не всегда означает поломку DNS на уровне системы. Иногда ошибка вообще в самой команде. Классический пример — забыли взять аргумент в кавычки, и shell передал часть строки как отдельный параметр, который curl попытался трактовать как имя хоста. Поэтому диагностику лучше начинать от простого к сложному.

Типичный симптом выглядит так:

curl https://example.com
curl: (6) Could not resolve host: example.com

Иногда ошибка появляется только у curl, а другие утилиты продолжают работать. А иногда не резолвится вообще ничего: apt, wget, ping, API-клиенты и пакетные менеджеры. Это уже хороший индикатор, что искать нужно в системном DNS-резолвере.

Что означает Could not resolve host

Эта ошибка означает, что приложение не смогло преобразовать доменное имя в IP-адрес. То есть проблема возникает на этапе DNS-резолвинга, ещё до TCP-подключения и до TLS. Если имя не превратилось в A или AAAA-запись, соединение просто не с чем устанавливать.

На практике цепочка выглядит так: приложение обращается к библиотеке резолвинга, та использует системные настройки, затем запрос уходит локальному резолверу или напрямую DNS-серверу, после чего возвращается ответ. Сбой может быть на любом звене: неправильное имя, ошибка в /etc/nsswitch.conf, нерабочий /etc/resolv.conf, упавший systemd-resolved, недоступный upstream DNS, проблемы маршрутизации или фильтрация трафика.

Главная идея troubleshooting здесь простая: сначала проверяем, не ошиблись ли в самой команде и имени хоста, затем тестируем системный резолвинг, и только после этого правим конфиги.

Быстрая первичная проверка

Перед разбором конфигурации убедитесь, что проблема воспроизводится стабильно и не связана с синтаксисом команды. Начните с трёх простых шагов.

Проверяем саму команду curl

curl -v https://example.com

Если в URL есть спецсимволы, параметры запроса или заголовки, перепроверьте кавычки. Частая ошибка выглядит так:

curl -H Host: example.com https://127.0.0.1

В этом случае shell разбивает аргументы, и curl может интерпретировать example.com не так, как вы ожидали. Безопасный вариант:

curl -H 'Host: example.com' https://127.0.0.1

Проверяем системный резолвинг

getent hosts example.com

Команда getent hosts полезна тем, что использует системный механизм резолвинга. Если getent не возвращает адрес, проблема почти наверняка системная.

Проверяем DNS напрямую

dig example.com
nslookup example.com

dig и nslookup показывают, как работает DNS как сетевой сервис, а getent hosts — что видит система через NSS. Поэтому возможна ситуация, когда dig отвечает, а getent — нет. Это уже намёк, что проблема находится между приложением и системным резолвером.

Минимальный маршрут диагностики DNS в Linux

Если нужно быстро локализовать проблему, я обычно иду в таком порядке:

1. Проверяю, есть ли сеть и маршрут до внешних адресов.
2. Смотрю, работает ли резолвинг через getent hosts.
3. Проверяю dig с системными настройками и с явным DNS-сервером.
4. Изучаю /etc/resolv.conf.
5. Проверяю состояние systemd-resolved.
6. Смотрю, кто вообще управляет DNS: Netplan, NetworkManager, cloud-init, ifupdown или ручные настройки.

Вот базовый набор команд:

ip addr
ip route
ping -c 1 1.1.1.1
getent hosts example.com
dig example.com
dig @1.1.1.1 example.com
resolvectl status
ls -l /etc/resolv.conf
cat /etc/resolv.conf

Если ping до IP проходит, а домены не резолвятся, проблема действительно в DNS, а не в общей сетевой связности.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Проверка файла resolv.conf

Файл /etc/resolv.conf — первая точка, куда смотрят многие админы, и это правильно. Но важно не просто открыть его, а понять, кто им управляет. В современных Debian и Ubuntu этот файл часто является симлинком, а не обычным статическим конфигом.

ls -l /etc/resolv.conf

Возможны такие варианты:

• обычный файл с вручную прописанными nameserver;
• симлинк на файл, который генерирует systemd-resolved;
• симлинк на конфиг от NetworkManager или другой сетевой подсистемы.

Типичное содержимое выглядит так:

nameserver 127.0.0.53
options edns0 trust-ad
search localdomain

Если вы видите 127.0.0.53, это не ошибка. Это локальный stub resolver от systemd-resolved. В таком режиме приложения обращаются к локальному слушателю, а уже он отправляет запросы на реальные upstream DNS-серверы.

Проблема появляется, если:

• /etc/resolv.conf указывает на несуществующий или неверный файл;
• в нём пусто или отсутствуют строки nameserver;
• файл вручную переписали, но сетевой менеджер потом откатывает изменения;
• указан 127.0.0.53, но сам systemd-resolved не работает.

Как выглядит явная поломка

Например, если /etc/resolv.conf пустой или содержит невалидную конфигурацию, резолвинг может не работать совсем:

cat /etc/resolv.conf

nameserver 127.0.0.1

Если при этом на локальном хосте нет DNS-сервера, такой конфиг почти гарантированно приведёт к ошибкам уровня Could not resolve host.

Диагностика systemd-resolved

В Ubuntu и части установок Debian именно systemd-resolved отвечает за DNS. Поэтому следующий шаг — проверить, запущен ли сервис и какие DNS-серверы он использует.

systemctl status systemd-resolved --no-pager
resolvectl status

Команда resolvectl status особенно полезна: она показывает глобальные DNS-серверы, настройки по интерфейсам, search domains и дополнительные параметры резолвера.

Ищите такие признаки проблемы:

• сервис не запущен или находится в состоянии failed;
• у интерфейса не назначены DNS-серверы;
• назначен DNS-сервер, недоступный из этой сети;
• есть split-DNS или VPN-профиль, который перехватывает запросы;
• в журнале встречаются таймауты, SERVFAIL или ошибки соединения.

Полезно сразу посмотреть журнал:

journalctl -u systemd-resolved -b --no-pager

Если сервис застрял в неконсистентном состоянии, иногда помогает перезапуск:

sudo systemctl restart systemd-resolved
resolvectl flush-caches

После этого снова проверьте:

getent hosts example.com
curl -I https://example.com

Когда dig работает, а curl всё ещё падает

Это один из самых полезных диагностических сценариев. Если команда вида dig @1.1.1.1 example.com возвращает ответ, а curl пишет error 6, то сеть наружу есть и DNS-сервер отвечает. Значит, нужно смотреть на локальную интеграцию DNS в системе.

Чаще всего виноваты:

• сломанный /etc/resolv.conf;
• неработающий systemd-resolved;
• нестандартная настройка в контейнере, chroot или network namespace;
• ошибка в /etc/nsswitch.conf;
• локальная фильтрация, которая блокирует доступ к DNS-серверу, указанному в системе.

Проверьте строку hosts в /etc/nsswitch.conf:

grep '^hosts:' /etc/nsswitch.conf

Обычно она выглядит так:

hosts: files mdns4_minimal [NOTFOUND=return] dns

На серверах без mDNS часто встречается и более простой вариант:

hosts: files dns

Если модуль dns отсутствует вовсе, приложения не будут выполнять обычные DNS-запросы через системный механизм.

Как безопасно восстановить resolv.conf

Самая частая ошибка при ремонте DNS — грубо переписать /etc/resolv.conf, не разобравшись, кто должен им управлять. Это может временно помочь, но после перезагрузки или обновления сетевого интерфейса проблема вернётся.

Сначала проверьте, существуют ли стандартные файлы от systemd-resolved:

ls -l /run/systemd/resolve/stub-resolv.conf
ls -l /run/systemd/resolve/resolv.conf

Если вы используете systemd-resolved в штатном режиме, обычно достаточно восстановить симлинк:

sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved

После этого проверьте результат:

cat /etc/resolv.conf

Если по архитектуре сервера вы не используете локальный stub, иногда выбирают ссылку на файл с реальными upstream DNS-серверами:

sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved

Но здесь важно понимать последствия. Поведение приложений может отличаться, особенно если у вас есть VPN, split-DNS или нестандартные маршруты. На обычных серверах я рекомендую сначала возвращать штатную схему, а не строить собственную вручную.

Если у вас крутится приложение на VDS, такой подход особенно важен: временный фикс почти всегда надо доводить до нормальной конфигурации, иначе инцидент повторится после ближайшего reload сети или reboot.

Если DNS-серверы не назначаются автоматически

Тогда проблема не в самом curl и не в resolv.conf, а выше — в том компоненте, который настраивает сеть. В Ubuntu это часто Netplan, который передаёт параметры либо systemd-networkd, либо NetworkManager. В Debian встречаются и классические конфиги интерфейсов.

Для серверной Ubuntu проверьте файлы Netplan:

ls /etc/netplan
cat /etc/netplan/*.yaml

Пример явного задания DNS:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      addresses:
        - 192.0.2.10/24
      routes:
        - to: default
          via: 192.0.2.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8

После правки применяйте изменения аккуратно, особенно на удалённом сервере:

sudo netplan try
sudo netplan apply

На Debian с ifupdown стоит проверить, не заданы ли DNS-параметры в конфигурации интерфейса или DHCP-клиента. Ещё один частый источник неожиданных изменений — cloud-init, который при следующем запуске может заново сгенерировать сетевые настройки.

Если проблема появилась после переноса сайта или изменения сетевой схемы, полезно также проверить, не сломаны ли DNS-настройки самого домена и делегирование. Для этого может пригодиться материал про делегирование NS и настройку поддоменов.

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

Проверка DNS-сервера на доступность

Иногда конфигурация формально правильная, но сами upstream DNS недоступны: не проходит маршрут, их режет фильтрация, сломан IPv6-путь или сервер отвечает слишком медленно. Тогда resolv.conf выглядит нормально, но запросы всё равно не работают.

Сначала посмотрите, какие серверы реально используются:

resolvectl dns
resolvectl status

Затем проверьте запросы к каждому явно:

dig @1.1.1.1 example.com
dig @8.8.8.8 example.com
dig @9.9.9.9 example.com

Если один сервер отвечает, а другой нет, проблема локализована. Если не отвечает ни один, проверьте маршрутизацию и доступность DNS-трафика.

Иногда помогает раздельный тест по IPv4 и IPv6:

dig -4 @1.1.1.1 example.com
dig -6 @2606:4700:4700::1111 example.com

На серверах с нерабочим IPv6 бывают странные зависания и таймауты DNS, особенно если резолвер пытается использовать IPv6 DNS-серверы, которые фактически недоступны.

Временное аварийное решение, если сервис нужно поднять срочно

Если у вас production-инцидент и нужно быстро вернуть резолвинг, можно временно прописать рабочие DNS-серверы вручную в /etc/resolv.conf. Но это именно временная мера, а не окончательный ремонт.

sudo cp /etc/resolv.conf /etc/resolv.conf.bak
printf 'nameserver 1.1.1.1\nnameserver 8.8.8.8\n' | sudo tee /etc/resolv.conf

После этого проверьте:

getent hosts example.com
curl -I https://example.com

Если всё заработало, значит корневая причина точно находится в управляющем слое DNS, а не в приложении. Дальше нужно спокойно разобраться, кто должен генерировать этот файл, и вернуть систему к штатной схеме.

Не оставляйте аварийную ручную правку навсегда, если на сервере есть Netplan, NetworkManager, systemd-resolved или cloud-init. Иначе через некоторое время можно снова получить тот же инцидент после обычной перезагрузки.

Короткий чек-лист для DNS troubleshooting

1. Проверьте, что проблема не в синтаксисе команды curl.
2. Убедитесь, что IP-связность есть: интерфейс, маршрут, доступ до внешнего IP.
3. Сравните вывод getent hosts, dig и nslookup.
4. Проверьте /etc/resolv.conf и определите, файл это или симлинк.
5. Проверьте systemd-resolved: статус, DNS, журнал, кэш.
6. Убедитесь, что DNS-серверы реально достижимы.
7. Проверьте, кто управляет сетью и DNS: Netplan, ifupdown, NetworkManager, cloud-init.
8. Только после этого вносите постоянные изменения.

Практический сценарий: ошибка после ручной правки сети

Очень типичная история на VPS или выделенном сервере: администратор меняет сетевой конфиг, перезапускает интерфейс, после чего apt и curl начинают падать с Could not resolve host. Почти всегда причина в том, что прописали адрес и шлюз, но забыли про DNS-серверы.

Диагностика в таком случае обычно выглядит так:

ip route
cat /etc/resolv.conf
resolvectl status
getent hosts deb.debian.org

Если маршрут есть, а DNS-серверов нет, нужно прописать их в том инструменте, который управляет сетью, а не только в текущем состоянии системы. Иначе после следующего reload проблема повторится.

Итоги

Ошибка curl error 6 в Debian и Ubuntu — это не отдельная неисправность curl, а симптом того, что система не смогла разрешить имя хоста. Чаще всего корень проблемы лежит в одном из трёх мест: неверный /etc/resolv.conf, сбой systemd-resolved или отсутствие корректно назначенных DNS-серверов на уровне сетевой конфигурации.

Если запомнить один практический принцип, то он такой: сначала сравните getent hosts, dig и nslookup, затем проверьте resolv.conf и статус systemd-resolved, и только потом что-то переписывайте. Такой порядок экономит время и снижает риск сломать рабочую конфигурацию ещё сильнее.

А для серверов в продакшне особенно важно не ограничиваться временными фиксами. Если DNS восстановился после ручной записи в resolv.conf, это не финал, а только подсказка, где искать настоящую причину. Правильное решение — вернуть управление DNS в штатный для системы механизм и убедиться, что после перезагрузки всё остаётся в рабочем состоянии.