2026-06-02

RTSP 401 não autorizado e 404 não encontrado: diagnosticando URL da câmera e falhas de autenticação

Como solucionar erros de câmera RTSP 401 não autorizado e 404 não encontrado separando credenciais, caminhos de URL, descoberta ONVIF e evidências de perfil de fluxo.

Dois erros RTSP aparecem repetidamente em tickets de suporte: "401 Unauthorized e 404 Not Found. Eles parecem simples. Um parece um problema de login, o outro parece um URL incorreto. Em implantações reais de câmeras, ambos podem ser mais sutis." Uma câmera pode aceitar as mesmas credenciais na UI da web, mas rejeitar o RTSP. Um gravador pode expor caminhos diferentes para o fluxo principal e o fluxo secundário. Uma varredura ONVIF pode descobrir um URL que muda posteriormente. Um fornecedor pode exigir um número de canal, sufixo de stream ou token de perfil. Algumas câmeras também retornam códigos de status enganosos quando o caminho é muito longo, o fluxo está desabilitado ou um modo de autenticação é incompatível com o cliente.

Para pesquisas no Google, a consulta do usuário geralmente é direta: “Câmera não autorizada RTSP 401”, “RTSP 404 não encontrada”, “VLC funciona, mas NVR diz que não há sinal” ou “URL RTSP da câmera ONVIF não funciona”. Um artigo útil não deve fingir que existe um URL mágico. Deve mostrar como coletar evidências.

Comece com o método RTSP que falhou

Não registre apenas o erro final. Registre qual método RTSP o retornou:

OPÇÕES
DESCREVA
CONFIGURAÇÃO
JOGAR

Se OPTIONS falhar com 401, a autenticação ou política do servidor está bloqueando a sessão antes que os metadados sejam solicitados. Se DESCRIBE falhar com 401, a câmera poderá aceitar a conexão, mas rejeitar o acesso a esse caminho de fluxo. Se DESCRIBE retornar 404, o caminho geralmente não é mapeado para um perfil de fluxo. Se SETUP falhar após um DESCRIBE bem-sucedido, o URL pode ser válido, mas o caminho de controle de trilha, modo de transporte ou perfil de mídia tem um problema.

Esta distinção é importante porque a próxima ação muda. As correções de credenciais não repararão um caminho de fluxo ausente. Alterar o sufixo do URL não reparará uma incompatibilidade de autenticação de resumo.

Separar credenciais do caminho do stream

Uma matriz de solução de problemas limpa é semelhante a esta:

o mesmo nome de usuário/senha funciona na interface da web da câmera
O serviço RTSP está ativado
A porta RTSP está aberta na rede do cliente
O caminho do URL corresponde ao padrão de stream principal ou secundário do fornecedor
o perfil de stream está ativado na câmera
o modo de autenticação é compatível com o cliente
caracteres especiais na senha são codificados corretamente

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 que 404 geralmente significa perfil ou caminho, não rede

404 Not Found significa que o servidor foi alcançado e entendeu a solicitação o suficiente para rejeitar o recurso. Para fluxos de câmera, isso geralmente aponta para um destes:

número de canal errado
sufixo de fluxo errado
fluxo principal desativado
substream desativado
o caminho do gravador difere do caminho da câmera
Token de perfil ONVIF alterado
nome de acesso específico do fornecedor necessário
stream existe somente após ativar o RTSP nas configurações

A evidência mais útil é o URI da solicitação DESCRIBE e o status da resposta. Se a câmera retornar 404 antes do SDP, ainda não há sessão de mídia. Não pule para perda de RTP ou depuração de codec antes de confirmar se o URL está mapeado para um fluxo real.

ONVIF Discovery ajuda, mas não é o mesmo que prova

A descoberta ONVIF pode fornecer URIs de fluxo e informações de perfil, mas o URI RTSP descoberto ainda precisa ser testado. Alguns sistemas expõem o ONVIF corretamente, enquanto a autenticação RTSP ou o comportamento do caminho são diferentes. Outros retornam um URI válido apenas para um perfil que posteriormente será desativado ou alterado.

A sequência de diagnóstico deve ser:

descubra ou insira o URL RTSP
execute OPTIONS e DESCRIBE
capturar códigos de status e cabeçalhos
inspecionar se o SDP foi retornado
só então inspecione SETUP, PLAY, RTP e evidências de codec

Essa ordem evita que um engenheiro trate cada falha como um problema de “câmera offline”.

Como o inspetor RTSP deve ser usado

O RTSP Inspector não é um player, um gerenciador ONVIF ou um produto de descoberta de câmera. Sua função é tornar a transação RTSP visível o suficiente para explicar o que aconteceu. Para os casos 401 e 404, a saída útil é:

solicitar URI
método falhado
código de status
limite de autenticação
se o SDP foi devolvido
se a falha aconteceu antes da negociação com a mídia
próximo proprietário recomendado: credenciais, perfil da câmera, formato de URL do fornecedor, porta de rede ou ativação de stream

Essa é exatamente a evidência que um integrador de campo ou engenheiro de plataforma de vídeo precisa antes de escalar para o fornecedor da câmera ou alterar cegamente as configurações do gravador.

Quando um ticket de suporte disser "RTSP não funciona", solicite o método, o código de status e o limite do SDP. Isso transforma uma reclamação genérica em um caso solucionável.

Evidência reproduzível para “RTSP 401 não autorizado e 404 não encontrado: diagnosticando URL da câmera e falhas de autenticação”

A resposta direta é que uma tela preta ou um único código não prova a origem da falha. Um diagnóstico confiável liga pedido e resposta RTSP, transporte negociado, sessão válida e depois números de sequência RTP, timestamps e sinais RTCP. Em “RTSP 401 não autorizado e 404 não encontrado: diagnosticando URL da câmera e falhas de autenticação”, comece pela camada mais próxima do sintoma, mas mantenha uma cronologia comum para não confundir controle, rede e decodificação.

Antes de alterar câmera, firewall ou VMS, crie um teste de referência pequeno. Registre URL RTSP sem senha, horário, caminho, Transport solicitado, resposta do servidor e chegada do primeiro pacote de mídia. Teste UDP e TCP interleaved separadamente quando disponíveis. Não mude caminho, credenciais e transporte juntos; caso a segunda tentativa funcione, será necessário identificar a variável decisiva.

Camada	Evidência a preservar	Pergunta
RTSP	método, estado, cabeçalhos, CSeq e Session	O servidor aceitou exatamente a operação?
SDP	control, payload type, clock rate e codec	A faixa esperada foi descrita?
Transport	client_port, server_port ou interleaved	Os dois lados usam o mesmo canal?
RTP	SSRC, sequência, timestamp e marker	As unidades chegam em ordem explicável?
RTCP	sender report, CNAME e BYE	Relógio, identidade e fim são rastreáveis?
Decoder	SPS/PPS/VPS e packetization mode	O payload recebido inicializa o decoder?

Separe “nenhuma mídia chegou” de “a mídia chegou, mas não decodifica”. Se RTP falta depois de SETUP e PLAY bem-sucedidos, verifique UDP, NAT, firewall e resposta Transport. Lacunas de sequência provam perda ou reordenação. Uma sequência contínua sem imagem desloca a investigação para payload type, clock rate, limites de frame e parâmetros H.264 ou H.265. Essa fronteira é mais útil que a mensagem genérica do player.

Como escrever uma resposta citável?

Use três frases: última operação bem-sucedida, primeira evidência com falha e próximo teste que separa duas causas. Exemplo: “DESCRIBE, SETUP e PLAY funcionam; nenhum RTP chega às portas anunciadas; um teste TCP interleaved separará bloqueio UDP de caminho de mídia errado”. Não atribua a falha à câmera ou rede sem resposta ou pacote que demonstre o limite.

Quais dados tornam o caso reproduzível?

Preserve OPTIONS, DESCRIBE, SETUP e PLAY, SDP, resposta Transport e Session sem segredos. Para RTP registre SSRC, primeira e última sequência, clock rate, lacunas e duração. Informe se VLC ou outro VMS funciona, mas trate isso como comparação controlada, não como prova de que o cliente bem-sucedido interpreta corretamente todas as regras.

Quando examinar servidor ou cliente?

Examine o servidor quando recusar método, fornecer control URL ausente, responder com transporte incompatível ou mudar SSRC ou relógio sem transição. Examine o cliente quando reutilizar nonce vencido, perder Session, solicitar UDP sem abrir portas ou tratar todo fim de NAL como fim de access unit. Se o problema estiver entre os dois, pacote e horário devem acompanhar cada conclusão.

Como revisar o relatório?

Repita a partir de uma conexão nova e compare as cronologias até a primeira diferença. Remova senhas e valores Authorization completos. Ligue cada conclusão a CSeq, sequência ou timestamp. Siga o guia RTSP relacionado e use RTSP Inspector para testar um stream RTSP e coletar evidências localmente, sem enviar o vídeo para um serviço público.

Resposta direta e limite de aceitação

A resposta curta para “RTSP 401 não autorizado e 404 não encontrado: diagnosticando URL da câmera e falhas de autenticação” é: Como solucionar erros de câmera RTSP 401 não autorizado e 404 não encontrado separando credenciais, caminhos de URL, descoberta ONVIF e evidências de perfil de fluxo. Trate essa frase como um resultado a verificar, não como promessa para qualquer entrada, dispositivo, projeto ou ambiente. Um resultado completo registra estado inicial, ação exata, saída visível e condição que comprova a conclusão da tarefa no RTSP Inspector.

Procedimento orientado por evidências

Comece com um caso pequeno e repetível antes de alterar um projeto completo. Registre versão do aplicativo, sistema operacional, identidade da entrada ou dispositivo, configurações relevantes e resultado esperado. Execute uma ação deliberada, preserve a primeira transição inesperada e compare com um caso conhecido quando possível. Alterar vários controles ao mesmo tempo esconde qual condição criou ou corrigiu o problema.

Ponto de controle 1: RTSP 401 não autorizado e 404 não encontrado: diagnosticando URL da câmera e falhas de aut

Encerre “RTSP 401 não autorizado e 404 não encontrado: diagnosticando URL da câmera e falhas de autenticação” somente quando o resultado salvo, exportado ou reaberto continuar igual ao estado observado. O retorno temporário da interface ajuda, mas evidência durável é mais forte. Registre qualquer limite restante para a próxima pessoa.

Ponto de controle 2: Como solucionar erros de câmera RTSP 401 não autorizado e 404 não encontrado separando cre

Para “Como solucionar erros de câmera RTSP 401 não autorizado e 404 não encontrado separando credenciais, caminhos de URL, descoberta ONVIF e evidências de ”, separe uma decisão do produto de um limite do sistema, hardware, arquivo, permissão ou processo. Confirme qual camada produziu a evidência antes de atribuir causa. Isso evita transformar um sintoma próximo em causa raiz supostamente provada.

Ponto de controle 3: Comece com o método RTSP que falhou

Encerre “Comece com o método RTSP que falhou” somente quando o resultado salvo, exportado ou reaberto continuar igual ao estado observado. O retorno temporário da interface ajuda, mas evidência durável é mais forte. Registre qualquer limite restante para a próxima pessoa.

Ponto de controle 4: Separar credenciais do caminho do stream

Para “Separar credenciais do caminho do stream”, separe uma decisão do produto de um limite do sistema, hardware, arquivo, permissão ou processo. Confirme qual camada produziu a evidência antes de atribuir causa. Isso evita transformar um sintoma próximo em causa raiz supostamente provada.

Ponto de controle 5: Por que 404 geralmente significa perfil ou caminho, não rede

Encerre “Por que 404 geralmente significa perfil ou caminho, não rede” somente quando o resultado salvo, exportado ou reaberto continuar igual ao estado observado. O retorno temporário da interface ajuda, mas evidência durável é mais forte. Registre qualquer limite restante para a próxima pessoa.

Ponto de controle 6: ONVIF Discovery ajuda, mas não é o mesmo que prova

Para “ONVIF Discovery ajuda, mas não é o mesmo que prova”, separe uma decisão do produto de um limite do sistema, hardware, arquivo, permissão ou processo. Confirme qual camada produziu a evidência antes de atribuir causa. Isso evita transformar um sintoma próximo em causa raiz supostamente provada.

Ponto de controle 7: Como o inspetor RTSP deve ser usado

Encerre “Como o inspetor RTSP deve ser usado” somente quando o resultado salvo, exportado ou reaberto continuar igual ao estado observado. O retorno temporário da interface ajuda, mas evidência durável é mais forte. Registre qualquer limite restante para a próxima pessoa.

Ponto de controle 8: Evidência reproduzível para “RTSP 401 não autorizado e 404 não encontrado: diagnosticando

Para “Evidência reproduzível para “RTSP 401 não autorizado e 404 não encontrado: diagnosticando URL da câmera e falhas de autenticação””, separe uma decisão do produto de um limite do sistema, hardware, arquivo, permissão ou processo. Confirme qual camada produziu a evidência antes de atribuir causa. Isso evita transformar um sintoma próximo em causa raiz supostamente provada.

Ponto de controle 9: Como escrever uma resposta citável?

Encerre “Como escrever uma resposta citável?” somente quando o resultado salvo, exportado ou reaberto continuar igual ao estado observado. O retorno temporário da interface ajuda, mas evidência durável é mais forte. Registre qualquer limite restante para a próxima pessoa.

Ponto de controle 10: Quais dados tornam o caso reproduzível?

Para “Quais dados tornam o caso reproduzível?”, separe uma decisão do produto de um limite do sistema, hardware, arquivo, permissão ou processo. Confirme qual camada produziu a evidência antes de atribuir causa. Isso evita transformar um sintoma próximo em causa raiz supostamente provada.

Matriz de aceitação

Ponto	Evidência a manter	Condição de aprovação
RTSP 401 não autorizado e 404 não encontrado: diagnosticando URL da câmera e falhas de autenticação	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Como solucionar erros de câmera RTSP 401 não autorizado e 404 não encontrado separando credenciais, caminhos de URL, des	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Comece com o método RTSP que falhou	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Separar credenciais do caminho do stream	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Por que 404 geralmente significa perfil ou caminho, não rede	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
ONVIF Discovery ajuda, mas não é o mesmo que prova	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado

Isolamento, recuperação e entrega

Pare no primeiro limite que falhar. Preserve fonte, projeto, sessão ou captura, duplique antes de edição destrutiva e altere uma variável por experimento. Repetir um fluxo amplo depois de várias mudanças pode gerar outro resultado sem explicar o motivo.

Separe ausência de evidência de evidência de ausência. Uma tela vazia pode indicar entrada, escopo, filtro, permissão, dispositivo, intervalo ou estado incorreto. Verifique aquisição ou importação antes de interpretar decoder, editor, relatório ou exportação.

Antes da entrega, reabra o artefato e examine início, ponto de decisão e final. Registre versão, plataforma, configuração, expectativa, observação e reprodução mínima. Remova ou oculte dados sensíveis e confirme a autorização do destinatário.

Perguntas e respostas

Qual é a maneira confiável mais rápida de começar?

Use o menor caso representativo, escreva o resultado esperado e altere uma variável. Confirme o caminho básico antes de adicionar filtros, efeitos, edições, automação ou uma fonte maior.

Quais evidências devem ser salvas?

Mantenha identidade da entrada, versão, plataforma, configurações, ação exata, primeira transição inesperada e saída final. Feche e reabra projeto, sessão, relatório ou exportação antes de tratá-lo como durável.

Quando o procedimento deve ser repetido?

Repita após mudanças relevantes no aplicativo, sistema, driver, firmware, modelo, fonte ou fluxo. Preserve o caso aceito anterior como referência sem alterações.

Quando a tarefa está pronta para entrega?

Quando outra pessoa autorizada identifica a entrada, repete a ação, vê o mesmo resultado, entende os limites restantes e abre o artefato sem depender de estado local não documentado.

Guias relacionados

Estas páginas no mesmo idioma cobrem etapas próximas sem alterar o proprietário canônico deste assunto: