2026-06-02

RTSP 401 nicht autorisiert und 404 nicht gefunden: Diagnose von Kamera-URL und Authentifizierungsfehlern

So beheben Sie die Kamerafehler RTSP 401 Unauthorized und 404 Not Found durch Trennung von Anmeldeinformationen, URL-Pfaden, ONVIF-Erkennung und Stream-Profil-Beweisen.

In Support-Tickets tauchen immer wieder zwei RTSP-Fehler auf: "„401 Unauthorized“ und „404 Not Found“. Sie klingen einfach. Das eine sieht nach einem Anmeldeproblem aus, das andere nach einer fehlerhaften URL. Bei realen Kameraeinsätzen können beide subtiler sein." Eine Kamera akzeptiert möglicherweise dieselben Anmeldeinformationen in der Web-Benutzeroberfläche, lehnt jedoch RTSP ab. Ein Rekorder kann unterschiedliche Pfade für den Hauptstream und den Substream offenlegen. Bei einem ONVIF-Scan wird möglicherweise eine URL entdeckt, die sich später ändert. Ein Anbieter benötigt möglicherweise eine Kanalnummer, ein Stream-Suffix oder ein Profil-Token. Einige Kameras geben auch irreführende Statuscodes zurück, wenn der Pfad zu lang ist, der Stream deaktiviert ist oder ein Authentifizierungsmodus mit dem Client nicht kompatibel ist.

Bei Google-Suchen erfolgt die Benutzerabfrage normalerweise direkt: „RTSP 401 nicht autorisierte Kamera“, „RTSP 404 nicht gefunden“, „VLC funktioniert, aber NVR sagt kein Signal“ oder „RTSP-URL der ONVIF-Kamera funktioniert nicht.“ Ein nützlicher Artikel sollte nicht so tun, als gäbe es eine magische URL. Es sollte zeigen, wie man Beweise sammelt.

Beginnen Sie mit der fehlgeschlagenen RTSP-Methode

Notieren Sie nicht nur den endgültigen Fehler. Notieren Sie, welche RTSP-Methode es zurückgegeben hat:

„OPTIONEN“.
„BESCHREIBEN“.
„SETUP“.
„SPIELEN“.

Wenn „OPTIONS“ mit 401 fehlschlägt, blockiert die Authentifizierung oder Serverrichtlinie die Sitzung, bevor Metadaten angefordert werden. Wenn „DESCRIBE“ mit 401 fehlschlägt, akzeptiert die Kamera möglicherweise die Verbindung, lehnt jedoch den Zugriff auf diesen Stream-Pfad ab. Wenn „DESCRIBE“ 404 zurückgibt, ist der Pfad normalerweise keinem Stream-Profil zugeordnet. Wenn „SETUP“ nach einem erfolgreichen „DESCRIBE“ fehlschlägt, ist die URL möglicherweise gültig, es liegt jedoch ein Problem mit dem Spursteuerungspfad, dem Transportmodus oder dem Medienprofil vor.

Diese Unterscheidung ist wichtig, da sich die nächste Aktion ändert. Anmeldeinformationskorrekturen reparieren keinen fehlenden Stream-Pfad. Durch Ändern des URL-Suffixes wird ein Digest-Authentifizierungskonflikt nicht behoben.

Trennen Sie Anmeldeinformationen vom Stream-Pfad

Eine saubere Fehlerbehebungsmatrix sieht so aus:

Derselbe Benutzername/dasselbe Passwort funktioniert in der Web-Benutzeroberfläche der Kamera
Der RTSP-Dienst ist aktiviert
Der RTSP-Port ist vom Client-Netzwerk aus geöffnet
Der URL-Pfad entspricht dem Haupt-Stream- oder Sub-Stream-Muster des Anbieters
Das Stream-Profil ist auf der Kamera aktiviert
Der Authentifizierungsmodus ist mit dem Client kompatibel
Sonderzeichen im Passwort sind korrekt kodiert

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.

Warum 404 oft Profil oder Pfad bedeutet, nicht Netzwerk

„404 Not Found“ bedeutet, dass der Server erreicht wurde und die Anfrage ausreichend verstanden hat, um die Ressource abzulehnen. Bei Kamerastreams deutet dies häufig auf eines der folgenden Probleme hin:

falsche Kanalnummer
Falsches Stream-Suffix
Hauptstream deaktiviert
Substream deaktiviert
Der Rekorderpfad unterscheidet sich vom Kamerapfad
ONVIF-Profiltoken geändert
Herstellerspezifischer Zugangsname erforderlich
Der Stream existiert erst, nachdem RTSP in den Einstellungen aktiviert wurde

Der nützlichste Beweis ist der „DESCRIBE“-Anfrage-URI und der Antwortstatus. Wenn die Kamera vor SDP 404 zurückgibt, gibt es noch keine Mediensitzung. Gehen Sie nicht zum RTP-Verlust oder Codec-Debugging über, bevor Sie bestätigt haben, dass die URL einem echten Stream zugeordnet ist.

Die ONVIF-Erkennung hilft, ist aber nicht dasselbe wie ein Beweis

Die ONVIF-Erkennung kann Stream-URIs und Profilinformationen bereitstellen, der erkannte RTSP-URI muss jedoch noch getestet werden. Einige Systeme stellen ONVIF korrekt bereit, während die RTSP-Authentifizierung oder das Pfadverhalten unterschiedlich sind. Andere geben einen URI zurück, der nur für ein Profil gültig ist, das später deaktiviert oder geändert wird.

Der Diagnoseablauf sollte wie folgt aussehen:

Finden Sie die RTSP-URL oder geben Sie sie ein
Führen Sie „OPTIONS“ und „DESCRIBE“ aus
Erfassen Sie Statuscodes und Header
Überprüfen Sie, ob SDP zurückgegeben wird
Überprüfen Sie erst dann „SETUP“, „PLAY“, RTP und Codec-Beweise

Diese Anordnung verhindert, dass ein Techniker jeden Fehler als „Kamera-Offline“-Problem behandelt.

Wie RTSP Inspector verwendet werden sollte

RTSP Inspector ist kein Player, ONVIF-Manager oder Kameraerkennungsprodukt. Seine Aufgabe besteht darin, die RTSP-Transaktion sichtbar genug zu machen, um zu erklären, was passiert ist. Für 401- und 404-Fälle lautet die nützliche Ausgabe:

Anfrage-URI
fehlgeschlagene Methode
Statuscode
Authentifizierungsgrenze
ob SDP zurückgegeben wurde
ob der Fehler vor der Medienverhandlung passiert ist
Empfohlener nächster Besitzer: Anmeldeinformationen, Kameraprofil, Anbieter-URL-Format, Netzwerkport oder Stream-Aktivierung

Das ist genau der Beweis, den ein Feldintegrator oder Videoplattform-Ingenieur benötigt, bevor er sich an den Kamerahersteller wendet oder die Rekordereinstellungen blind ändert.

Wenn in einem Support-Ticket „RTSP funktioniert nicht“ steht, fragen Sie nach der Methode, dem Statuscode und der SDP-Grenze. Dadurch wird aus einer allgemeinen Beschwerde ein lösbarer Fall.

Reproduzierbarer Nachweis für „RTSP 401 nicht autorisiert und 404 nicht gefunden: Diagnose von Kamera-URL und Authentifizierungsfehlern“

Die direkte Antwort lautet: Eine Kamerastream-Störung wird nicht durch ein einzelnes Player-Fenster oder einen Statuscode bewiesen. Die belastbare Diagnose verbindet RTSP-Anfrage und Antwort, die ausgehandelte Transportart, eine gültige Session und anschließend RTP-Sequenznummern, Zeitstempel sowie RTCP-Belege. Beginnen Sie bei „RTSP 401 nicht autorisiert und 404 nicht gefunden: Diagnose von Kamera-URL und Authentifizierungsfehlern“ an der Schicht, die dem sichtbaren Symptom am nächsten liegt, behalten Sie aber eine gemeinsame Zeitleiste, damit Steuerungs-, Netzwerk- und Decoderfehler nicht vermischt werden.

Erstellen Sie vor Änderungen an Kamera, Firewall oder VMS einen kleinen Ausgangstest. Notieren Sie die bereinigte RTSP-URL, Uhrzeit, Pfad, angeforderten Transport, Serverantwort und den Zeitpunkt des ersten Medienpakets. Testen Sie UDP und TCP interleaved getrennt, sofern das Gerät beides anbietet. Ändern Sie nicht gleichzeitig Pfad, Zugangsdaten und Transport. Sonst zeigt ein erfolgreicher zweiter Versuch nicht, welche Variable den Fehler beseitigt hat.

Prüfschicht	Zu sichernder Nachweis	Entscheidungsfrage
RTSP	Methode, Status, Header, CSeq und Session	Hat der Server genau diese Operation akzeptiert?
SDP	control, Payload-Typ, Clock Rate und Codec	Beschreibt der Server den erwarteten Medientrack?
Transport	client_port, server_port oder interleaved	Verwenden beide Seiten denselben Kanal?
RTP	SSRC, Sequenz, Timestamp und Marker	Kommen Medieneinheiten in erklärbarer Reihenfolge an?
RTCP	Sender Report, CNAME und BYE	Sind Uhr, Identität und Sitzungsende nachvollziehbar?
Decoder	SPS/PPS/VPS und Packetization Mode	Lassen sich die angekommenen Nutzdaten initialisieren?

Trennen Sie „keine Medien angekommen“ von „Medien angekommen, aber nicht decodierbar“. Fehlt RTP nach erfolgreichem SETUP und PLAY, prüfen Sie UDP-Pfad, NAT, Firewall und einen abweichenden Transport-Reply. RTP mit Sequenzlücken belegt Verlust oder Reordering. Eine lückenlose Folge ohne Bild verschiebt die Prüfung auf Payload-Typ, Clock Rate, Frame-Grenzen und H.264-/H.265-Parameter. Diese Grenze ist aussagekräftiger als eine allgemeine Player-Meldung.

Wie formuliert man eine zitierfähige Kurzantwort?

Nennen Sie in drei Sätzen die letzte erfolgreiche Operation, den ersten fehlgeschlagenen Beleg und den nächsten trennenden Test. Beispielstruktur: „DESCRIBE, SETUP und PLAY waren erfolgreich. An den angekündigten Client-Ports kam kein RTP an. Ein Test über TCP interleaved trennt UDP-Blockierung von einem falschen Medienpfad.“ Behaupten Sie keinen Kamera- oder Netzwerkdefekt ohne passende Antwort oder Paketbeleg.

Welche Angaben machen den Fehler reproduzierbar?

Sichern Sie OPTIONS, DESCRIBE, SETUP und PLAY samt SDP, Transport-Antwort und bereinigter Session-ID. Für Medien genügen zunächst SSRC, erste und letzte Sequenznummer, Clock Rate, Lückenanzahl und Aufnahmedauer. Vermerken Sie, ob VLC oder ein anderes VMS funktioniert. Das ist ein Differenztest, aber kein Beweis, dass der erfolgreiche Client jede Protokollgrenze korrekt behandelt.

Wann liegt der nächste Test auf Server- oder Clientseite?

Prüfen Sie den Server, wenn er eine Methode klar ablehnt, einen nicht vorhandenen control-Pfad liefert, das Transportangebot widersprüchlich beantwortet oder SSRC beziehungsweise Clock Rate ohne erklärten Übergang wechselt. Prüfen Sie den Client, wenn er einen alten Nonce wiederverwendet, Session-Header verliert, UDP anfordert ohne Ports zu öffnen oder jedes NAL-Ende als Access-Unit-Ende behandelt. Für Zwischenfehler bleiben Zeitstempel und Paketfolge unverzichtbar.

Wie wird der Bericht vor der Übergabe geprüft?

Wiederholen Sie den Test mit einer frischen Verbindung und vergleichen Sie beide Abläufe nur bis zur ersten Abweichung. Entfernen Sie Passwörter und vollständige Authorization-Werte. Verknüpfen Sie jede Aussage mit CSeq, Sequenznummer oder Timestamp. Der passende RTSP-Leitfaden erklärt angrenzende Schritte; RTSP Inspector dient als lokaler Arbeitsbereich zum Testen eines RTSP-Streams und zum Sammeln der Belege, ohne den Kamerastream zu einem öffentlichen Dienst hochzuladen.

Direkte Antwort und Abnahmegrenze

Die kurze Antwort zu „RTSP 401 nicht autorisiert und 404 nicht gefunden: Diagnose von Kamera-URL und Authentifizierungsfehlern“ lautet: So beheben Sie die Kamerafehler RTSP 401 Unauthorized und 404 Not Found durch Trennung von Anmeldeinformationen, URL-Pfaden, ONVIF-Erkennung und Stream-Profil-Beweisen. Behandeln Sie diese Aussage als zu prüfendes Ergebnis und nicht als Versprechen für jede Eingabe, jedes Gerät, jedes Projekt oder jede Umgebung. Ein vollständiges Ergebnis dokumentiert Ausgangszustand, exakte Aktion, sichtbare Ausgabe und die Bedingung, die den Abschluss in RTSP Inspector belegt.

Evidenzorientiertes Vorgehen

Beginnen Sie mit einem kleinen, wiederholbaren Fall, bevor Sie ein vollständiges Projekt verändern. Protokollieren Sie Anwendungsversion, Betriebssystem, Eingabe- oder Geräteidentität, relevante Einstellungen und erwartetes Ergebnis. Führen Sie eine bewusste Aktion aus, bewahren Sie den ersten unerwarteten Übergang und vergleichen Sie möglichst mit einem bekannten guten Lauf. Mehrere gleichzeitige Änderungen verdecken, welche Bedingung den Fehler erzeugt oder behoben hat.

Prüfpunkt 1: RTSP 401 nicht autorisiert und 404 nicht gefunden: Diagnose von Kamera-URL und Authentifiz

Schließen Sie „RTSP 401 nicht autorisiert und 404 nicht gefunden: Diagnose von Kamera-URL und Authentifizierungsfehlern“ erst, wenn gespeichertes, exportiertes oder erneut geöffnetes Ergebnis weiterhin dem beobachteten Zustand entspricht. Vorübergehendes UI-Feedback hilft, dauerhafte Evidenz ist aber stärker. Dokumentieren Sie verbleibende Grenzen für die nächste Person.

Prüfpunkt 2: So beheben Sie die Kamerafehler RTSP 401 Unauthorized und 404 Not Found durch Trennung von

Trennen Sie bei „So beheben Sie die Kamerafehler RTSP 401 Unauthorized und 404 Not Found durch Trennung von Anmeldeinformationen, URL-Pfaden, ONVIF-Erkennung und Strea“ eine Produktentscheidung von Grenzen des Betriebssystems, der Hardware, Quelldatei, Berechtigung oder Arbeitsweise. Bestätigen Sie zuerst, welche Schicht die Evidenz geliefert hat. So wird ein benachbartes Symptom nicht fälschlich zur bewiesenen Ursache.

Prüfpunkt 3: Beginnen Sie mit der fehlgeschlagenen RTSP-Methode

Schließen Sie „Beginnen Sie mit der fehlgeschlagenen RTSP-Methode“ erst, wenn gespeichertes, exportiertes oder erneut geöffnetes Ergebnis weiterhin dem beobachteten Zustand entspricht. Vorübergehendes UI-Feedback hilft, dauerhafte Evidenz ist aber stärker. Dokumentieren Sie verbleibende Grenzen für die nächste Person.

Prüfpunkt 4: Trennen Sie Anmeldeinformationen vom Stream-Pfad

Trennen Sie bei „Trennen Sie Anmeldeinformationen vom Stream-Pfad“ eine Produktentscheidung von Grenzen des Betriebssystems, der Hardware, Quelldatei, Berechtigung oder Arbeitsweise. Bestätigen Sie zuerst, welche Schicht die Evidenz geliefert hat. So wird ein benachbartes Symptom nicht fälschlich zur bewiesenen Ursache.

Prüfpunkt 5: Warum 404 oft Profil oder Pfad bedeutet, nicht Netzwerk

Schließen Sie „Warum 404 oft Profil oder Pfad bedeutet, nicht Netzwerk“ erst, wenn gespeichertes, exportiertes oder erneut geöffnetes Ergebnis weiterhin dem beobachteten Zustand entspricht. Vorübergehendes UI-Feedback hilft, dauerhafte Evidenz ist aber stärker. Dokumentieren Sie verbleibende Grenzen für die nächste Person.

Prüfpunkt 6: Die ONVIF-Erkennung hilft, ist aber nicht dasselbe wie ein Beweis

Trennen Sie bei „Die ONVIF-Erkennung hilft, ist aber nicht dasselbe wie ein Beweis“ eine Produktentscheidung von Grenzen des Betriebssystems, der Hardware, Quelldatei, Berechtigung oder Arbeitsweise. Bestätigen Sie zuerst, welche Schicht die Evidenz geliefert hat. So wird ein benachbartes Symptom nicht fälschlich zur bewiesenen Ursache.

Prüfpunkt 7: Wie RTSP Inspector verwendet werden sollte

Schließen Sie „Wie RTSP Inspector verwendet werden sollte“ erst, wenn gespeichertes, exportiertes oder erneut geöffnetes Ergebnis weiterhin dem beobachteten Zustand entspricht. Vorübergehendes UI-Feedback hilft, dauerhafte Evidenz ist aber stärker. Dokumentieren Sie verbleibende Grenzen für die nächste Person.

Prüfpunkt 8: Reproduzierbarer Nachweis für „RTSP 401 nicht autorisiert und 404 nicht gefunden: Diagnose

Trennen Sie bei „Reproduzierbarer Nachweis für „RTSP 401 nicht autorisiert und 404 nicht gefunden: Diagnose von Kamera-URL und Authentifizierungsfehlern““ eine Produktentscheidung von Grenzen des Betriebssystems, der Hardware, Quelldatei, Berechtigung oder Arbeitsweise. Bestätigen Sie zuerst, welche Schicht die Evidenz geliefert hat. So wird ein benachbartes Symptom nicht fälschlich zur bewiesenen Ursache.

Prüfpunkt 9: Wie formuliert man eine zitierfähige Kurzantwort?

Schließen Sie „Wie formuliert man eine zitierfähige Kurzantwort?“ erst, wenn gespeichertes, exportiertes oder erneut geöffnetes Ergebnis weiterhin dem beobachteten Zustand entspricht. Vorübergehendes UI-Feedback hilft, dauerhafte Evidenz ist aber stärker. Dokumentieren Sie verbleibende Grenzen für die nächste Person.

Prüfpunkt 10: Welche Angaben machen den Fehler reproduzierbar?

Trennen Sie bei „Welche Angaben machen den Fehler reproduzierbar?“ eine Produktentscheidung von Grenzen des Betriebssystems, der Hardware, Quelldatei, Berechtigung oder Arbeitsweise. Bestätigen Sie zuerst, welche Schicht die Evidenz geliefert hat. So wird ein benachbartes Symptom nicht fälschlich zur bewiesenen Ursache.

Abnahmematrix

Prüfpunkt	Aufzubewahrender Nachweis	Passkriterium
RTSP 401 nicht autorisiert und 404 nicht gefunden: Diagnose von Kamera-URL und Authentifizierungsfehlern	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
So beheben Sie die Kamerafehler RTSP 401 Unauthorized und 404 Not Found durch Trennung von Anmeldeinformationen, URL-Pfa	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Beginnen Sie mit der fehlgeschlagenen RTSP-Methode	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Trennen Sie Anmeldeinformationen vom Stream-Pfad	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Warum 404 oft Profil oder Pfad bedeutet, nicht Netzwerk	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Die ONVIF-Erkennung hilft, ist aber nicht dasselbe wie ein Beweis	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren

Fehlerisolierung, Recovery und Übergabe

Stoppen Sie beim ersten fehlerhaften Übergang. Bewahren Sie Quelle, Projekt, Session oder Capture und erstellen Sie vor destruktiven Änderungen eine Kopie. Ändern Sie pro Experiment nur eine Variable. Ein kompletter erneuter Lauf nach mehreren Änderungen kann anders enden, ohne die Ursache zu erklären.

Unterscheiden Sie fehlende Evidenz von Evidenz für ein Fehlen. Eine leere Ansicht kann auf falsche Eingabe, Scope, Filter, Berechtigung, Gerät, Zeitbereich oder Projektzustand hinweisen. Beweisen Sie Aufnahme oder Import, bevor Sie Decoder, Editor, Bericht oder Export interpretieren.

Öffnen Sie vor der Übergabe das dauerhafte Artefakt erneut und prüfen Sie Anfang, Entscheidungsstelle und Ende. Dokumentieren Sie Version, Plattform, Konfiguration, Erwartung, Beobachtung und kleinste Reproduktion. Entfernen oder schwärzen Sie sensible Daten und prüfen Sie die Berechtigung des Empfängers.

Fragen und Antworten

Wie beginnt man am schnellsten zuverlässig?

Verwenden Sie den kleinsten repräsentativen Fall, notieren Sie das erwartete Ergebnis und ändern Sie nur eine Variable. Beweisen Sie den Grundpfad, bevor Filter, Effekte, Bearbeitungen, Automatisierung oder größere Quellen hinzukommen.

Welche Evidenz sollte gespeichert werden?

Bewahren Sie Eingabeidentität, Version, Plattform, Einstellungen, exakte Aktion, ersten unerwarteten Übergang und Endausgabe. Projekt, Session, Bericht oder Export müssen geschlossen und erneut geöffnet werden.

Wann sollte das Verfahren wiederholt werden?

Wiederholen Sie es nach relevanten Änderungen an Anwendung, Betriebssystem, Treiber, Firmware, Modell, Quelle oder Workflow. Behalten Sie den früher akzeptierten Fall als unveränderte Vergleichsbasis.

Wann ist die Aufgabe übergabefähig?

Wenn eine autorisierte zweite Person Eingabe und Aktion erkennt, dasselbe Ergebnis reproduziert, verbleibende Grenzen versteht und das gespeicherte Artefakt ohne undokumentierten lokalen Zustand öffnen kann.