Проблема с мониторингом задержки и 33.3% потери пакетов на 5.1.12

Проблема с мониторингом задержки и 33.3% потери пакетов на 5.1.12, UniFi Network

yunhao.jiang

Guest

22.05.2026 21:48:00

Вчера обновил свой UCG Max до 5.1.12, и, похоже, появилась проблема с мониторингом задержки и обнаружением потери пакетов. Задержка до Google и Microsoft не отображается, работает только Cloudflare. Дашборд постоянно показывает 33.3% потери пакетов, хотя реальной потери нет и качество сети довольно стабильное (пробовал добавить WAN SLA, но это не решает проблему). Кто-нибудь сталкивался с похожими проблемами? Спасибо!

j0shin

Guest

03.08.2026 09:53:00

Спасибо! Это меня раздражало, хоть и было всего лишь «косметически» в дашборде для моего использования. Твоя теория про DNS-разрешение совпадает с тем, что помогло мне: я использую NextDNS, а не Pi-hole, но это DNS-блокировщик рекламы, так что это частично подтверждает твою теорию. Я создал кастомный SLA, используя только IP-адреса (без хостов), и с тех пор всё стабильно (использую значения порогов по умолчанию):* Состояние сервера: Все* Проверочный сервер 1: Ping, 1.1.1.1, интервал 5 с / период 60 с, потеря пакетов 20%, задержка 1500 мс, джиттер 200 мс, условие порога: Любое* Проверочный сервер 2: Ping, 8.8.8.8, интервал 5 с / период 60 с, потеря пакетов 20%, задержка 1500 мс, джиттер 200 мс, условие порога: Любое* Проверочный сервер 3: Ping, 9.9.9.9, интервал 5 с / период 60 с, потеря пакетов 20%, задержка 1500 мс, джиттер 200 мс, условие порога: ЛюбоеПрименил это к WAN1 вместо стандартного Auto SLA. Больше никаких ложных срабатываний после переключения.Это также починило отображение задержки. Раньше: Avg/Min/Max Latency показывали «-» при 33,3% потери пакетов. Теперь: Avg/Min/Max Latency показывают 8 мс при 0% потери пакетов.

Phrogz42

Guest

24.07.2026 16:55:00

Отвечаю на верхнем уровне, хотя я только что запостил это внутри ветки ответов: У меня проблема решилась так: (а) создал кастомный SLA, в котором для назначений используются только IP-адреса, и (б) убедился, что этот SLA применён ко всем WAN. Разумная теория — это потому, что у меня в сети для WAN стоит pi-hole, и когда к одному или нескольким WAN применён SLA «Auto», в качестве цели используется DNS-имя, и почему-то это вызывает сбой. (Хотя, как ни странно, это не настолько серьёзный сбой, чтобы сработал failover, так что, похоже, отображение использует другой расчёт потерь пакетов, чем фактический калькулятор failover? И более того, без понятия, почему использование Load Balancing решает эту проблему, когда WAN1 использует кастомный SLA, а WAN2 использует Auto, но эта проблема возникает в режиме failover.)

Phrogz42

Guest

24.07.2026 16:51:00

Но погоди! Спорим, ты нашёл причину! WAN1 использовал этот SLA, где в качестве назначений только IP-адреса, а WAN2 всё ещё использовал «Auto» в качестве SLA. Который, возможно, использует DNS-имена как целевые назначения, и, возможно, их блокировал pi-hole? Я только что переключил WAN2 на тот же SLA… и Dashboard стал лучше! Спасибо, что задал этот вопрос!

Phrogz42

Guest

24.07.2026 16:44:00

Я использую Pi-Hole в локальной сети в качестве DNS для WAN. Пользовательский SLA его не использует. Я приложил изображение своего SLA; настройки для двух других серверов такие же, как у первого, так как все они работают примерно одинаково. Поскольку переключение на Starlink — такая боль, а один пинг в 500 мс на двух маршрутахTrigger даже порог джиттера в 100 мс, я пока отключил джиттер для теста.

MarkBrokeIt Guest	#6 17.07.2026 14:40:00 Какая конфигурация у твоего кастомного SLA? Ты используешь устройство в своей локальной сети в качестве WAN DNS?

Phrogz42

Guest

17.07.2026 14:27:00

У меня была эта проблема с двумя WAN, failover и кастомным SLA, который пинговал по IP (не по имени). (Когда я перешёл с обычного SLA на кастомный SLA, это изменилось с 33% сбоев на 16.7% сбоев.) SSH на dream machine и логирование пингов в течение нескольких часов по тем же самым IP показали почти нулевую потерю пакетов. (Может, один пакет на провайдера за час.)По совету друга я поменял свою схему с failover на load balancing, 99%/1%. Похоже, это исправило отображение в Dashboard. Обратите внимание на красную линию, которая обрывается в момент, когда я переключился на load balancing.

Апдейт: я решил, что мне не нравится, как ощущается load balancing, и вчера переключился обратно в режим failover. И конечно же, следующее обновление Dashboard начало показывать полностью ложную потерю пакетов.

oriongr Guest	#8 14.06.2026 22:19:00 У меня то же самое с UCG-Ultra

muziqaz Guest	#9 06.06.2026 08:53:00 Эта проблема вернулась с 5.1.15. Как только я обновился до этой версии и перезагрузил свой UDR7, постоянная потеря пакетов 33.3% и нет результатов ping для MS и google. У меня стоит pihole, и никогда не было таких проблем до 5.1.15. Интересно то, что если у меня открыт дашборд какое-то время, потеря пакетов падает до 0, пока я не обновлю страницу, и тогда она снова возвращается к 33.3%. В моих собственных тестах я не видел реальных потерянных пакетов. Настройка Pihole тоже не менялась уже давно.

Читают тему (гостей: 1)