Depuração de autenticação RTSP Digest: 401 não autorizado, Nonce, Realm, Basic vs Digest e loops de login de câmera

Como solucionar falhas de autenticação RTSP Digest, loops 401 não autorizados, valores nonce obsoletos, incompatibilidades de domínio, configurações de câmera Basic vs Digest e problemas de credenciais de URL.

autenticação de resumo rtsp, 401 não autorizado, nonce, realm, básico vs resumo, login da câmera ip, diagnóstico rtsp

Falhas de autenticação RTSP são alguns dos casos mais comuns de suporte de câmeras IP. Os usuários procuram por "RTSP 401 não autorizado", "falha na autenticação RTSP Digest", "a câmera funciona no VLC, mas não no NVR", "RTSP Basic vs Digest", "nonce obsoleto", "reino errado" e "loop de login da câmera IP" porque o sintoma é simples, mas a causa está oculta nos cabeçalhos de solicitação e resposta.

O RTSP Inspector foi desenvolvido exatamente para essa classe de problema. Um jogador só pode dizer "falha na autenticação". Um inspetor de protocolo pode mostrar o primeiro DESCRIBE não autenticado, o desafio WWW-Authenticate, a resposta Authorization do cliente, o valor nonce, o domínio, o URI usado no cálculo do resumo e se a câmera rejeita a segunda solicitação.

Por que a autenticação RTSP é confusa

Muitas câmeras não aceitam credenciais na primeira solicitação. O fluxo normal do Digest é:

  1. O cliente envia DESCRIBE sem autorização.
  2. A câmera retorna 401 Não autorizado.
  3. A câmera inclui WWW-Authenticate: Digest ....
  4. O cliente recalcula a resposta Digest.
  5. O cliente envia DESCRIBE novamente com Autorização: Digest ....
  6. A câmera aceita a solicitação ou retorna outro 401.

O primeiro 401 não é necessariamente um erro. O 401 repetido após o cliente enviar as credenciais do Digest é a evidência importante.

Configurações básicas e resumidas da câmera

Algumas câmeras expõem configurações como:

  • Autenticação básica
  • Autenticação resumida
  • Básico e resumido
  • Apenas resumo
  • Sem autenticação

Se o cliente oferecer suporte apenas ao Basic, mas a câmera exigir o Digest, o fluxo falhará. Se o cliente enviar o Digest, mas a câmera estiver configurada para uma variante específica do fornecedor, o fluxo também poderá falhar.

Termos de pesquisa que geralmente descrevem este caso:

  • "Câmera de autenticação básica RTSP"
  • "Câmera de autenticação RTSP Digest"
  • "VLC funciona, mas o aplicativo recebe 401"
  • "Falha na autenticação da câmera NVR"
  • "ONVIF funciona, mas o login RTSP falha"

A solução é não adivinhar a senha novamente. Primeiro inspecione qual esquema de autenticação a câmera realmente anunciou.

Incompatibilidades de reino

O realm do Digest faz parte do cálculo de autenticação. Se o cliente calcular a resposta com um domínio diferente daquele fornecido pela câmera, a autenticação falhará.

Isso pode acontecer quando:

  • Um proxy reescreve o desafio.
  • O firmware altera o domínio da câmera após a atualização.
  • O cliente armazena em cache um desafio anterior.
  • Várias câmeras compartilham um nome de host por meio de um proxy reverso.
  • O aplicativo usa um perfil salvo de um modelo de câmera diferente.

O Inspetor RTSP deve tornar o domínio visível para que a falha se torne concreta. A questão não é "a senha está errada?" mas "qual domínio exato e URI foram usados ​​quando a resposta Digest foi gerada?"

Problemas de nonce e obsoletos

O nonce Digest é um valor fornecido pelo servidor. Algumas câmeras expiram rapidamente. Algumas câmeras o reutilizam para uma sessão. Algumas câmeras rejeitam nonces antigos após reinicialização, atualização de firmware, desvio de tempo ou muitas tentativas fracassadas.

Evidência útil:

  • A câmera inclui stale=true?
  • O cliente tenta novamente com um novo nonce?
  • A câmera envia um nonce diferente após cada 401?
  • A autenticação funciona uma vez e falha mais tarde?
  • O mesmo URL falha depois que a câmera fica ociosa?

Se a câmera retornar um novo desafio, mas o cliente continuar enviando o nonce antigo, a falha será o cache do lado do cliente. Se a câmera retornar desafios repetidos sem nenhum progresso útil, o problema poderá ser firmware da câmera, política de bloqueio ou incompatibilidade de credenciais.

Incompatibilidade de URI dentro da autenticação Digest

A autenticação Digest inclui o URI solicitado. Uma incompatibilidade sutil pode quebrar o login:

  • O cliente se conecta a rtsp://192.168.1.10/stream1.
  • A resposta resumida é calculada para /stream1.
  • A câmera espera rtsp://192.168.1.10:554/stream1.
  • O proxy encaminha /live/stream1.
  • O cliente tenta novamente com uma URL normalizada.

É por isso que as linhas de solicitação brutas são importantes. O URI DESCRIBE, o URI do cabeçalho Authorization e o caminho final da câmera devem ser comparados.

A senha não é a única causa

As equipes de suporte geralmente redefinem as senhas muito cedo. 401 Não Autorizado repetido também pode significar:

  • Esquema de autenticação errado.
  • Digerir incompatibilidade de reino.
  • Nonce obsoleto.
  • Incompatibilidade de caminho de URL.
  • A conta da câmera não tem permissão RTSP.
  • A conta é bloqueada após tentativas de login malsucedidas.
  • Caracteres especiais no nome de usuário ou senha não são codificados em URL.
  • O cliente retirou credenciais do URL redirecionado ou de nova tentativa.
  • A câmera requer a criação de usuário ONVIF antes do acesso RTSP.

O melhor artigo para SEO deve dizer isso claramente porque muitas pesquisas começam com a suposição de que a senha está errada.

Caracteres especiais em URLs RTSP

URLs RTSP geralmente contêm credenciais embutidas:

rtsp://user:password@camera.example.local:554/stream1

If the password contains @, :, /, ?, #, or %, the URL parser may split the string incorrectly. The protocol trace can show whether the client actually sent the intended username and whether the request path was damaged.

Better diagnostics separate:

  • URL parsing.
  • Authentication challenge.
  • Digest calculation.
  • Camera authorization decision.

What to capture

For a useful RTSP authentication report, collect:

  • Full request method sequence: OPTIONS, DESCRIBE, SETUP, PLAY.
  • First 401 Unauthorized response.
  • WWW-Authenticate header.
  • Authentication scheme.
  • Realm.
  • Nonce.
  • Stale flag.
  • Client Authorization header metadata.
  • Request URI used for Digest.
  • Second or third camera response.
  • Timing between retries.

Do not publish passwords or full Digest response values in public support cases. For internal debugging, preserve enough header structure to prove the protocol path.

Diagnosis workflow

Use this process:

  1. Confirm whether the first 401 is only a challenge.
  2. Check whether the client retries with Authorization.
  3. Compare Basic vs Digest.
  4. Compare realm and nonce values.
  5. Check whether stale=true appears.
  6. Verify the URI used in the authorization header.
  7. Check whether credentials contain reserved URL characters.
  8. Confirm the account has RTSP permissions.
  9. Test the same camera path after reboot or lockout window.
  10. Save the trace for regression testing.

Final diagnosis

RTSP Digest authentication failures should be diagnosed from headers, not from player error text. The important evidence is the challenge, the retry, the nonce, the realm, the URI, and the final camera decision.

RTSP Inspector helps turn "RTSP 401 Unauthorized" into a specific finding: wrong scheme, stale nonce, realm mismatch, URL credential parsing, account permission, or camera lockout.

<!-- rtsp-localized-evidence-foundation-v1:start -->

Evidência reproduzível para “Depuração de autenticação RTSP Digest: 401 não autorizado, Nonce, Realm, Basic vs Digest e loops de login de câmera”

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 “Depuração de autenticação RTSP Digest: 401 não autorizado, Nonce, Realm, Basic vs Digest e loops de login de câmera”, 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.

<!-- rtsp-localized-evidence-foundation-v1:end --><!-- multilingual-blog-closeout:start -->

Resposta direta e limite de aceitação

A resposta curta para “Depuração de autenticação RTSP Digest: 401 não autorizado, Nonce, Realm, Basic vs Digest e loops de login de câmera” é: Como solucionar falhas de autenticação RTSP Digest, loops 401 não autorizados, valores nonce obsoletos, incompatibilidades de domínio, configurações de câmera Basic vs Digest e problemas de credenciais de URL. 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: Depuração de autenticação RTSP Digest: 401 não autorizado, Nonce, Realm, Basic vs Digest e

Verifique “Depuração de autenticação RTSP Digest: 401 não autorizado, Nonce, Realm, Basic vs Digest e loops de login de câmera” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 2: Como solucionar falhas de autenticação RTSP Digest, loops 401 não autorizados, valores non

Quando “Como solucionar falhas de autenticação RTSP Digest, loops 401 não autorizados, valores nonce obsoletos, incompatibilidades de domínio, configurações d” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 3: Por que a autenticação RTSP é confusa

Verifique “Por que a autenticação RTSP é confusa” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 4: Configurações básicas e resumidas da câmera

Quando “Configurações básicas e resumidas da câmera” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 5: Incompatibilidades de reino

Verifique “Incompatibilidades de reino” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 6: Problemas de nonce e obsoletos

Quando “Problemas de nonce e obsoletos” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 7: Incompatibilidade de URI dentro da autenticação Digest

Verifique “Incompatibilidade de URI dentro da autenticação Digest” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 8: A senha não é a única causa

Quando “A senha não é a única causa” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 9: Caracteres especiais em URLs RTSP

Verifique “Caracteres especiais em URLs RTSP” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 10: What to capture

Quando “What to capture” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Matriz de aceitação

Ponto Evidência a manter Condição de aprovação
Depuração de autenticação RTSP Digest: 401 não autorizado, Nonce, Realm, Basic vs Digest e loops de login de câmera Estado inicial, uma ação e estado resultante Outra pessoa reproduz o resultado declarado
Como solucionar falhas de autenticação RTSP Digest, loops 401 não autorizados, valores nonce obsoletos, incompatibilidad Estado inicial, uma ação e estado resultante Outra pessoa reproduz o resultado declarado
Por que a autenticação RTSP é confusa Estado inicial, uma ação e estado resultante Outra pessoa reproduz o resultado declarado
Configurações básicas e resumidas da câmera Estado inicial, uma ação e estado resultante Outra pessoa reproduz o resultado declarado
Incompatibilidades de reino Estado inicial, uma ação e estado resultante Outra pessoa reproduz o resultado declarado
Problemas de nonce e obsoletos 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:

<!-- multilingual-blog-closeout:end -->