Ошибка Hash Sum mismatch в Debian и Ubuntu выглядит тревожно: вы запускаете apt update или установку пакета, а APT сообщает, что контрольная сумма не совпадает, размер файла неожиданен или есть проблема с Packages.gz. На практике это обычно не поломка пакетного менеджера, а симптом рассинхрона между индексами репозитория, зеркалом, кэширующим прокси или локальным кэшем метаданных.
Чаще всего проблема проявляется сообщениями Hash Sum mismatch, File has unexpected size и Packages.gz mismatch. Сценарий типичный: файл Release уже обновился, а один из индексных файлов на зеркале или в промежуточном кэше ещё старый. В итоге APT получает метаданные одной версии, а сам индекс — другой.
Хорошая новость в том, что в большинстве случаев это чинится без рискованных действий. Главное — не отключать проверки целостности и не удалять системные каталоги наугад. Несовпадение хэша — это защитный механизм, который не даёт использовать битые или подменённые данные.
Ниже разберём, как быстро определить источник проблемы и в каком порядке действовать на обычном сервере, в CI-среде и в инфраструктуре с кэширующим прокси.
Короткий принцип такой: сначала исключаем локальную проблему, затем очищаем списки APT, после этого проверяем зеркало и только потом разбираемся с прокси-кэшем и особенностями конкретного репозитория.
Что именно не совпадает при ошибке APT
APT работает не только со списком пакетов, а с набором подписанных и хэшируемых метаданных. Сначала он получает Release или InRelease, где указаны ожидаемые размеры и контрольные суммы индексных файлов: например, Packages, Packages.gz и Sources. Затем APT скачивает сами файлы и сверяет фактические значения с ожидаемыми.
Если зеркало обновилось не полностью, возникает ситуация, когда новый Release уже доступен, а Packages.gz ещё старый. Если между клиентом и зеркалом есть кэширующий прокси, он может усугубить проблему: часть файлов уже отдать в новой версии, а часть — из старого кэша.
Важно не путать пакетный кэш и кэш списков. Команда apt clean очищает локальный кэш скачанных .deb-файлов в /var/cache/apt/archives/, но ошибка Hash Sum mismatch чаще связана со списками репозиториев в /var/lib/apt/lists/. Поэтому одной apt clean часто недостаточно.
Типовые причины Hash Sum mismatch и File has unexpected size
Рассинхрон зеркала
Самый частый случай — зеркало репозитория находится в процессе синхронизации. Часть файлов уже новая, часть ещё старая. Особенно заметно это на крупных репозиториях, где обновление индексов идёт не мгновенно.
Если ошибка внезапно появилась сразу на нескольких серверах, а конфигурация APT не менялась, первым подозреваемым почти всегда будет зеркало.
Проблемный прокси-кэш
Если в сети используется apt-cacher-ng, Squid или другой HTTP-прокси, он может отдавать устаревшие индексные файлы. Тогда напрямую репозиторий работает нормально, а через прокси вы получаете packages.gz mismatch. Если у вас уже развёрнут общий кэширующий слой, пригодится и отдельный разбор настройки Squid для кэширования APT и других пакетных менеджеров.
Локально повреждённые списки APT
Если раньше обрывалось соединение, переполнялся диск или индексы скачались частично, APT может опираться на неконсистентные локальные файлы. Это самый простой сценарий: обычно он лечится удалением локальных списков и повторной загрузкой.
Проблемный сторонний репозиторий
Не все внешние репозитории обновляются аккуратно. Самописные и редко обслуживаемые источники могут публиковать Release и индексы неатомарно, не использовать by-hash или некорректно работать через CDN.
CDN и несогласованные edge-узлы
Иногда запросы попадают на разные узлы CDN: один уже получил свежие данные, другой — нет. Для APT это выглядит как обычный рассинхрон зеркала.
Быстрый практический вывод такой: если один и тот же сбой появляется сразу на нескольких машинах, сначала подозревайте источник пакетов или общий прокси, а не локальную систему.
Быстрая проверка: локальная проблема или массовая
До любых очисток полезно понять масштаб. Если ошибка возникает только на одном сервере, вероятнее локальный кэш или особенности сети. Если одинаковый File has unexpected size прилетает сразу на нескольких машинах, почти наверняка проблема во внешнем зеркале или прокси.
Первое, что стоит сделать, — просто повторить обновление через несколько минут:
sudo apt updateЕсли причина была в синхронизации зеркала, ошибка может исчезнуть сама. Если она воспроизводится стабильно, переходите к диагностике.
Пошаговое исправление на сервере
Шаг 1. Очистить локальные списки репозиториев
Это самый безопасный и часто самый эффективный шаг. Мы не трогаем установленные пакеты, а только удаляем локально сохранённые индексные файлы, чтобы APT скачал их заново.
sudo rm -vf /var/lib/apt/lists/*
sudo rm -vf /var/lib/apt/lists/partial/*
sudo apt clean
sudo apt updateУдаление файлов из /var/lib/apt/lists/ сбрасывает именно локальный индексный кэш. Команда apt clean очищает кэш пакетов и полезна как дополнительная мера, но не является основным лечением для mismatch по метаданным.
Если после этого apt update проходит успешно, проблема была локальной.
Шаг 2. Проверить, какой репозиторий ломается
APT обычно показывает источник ошибки: URL, компонент или конкретный индексный файл. Нужно понять, это официальный репозиторий Debian или Ubuntu либо внешний источник.
grep -Rhv '^*#' /etc/apt/sources.list /etc/apt/sources.list.d/*.list /etc/apt/sources.list.d/*.sources 2>/dev/nullЕсли сбоит конкретный внешний репозиторий, временно отключите его и проверьте обновление остальных источников. Это быстро показывает, где именно корень проблемы.
Шаг 3. Сменить зеркало
Если ошибка связана с официальным зеркалом, самый практичный путь — временно перейти на другое зеркало. После смены зеркала снова очистите списки и повторите обновление.
На небольших проектах и сайтах на виртуальном хостинге вы обычно не управляете системным APT напрямую, а вот на собственном VDS такая диагностика полностью на стороне администратора, поэтому иметь понятный runbook особенно важно.
Шаг 4. Проверить прокси
Если серверы ходят к репозиториям через прокси, важно исключить его из цепочки. На одном хосте временно уберите настройки прокси и выполните прямое обновление.
grep -Rni 'Acquire::http::Proxy|Acquire::https::Proxy' /etc/apt/apt.conf /etc/apt/apt.conf.d/ 2>/dev/nullsudo apt -o Acquire::http::Proxy=false -o Acquire::https::Proxy=false updateЕсли с отключённым прокси ошибка исчезла, проблема почти наверняка в промежуточном кэше.
Почему by-hash снижает риск таких ошибок
Механизм by-hash придуман именно для борьбы с рассинхроном. Вместо запроса «плавающего» файла вроде Packages.gz клиент получает индекс по пути, содержащему конкретный хэш содержимого. Это резко снижает вероятность получить старый файл при уже обновлённом Release.
Если репозиторий корректно поддерживает by-hash, шансов столкнуться с Hash Sum mismatch заметно меньше, особенно за CDN и прокси. Но не все сторонние репозитории настроены одинаково хорошо.
Обычно лучше не пытаться насильно обходить поведение APT, а дождаться синхронизации зеркала, сменить источник пакетов или исправить прокси-кэш.
Как диагностировать проблему глубже
Включить подробный вывод APT
sudo apt -o Debug::Acquire::http=true updateТак можно увидеть, какие файлы запрашиваются, какие ответы приходят от сервера и нет ли проблем с кэшированием или переадресацией.
Понять, ломается ли только сжатый индекс
Если ошибка проявляется только на Packages.gz, это может указывать на прокси или промежуточный кэш, который некорректно работает со сжатыми объектами.
Сопоставить время появления ошибки
Если сбой возникает в определённые часы, например сразу после публикации обновлений или во время массовых сборок, это сильный индикатор гонки зеркала или proxy-cache race. Если же проблема привязана к одному серверу, вероятнее локальный кэш или особенности маршрутизации.
Что проверить на apt-cacher-ng, Squid и похожих прокси
Если проблема находится не на клиенте, а в общем прокси, нужно устранять первопричину, иначе ошибка будет возвращаться на всех машинах.
Проверьте, не кэшируются ли индексные файлы слишком долго.
Убедитесь, что старые и новые объекты не смешиваются при параллельной загрузке.
Проверьте, поддерживает ли схема работы репозиториев
by-hash.Исключите дополнительный CDN или reverse proxy перед apt-кэшем.
Сравните результат работы через прокси и напрямую.
Если вы используете apt-cacher-ng, не стоит автоматически считать его виновником. Обычно проблема проявляется при нестабильных upstream-зеркалах, слишком агрессивном кэшировании или неудачном сочетании нескольких промежуточных слоёв.
Когда несколько серверов регулярно собирают проекты и обновляют пакеты, полезно заранее держать под рукой документированный порядок проверки и резервное зеркало. Это экономит время и снижает риск хаотичных изменений в конфигурации.
Чего делать не стоит
Не отключайте проверку подписи и хэшей.
Не запускайте десятки команд очистки без понимания, что именно вы чистите.
Не редактируйте вручную файлы в
/var/lib/apt/lists/.Не обвиняйте сразу DNS, MTU или диск, пока не исключены зеркало и прокси.
Короткий runbook
Повторите
apt updateчерез 5–15 минут.Удалите локальные списки APT и выполните повторное обновление.
Посмотрите, какой репозиторий падает.
Если это внешний репозиторий, временно отключите его.
Если это официальное зеркало, смените mirror.
Если используется прокси, временно обойдите его.
Если напрямую всё хорошо, чистите и перенастраивайте proxy-cache.
Пример безопасного набора команд
sudo rm -vf /var/lib/apt/lists/*
sudo rm -vf /var/lib/apt/lists/partial/*
sudo apt clean
sudo apt update
sudo apt upgradeЗапускать upgrade имеет смысл только после успешного завершения apt update. Если обновление списков всё ещё падает, сначала доведите до конца диагностику репозитория или прокси.
Как понять, что проблема действительно устранена
apt updateстабильно проходит на нескольких машинах подряд.Ошибка не возвращается после публикации новых пакетов.
Обход прокси и работа через прокси дают одинаковый результат.
Один и тот же репозиторий больше не выпадает на
File has unexpected size.
Итог
APT Hash Sum mismatch, File has unexpected size и Packages.gz mismatch — это не признак сломанной системы обновлений, а индикатор рассинхрона между Release, индексами и путём доставки файлов до клиента. В большинстве случаев виноваты зеркало, кэширующий прокси или локально повреждённые списки.
Самый надёжный подход — идти от простого к сложному: немного подождать, очистить локальные списки, определить проблемный репозиторий, проверить зеркало и затем исключить прокси. Такой порядок почти всегда позволяет найти причину без лишнего риска для системы.
