2026-06-02

RTSP 401 no autorizado y 404 no encontrado: diagnóstico de la URL de la cámara y errores de autenticación

Cómo solucionar los errores de cámara RTSP 401 no autorizado y 404 no encontrado separando credenciales, rutas URL, descubrimiento ONVIF y evidencia de perfil de transmisión.

Dos errores RTSP aparecen una y otra vez en los tickets de soporte: "401 no autorizado" y "404 no encontrado". Suenan simples. Uno parece un problema de inicio de sesión, el otro parece una URL incorrecta. En despliegues de cámara reales, ambos pueden ser más sutiles." Una cámara puede aceptar las mismas credenciales en la interfaz de usuario web pero rechazar RTSP. Una grabadora puede exponer diferentes rutas para la transmisión principal y la transmisión secundaria. Un escaneo ONVIF puede descubrir una URL que luego cambia. Un proveedor puede requerir un número de canal, un sufijo de transmisión o un token de perfil. Algunas cámaras también devuelven códigos de estado engañosos cuando la ruta es demasiado larga, la transmisión está deshabilitada o un modo de autenticación es incompatible con el cliente.

Para las búsquedas en Google, la consulta del usuario suele ser directa: "cámara no autorizada RTSP 401", "RTSP 404 no encontrada", "VLC funciona pero NVR dice que no hay señal" o "la URL RTSP de la cámara ONVIF no funciona". Un artículo útil no debe pretender que existe una URL mágica. Debería mostrar cómo recopilar pruebas.

Comience con el método RTSP que falló

No registre sólo el error final. Registre qué método RTSP lo devolvió:

OPCIONES
DESCRIBIR
CONFIGURACIÓN
REPRODUCIR

Si OPCIONES falla con 401, la autenticación o la política del servidor están bloqueando la sesión antes de que se soliciten los metadatos. Si DESCRIBE falla con 401, la cámara puede aceptar la conexión pero rechazar el acceso a esa ruta de transmisión. Si DESCRIBE devuelve 404, la ruta generalmente no se asigna a un perfil de transmisión. Si SETUP falla después de DESCRIBE exitoso, la URL puede ser válida pero la ruta de control de pista, el modo de transporte o el perfil de medios tienen un problema.

Esta distinción es importante porque la siguiente acción cambia. Las correcciones de credenciales no repararán una ruta de transmisión faltante. Cambiar el sufijo de la URL no solucionará una discrepancia en la autenticación de resumen.

Separe las credenciales de la ruta de transmisión

Una matriz de solución de problemas limpia se ve así:

El mismo nombre de usuario/contraseña funciona en la interfaz de usuario web de la cámara.
El servicio RTSP está habilitado
El puerto RTSP está abierto desde la red del cliente.
La ruta URL coincide con el patrón de transmisión principal o secundaria del proveedor.
El perfil de transmisión está habilitado en la cámara.
el modo de autenticación es compatible con el cliente
Los caracteres especiales en la contraseña están codificados correctamente.

Password characters are a frequent source of false failures. A password that contains @, :, /, ?, #, or spaces may need URL encoding when embedded in an RTSP URL. A better test is to use a client that sends credentials separately rather than relying on an inline URL.

Por qué 404 a menudo significa perfil o ruta, no red

404 No encontrado significa que se contactó al servidor y entendió la solicitud lo suficiente como para rechazar el recurso. Para las transmisiones de cámara, esto suele apuntar a uno de estos:

número de canal incorrecto
sufijo de transmisión incorrecto
transmisión principal deshabilitada
subtransmisión deshabilitada
la ruta de la grabadora difiere de la ruta de la cámara
Token de perfil ONVIF cambiado
Se requiere un nombre de acceso específico del proveedor
la transmisión existe solo después de habilitar RTSP en la configuración

La evidencia más útil es el URI de solicitud "DESCRIBE" y el estado de la respuesta. Si la cámara devuelve 404 antes del SDP, todavía no hay sesión multimedia. No salte a la pérdida de RTP o a la depuración de códecs antes de confirmar que la URL se asigna a una transmisión real.

ONVIF Discovery ayuda, pero no es lo mismo que una prueba

El descubrimiento ONVIF puede proporcionar URI de transmisión e información de perfil, pero el URI RTSP descubierto aún debe probarse. Algunos sistemas exponen ONVIF correctamente, mientras que la autenticación RTSP o el comportamiento de la ruta son diferentes. Otros devuelven un URI que es válido sólo para un perfil que luego se desactiva o se modifica.

La secuencia diagnóstica debe ser:

descubrir o ingresar la URL RTSP
ejecute OPCIONES y DESCRIBIR
capturar códigos de estado y encabezados
inspeccionar si se devuelve SDP
solo entonces inspeccione SETUP, PLAY, RTP y evidencia de códec

Ese orden impide que un ingeniero trate cada falla como un problema de "cámara fuera de línea".

Cómo se debe utilizar el inspector RTSP

RTSP Inspector no es un reproductor, un administrador ONVIF ni un producto de descubrimiento de cámaras. Su función es hacer que la transacción RTSP sea lo suficientemente visible como para explicar lo sucedido. Para los casos 401 y 404, el resultado útil es:

solicitar URI
método fallido
código de estado
límite de autenticación
si el SDP fue devuelto
si el fracaso ocurrió antes de la negociación con los medios
Siguiente propietario recomendado: credenciales, perfil de cámara, formato de URL del proveedor, puerto de red o habilitación de transmisión

Esa es exactamente la evidencia que un integrador de campo o un ingeniero de plataformas de video necesita antes de recurrir al proveedor de la cámara o cambiar la configuración de la grabadora a ciegas.

Cuando un ticket de soporte diga "RTSP no funciona", solicite el método, el código de estado y el límite del SDP. Eso convierte una queja genérica en un caso solucionable.

Evidencia reproducible para «RTSP 401 no autorizado y 404 no encontrado: diagnóstico de la URL de la cámara y errores de autenticación»

La respuesta directa es que una avería de vídeo no se demuestra con una ventana negra ni con un solo código de estado. Un diagnóstico fiable conecta la petición y la respuesta RTSP, el transporte negociado, una sesión válida y después los números de secuencia RTP, las marcas de tiempo y las señales RTCP. Para «RTSP 401 no autorizado y 404 no encontrado: diagnóstico de la URL de la cámara y errores de autenticación», empieza por la capa más cercana al síntoma visible, pero conserva una cronología común para no mezclar un fallo de control con uno de red o decodificación.

Antes de cambiar la cámara, el firewall o el VMS, crea una prueba base pequeña. Anota la URL RTSP sin contraseña, la hora, la ruta, el transporte solicitado, la respuesta del servidor y el instante del primer paquete multimedia. Prueba UDP y TCP interleaved por separado cuando el equipo ofrezca ambos. No cambies ruta, credenciales y transporte a la vez; si el segundo intento funciona, necesitas saber qué variable produjo la diferencia.

Capa	Evidencia que se debe guardar	Pregunta de decisión
RTSP	método, estado, cabeceras, CSeq y Session	¿El servidor aceptó exactamente la operación?
SDP	control, payload type, clock rate y codec	¿El servidor describió la pista esperada?
Transport	client_port, server_port o interleaved	¿Ambos extremos usan el mismo canal?
RTP	SSRC, secuencia, timestamp y marker	¿Las unidades llegan en un orden explicable?
RTCP	sender report, CNAME y BYE	¿Se pueden relacionar reloj, identidad y final?
Decoder	SPS/PPS/VPS y packetization mode	¿El payload recibido permite iniciar el decoder?

Separa «no llega multimedia» de «llega multimedia que no se puede decodificar». Si no aparece RTP después de SETUP y PLAY correctos, revisa UDP, NAT, firewall y una respuesta Transport distinta de la oferta. RTP con huecos de secuencia prueba pérdida o reordenación. Una secuencia continua sin imagen desplaza la investigación hacia payload type, clock rate, límites de cuadro y parámetros H.264 o H.265. Esta frontera es más útil que el mensaje general del reproductor.

¿Cómo se redacta una respuesta que pueda citarse?

Usa tres frases: última operación correcta, primera evidencia que falla y siguiente prueba que separa dos causas. Ejemplo: «DESCRIBE, SETUP y PLAY terminan correctamente; no llega RTP a los puertos anunciados por el cliente; repetir por TCP interleaved separará el bloqueo UDP de una ruta multimedia incorrecta». No atribuyas el fallo a la cámara o a la red sin una respuesta o un paquete que marque ese límite.

¿Qué hace reproducible el caso?

Guarda OPTIONS, DESCRIBE, SETUP y PLAY, el SDP, la respuesta Transport y el identificador Session saneado. Para RTP registra SSRC, primer y último número de secuencia, clock rate, huecos y duración. Indica si VLC u otro VMS funciona, pero úsalo como comparación controlada, no como prueba de que el cliente exitoso interpreta todas las reglas de forma correcta.

¿Cuándo se investiga el servidor y cuándo el cliente?

Mira el servidor si rechaza un método, entrega un control URL inexistente, responde con un transporte incompatible o cambia SSRC o reloj sin transición. Mira el cliente si reutiliza un nonce caducado, pierde Session, solicita UDP sin abrir los puertos o interpreta cada final NAL como final de access unit. Si el límite está entre ambos, conserva paquete y hora en cada afirmación.

¿Cómo se revisa el informe?

Repite desde una conexión nueva y compara las dos cronologías solo hasta la primera diferencia. Elimina contraseñas y valores Authorization completos. Relaciona cada conclusión con CSeq, secuencia o timestamp. Continúa con la guía RTSP relacionada y usa RTSP Inspector para probar un stream RTSP y recoger evidencia de forma local, sin subir el vídeo de la cámara a un servicio público.

Respuesta directa y límite de aceptación

La respuesta breve a «RTSP 401 no autorizado y 404 no encontrado: diagnóstico de la URL de la cámara y errores de autenticación» es: Cómo solucionar los errores de cámara RTSP 401 no autorizado y 404 no encontrado separando credenciales, rutas URL, descubrimiento ONVIF y evidencia de perfil de transmisión. Trate esa frase como un resultado que debe comprobarse, no como una promesa para cualquier entrada, dispositivo, proyecto o entorno. Un resultado completo registra estado inicial, acción exacta, salida visible y condición que demuestra que la tarea terminó en RTSP Inspector.

Procedimiento basado en evidencia

Empiece con un caso pequeño y repetible antes de cambiar un proyecto completo. Anote versión de la aplicación, sistema operativo, identidad de entrada o dispositivo, ajustes relevantes y resultado esperado. Ejecute una acción deliberada, conserve la primera transición inesperada y compárela con un caso conocido cuando exista. Cambiar varios controles a la vez oculta qué condición creó o corrigió el problema.

Punto de control 1: RTSP 401 no autorizado y 404 no encontrado: diagnóstico de la URL de la cámara y errores d

Cierre «RTSP 401 no autorizado y 404 no encontrado: diagnóstico de la URL de la cámara y errores de autenticación» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 2: Cómo solucionar los errores de cámara RTSP 401 no autorizado y 404 no encontrado separando

Para «Cómo solucionar los errores de cámara RTSP 401 no autorizado y 404 no encontrado separando credenciales, rutas URL, descubrimiento ONVIF y evidencia d», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Punto de control 3: Comience con el método RTSP que falló

Cierre «Comience con el método RTSP que falló» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 4: Separe las credenciales de la ruta de transmisión

Para «Separe las credenciales de la ruta de transmisión», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Punto de control 5: Por qué 404 a menudo significa perfil o ruta, no red

Cierre «Por qué 404 a menudo significa perfil o ruta, no red» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 6: ONVIF Discovery ayuda, pero no es lo mismo que una prueba

Para «ONVIF Discovery ayuda, pero no es lo mismo que una prueba», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Punto de control 7: Cómo se debe utilizar el inspector RTSP

Cierre «Cómo se debe utilizar el inspector RTSP» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 8: Evidencia reproducible para «RTSP 401 no autorizado y 404 no encontrado: diagnóstico de la

Para «Evidencia reproducible para «RTSP 401 no autorizado y 404 no encontrado: diagnóstico de la URL de la cámara y errores de autenticación»», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Punto de control 9: ¿Cómo se redacta una respuesta que pueda citarse?

Cierre «¿Cómo se redacta una respuesta que pueda citarse?» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 10: ¿Qué hace reproducible el caso?

Para «¿Qué hace reproducible el caso?», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Matriz de aceptación

Punto	Evidencia que conservar	Condición de aprobado
RTSP 401 no autorizado y 404 no encontrado: diagnóstico de la URL de la cámara y errores de autenticación	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Cómo solucionar los errores de cámara RTSP 401 no autorizado y 404 no encontrado separando credenciales, rutas URL, desc	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Comience con el método RTSP que falló	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Separe las credenciales de la ruta de transmisión	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Por qué 404 a menudo significa perfil o ruta, no red	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
ONVIF Discovery ayuda, pero no es lo mismo que una prueba	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado

Aislamiento, recuperación y entrega

Deténgase en el primer límite que falla. Conserve fuente, proyecto, sesión o captura, duplíquelo antes de una edición destructiva y cambie una variable por experimento. Repetir un flujo amplio después de varios cambios puede dar otro resultado sin explicar la causa.

Separe ausencia de evidencia de evidencia de ausencia. Una vista vacía puede indicar entrada, alcance, filtro, permiso, dispositivo, intervalo o estado equivocado. Verifique adquisición o importación antes de interpretar el decoder, editor, informe o exportación.

Antes de entregar, reabra el artefacto y revise inicio, punto de decisión y final. Registre versión, plataforma, configuración, expectativa, observación y reproducción mínima. Elimine o redacte datos sensibles y confirme que el destinatario está autorizado.

Preguntas y respuestas

¿Cuál es la forma fiable más rápida de empezar?

Use el caso representativo más pequeño, escriba el resultado esperado y cambie una variable. Confirme el recorrido básico antes de añadir filtros, efectos, ediciones, automatización o una fuente mayor.

¿Qué evidencia debe guardarse?

Conserve identidad de entrada, versión, plataforma, ajustes, acción exacta, primera transición inesperada y salida final. Cierre y reabra cualquier proyecto, sesión, informe o exportación antes de considerarlo duradero.

¿Cuándo debe repetirse el procedimiento?

Repítalo después de cambios relevantes en aplicación, sistema, driver, firmware, modelo, fuente o flujo. Preserve el caso aceptado anterior como referencia sin modificar.

¿Cuándo está listo para entregar?

Cuando otra persona autorizada identifica la entrada, repite la acción, obtiene el mismo resultado, entiende los límites restantes y abre el artefacto sin depender de estado local no documentado.

Guías relacionadas

Estas páginas en el mismo idioma cubren etapas contiguas sin cambiar el propietario canónico del tema: