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.