2026-06-02

RTSP 401 non autorisé et 404 introuvable : diagnostic de l'URL de la caméra et des échecs d'authentification

Comment dépanner les erreurs de caméra RTSP 401 non autorisées et 404 non trouvées en séparant les informations d'identification, les chemins d'URL, la découverte ONVIF et les preuves de profil de flux.

Deux erreurs RTSP apparaissent encore et encore dans les tickets d'assistance: "« 401 Unauthorized » et « 404 Not Found ». Ils semblent simples. L’un ressemble à un problème de connexion, l’autre à une mauvaise URL. Dans les déploiements réels de caméras, les deux peuvent être plus subtils." Une caméra peut accepter les mêmes informations d'identification dans l'interface utilisateur Web mais rejeter RTSP. Un enregistreur peut exposer différents chemins pour le flux principal et le sous-flux. Une analyse ONVIF peut découvrir une URL qui change ultérieurement. Un fournisseur peut exiger un numéro de canal, un suffixe de flux ou un jeton de profil. Certaines caméras renvoient également des codes d'état trompeurs lorsque le chemin est trop long, que le flux est désactivé ou qu'un mode d'authentification est incompatible avec le client.

Pour les recherches Google, la requête de l'utilisateur est généralement directe : "Caméra RTSP 401 non autorisée", "RTSP 404 introuvable", "VLC fonctionne mais le NVR ne dit aucun signal" ou "L'URL RTSP de la caméra ONVIF ne fonctionne pas". Un article utile ne doit pas prétendre qu’il existe une URL magique. Il devrait montrer comment recueillir des preuves.

Commencez avec la méthode RTSP qui a échoué

N'enregistrez pas uniquement l'erreur finale. Enregistrez quelle méthode RTSP l'a renvoyé :

'OPTIONS'
DÉCRIRE
CONFIGURATION
'JOUER'

Si OPTIONS échoue avec 401, l'authentification ou la politique du serveur bloque la session avant que les métadonnées ne soient demandées. Si « DESCRIBE » échoue avec 401, la caméra peut accepter la connexion mais refuser l'accès à ce chemin de flux. Si DESCRIBE renvoie 404, le chemin ne correspond généralement pas à un profil de flux. Si SETUP échoue après un DESCRIBE réussi, l'URL peut être valide mais le chemin de contrôle de la piste, le mode de transport ou le profil multimédia a un problème.

Cette distinction est importante car la prochaine action change. Les correctifs d’informations d’identification ne répareront pas un chemin de flux manquant. La modification du suffixe de l'URL ne réparera pas une incompatibilité digest-auth.

Séparer les informations d'identification du chemin de flux

Une matrice de dépannage propre ressemble à ceci :

le même nom d'utilisateur/mot de passe fonctionne dans l'interface utilisateur Web de la caméra
Le service RTSP est activé
Le port RTSP est ouvert depuis le réseau client
Le chemin de l'URL correspond au modèle de flux principal ou de sous-flux du fournisseur.
le profil de flux est activé sur la caméra
le mode d'authentification est compatible avec le client
les caractères spéciaux du mot de passe sont correctement codés

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.

Pourquoi 404 signifie souvent profil ou chemin, pas réseau

« 404 Not Found » signifie que le serveur a été atteint et a suffisamment compris la demande pour rejeter la ressource. Pour les flux de caméra, cela renvoie souvent à l'un des éléments suivants :

mauvais numéro de chaîne
mauvais suffixe de flux
flux principal désactivé
sous-flux désactivé
le chemin de l'enregistreur diffère du chemin de la caméra
Jeton de profil ONVIF modifié
nom d'accès spécifique au fournisseur requis
le flux n'existe qu'après avoir activé RTSP dans les paramètres

La preuve la plus utile est l'URI de la requête « DESCRIBE » et l'état de la réponse. Si la caméra renvoie 404 avant SDP, il n'y a pas encore de session multimédia. Ne passez pas à la perte RTP ou au débogage du codec avant de confirmer que l'URL correspond à un flux réel.

La découverte ONVIF aide, mais ce n'est pas la même chose qu'une preuve

La découverte ONVIF peut fournir des URI de flux et des informations de profil, mais l'URI RTSP découvert doit encore être testé. Certains systèmes exposent correctement ONVIF alors que l'authentification RTSP ou le comportement du chemin est différent. D'autres renvoient un URI valide uniquement pour un profil qui est ensuite désactivé ou modifié.

La séquence diagnostique doit être :

découvrir ou saisir l'URL RTSP
exécutez OPTIONS et DESCRIBE
capturer les codes d'état et les en-têtes
vérifier si le SDP est renvoyé
alors seulement, inspectez les preuves SETUP, PLAY, RTP et codec

Cet ordre empêche un ingénieur de traiter chaque panne comme un problème de « caméra hors ligne ».

Comment l'inspecteur RTSP doit être utilisé

RTSP Inspector n'est pas un lecteur, un gestionnaire ONVIF ou un produit de découverte de caméra. Son rôle est de rendre la transaction RTSP suffisamment visible pour expliquer ce qui s'est passé. Pour les cas 401 et 404, le résultat utile est :

demander l'URI
méthode échouée
code d'état
limite d'authentification
si le SDP a été renvoyé
si l'échec s'est produit avant la négociation avec les médias
Prochain propriétaire recommandé : informations d'identification, profil de caméra, format d'URL du fournisseur, port réseau ou activation du flux.

C’est exactement la preuve dont un intégrateur de terrain ou un ingénieur de plate-forme vidéo a besoin avant de s’adresser au fournisseur de la caméra ou de modifier aveuglément les paramètres de l’enregistreur.

Lorsqu'un ticket d'assistance indique « RTSP ne fonctionne pas », demandez la méthode, le code d'état et la limite SDP. Cela transforme une plainte générique en un cas réparable.

Preuve reproductible pour « RTSP 401 non autorisé et 404 introuvable : diagnostic de l'URL de la caméra et des échecs d'authentification »

La réponse directe est qu’un écran noir ou un code isolé ne prouve pas l’origine d’une panne de caméra. Un diagnostic fiable relie requête et réponse RTSP, transport négocié, session valide, puis numéros de séquence RTP, horodatages et éléments RTCP. Pour « RTSP 401 non autorisé et 404 introuvable : diagnostic de l'URL de la caméra et des échecs d'authentification », partez de la couche la plus proche du symptôme, tout en conservant une chronologie unique afin de ne pas confondre contrôle, réseau et décodage.

Avant de modifier caméra, pare-feu ou VMS, établissez un test de référence. Notez l’URL RTSP sans mot de passe, l’heure, le chemin, le transport demandé, la réponse du serveur et l’arrivée du premier paquet média. Testez séparément UDP et TCP interleaved si l’équipement les propose. Ne changez pas à la fois chemin, identifiants et transport : un second essai réussi ne dirait pas quelle variable a corrigé l’écart.

Couche	Preuve à conserver	Question de décision
RTSP	méthode, statut, en-têtes, CSeq et Session	Le serveur accepte-t-il précisément l’opération ?
SDP	control, payload type, clock rate et codec	La piste décrite est-elle celle attendue ?
Transport	client_port, server_port ou interleaved	Les deux extrémités utilisent-elles le même canal ?
RTP	SSRC, séquence, timestamp et marker	Les unités arrivent-elles dans un ordre explicable ?
RTCP	sender report, CNAME et BYE	Horloge, identité et fin sont-elles traçables ?
Décodeur	SPS/PPS/VPS et packetization mode	Le payload reçu permet-il l’initialisation ?

Séparez « aucun média reçu » de « média reçu mais indécodable ». L’absence de RTP après SETUP et PLAY réussis dirige vers UDP, NAT, pare-feu ou une réponse Transport différente de l’offre. Des trous de séquence prouvent perte ou réordonnancement. Une séquence continue sans image déplace l’enquête vers payload type, fréquence d’horloge, limites d’image et paramètres H.264 ou H.265. Cette frontière est plus utile qu’un message générique du lecteur.

Comment rédiger une réponse directement réutilisable ?

Écrivez trois phrases : dernière opération réussie, première preuve en échec, prochain test discriminant. Exemple : « DESCRIBE, SETUP et PLAY réussissent ; aucun RTP n’arrive aux ports annoncés ; un essai TCP interleaved séparera blocage UDP et mauvais chemin média. » N’accusez ni caméra ni réseau sans réponse ou paquet qui matérialise cette limite.

Quelles données rendent le cas reproductible ?

Conservez OPTIONS, DESCRIBE, SETUP et PLAY, le SDP, la réponse Transport et l’identifiant Session nettoyé. Pour RTP, relevez SSRC, première et dernière séquence, clock rate, nombre de trous et durée. Mentionnez le résultat dans VLC ou un autre VMS comme test différentiel, pas comme preuve que le client qui fonctionne respecte toutes les frontières.

Quand tester le serveur ou le client ?

Examinez le serveur s’il refuse une méthode, fournit une URL control absente, renvoie un transport incompatible ou change SSRC ou horloge sans transition. Examinez le client s’il réutilise un nonce expiré, perd Session, demande UDP sans ouvrir les ports ou assimile chaque fin de NAL à une fin d’access unit. Entre les deux, paquet et heure doivent accompagner chaque conclusion.

Comment valider le rapport ?

Recommencez avec une connexion neuve et comparez les chronologies jusqu’à la première divergence. Retirez mots de passe et valeurs Authorization complètes. Reliez chaque conclusion à CSeq, séquence ou timestamp. La documentation RTSP associée couvre les étapes voisines ; RTSP Inspector permet de tester un flux RTSP et de collecter localement les preuves sans téléverser la vidéo vers un service public.

Réponse directe et limite d’acceptation

La réponse courte à « RTSP 401 non autorisé et 404 introuvable : diagnostic de l'URL de la caméra et des échecs d'authentification » est la suivante : Comment dépanner les erreurs de caméra RTSP 401 non autorisées et 404 non trouvées en séparant les informations d'identification, les chemins d'URL, la découverte ONVIF et les preuves de profil de flux. Considérez cette phrase comme un résultat à vérifier, et non comme une promesse valable pour toute entrée, tout appareil, tout projet ou tout environnement. Un résultat complet consigne l’état initial, l’action exacte, la sortie visible et la condition qui prouve la fin de la tâche dans RTSP Inspector.

Procédure fondée sur les preuves

Commencez par un cas petit et répétable avant de modifier un projet complet. Notez version de l’application, système, identité de l’entrée ou de l’appareil, réglages pertinents et résultat attendu. Exécutez une action volontaire, conservez la première transition inattendue et comparez-la à un cas nominal si possible. Plusieurs changements simultanés masquent la condition qui a créé ou corrigé le problème.

Point de contrôle 1 : RTSP 401 non autorisé et 404 introuvable : diagnostic de l'URL de la caméra et des échecs

Ne fermez « RTSP 401 non autorisé et 404 introuvable : diagnostic de l'URL de la caméra et des échecs d'authentification » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

Point de contrôle 2 : Comment dépanner les erreurs de caméra RTSP 401 non autorisées et 404 non trouvées en sépa

Pour « Comment dépanner les erreurs de caméra RTSP 401 non autorisées et 404 non trouvées en séparant les informations d'identification, les chemins d'URL, l », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Point de contrôle 3 : Commencez avec la méthode RTSP qui a échoué

Ne fermez « Commencez avec la méthode RTSP qui a échoué » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

Point de contrôle 4 : Séparer les informations d'identification du chemin de flux

Pour « Séparer les informations d'identification du chemin de flux », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Point de contrôle 5 : Pourquoi 404 signifie souvent profil ou chemin, pas réseau

Ne fermez « Pourquoi 404 signifie souvent profil ou chemin, pas réseau » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

Point de contrôle 6 : La découverte ONVIF aide, mais ce n'est pas la même chose qu'une preuve

Pour « La découverte ONVIF aide, mais ce n'est pas la même chose qu'une preuve », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Point de contrôle 7 : Comment l'inspecteur RTSP doit être utilisé

Ne fermez « Comment l'inspecteur RTSP doit être utilisé » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

Point de contrôle 8 : Preuve reproductible pour « RTSP 401 non autorisé et 404 introuvable : diagnostic de l'URL

Pour « Preuve reproductible pour « RTSP 401 non autorisé et 404 introuvable : diagnostic de l'URL de la caméra et des échecs d'authentification » », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Point de contrôle 9 : Comment rédiger une réponse directement réutilisable ?

Ne fermez « Comment rédiger une réponse directement réutilisable ? » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

Point de contrôle 10 : Quelles données rendent le cas reproductible ?

Pour « Quelles données rendent le cas reproductible ? », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Matrice d’acceptation

Point	Preuve à conserver	Critère de réussite
RTSP 401 non autorisé et 404 introuvable : diagnostic de l'URL de la caméra et des échecs d'authentification	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Comment dépanner les erreurs de caméra RTSP 401 non autorisées et 404 non trouvées en séparant les informations d'identi	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Commencez avec la méthode RTSP qui a échoué	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Séparer les informations d'identification du chemin de flux	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Pourquoi 404 signifie souvent profil ou chemin, pas réseau	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
La découverte ONVIF aide, mais ce n'est pas la même chose qu'une preuve	État initial, une action et état obtenu	Une seconde personne reproduit le résultat

Isolation, reprise et transmission

Arrêtez-vous à la première limite en échec. Conservez source, projet, session ou capture, dupliquez avant toute modification destructive et changez une variable par essai. Rejouer un flux entier après plusieurs changements peut modifier le résultat sans expliquer pourquoi.

Distinguez absence de preuve et preuve d’absence. Une vue vide peut signaler mauvaise entrée, portée, filtre, permission, appareil, période ou état du projet. Vérifiez acquisition ou import avant d’interpréter décodeur, éditeur, rapport ou export.

Avant transmission, rouvrez l’artefact durable et inspectez début, point de décision et fin. Notez version, plateforme, configuration, attente, observation et reproduction minimale. Retirez ou masquez les données sensibles et confirmez l’autorisation du destinataire.

Questions et réponses

Quelle est la manière fiable la plus rapide de commencer ?

Utilisez le plus petit cas représentatif, écrivez le résultat attendu et ne changez qu’une variable. Validez le parcours de base avant d’ajouter filtres, effets, modifications, automatisation ou grande source.

Quelles preuves faut-il conserver ?

Gardez identité de l’entrée, version, plateforme, réglages, action exacte, première transition inattendue et sortie finale. Fermez puis rouvrez projet, session, rapport ou export avant de le considérer durable.

Quand faut-il répéter la procédure ?

Répétez-la après un changement pertinent d’application, système, pilote, firmware, modèle, source ou processus. Conservez le cas accepté précédent comme référence non modifiée.

Quand le résultat est-il transmissible ?

Lorsqu’une seconde personne autorisée identifie l’entrée, répète l’action, obtient le même résultat, comprend les limites et ouvre l’artefact sans état local non documenté.

Guides associés

Ces pages dans la même langue couvrent les étapes voisines sans changer le propriétaire canonique du sujet :