Интернет-соединение WAN1 несколько раз отключалось.

Интернет-соединение WAN1 несколько раз отключалось., UniFi Network

BP1977

Guest

04.08.2025 19:51:00

У меня серьёзные проблемы с интернетом. Я использую LTE интернет от крупного провайдера в Австрии. К сожалению, я уже не знаю, что делать. Интернет постоянно отваливается. Постоянно приходят сообщения вроде "Internet connection WAN1 (Hutchison Drei Austria GmbH) on port 9 went down multiple times in the last 24 hours." Если подключу маршрутизатор напрямую к компьютеру, таких проблем не возникает. Маршрутизатор уже давно подключён к моему UDM PRO на WAN порт 9 без каких-либо изменений. Всё работало нормально, пока я несколько месяцев назад не обновил UDM Pro. Кто-нибудь может помочь? Я не нашёл никаких упоминаний об этом в интернете, но похоже, что у многих людей такие же проблемы. Я понятия не имею, что тут натворила UNIFI.

BP1977

Guest

28.12.2025 18:12:00

Ещё одно обновление. Всё ещё работает очень плохо. Интернет всегда отключается, когда меняется публичный IP-адрес. То, что здесь происходит, это то, что UniFi сообщает, что интернет больше не работает. Я думаю, это ключ к успеху!

pgrey Guest	#3 06.12.2025 21:38:00 Да, это выглядит довольно неплохо для начала, надеюсь, это продолжится.

BP1977

Guest

06.12.2025 21:04:00

Нет, маршрутизатор работает в режиме моста. Я переключил соединение с порта 9 на SFP и также заменил маршрутизатор. Теперь использую ZTE G5TC и выглядит лучше.

% ping ping2.ui.com
PING ping2.ui.com (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=113 time=19.812 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=113 time=19.485 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=113 time=21.415 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=113 time=20.011 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=113 time=18.532 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=113 time=22.332 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=113 time=24.243 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=113 time=23.598 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=113 time=24.323 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=113 time=24.539 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=113 time=32.985 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=113 time=34.685 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=113 time=35.647 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=113 time=32.454 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=113 time=28.225 ms
^C--- ping2.ui.com ping statistics ---
15 packets transmitted, 15 packets received, 0.0% packet loss

Но часто выглядело и лучше, так что придётся ждать дальше.

pgrey

Guest

06.12.2025 20:40:00

Ну хорошо, похоже, всё работает нормально — это хорошая новость. Возвращаюсь к своему вопросу: а как вообще настраивается устройство-мост (модем ISP или модем/маршрутизатор)? Возможно, оно на самом деле не находится в режиме моста?

BP1977

Guest

06.12.2025 20:17:00

Слушай, вот результат, когда я подключаю маршрут без UDM. Напрямую к Mac'у! Никаких проблем. % ping ping2.ui.com
PING ping2.ui.com (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=33 ttl=115 time=22.656 ms
64 bytes from 8.8.8.8: icmp_seq=34 ttl=115 time=26.025 ms
64 bytes from 8.8.8.8: icmp_seq=35 ttl=115 time=26.002 ms
64 bytes from 8.8.8.8: icmp_seq=36 ttl=115 time=21.865 ms
64 bytes from 8.8.8.8: icmp_seq=37 ttl=115 time=23.618 ms
64 bytes from 8.8.8.8: icmp_seq=38 ttl=115 time=25.093 ms
64 bytes from 8.8.8.8: icmp_seq=39 ttl=115 time=23.867 ms
64 bytes from 8.8.8.8: icmp_seq=40 ttl=115 time=25.515 ms
64 bytes from 8.8.8.8: icmp_seq=41 ttl=115 time=24.824 ms
64 bytes from 8.8.8.8: icmp_seq=42 ttl=115 time=24.638 ms
64 bytes from 8.8.8.8: icmp_seq=43 ttl=115 time=31.381 ms
64 bytes from 8.8.8.8: icmp_seq=44 ttl=115 time=26.215 ms
64 bytes from 8.8.8.8: icmp_seq=45 ttl=115 time=22.762 ms
64 bytes from 8.8.8.8: icmp_seq=46 ttl=115 time=24.320 ms
^C--- ping2.ui.com ping statistics ---
47 packets transmitted, 47 packets received, 0.0% packet loss

Что это нам говорит? Проблема в UniFi или в UDM Pro. Что дальше?

pgrey

Guest

06.12.2025 00:05:00

Звучит хорошо, завтра протестируем на ISP роутере, интересно будет сравнить результаты. Это пинги из результата "nslookup ping.ui.com" (разрешение 8.8.8.8), верно? У меня получается разрешение Google/Cloudflare, например, было бы полезно попробовать оба варианта, если ты видишь то же самое? Потеря пакетов, которую ты наблюдаешь, тоже не очень хорошая, на самом деле не должно быть больше 2% или около того, иначе у тебя будет много проблем с большинством вещей, проверка Unifi для WAN — это только одна из них. Ты, вероятно, заметишь некоторые проблемы и в большинстве VOIP и потоковых сервисов — оба довольно чувствительны к этому.

nslookup ping.ubnt.com
Server: unifi.<me-removed>
Address: 2601:600:<removed>::1

Non-authoritative answer:
Name: ping2.ui.com
Addresses: 8.8.8.8 1.1.1.1
Aliases: ping.ubnt.com

64 bytes from one.one.one.one (1.1.1.1): icmp_seq=37 ttl=56 time=20.0 ms
64 bytes from one.one.one.one (1.1.1.1): icmp_seq=38 ttl=56 time=16.9 ms
64 bytes from one.one.one.one (1.1.1.1): icmp_seq=39 ttl=56 time=17.0 ms
64 bytes from one.one.one.one (1.1.1.1): icmp_seq=40 ttl=56 time=16.2 ms
64 bytes from one.one.one.one (1.1.1.1): icmp_seq=41 ttl=56 time=17.7 ms
64 bytes from one.one.one.one (1.1.1.1): icmp_seq=42 ttl=56 time=16.4 ms
64 bytes from one.one.one.one (1.1.1.1): icmp_seq=43 ttl=56 time=17.4 ms
64 bytes from one.one.one.one (1.1.1.1): icmp_seq=44 ttl=56 time=17.6 ms
64 bytes from one.one.one.one (1.1.1.1): icmp_seq=45 ttl=56 time=25.0 ms
64 bytes from one.one.one.one (1.1.1.1): icmp_seq=46 ttl=56 time=17.4 ms
64 bytes from one.one.one.one (1.1.1.1): icmp_seq=47 ttl=56 time=19.2 ms
^C--- ping2.ui.com ping statistics ---
47 packets transmitted, 47 received, 0% packet loss, time 46058ms

BP1977

Guest

05.12.2025 23:17:00

это из UDM! 64 байта от dns.google (8.8.8.8): icmp_seq=76 ttl=116 time=26.7 ms64 байта от dns.google (8.8.8.8): icmp_seq=77 ttl=116 time=75.8 ms64 байта от dns.google (8.8.8.8): icmp_seq=78 ttl=116 time=196 ms64 байта от dns.google (8.8.8.8): icmp_seq=79 ttl=116 time=36.9 ms64 байта от dns.google (8.8.8.8): icmp_seq=80 ttl=116 time=23.5 ms64 байта от dns.google (8.8.8.8): icmp_seq=81 ttl=116 time=43.1 ms64 байта от dns.google (8.8.8.8): icmp_seq=82 ttl=116 time=26.7 ms64 байта от dns.google (8.8.8.8): icmp_seq=83 ttl=116 time=25.5 ms64 байта от dns.google (8.8.8.8): icmp_seq=84 ttl=116 time=23.9 ms64 байта от dns.google (8.8.8.8): icmp_seq=85 ttl=116 time=68.9 ms64 байта от dns.google (8.8.8.8): icmp_seq=86 ttl=116 time=181 ms64 байта от dns.google (8.8.8.8): icmp_seq=87 ttl=116 time=301 ms64 байта от dns.google (8.8.8.8): icmp_seq=88 ttl=116 time=422 ms64 байта от dns.google (8.8.8.8): icmp_seq=89 ttl=116 time=26.6 ms64 байта от dns.google (8.8.8.8): icmp_seq=90 ttl=116 time=26.9 ms64 байта от dns.google (8.8.8.8): icmp_seq=94 ttl=116 time=27.6 ms64 байта от dns.google (8.8.8.8): icmp_seq=95 ttl=116 time=517 ms64 байта от dns.google (8.8.8.8): icmp_seq=97 ttl=116 time=31.2 ms64 байта от dns.google (8.8.8.8): icmp_seq=98 ttl=116 time=63.4 ms64 байта от dns.google (8.8.8.8): icmp_seq=100 ttl=116 time=274 ms^C--- ping2.ui.com статистика пинга ---101 пакет отправлен, 88 получено, 12.8713% потери пакетов, время 100516 мсВТТ минимум/средний/максимум/мдев = 21.288/72.658/516.819/106.389 мс

Завтра подключу маршрутизатор поставщика интернет-услуг напрямую к Mac без UDM.

pgrey

Guest

05.12.2025 22:56:00

Ты можешь протестировать это на UDM через SSH или используя консоль Debug в разделе Devices → UDM-Pro → Settings. В любом случае, эти значения пинга просто сумасшедшие, перемешанные с таймаутами, поэтому хотя попытка напрямую с UDM будет стоящей, я подозреваю, что ты увидишь похожие цифры и потери пакетов. А что если ты подключишь маршрутизатор ISP и снова запустишь тест — какие соответствующие значения пинга ты получишь и будут ли там какие-нибудь потери (таймауты)?

BP1977

Guest

#10

05.12.2025 22:09:00

...это от клиента. 64 байта от 8.8.8.8: icmp_seq=51 ttl=115 time=33.104 ms
Request timeout для icmp_seq 52
64 байта от 8.8.8.8: icmp_seq=53 ttl=115 time=95.870 ms
64 байта от 8.8.8.8: icmp_seq=54 ttl=115 time=42.346 ms
Request timeout для icmp_seq 55
Request timeout для icmp_seq 56
Request timeout для icmp_seq 57
64 байта от 8.8.8.8: icmp_seq=58 ttl=115 time=414.220 ms
Request timeout для icmp_seq 59
64 байта от 8.8.8.8: icmp_seq=60 ttl=115 time=120.832 ms
64 байта от 8.8.8.8: icmp_seq=61 ttl=115 time=70.209 ms
64 байта от 8.8.8.8: icmp_seq=62 ttl=115 time=61.674 ms
64 байта от 8.8.8.8: icmp_seq=63 ttl=115 time=128.022 ms
64 байта от 8.8.8.8: icmp_seq=64 ttl=115 time=35.599 ms
64 байта от 8.8.8.8: icmp_seq=65 ttl=115 time=27.053 ms
64 байта от 8.8.8.8: icmp_seq=432 ttl=115 time=88.724 ms
64 байта от 8.8.8.8: icmp_seq=433 ttl=115 time=175.452 ms
64 байта от 8.8.8.8: icmp_seq=434 ttl=115 time=294.925 ms
64 байта от 8.8.8.8: icmp_seq=435 ttl=115 time=101.079 ms
64 байта от 8.8.8.8: icmp_seq=436 ttl=115 time=29.202 ms
64 байта от 8.8.8.8: icmp_seq=437 ttl=115 time=77.584 ms
Request timeout для icmp_seq 438
Request timeout для icmp_seq 439
64 байта от 8.8.8.8: icmp_seq=440 ttl=115 time=49.607 ms
64 байта от 8.8.8.8: icmp_seq=441 ttl=115 time=29.214 ms
Request timeout для icmp_seq 442
64 байта от 8.8.8.8: icmp_seq=443 ttl=115 time=39.180 ms
Request timeout для icmp_seq 444
Request timeout для icmp_seq 445
Request timeout для icmp_seq 446
Request timeout для icmp_seq 447
64 байта от 8.8.8.8: icmp_seq=448 ttl=115 time=294.503 ms
64 байта от 8.8.8.8: icmp_seq=449 ttl=115 time=30.913 ms
64 байта от 8.8.8.8: icmp_seq=450 ttl=115 time=36.055 ms
64 байта от 8.8.8.8: icmp_seq=451 ttl=115 time=59.059 ms
64 байта от 8.8.8.8: icmp_seq=452 ttl=115 time=32.614 ms
64 байта от 8.8.8.8: icmp_seq=453 ttl=115 time=27.712 ms
64 байта от 8.8.8.8: icmp_seq=454 ttl=115 time=30.100 ms
64 байта от 8.8.8.8: icmp_seq=455 ttl=115 time=31.643 ms
64 байта от 8.8.8.8: icmp_seq=456 ttl=115 time=50.490 ms

Как я могу это протестировать на UDM?

pgrey

Guest

#11

05.12.2025 20:48:00

Что возвращает команда "nslookup ping.ui.com" на клиенте И на UDM? Если вы выполните серию пингов на возвращённый IP-адрес (примерно в духе ping2.ui.com) в течение как минимум нескольких минут, она продолжит работать без проблем? Результат будет одинаковым, если вы используете ping.ubnt.com?

BP1977

Guest

#12

05.12.2025 20:15:00

На данный момент я могу вводить что угодно, но ни один IP-адрес не работает. Я уже искал информацию на разных форумах, но не нашел ничего полезного. Обнаружил, что у многих других пользователей точно такая же проблема. Я в растерянности. Понятия не имею, что ещё попробовать.

pgrey

Guest

#13

05.12.2025 19:51:00

Да, они также проверяют ping.ubnt.com, который должен быть перенаправлен на локальный сервер Cloudflare, обычно это 1.1.1.1, в ответ на ping (который, как ты заметил, обычно легко доступен). Им нужна эта проверка, чтобы обеспечить SLA, необходимый для большинства пользователей, так как это (насколько я знаю) ориентировано в большей степени на деловых клиентов. Мне непонятно, почему ping твоего провайдера так часто переходит на резервный сервер. Ты проверял форумы провайдера, есть ли там ветки обсуждения о проблемах с Unifi? Возможно, есть несколько небольших настроек в текстовых файлах на контроллере, которые помогут обойти эту проблему. С сохранением таких исправлений сложнее всего — иногда нужно найти репозиторий Git, который показывает, как сохранить настройки после перезагрузки.

mt104

Guest

#14

05.12.2025 15:02:00

Я не думаю, что SLA серверы имеют значение, когда Unifi определяет, работает ли канал WAN или нет. Мой WAN3 (второй резервный канал WAN, который я почти никогда не использую) ненадёжен в некоторые дни, включая сегодня. Для эксперимента я просто установил SLA для этого канала на проверку ping 127.0.0.1, который всегда должен быть в сети на 100%. Это ничего не изменило, и Unifi всё ещё сообщает, что канал WAN постоянно включается и отключается.

BP1977

Guest

#15

05.12.2025 14:39:00

@pgrey Проблема целиком в Unifi. Если я использую маршрутизатор без UDM Pro, проблем вообще нет. Значит, всё дело только в этих глупых настройках SLA. Зачем Unifi постоянно это проверять? Почему нет никаких опций, чтобы это отключить? Это просто бесит. До этого обновления софта всё работало идеально.

RobbieH

Guest

#16

11.02.2026 18:53:00

По большей части не связано с предыдущим, но изменение ping-сервера застало меня врасплох несколько дней назад. Я заметил, что скорость упала, а задержка возросла, но разница была не настолько серьёзной, чтобы вызвать тревогу. Прошёл ещё день — ничего не улучшилось, и я перезагрузил свой 5G-модем и брандмауэр. Без изменений. Зашёл в интерфейс брандмауэра, и там сообщалось, что WAN1 отключен. Я проверял и проверял, и проверял снова, не мог найти проблему, пока мне в голову не пришла мысль о ping-сервере. Признаю, я подошёл к этому лениво, но использовал один из DNS-серверов Cloudflare в качестве ping-сервера, а именно 1.1.1.2. Это работало прекрасно на протяжении лет, но теперь почему-то Cloudflare закрыл этот IP-адрес. Получается, что даже когда ты думаешь, будто у тебя надёжный мониторинг, на самом деле на него рассчитывать нельзя. Теперь я хотел бы, чтобы в pfSense была возможность указать больше одного ping-сервера. К тому же, у меня не была настроена отправка уведомлений по электронной почте. Когда-то я столкнулся с проблемой при аутентификации в Gmail и просто сдался. Так вот, теперь это работает. Это побудило меня разобраться и настроить всё как следует.

pgrey

Guest

#17

11.02.2026 18:48:00

Хм, один из моих провайдеров периодически меняет мой IP (примерно раз в месяц), а мой UDM ни разу не подведёт. Я подозреваю, что это связано с особенностями CG-NAT, но это просто предположение. Ты пробовал обратиться в чат поддержки CS, может быть, там есть какие-нибудь идеи по этому поводу?

BP1977

Guest

#18

10.02.2026 11:58:00

Еще одно обновление. Как я уже несколько раз упоминал, UniFi на 100% виновен в этих проблемах. Если ты поищешь в интернете, ты найдешь одни и те же проблемы. Я испытываю ту же проблему с другой системой, но с другим провайдером LTE. Итак, два разных провайдера LTE, но одинаковые проблемы в разных местах. Это совершенно неприемлемо. И самое печальное — решения нет. Команда @UI-Team, вы можете помочь?

BP1977

Guest

#19

01.01.2026 19:12:00

Прежде всего, с Новым годом! @pgrey

Под "ключом к успеху" я имею в виду, что если бы мы знали, в чём именно проблема UniFi при смене WAN. Мне кажется, что когда WAN меняется, UniFi больше не может к нему подключиться (и не может его пинговать), а затем UniFi сообщает, что ISP не работает.

Как пишет @RobbieH, меняется и сервер пинга. 178.000.000.000.wireless.dyn.drei.com (178.112.132.73)

В начале это мой WAN IP адрес, и когда он меняется, также меняется IP адрес в конце. Я думаю, это проблема для всех.

RobbieH Guest	#20 30.12.2025 15:23:00 Как я уже говорил, у меня работают 3 WAN-соединения, но я не использую Unifi gateway. Мои WAN-соединения не меняют свой публичный IP слишком часто. На моих шлюзах, Unifi или других, я люблю пытаться найти ближайший ping-сервер, который смогу обнаружить через tracert. Проблема в том, что если этот ближайший ping-сервер изменится из-за изменения на WAN, это может стать проблемой.

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