2026-06-02

RTSP 認証ループ: 401 未承認、ダイジェスト認証、およびカメラのログイン失敗の修正

RTSP 401 不正ループ、ダイジェスト認証、基本認証、古いノンス応答、間違ったカメラユーザー、および URL 認証情報の問題に関する実践的なガイド。

最も一般的な RTSP カメラの問題の 1 つは、一見単純に見えます。クライアントは接続し、カメラは応答しますが、ストリームが開始されません。ログに「401 Unauthorized」が繰り返され、視聴者が再度パスワードを要求するか、ユーザー名とパスワードが正しいように見えてもアプリケーションが RTSP URL が間違っていると表示します。

これは RTSP 認証ループです。これは、カメラがクライアントにチャレンジし、クライアントが認証情報を送信し、カメラがそれを拒否するか、再度要求するときに発生します。根本的な原因は不正なパスワードである可能性がありますが、ダイジェスト認証の不一致、古いノンス処理、アカウントのアクセス許可、URL 内の特殊文字、間違ったストリームパス、または「DESCRIBE」、「SETUP」、および「PLAY」で個別に認証を必要とするカメラである可能性もあります。

重要な証拠は RTSP 制御交換にあるため、ここでは RTSP Inspector が役立ちます。メディアプレーヤーでは、1 つのログインエラーの背後にチャレンジと再試行の詳細が隠蔽されることがよくあります。プロトコル診断ビューでは、エラーが「OPTIONS」、「DESCRIBE」、「SETUP」、または「PLAY」で発生したかどうか、およびカメラが「WWW-Authenticate」、「stale=true」、または反復されたレルムチャレンジを返したかどうかを表示できます。

RTSP 401 Unauthorized 応答の意味

RTSP では、「401 Unauthorized」は通常、「サーバーにアクセスできない」というよりも「認証が必要である」ことを意味します。カメラは、次のように未認証リクエストに応答できます。

RTSP/1.0 401 Unauthorized
CSeq: 2
WWW-Authenticate: Digest realm="IP Camera", nonce="abc123"

Basic authentication vs Digest authentication

Special characters in RTSP URL credentials

Credentials in an RTSP URL can break when the password contains characters such as @, :, /, ?, #, %, or &.

A URL like this is ambiguous:

rtsp://admin:pa@ss@192.168.1.50:554/stream1

rtsp://admin:pa%40ss@192.168.1.50:554/stream1

Account permissions can block RTSP even when web login works

Wrong stream path can look like wrong credentials

That means a 401 does not prove the URL path is valid.

Common RTSP path patterns include:

/stream1
/stream2
/live
/h264
/h265
/cam/realmonitor?channel=1&subtype=0
/Streaming/Channels/101
/profile1/media.smp

Stale nonce and repeated Digest challenges

The camera may respond with:

WWW-Authenticate: Digest realm="IP Camera", nonce="new-value", stale=true

正しいクライアントは、新しい nonce を使用して再試行する必要があります。クライアントが古いノンス処理を理解していない場合、ストリームは認証を超えて進むことができない可能性があります。

この問題は、プロキシ、NVR リレーレイヤー、またはダイジェスト認証を緩やかに実装するファームウェアの背後にあるカメラで特によく発生します。また、クライアントが古い RTSP セッションを積極的に再利用した場合にも発生することがあります。

DESCRIBE、SETUP、PLAYでの認証

一部のカメラは、最初の「DESCRIBE」リクエストのみに挑戦します。複数の方法に挑戦する人もいます。ストリームは次のように失敗する可能性があります。

認証後、DESCRIBE は成功します。
「SETUP」は別の「401 Unauthorized」を受け取ります。
クライアントは「SETUP」の資格情報を再送信しません。
再生が始まりません。

「PLAY」でも同じことが起こります。カメラは、すべての保護されたリクエストに「Authorization」ヘッダーを必要とする場合があります。クライアントが最初のリクエストのみを認証する場合、認証エラーではなく、紛らわしい「ストリームを再生できません」エラーが表示されることがあります。

RTSP Inspector は RTSP メソッドシーケンスを第一級の証拠として扱うため、これを確認しやすくします。問題は「ログインは機能しましたか?」ということだけではありません。しかし、「どのメソッドが挑戦され、クライアントは正しく答えましたか?」

RTSP 401 認証ループのチェックリスト

デバッグ時には次の順序を使用します。

既知のカメラアカウントを使用して正確なユーザー名とパスワードを確認します。
RTSP URL 内の特殊文字を URL エンコードします。
カメラにダイジェスト認証または基本認証が必要かどうかをテストします。
「WWW-Authenticate」ヘッダーでレルム、ノンス、アルゴリズム、および古いフラグを調べます。
クライアントが DESCRIBE、SETUP、および PLAY で Authorization を送信するかどうかを確認します。
アカウントに Web UI 権限だけでなく、RTSP およびチャネル権限があることを確認します。
メインストリームパスとサブストリームパスを個別にテストします。
RTSP リクエストで使用される URI と、ダイジェスト応答の計算で使用される URI を比較します。
カメラのファームウェアが認証動作を変更したかどうかを確認します。
RTSP 認証が実際に完了するまでは、メディアコーデックの診断を避けてください。

Google 検索が通常意味するもの

「RTSP 401 Unauthorized IP カメラ」を検索する場合、通常は資格情報が間違っているかどうかを知る必要があります。「RTSP ダイジェスト認証ループ」を検索する場合、通常はすでにパスワードを試しており、プロトコルの証拠が必要です。「カメラ RTSP がパスワードを繰り返し要求する」を検索する場合、チャレンジと再試行のシーケンスを検査する必要があります。

役に立つ答えは、単に「パスワードをリセットする」というだけではありません。役に立つ答えは次のとおりです。

カメラはその要求に異議を唱えましたか?
クライアントは期待された認証方式で応答しましたか?
カメラは答えを受け入れましたか？
その後の RTSP メソッドが再び失敗しましたか?
ログイン後にストリームパスまたはアカウントの権限が失敗しましたか?

この種の問題については、プレーヤーのみのテストよりもプロトコル指向のツールの方が優れているのはこのためです。

最終診断

RTSP 認証ループは、資格情報、URL エンコード、認証スキーム、リクエスト URI、アカウント許可、およびメソッドレベルの認可動作を照合することによって解決されます。トレースに、ノンスが変化する「401 Unauthorized」応答が繰り返し表示される場合は、ダイジェスト処理を調べてください。認証の成功に続いてストリームエラーが表示された場合は、URL パス、SDP、トランスポート、RTP、およびコーデックの診断に進みます。

RTSP Inspector は証拠優先のワークフロー向けに設計されており、カメラ、プレーヤー、コーデック、またはネットワークに障害があると想定する前に RTSP 制御パスを確認します。

「RTSP 認証ループ: 401 未承認、ダイジェスト認証、およびカメラのログイン失敗の修正」を再現可能に検証する手順

結論から言うと、黒画面や一つのステータスコードだけでは障害の所在を証明できません。信頼できる診断では、RTSP の要求と応答、合意した Transport、有効な Session、その後の RTP シーケンス番号、タイムスタンプ、RTCP の証拠を一つの時系列につなげます。「RTSP 認証ループ: 401 未承認、ダイジェスト認証、およびカメラのログイン失敗の修正」では表示症状に近い層から調べますが、制御、ネットワーク、デコーダーの問題を混同しないよう同じ記録時刻を使います。

カメラ、ファイアウォール、VMS の設定を変える前に、小さな基準テストを作ります。パスワードを除いた RTSP URL、時刻、パス、要求した Transport、サーバー応答、最初のメディアパケット到着時刻を記録してください。機器が対応する場合は UDP と TCP interleaved を別々に試します。パス、認証情報、Transport を同時に変えると、二回目の成功がどの変更によるものか分かりません。

確認層	保存する証拠	判断する質問
RTSP	メソッド、状態、ヘッダー、CSeq、Session	サーバーはその操作を受理したか
SDP	control、payload type、clock rate、codec	期待するトラックが記述されているか
Transport	client_port、server_port、interleaved	両端が同じ経路を使うか
RTP	SSRC、sequence、timestamp、marker	メディア単位が説明可能な順序で届くか
RTCP	sender report、CNAME、BYE	時計、識別子、終了を追跡できるか
Decoder	SPS/PPS/VPS、packetization mode	受信 payload で初期化できるか

「メディアが届かない」と「届くが復号できない」を分けます。SETUP と PLAY が成功しても RTP がなければ、UDP 経路、NAT、ファイアウォール、Transport 応答を調べます。シーケンスの穴は損失または並べ替えを示します。連続した RTP があるのに映像がなければ、payload type、clock rate、フレーム境界、H.264 または H.265 のパラメーターへ進みます。この境界はプレーヤーの一般的なエラーより有用です。

引用できる短い回答はどう書きますか

三文で、最後に成功した操作、最初に失敗した証拠、二つの原因を分ける次の試験を書きます。例は「DESCRIBE、SETUP、PLAY は成功した。通知されたクライアントポートに RTP が届かない。TCP interleaved の再試験で UDP 遮断とメディアパス誤りを分ける」です。応答やパケットなしにカメラやネットワーク全体を原因と断定しません。

再現に必要な最小情報は何ですか

OPTIONS、DESCRIBE、SETUP、PLAY、SDP、Transport 応答、秘密を除いた Session を保存します。RTP は SSRC、最初と最後のシーケンス、clock rate、欠落数、収録時間を記録します。VLC や別 VMS の成否は差分試験として有用ですが、成功したクライアントが全規則を正しく扱う証明ではありません。

サーバーとクライアントのどちらを調べますか

メソッド拒否、存在しない control URL、不一致 Transport、説明のない SSRC や時計変更はサーバー側を調べます。期限切れ nonce の再利用、Session 欠落、ポートを開かない UDP 要求、各 NAL 終端を access unit 終端とみなす処理はクライアント側を調べます。中間経路の問題では、各結論にパケットと時刻を添えます。

報告前に何を確認しますか

新しい接続で再試験し、二つの時系列を最初の相違点まで比較します。パスワードと完全な Authorization 値を削除し、結論を CSeq、sequence、timestamp に結び付けます。関連する RTSP ガイドで周辺手順を確認し、RTSP Inspectorで RTSP ストリームをローカルに試験してください。カメラ映像を公開サービスへアップロードする必要はありません。