Ошибки и коды · Инструкция
IP-камера не отдаёт RTSP-поток: что проверить
IP-камера не отдаёт RTSP-поток — проверяйте по порядку доступность камеры по IP, включённый RTSP, правильный endpoint.
Короткий ответ
Сначала убедитесь, что камера открывается по IP, RTSP включён и URL взят из документации производителя. Затем отдельно проверьте credentials и transport TCP/UDP.
Сначала отделите проблему сети от ошибки RTSP
Ошибка RTSP чаще всего возникает не из-за «сломавшегося ONVIF», а на одном из четырёх уровней: камера недоступна по сети, RTSP-сервис выключен, неверен URL/канал или соединение блокирует транспорт/аутентификация. Axis в актуальной документации отдельно указывает, что для RTSP-потока сервис должен быть включён, а клиенту нужны корректный адрес устройства и учётные данные. Поэтому первый тест — проверить веб-интерфейс камеры по её IP-адресу из той же локальной сети. Если веб-интерфейс не открывается, бессмысленно менять путь RTSP. Если камера доступна, используйте документированный производителем RTSP endpoint и минимальный набор параметров без лишних опций. Для Axis базовый endpoint — `/axis-media/media.amp`; у других брендов путь другой, и его нельзя угадывать по чужому примеру.
Важно: Не публикуйте RTSP-порт камеры напрямую в интернет ради проверки. Диагностику делайте из локальной сети или через защищённый VPN.
RTSP-ошибки: куда смотреть в первую очередь
- Connection refused. Сервис/порт. Включён ли RTSP, тот ли порт, нет ли локального firewall
- Timeout. Маршрут/фильтрация. IP, VLAN, ACL, VPN, доступность камеры из этой подсети
- 401 Unauthorized. Аутентификация. Логин, пароль, права пользователя, поддерживаемый метод auth
- 404 / stream not found. URL/endpoint или канал. Путь и номер канала по документации производителя
- TCP играет, UDP нет. RTP/UDP транспорт. Firewall/NAT/маршрутизацию и правила для UDP
Предупреждение: Код ошибки клиента важнее сообщения «камера не работает». Сохраните точный ответ и URL без пароля — это резко сужает диагностику.
Пошаговая проверка RTSP от сети до видеопотока
- Узнайте текущий IP камеры и откройте её веб-интерфейс с того же компьютера, где запускаете VLC, ffplay или VMS. Если интерфейс недоступен, сначала исправьте IP, VLAN, кабель или Wi‑Fi.
- В настройках камеры убедитесь, что RTSP включён. После обновления прошивки или сброса сервис может быть отключён либо ограничен политикой безопасности.
- Возьмите RTSP-URL из руководства именно вашей модели. Подставьте IP и отдельного пользователя с правами на просмотр; не используйте пример Axis для камеры другого производителя.
- Проверьте поток в другом клиенте. Для Axis документация показывает ffplay с RTP/RTSP over TCP, HTTP и UDP — смена транспорта помогает отделить проблему клиента от сетевого пути.
- Если TCP работает, а UDP нет, проверяйте межсетевой экран, NAT, VLAN и маршрутизацию UDP. Если не работает ни один транспорт, возвращайтесь к URL, учётным данным и настройке сервиса.
- После успешного базового потока добавляйте конкретный channel, resolution или profile. Не начинайте диагностику с длинного URL с десятком параметров.
Совет: Сначала добейтесь открытия одного стандартного потока. Параметры второго сенсора, профиля или субпотока добавляйте только после базовой проверки.
TCP, UDP и RTSP over HTTP: почему один вариант работает, а другой нет
RTSP управляет сессией, а медиаданные могут идти разными способами. Axis показывает отдельные примеры для RTP/RTSP over TCP, RTSP tunneled over HTTP, UDP unicast и UDP multicast. В простой домашней сети UDP может работать отлично, но через сложный firewall, NAT или корпоративный VLAN TCP нередко диагностировать проще, потому что соединение идёт в рамках предсказуемого сеанса. Это не означает, что TCP «всегда лучше»: выбор зависит от задержки, потерь, инфраструктуры и требований VMS. Если один транспорт запускается, вы уже доказали, что камера, URL и учётные данные в целом рабочие. Дальше проблема находится в сетевой политике или конкретном способе доставки RTP. Для multicast дополнительно требуется корректная настройка сети; Axis прямо предупреждает, что multicast часто зависит от firewall и сетевой конфигурации.
Совет: Для первой проверки выбирайте unicast TCP. Multicast оставьте для момента, когда базовый поток уже доказан и сеть подготовлена.
Что проверить в логине, URL и профиле камеры
- Создайте отдельного пользователя только для просмотра вместо использования администратора в VMS.
- Если пароль содержит специальные символы, проверьте, как ваш клиент ожидает их кодировать в URL; лучше вводить credentials через интерфейс клиента, если это возможно.
- Сверьте номер канала: многосенсорные камеры и видеорегистраторы могут иметь несколько источников.
- Проверьте, не запрашивает ли клиент неподдерживаемый codec или профиль. Сначала используйте поток по умолчанию.
- После смены IP обновите RTSP-адрес во всех клиентах и VMS; старый DNS-кеш или сохранённый URL может вводить в заблуждение.
- Если камера поддерживает secure RTSP/RTSPS, не путайте его порт и схему с обычным RTSP.
- Не оставляйте пароль в скриншотах, логах и публичных командах диагностики.
Когда проблема уже не в RTSP
Если веб-интерфейс камеры периодически пропадает, ping нестабилен или устройство меняет IP, сначала чините сеть. RTSP только проявляет базовую нестабильность быстрее, потому что видеопоток чувствителен к потерям и разрывам. Зафиксируйте адрес камеры через корректную DHCP-reservation или статическую схему, проверьте питание PoE и кабель, а затем возвращайтесь к потоку. Если камера стабильна, но документированный endpoint не работает ни в одном клиенте, посмотрите журнал устройства и release notes прошивки. После обновления могли измениться настройки безопасности или отключиться устаревший метод аутентификации. Для интеграции с NVR полезно отдельно проверить ONVIF discovery, но работоспособность ONVIF не гарантирует правильность вручную введённого RTSP URL. Эти механизмы связаны, но диагностируются раздельно. Для NVR полезно сохранить минимальный рабочий RTSP-URL отдельно от URL, который формирует сам регистратор. Если после обновления VMS поток перестал открываться, этот эталон позволяет быстро проверить камеру независимым клиентом. Также смотрите число одновременных потоков: некоторые камеры ограничивают количество сессий или ресурсы при высоких разрешениях. Если один клиент уже воспроизводит видео, а второй получает отказ, проблема может быть не в адресе и не в пароле. Закройте лишние сеансы, снизьте тестовую нагрузку и повторите подключение к базовому stream без дополнительных параметров. Если URL и сеть подтверждены, следующим слоем становится аутентификация и ограничение ресурсов камеры. Некоторые клиенты по-разному работают с digest/basic auth, а специальные символы в пароле требуют корректного URL-encoding, если credentials вставляются прямо в URI. Для чистого теста лучше вводить логин и пароль отдельными полями клиента. Также учитывайте лимит одновременных stream sessions: камера может отдавать один поток, но отказывать второму при высокой нагрузке или установленном ограничении. Закройте лишние viewers и повторите базовый запрос. Если доступен RTSPS/SRTP, проверяйте его отдельно от обычного RTSP: другая схема, порт или политика TLS не должны смешиваться с диагностикой незашифрованного локального потока. Точный журнал клиента также полезен: время отказа, RTSP-код ответа и выбранный transport дают больше информации, чем общий текст «не подключается». Сохраняйте URL без пароля и сравнивайте один и тот же запрос в двух клиентах.
Что учитывать
RTSP управляет сессией, а медиаданные могут идти разными способами. Axis показывает отдельные примеры для RTP/RTSP over TCP, RTSP tunneled over HTTP, UDP unicast и UDP multicast. В простой домашней сети UDP может работать отлично, но через сложный firewall, NAT или корпоративный VLAN TCP нередко диагностировать проще, потому что соединение идёт в рамках предсказуемого сеанса. Это не означает, что TCP «всегда лучше»: выбор зависит от задержки, потерь, инфраструктуры и требований VMS. Если один…
Источники и проверка
Инструкция составлена редакцией N1RO на 2026-09-20. Перед действием сверьте актуальные условия на официальном сайте сервиса или производителя.