Сообщение Failed to fetch во время apt update — одна из самых частых проблем на Debian и Ubuntu. На практике это не одна ошибка, а целый класс сбоев: от банального отсутствия DNS до некорректного прокси, битого зеркала, проблем с TLS или IPv6. Поэтому полезнее не «лечить APT целиком», а быстро понять, на каком именно слое рвётся цепочка: имя репозитория, маршрут, транспорт, сертификаты или конфигурация источников.
Типичный симптом выглядит так: часть репозиториев обновляется нормально, а часть отдаёт Failed to fetch. Часто рядом есть уточнение: Temporary failure resolving, Connection timed out, TLS handshake failed, Could not connect, 404 Not Found или Connection refused. Именно эта строка обычно и даёт ключ к диагнозу.
Хорошая новость в том, что в большинстве случаев проблема решается без переустановки системы и без опасных действий вроде отключения проверки подписей. Достаточно идти по короткому runbook: проверить репозитории, DNS, сетевую доступность, прокси, время и затем уже переходить к более редким случаям вроде MTU или сломанного IPv6.
С чего начать: смотрите не на заголовок ошибки, а на её хвост
Когда администратор видит apt failed to fetch, первый порыв — сразу менять зеркало или чистить кэш. Но APT почти всегда пишет, что именно ему не понравилось. Для начала просто повторите обновление и внимательно прочитайте вывод.
apt updateНаиболее частые варианты означают следующее:
Temporary failure resolving— проблема с DNS.Could not connectилиConnection timed out— проблема с сетью, маршрутом, firewall, proxy или IPv6.Connection refused— порт доступен, но сервис на стороне зеркала или прокси не принимает соединение.404 Not Found— неверный путь, устаревший репозиторий или неправильный codename.TLS handshake failed— сбой TLS, время, сертификаты, прокси с инспекцией, иногда MTU.The repository does not have a Release file— неподходящий или некорректный репозиторий.
Первое правило диагностики здесь простое: чините не «apt», а тот уровень, на котором APT перестал получать индекс пакетов.
Проверьте sources.list и codename системы
Очень часто проблема начинается после ручной правки sources.list, добавления внешнего репозитория или обновления ОС. Поэтому сначала полезно посмотреть, какие источники реально подключены и не осталось ли там старых записей.
grep -R ^deb /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null
ls -la /etc/apt/sources.list.d/Что проверить в первую очередь:
- совпадает ли codename с вашей системой:
bookworm,bullseye,jammy,nobleи так далее; - нет ли дубликатов с разными URL;
- не остались ли старые PPA или внешние репозитории после апгрейда;
- существует ли указанный путь на зеркале.
Текущий релиз можно быстро уточнить так:
. /etc/os-release
echo "$PRETTY_NAME"
echo "$VERSION_CODENAME"Если в источниках указан старый релиз или просто есть опечатка в имени ветки, APT будет стабильно получать 404 Not Found, даже если сеть и DNS полностью исправны.
Если система работает на сервере или в облаке, где вам нужна предсказуемая среда для обновлений и диагностики, удобнее держать такие машины на отдельном VDS с понятной сетевой схемой и полным контролем над DNS, маршрутами и прокси.
Если ошибка про resolving, почти всегда виноват DNS
Сообщение Temporary failure resolving обычно означает, что сервер не может превратить имя репозитория в IP-адрес. Это один из самых частых сценариев: по IP всё может ходить, а по имени — уже нет.
resolvectl status
cat /etc/resolv.conf
getent hosts deb.debian.org
getent hosts archive.ubuntu.comЕсли getent ничего не возвращает, круг причин уже сильно сужается. Обычно проблема в одном из следующих мест:
- не работает локальный резолвер;
- в
/etc/resolv.confпусто или указаны неверные DNS; - сломался
systemd-resolved; - firewall режет исходящие DNS-запросы;
- интерфейс не получил DNS через DHCP или netplan.
Проверьте состояние резолвера:
systemctl status systemd-resolved --no-pager
journalctl -u systemd-resolved -n 50 --no-pagerОтдельно стоит посмотреть, не был ли вручную перезаписан /etc/resolv.conf. На системах с systemd-resolved это частая ловушка: после ручной правки там остаются старые или невалидные адреса, и APT начинает падать именно на этапе DNS.
Проверьте, есть ли доступ до зеркала по сети
Если DNS работает, следующий шаг — убедиться, что машина вообще может дойти до зеркала по HTTP или HTTPS. Обычный ping здесь не всегда показателен: ICMP может быть закрыт, а веб-трафик — разрешён. Поэтому лучше тестировать именно тот транспорт, который использует APT.
getent hosts deb.debian.org
getent hosts archive.ubuntu.com
ip route
ip -4 route
ip -6 route
curl -I deb.debian.org
curl -I archive.ubuntu.comЕсли curl зависает, возвращает таймаут или не может установить соединение, а DNS уже работает, ищите проблему в маршруте, gateway, firewall, прокси или IPv6.
- нет маршрута наружу;
- ошибка в default gateway;
- исходящий трафик режется локально или на стороне провайдера;
- APT пытается идти через недоступный proxy;
- сломана IPv6-связность;
- есть проблемы с MTU.
Для быстрой проверки удобно сравнить IPv4 и IPv6:
ping -4 -c 2 deb.debian.org
ping -6 -c 2 deb.debian.org
curl -4 -I deb.debian.org
curl -6 -I deb.debian.orgЕсли по IPv4 всё хорошо, а по IPv6 стабильно таймаут, то источник ошибки уже почти найден.
Не забывайте про проблемы самого зеркала
Не каждый Failed to fetch означает поломку на вашей стороне. Иногда проблема в конкретном mirror: он отстаёт по синхронизации, частично недоступен или плохо reachable именно из вашей сети. Такое особенно заметно, когда большинство репозиториев обновляется, а один hostname постоянно отвечает ошибкой.
Обычно на проблему зеркала указывают такие признаки:
- другие сайты и репозитории работают нормально;
- ошибка воспроизводится только на одном hostname;
- через некоторое время всё проходит без изменений на вашей стороне;
- замена зеркала сразу решает проблему.
Если у вас жёстко прописано конкретное зеркало, временно переключитесь на официальный пул дистрибутива. Но делайте это только после проверки codename и сети, иначе можно случайно скрыть реальную причину и получить ту же проблему позже.
Если релиз уже устарел и переехал в архив, это не сетевой сбой. В таком случае нужно поправить адреса репозиториев под архивную схему или планировать поддерживаемый upgrade.
Проверьте, не мешает ли proxy
APT умеет работать через HTTP- и HTTPS-прокси, и именно старые прокси-настройки часто ломают обновления после переезда сервера или смены сети. Система может иметь доступ наружу напрямую, но APT всё равно будет упорно ходить через старый узел.
grep -R -i proxy /etc/apt/apt.conf /etc/apt/apt.conf.d/ 2>/dev/null
env | grep -i proxyИщите в первую очередь параметры Acquire::http::Proxy и Acquire::https::Proxy. Если там указан несуществующий адрес, APT будет получать Connection refused, таймауты или TLS-ошибки.
В корпоративной сети бывает и обратная ситуация: браузер работает, а APT нет. Причина — прозрачная TLS-инспекция, обязательный аутентифицирующий proxy или отдельные правила фильтрации для серверного трафика. В этом случае сначала нужно понять сетевую политику, а уже потом корректировать параметры APT.
TLS handshake failed и ошибки сертификатов
Если в выводе фигурируют слова TLS, certificate или handshake, не спешите отключать проверку сертификатов. Это небезопасно и обычно не нужно. Начните с трёх базовых проверок: время системы, пакет корневых сертификатов и отсутствие подмены трафика со стороны прокси или сетевого оборудования.
timedatectl status
date
dpkg -l ca-certificates
curl -Iv deb.debian.org
curl -Iv archive.ubuntu.comЕсли часы сильно ушли в прошлое или будущее, даже корректный сертификат будет считаться недействительным. Такое регулярно встречается после восстановления VM, проблем с RTC или отключённой синхронизации времени.
Если у вас есть собственные сервисы, где важно корректно управлять TLS и цепочкой доверия, полезно отдельно держать в порядке SSL-сертификаты. А для автоматизации выпуска wildcard-сертификатов пригодится материал про автоматизацию DNS-01 для wildcard SSL.
Сломанный IPv6 — один из самых неприятных случаев
Очень частый сценарий на VPS и в корпоративных сетях: IPv6 формально включён, адрес есть, DNS возвращает AAAA-запись, но фактической связности наружу нет. Тогда APT сначала пытается идти по IPv6, упирается в таймаут и только потом переключается на IPv4 — или вообще не успевает это сделать.
ping -6 -c 2 deb.debian.org
curl -6 -I deb.debian.org
curl -4 -I deb.debian.org
apt -o Acquire::ForceIPv4=true updateЕсли с принудительным IPv4 обновление сразу прошло, проблема не в APT и не в зеркале, а именно в сетевом стеке. Дальше уже нужно чинить маршрут, RA, firewall, MTU или отключать нерабочий IPv6 там, где он не нужен.
MTU и transport errors: редкая, но реальная причина
Иногда ошибка связана не с DNS и не с зеркалом, а с MTU blackhole. Особенно это бывает поверх VPN, туннелей, overlay-сетей и нестандартной облачной маршрутизации. Симптомы выглядят запутанно: DNS работает, TCP-соединение открывается, а затем HTTPS зависает на handshake или обрывается на скачивании.
Косвенные признаки обычно такие:
- по IPv4 и IPv6 поведение отличается;
curl -Iиногда отвечает, а загрузка файла зависает;- через другую сеть проблема исчезает;
- ошибка появилась после включения VPN, WireGuard, GRE или изменения MTU интерфейса.
В такой ситуации уже нужно смотреть MTU на интерфейсах и проверять сетевую схему в целом. Это не проблема APT как такового, а общий дефект транспорта, который просто первым проявился на обновлениях.
Как получить больше информации от самого APT
Если обычного вывода недостаточно, включите отладку. Это особенно полезно при плавающих ошибках или если сбой касается только отдельных репозиториев.
apt -o Debug::Acquire::http=true update
apt -o Debug::Acquire::https=true update
apt -o Acquire::ForceIPv4=true -o Debug::Acquire::https=true updateСмотрите, где именно начинается сбой: на резолвинге имени, установке сокета, TLS handshake, запросе конкретного файла или проверке Release. Это быстро отделяет проблему зеркала от локальной сетевой ошибки.
Короткий безопасный runbook
Если нужен минимальный порядок действий без лишней теории, используйте такой алгоритм:
- Посмотрите текст после
Failed to fetch. - Сверьте codename системы и записи в
sources.list. - Проверьте DNS через
getent hosts. - Проверьте доступность зеркала через
curl -I. - Исключите старые proxy-настройки в APT и окружении.
- Проверьте системное время и пакет
ca-certificates. - Сравните поведение по IPv4 и IPv6.
- Если проблема только у одного mirror, временно смените его.
- Если ошибка нестабильная, включите debug-режим APT.
Чего делать не стоит
При поиске решения легко наткнуться на советы, которые только усугубляют ситуацию. Вот чего лучше избегать:
- не отключайте проверку подписей репозиториев ради «быстрого результата»;
- не удаляйте наугад содержимое
/etc/apt/apt.conf.d/; - не смешивайте репозитории разных выпусков Debian или Ubuntu;
- не лечите DNS заменой зеркала, если имя вообще не резолвится;
- не игнорируйте системное время при TLS-ошибках;
- не оставляйте сломанный IPv6 в состоянии «иногда работает».
Если вы администрируете несколько веб-серверов, полезно держать такой runbook рядом с остальными эксплуатационными инструкциями. В схожем формате удобно документировать и соседние задачи, например настройку нескольких PHP-FPM pool в Nginx, чтобы типовые инциденты решались одинаково предсказуемо.
Итог
Failed to fetch — это не диагноз, а признак того, что APT не смог скачать индекс пакета. Дальше всё зависит от уточняющей ошибки: DNS, transport, mirror, proxy, TLS, codename или IPv6.
На практике для быстрой локализации достаточно ответить на четыре вопроса: резолвится ли имя репозитория, есть ли сетевой доступ до него, корректно ли указан источник пакетов и не вмешиваются ли прокси, IPv6 или TLS-проблемы. Если идти по этой последовательности, даже неприятный сбой обычно превращается в обычную сетевую или конфигурационную задачу, которую можно закрыть за несколько минут.
