Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1 2 След.
RSS
400: Неверный запрос, UniFi Network
 
Всем привет, у меня проблема с нашим Cloud Key: он нормально работает, чтобы зайти и просмотреть устройства и данные по основному сайту, но для дополнительных сайтов (всего 2) выдает ошибку 400: Bad Request. Там написано «пожалуйста, нажмите сюда, чтобы вернуться на главную страницу». При клике обычно возвращает на сайт по умолчанию. Тем не менее, я больше не могу получить доступ к устройствам на дополнительных беспроводных сайтах. Как можно восстановить эти локации или починить Cloud Key? Пытался с разных компьютеров и браузеров. Нашел похожие запросы на форумах, но никто не ответил. Unifi Controller v5.6.22, Cloud Key v0.8.2, свободно 9.83 ГБ памяти. Есть идеи? Спасибо!
 
Уже есть решение этой проблемы? Это становится очень раздражающим, потому что всё слишком быстро «время истекает». Я даже не могу сделать два изменения, прежде чем получаю ошибку 400.
 
Перезагрузка CloudKey 2+ решила проблему для меня.
 
Со мной сегодня только что случилось то же самое. Эта неделя выдалась у меня очень плохой.
 
Да, это происходит только при использовании unifi.ubnt.com. При локальном доступе такого нет.
 
@miltimj Очевидно, проблема не только у тебя или в конкретной настройке — какова вероятность того, что у меня начались такие же проблемы именно тогда же, когда и у тебя, и что я пришёл искать решение через гугл? У меня cloudkey+, и я вынужден разбираться с разными клиентами, постоянно вылетают ошибки — я тоже чистил кэш и всё остальное.
 
Я знаю, что этому сообщению больше года, но у меня была такая же проблема, и, как оказалось, у меня уже была в устройстве 64 ГБ MicroSD карта (не помню, ставил ли я её туда сам, но скорее всего да). Я её вынул, в итоге слот оказался пустым, и ошибка 400 исчезла — теперь всё работает нормально. Если это кому-то поможет... похоже, что причиной может быть плохой сектор или что-то в этом роде.
 
Уже прошло много лет, а проблему до сих пор не решили? Почему бы не сделать простой общий доступ, как в любом обычном роутере, без всякой заморочки?
 
Для всех, кто использует контроллер на платформе Windows и всё ещё сталкивается с проблемой, вам нужно установить x64 Java на ту Windows, где установлен контроллер. Скачайте Windows Offline (64-bit) по ссылке ниже: https://www.java.com/en/download/manual.jsp Windows Offline (64-bit) Надеюсь, это поможет!
 
У меня тоже была такая проблема, но я вынул карту памяти из UniFi cloud controller, и после этого всё заработало. Может быть, проблема в плохой карте памяти?
 
Проблема, о которой я сообщил в версиях 5.7.x и 5.8.x вчера, сегодня работает нормально. Доступ к облаку кажется медленнее обычного и требует нескольких попыток, чтобы зайти без тайм-аута, но по крайней мере больше нет пустого белого экрана — что уже хорошо. По крайней мере, доступ к облаку снова стал работоспособным.
 
У меня такая же проблема после обновления с версии 5.9.29 до 5.10.12. Я обновился до 5.10.17, но проблема осталась. Теперь я не могу зайти через облако, только напрямую по IP контроллера.
 
@UBNT-Piotr

Это снова всплыло при облачном доступе к контроллерам версий 5.7.x и 5.8.x (и, вероятно, к более ранним). Вот скриншот попытки зайти на контроллер 5.7.x, который работал без проблем несколько месяцев после установки. Судя по всему, на 5.9.x такой проблемы нет. Про 5.10.x не знаю — пока от неё держусь подальше, учитывая неудачные обновления, о которых пишут на форуме и в группах в Facebook 😀. Надеюсь, вы сможете понять, что именно сломали на сервере облака.

Ещё — проблема с пустой страницей и ошибкой bad request уже много месяцев, а может, и лет не решается при облачном доступе к "Hotspot manager". Было бы здорово, если бы вы провели проверку и, возможно, применили исправление, которого раньше не было.

Вероятно, эту проблему легко воспроизвести — ни к одному из моих нескольких контроллеров 5.7.x и 5.8.x я не могу подключиться через облако из-за этого. Приходится использовать VPN. Спасибо.
 
Со мной такое происходит после 5-10 минут бездействия в контроллере. Если перейти на другой экран, появляется ошибка «400 Bad Request», и приходится заново запускать контроллер.
 
Да, я вернулся к использованию нашего VPN-туннеля на каждом объекте для обновлений. Получается, что смысл облачного сервиса теряется. Но я думаю, что это скоро исправят (наверняка мы не одни такие пострадавшие).

@UBNT-Piotr

- Есть какой-то прогноз, когда эту проблему решат?
 
Еще один факт: я только что перезагрузил одну из своих точек доступа (через контроллер). В этот момент мой ноутбук, который работал через браузер, был подключен именно к этой точке доступа. В журнале событий видно, что мой ноутбук переключился с этой точки доступа на другую. При этом интерфейс контроллера в браузере перестал работать. Когда я пытался открыть другую страницу контроллера, получал ошибку 400. Похоже, что WebRTC-соединение не выдерживает перехода с одной точки доступа на другую. Обратите внимание, что в этот момент я находился в той же локальной сети, что и контроллер. Это происходит на версии контроллера 5.8.30. [Обновление: позже я принудительно переподключил ноутбук через GUI. Это заставило его снова подключиться к исходной точке доступа. Но при этом GUI не сломался — видимо, в этом случае WebRTC-соединение смогло пережить переход.]
 
Когда я пытаюсь подключиться к своей удалённой сети через облако... я устанавливаю соединение, и пока браузер успевает загрузить «Панель управления», получаю ошибку 400 Bad Request. Иногда «Панель управления» загружается, но через пару секунд после того, как я начинаю нажимать нужное меню, снова выскакивает ошибка 400 Bad Request. Это происходит довольно часто. В итоге я поставил компьютер без монитора в локальную сеть и подключаюсь к нему через TeamViewer. Как уже говорил один из пользователей, это полностью нивелирует смысл использования Cloud Key. Сейчас это просто выброшенные деньги, ведь компьютер может выполнять функции контроллера UniFi... Пожалуйста, Ubiquity! Мы все любим вашу технику, сделайте что-нибудь, чтобы мы снова поверили в неё.
 
@OrthoC

То же самое, у меня версия 5.8.30 билд... только при доступе через облако. У меня таймаут очень быстрый, но пока я «кликаю» в интерфейсе, реагирует нормально. Если оставить на 2–3 минуты без действия, появляется ошибка 400. К сожалению, доступ через LAN не всегда возможен, вы, конечно, это тоже знаете. Спасибо за помощь сообщества!
 
@phk46

У меня в облаке три контроллера: один локальный и два удалённых. Эта проблема возникает только с удалёнными Cloud Key. Ты прав, что система определяет, что я в той же подсети, что и локальный Cloud Key, и подключается к нему по локальному IP. Проблема именно с удалёнными адресами.  

Скажу, что до версии 5.8.24-11016 сборки этой проблемы не было. Я не обновлялся до самой свежей версии, так как она явно не решает эту проблему, а других проблем у меня пока нет, поэтому не хочется вносить новые ошибки, которые замечены в версии 5.8.30-11076-1.
 
Я слежу за этой веткой с самого начала. Похоже, что под одним и тем же симптомом скрывается куча разных проблем. Значит, причин может быть множество. Было бы полезно, если бы разработчики добавили больше информации о том, что именно пошло не так, чтобы можно было проще понять, в чем проблема. Обычно я открываю окно с моим домашним сайтом через облако и оставляю его открытым на неопределённый срок. Иногда всё отлично работает несколько дней подряд, но в итоге всё ломается. Обычно это проявляется тем, что окно просто зависает — никакой ошибки не показывает, но любые действия внутри окна не выполняются. Иногда появляется ошибка 400, иногда нет (в последнее время такого не было, детали уже не помню). В таких случаях я обычно просто закрываю окно, возвращаюсь на страницу облака и заново запускаю свой сайт. Обычно это помогает. В последнее время я заметил пару случаев, когда старое окно облака тоже переставало работать, и его приходилось перезагружать.

Я *подозреваю*, что ждать, что webrtc-соединение будет работать бесконечно — это слишком оптимистично. После установления сессии, ключевая часть — это data channel, который работает поверх UDP между браузером и контроллером. В зависимости от сети и где находится ваш браузер, соединение может быть прямым или проходить через NAT (через роутер и провайдера). Если через NAT, то есть высокая вероятность, что NAT-устройство (роутер и/или провайдер) в конце концов разорвет это соединение. Когда и если это случится — очень зависит от конкретной реализации NAT-устройств.

Я *надеюсь*, что код Unifi в контроллере и облачном портале готов к этому и сможет автоматически восстановить новое соединение при разрыве. Но, честно говоря, в это верится с трудом.

Если вы подключаетесь через облако, но при этом находитесь в той же локальной сети, что и контроллер, то webrtc должен установить прямое соединение по LAN. Это избавляет от всех проблем с NAT и, теоретически, должен держаться бесконечно — если только компьютер с браузером или контроллер не прервут долгое UDP-соединение. Обычно я так и подключаюсь, но не проверял напрямую, действительно ли соединение установлено напрямую.
Страницы: 1 2 След.
Читают тему (гостей: 1)