# Ping проходит, загрузка зависает: как распознать MTU black hole

Диагностика: Ping проходит, загрузка зависает: как распознать MTU black hole. Признаки, последовательность проверки, рабочий пример и критерии восстановления.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/network-mtu-blackhole-diagnostics/
Language: ru

Успешный ping и зависающая большая передача совместимы с MTU black hole. Маленькие пакеты проходят, а крупные теряются; отправитель не получает нужный сигнал для корректировки размера. Проверьте PMTUD, ICMP и tunnel overhead, прежде чем менять timeout или GPU.

## Сначала отделите стадии соединения

Запишите, работает ли DNS, устанавливается ли TCP и где останавливается TLS либо передача данных. Успешный ping проверяет конкретный размер и маршрут, а не произвольный application payload. Сравните один и тот же источник и назначение: запрос с ноутбука может идти иначе, чем трафик Pod через overlay и VPN. Сохраните маршруты, interfaces, семейство IP и фактическую MTU на участках, которыми вы управляете.


[Официальный источник 1](https://www.rfc-editor.org/rfc/rfc2923.html).

## Проверьте механизм PMTUD

При Path MTU Discovery крупным пакетам может требоваться соответствующее ICMP уведомление о невозможности передачи. Если такие сообщения теряются или фильтруются, TCP способен повторять данные без прогресса. RFC описывает характерный black-hole сценарий. Это гипотеза сетевого уровня, а не следствие размера файла как такового. Размер TLS records, сегментация и offload делают наблюдение сложнее: не считайте каждый большой пакет в capture доказательством того, что именно такой кадр ушёл в сеть.


[Официальный источник 2](https://docs.kernel.org/networking/ip-sysctl.html).

## Выполните ограниченное сравнение

В учебном опыте один путь содержит туннель, уменьшающий полезную MTU. Короткий запрос проходит, передача синтетического большого ответа зависает. Сравните контролируемые размеры и наблюдаемые retransmissions с ICMP на разрешённых точках. Затем повторите по пути без туннеля на стенде. Такой опыт помогает локализовать границу, но не назначает универсальную MTU для всех облаков и не требует передачи реальных пользовательских данных.

| Артефакт | Диагностическая ценность |
| --- | --- |
| Source/destination | Определён исследуемый маршрут |
| Interface MTU | Видна локальная конфигурация |
| ICMP observations | Проверен сигнал PMTUD |
| Retransmissions | Подтверждено отсутствие TCP прогресса |

## Исправьте подтверждённый участок

Согласуйте MTU overlay/tunnel и разрешённый ICMP для используемого семейства IP. Kernel tcp_mtu_probing имеет документированные режимы и может участвовать в mitigations, но не заменяет понимания сетевого дефекта. Не включайте глобальный режим вслепую на общем узле. Сохраните исходные настройки и протестируйте изменение отдельно. Если передача ограничена congestion или application backpressure, изменение MTU может ничего не дать и отвлечь от другой причины.

## Повторите крупную передачу

После изменения проверьте маленькие и большие синтетические данные тем же источником, маршрутом и клиентом. Сохраните длительность, retransmissions и наблюдения PMTUD. Успешный результат должен переживать повторное подключение и не ломать другой нужный маршрут. Итоговый артефакт связывает симптом с конкретным участком сети. Если зависание осталось на стадии сертификата без признаков потери данных, возвращайтесь к TLS диагностике отдельно: один внешний симптом не подтверждает единственную причину во всех случаях.

Сохраняйте направление передачи: асимметричный маршрут способен проявить проблему только при ответе сервера. Успешная загрузка короткого запроса не подтверждает такой же путь и допустимый размер пакета для обратного потока данных.

Связанные разборы: [network and uptime](/ru/journal/network-and-uptime/); [cloud egress model serving](/ru/journal/cloud-egress-model-serving/).