Ситуация знакомая: запускаете apt update, видите обычные строки InRelease, Packages или Ign, а затем процесс как будто замирает на сообщении Waiting for headers. Иногда это длится десятки секунд, иногда почти бесконечно, а иногда команда доходит до ошибки только через большой таймаут.
На Debian и Ubuntu такое поведение обычно связано не с «поломкой APT», а с сетевым стеком между сервером и зеркалом пакетов. Чаще всего виноваты IPv6 без нормального выхода, проблемы с MTU и PMTUD, старые настройки proxy, фильтрация трафика или просто неудачное зеркало.
Хорошая новость в том, что почти все такие случаи можно быстро локализовать, если не править конфиги наугад, а пройтись по понятной последовательности проверок.
Если
apt updateзависает наWaiting for headers, это чаще всего означает, что соединение уже началось, но клиент вовремя не получает ответ.
Проверять в первую очередь стоит маршрут, MTU, DNS, IPv6, прокси и доступность зеркала.
Сначала поймите, на каком этапе все ломается
Первая задача — определить, где именно возникает задержка: на DNS, на установке соединения, на TLS или уже на ответе сервера. Для этого удобно запустить APT с отладочным выводом.
apt -o Debug::Acquire::http=true -o Debug::Acquire::https=true updateТакой запуск показывает, к каким хостам идет обращение, открылось ли соединение и отправлен ли запрос. Если соединение есть, а заголовки долго не приходят, значит DNS, скорее всего, уже отработал, и проблема начинается позже.
Заодно проверьте, какие зеркала реально указаны в системе:
grep -R "^deb|^URIs:" /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/nullИ посмотрите, какие адреса возвращает резолвер:
getent ahosts deb.debian.orggetent ahosts archive.ubuntu.comЕсли у имени есть и IPv4, и IPv6, это нормально. Но именно в dual stack очень часто проявляется ситуация, когда IPv6 формально есть, а по факту работает нестабильно.
Самая частая причина — частично сломанный IPv6
Типовой сценарий: у сервера есть IPv6-адрес, маршрут по умолчанию тоже присутствует, DNS отдает AAAA-записи, но наружу трафик по IPv6 ходит плохо или не ходит совсем. В результате APT пытается использовать этот путь и подвисает до таймаута.
Проверьте, есть ли у интерфейса IPv6 и какой задан маршрут:
ip -6 addr showip -6 route showТеперь проверьте связность:
ping -6 -c 3 2001:4860:4860::8888ping -6 -c 3 deb.debian.orgЕсли ICMP где-то режется, удобнее проверить TCP через curl с принудительным IPv6:
curl -6 -I --max-time 10 http://deb.debian.org/debian/curl -6 -I --max-time 10 http://archive.ubuntu.com/ubuntu/Если по IPv6 запросы висят, а по IPv4 все открывается быстро, для проверки можно принудительно перевести APT на IPv4:
apt -o Acquire::ForceIPv4=true updateЕсли после этого обновление проходит, причина почти наверняка в IPv6. Временный обходной вариант — закрепить это поведение в конфиге APT:
printf 'Acquire::ForceIPv4 "true";
' > /etc/apt/apt.conf.d/99force-ipv4Это не лечение первопричины, а аккуратный workaround. Если у вас полноценный сервер на VDS или отдельный хост в dual stack, лучше все же починить маршрут, обратный путь и PMTUD, чем навсегда прятать проблему.
Когда такой обход действительно уместен
Временная фиксация IPv4 для APT оправдана на старых VPS-шаблонах, в туннельных схемах, в лабораторных стендах, контейнерных сетях и в сетях, где IPv6 объявлен раньше, чем реально доведен до рабочего состояния.
MTU и PMTUD: скрытая причина зависаний на Waiting for headers
Вторая очень частая причина — неверный MTU. Особенно после миграции в другую сеть, включения VPN, GRE, VXLAN, PPPoE или любой overlay-схемы. Маленькие пакеты в таких условиях проходят, DNS работает, TCP-сеанс открывается, а передача данных начинает застревать.
Проверьте текущий MTU на интерфейсах:
ip link showЗначение 1500 не гарантирует, что весь путь реально поддерживает такой размер. Для быстрой проверки PMTU используйте ICMP с запретом фрагментации для IPv4:
ping -c 3 -M do -s 1472 deb.debian.orgЕсли не проходит, уменьшайте размер: 1464, 1452, 1420, 1400. Для IPv6 можно начать с консервативного значения:
ping -6 -c 3 -s 1232 deb.debian.orgЕсли маленькие пакеты проходят, а большие — нет, очень похоже на PMTUD blackhole: где-то по пути режутся нужные ICMP или реальный MTU ниже, чем вы ожидаете.
Полезно сравнить поведение зеркала через curl:
curl -I --max-time 10 http://deb.debian.org/debian/curl --max-time 20 -o /dev/null http://deb.debian.org/debian/dists/stable/InReleaseЕсли подозрение подтверждается, временно уменьшите MTU на интерфейсе и сразу повторите тесты:
ip link set dev eth0 mtu 1400После этого снова выполните apt update. Если проблема исчезла, закрепите настройку уже в вашей сетевой системе: netplan, ifupdown, systemd-networkd или панели провайдера.
Кстати, похожие симптомы встречаются и в multi-stack окружениях с несколькими PHP-пулами и сложной сетевой схемой на одном сервере — если у вас такой сценарий, может пригодиться материал про настройку нескольких PHP-FPM pool в Nginx, где сетевые и системные узкие места тоже легко маскируются под «подвисания» сервисов.
Если проблема плавающая и повторяется на разных узлах, имеет смысл сначала собрать базовую картину по сети, а уже потом менять конфиги APT.
Proxy и фильтрующие узлы: APT ждет ответ не от того, от кого вы думаете
Следующая группа причин — proxy. Это могут быть переменные окружения, старые настройки в APT, локальный кэширующий proxy, прозрачный корпоративный фильтр или остатки старой миграции сервера. Внешне проблема часто выглядит одинаково: соединение вроде есть, но заголовки не приходят.
Сначала проверьте переменные окружения:
env | grep -i proxyЗатем конфиги APT:
grep -R "Acquire::http::Proxy|Acquire::https::Proxy" /etc/apt/apt.conf /etc/apt/apt.conf.d/ 2>/dev/nullЕсли видите старый адрес или ненужный proxy, временно запретите его использование для проверки:
printf 'Acquire::http::Proxy "false";
Acquire::https::Proxy "false";
' > /etc/apt/apt.conf.d/99no-proxyapt updateЕсли после этого обновление пошло нормально, причина найдена. Дальше уже разбирайтесь, нужен ли прокси вообще, актуален ли его адрес и корректно ли он работает с текущими репозиториями.
Особенно часто такие истории всплывают после клонирования шаблонов, миграции между площадками или восстановления системы из старого образа.
Иногда виновато зеркало пакетов, а не ваша сеть
Не всегда нужно искать экзотику. Иногда конкретное зеркало просто отвечает медленно, перегружено или неудачно маршрутизируется именно из вашей сети. Тогда создается впечатление, что сломан APT, хотя проблема снаружи.
Проверьте несколько типовых точек напрямую:
curl -I --max-time 10 http://deb.debian.org/debian/curl -I --max-time 10 http://security.debian.org/debian-security/curl -I --max-time 10 http://archive.ubuntu.com/ubuntu/Если один хост заметно тормозит, а остальные отвечают быстро, попробуйте временно заменить зеркало на другое официальное или более близкое по географии. Случайные сторонние mirror без необходимости лучше не использовать.
На инфраструктуре с несколькими серверами имеет смысл заодно проверить, одинаково ли проявляется проблема на всех узлах. Если зависание есть только на одной машине, вероятнее локальная сеть, MTU или proxy. Если на всех — смотрите зеркало или внешний маршрут.
Полезные таймауты и повторы в APT
Таймауты не устраняют сетевую проблему, но делают поведение APT предсказуемее. Это особенно полезно в автоматизации, CI и скриптах, где зависший apt update может держать задачу слишком долго.
printf 'Acquire::http::Timeout "15";
Acquire::https::Timeout "15";
Acquire::Retries "2";
' > /etc/apt/apt.conf.d/99network-timeoutsПосле этого APT будет быстрее фиксировать сбой и не создавать ощущение бесконечного ожидания. Для нестабильных каналов это практичнее, чем жить с дефолтными длинными паузами.
Что еще проверить: tracepath, tcpdump, контейнеры и VPN
Если базовые тесты ничего не показали, переходите к сетевой диагностике. Для PMTU и трассировки полезны tracepath и tracepath6:
tracepath deb.debian.orgtracepath6 deb.debian.orgЕсли нужно понять, доходит ли ответ вообще, снимите трафик во время зависания:
tcpdump -ni any host deb.debian.org and tcp port 80tcpdump -ni any host archive.ubuntu.com and tcp port 443Если SYN уходит, SYN-ACK приходит, запрос отправляется, а дальше видны ретрансляции или тишина, почти всегда нужно смотреть на маршрут, MTU или фильтрацию.
В контейнерах, LXC, Incus, Docker и за VPN проблема часто проявляется еще чаще. На хосте все может работать идеально, а внутри namespace — нет. В таких случаях отдельно проверяйте DNS, MTU bridge-сети и IPv6-маршрут именно внутри контейнера.
После сетевой диагностики уже проще понять, нужен ли вам более гибкий серверный стек или текущая инфраструктура справляется. Для проектов с полным контролем над маршрутами и пакетной базой обычно удобнее использовать VDS, а для типовых сайтов без сложной сетевой логики подойдет виртуальный хостинг.
Практика показывает, что сначала лучше локализовать сетевой сбой, а уже потом переносить сервисы или менять окружение.
Короткий чек-лист для быстрой локализации
Проверьте зеркало через
curl -I --max-time 10.Запустите
apt -o Debug::Acquire::http=true -o Debug::Acquire::https=true update.Сравните IPv4 и IPv6:
ping -6,curl -6,ip -6 route.Сделайте тест через
apt -o Acquire::ForceIPv4=true update.Проверьте MTU и PMTU через
ip link show,ping -M do,tracepath.Проверьте proxy в окружении и в
/etc/apt/apt.conf.d/.Добавьте разумные таймауты, чтобы быстрее видеть сбой.
Обычно уже на одном из этих шагов картина становится очевидной.
Практический вывод
Если в Debian или Ubuntu apt update зависает на Waiting for headers, не начинайте с переустановки APT. В подавляющем большинстве случаев это один из четырех сценариев: сломанный IPv6, неверный MTU, проблемный proxy или медленное зеркало.
Самый быстрый путь — проверить зеркало через curl, затем сравнить IPv4 и IPv6, потом исключить proxy и только после этого лезть в глубокую трассировку. Такой порядок экономит время и почти всегда приводит к предсказуемому результату.
А если вы разворачиваете новые серверы и хотите меньше сюрпризов на сетевом уровне, лучше сразу выбирать понятную инфраструктуру: от простого виртуального хостинга для небольших проектов до отдельного VDS для сервисов, где важны контроль сети, маршрутизации и системных настроек.
