BAD_LZO_HEADER_BYTE Сетевое оборудование и VPN

Ошибка OpenVPN: Bad LZO decompression header byte: 0x00 или 0x66

Обновлено: 24.08.2026 · Официальная документация ↗

Журнал OpenVPN непрерывно заполняется ошибками: Bad LZO decompression header byte: 0 или Bad LZO decompression header byte: 66.
Сетевой трафик внутри туннеля полностью блокируется (пакеты отбрасываются).
Сбой возникает сразу после успешного прохождения TLS-рукопожатия и отправки первого полезного payload.

1. Причина сбоя: несоответствие заголовков сжатия

Ошибка возникает, когда один конец туннеля сжимает пакет алгоритмом LZO (добавляя байт заголовка компрессии), а второй ожидает несжатый поток данных (или наоборот).

Конфигурация сервера	Конфигурация клиента	Результат
`comp-lzo yes`	`comp-lzo no` (или не указано)	Bad LZO header byte
`compress lz4`	`comp-lzo yes`	Bad LZO header byte
Сжатие отключено	Сжатие отключено	Стабильное соединение

2. Полное отключение сжатия (Рекомендуемый стандарт безопасности)

Из-за криптографических атак VORACLE (утечка данных через длину сжатых зашифрованных пакетов) сжатие трафика в современных версиях OpenVPN признано небезопасным.

Удалите любые строки comp-lzo и compress из конфигов и добавьте на сервере и клиенте:

# Полное отключение сжатия и игнорирование входящих сжатых пакетов
compress
push "compress"

3. Согласование старых конфигураций с comp-lzo adaptive

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

# В конфиге клиента .ovpn:
comp-lzo adaptive

4. Исправление конфликта в OpenVPN 2.4+ / 2.5+

# В файле сервера server.conf:
push "comp-lzo no"
comp-lzo no

💡 Практика специалистов: Начиная с версии OpenVPN 2.5, использование comp-lzo генерирует предупреждение безопасности в логах. Рекомендуется перевести сервер и всех клиентов на директиву data-ciphers без компрессии.

Частые вопросы (FAQ)

Что означает байт 0x00 в 'Bad LZO decompression header byte: 0'?

Байт 0x00 означает, что пришел обычный несжатый IP-пакет (первый байт IPv4 заголовка содержит версию 4), но декомпрессор попытался прочитать его как управляющий байт LZO компрессии.

Почему алгоритм компрессии LZ4 лучше LZO?

LZ4 потребляет значительно меньше тактов процессора при декомпрессии, однако в продакшене рекомендуется полностью отключать любое сжатие поверх шифрованного VPN.

Влияет ли MTU на появление этой ошибки?

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

Как заставить сервер принудительно отключить компрессию у всех клиентов?

Добавьте в server.conf директиву push 'comp-lzo no' и перезапустите службу.