実際の応答から始める
Windows・macOS・Linux の rdp-cli 0.1.0 RDP インターフェースが対象です。2026年9月の既存の接続・Agent検証記録に基づく案内であり、今回サーバーを再試験したものではありません。許可されたWindows RDPサーバーと対応する現行クライアントを使います。例はPATH上の rdp-cli を使用します。Windowsは実行ファイルのフォルダーで .\rdp-cli.exe、Linuxはインストール済みコマンドかダウンロードした実行ファイルに置き換えてください。
rdp-cli --version
rdp-cli list
rdp-cli status --session SESSION
SESSION は自分の接続結果のIDに置き換えます。失敗時は error.code、error.message、error.retryable を確認します。status成功時は data.connection_state、data.control_state、存在すれば data.last_error、さらに data.capabilities を読みます。再試行可能という表示だけで入力を再送してはいけません。
接続の段階ごとに確認する
| エラー | 確認と対処 |
|---|---|
CONNECT_TIMEOUT / RDP_CONNECT_FAILED |
ホスト、実際のポート（通常3389）、LAN/VPN経路、RDPサービスを確認します。管理者に待受状態と許可するファイアウォール規則を確認してもらいます。ポートに到達できてもRDPログイン成功とは限りません。原因を直してから一度再試行します。 |
RDP_TLS_HANDSHAKE_FAILED |
サーバーのTLS設定を確認します。標準の modern はTLS 1.2が必要です。信頼できるネットワーク上で確認済みの旧サーバーに限り --tls-profile legacy を検討します。古い暗号設定を許可するため、全接続への適用や試験目的でのサーバー保護の解除は避けます。 |
CERTIFICATE_UNTRUSTED |
--cert-policy strict ではサーバー名と証明書チェーンを確認します。個別に信頼を登録する場合は、返されたSHA-256指紋を先に管理者と照合します。現在の標準値 ignore はサーバーの身元を検証しません。strictのエラーを消すためだけに変更しないでください。 |
AUTH_FAILED |
ユーザー名、ローカル/ドメインアカウント、--domain、リモートログオン権限を確認します。クイックスタートの非表示パスワード入力か保存済み認証情報を使います。TLS失敗や到達不能はパスワード誤りの証拠ではなく、繰り返し試すべきではありません。 |
接続済みでも画面が使えないとき
次の読み取り専用コマンドを実行し、data.path のPNGを開きます。connected はRDPが有効になり一貫したフレームを受信した状態です。ログイン画面、ようこそ画面、黒い画面の場合もあり、デスクトップの準備完了は保証しません。
rdp-cli screenshot --session SESSION
FRAME_UNAVAILABLE ならstatusと error.retryable を確認し、再接続や画面変更が落ち着いてから再取得します。取得できた画像が黒いままなら、サーバー状態、クライアントのスリープ、VPN切断を調べます。過去の黒い画面には異なる原因や未解明の原因がありました。見えない対象に認証情報を入力せず、静止画面をすべてプロトコル停止と決めつけないでください。
入力と権限のエラーを解決する
OBSERVATION_REQUIRED：新しい画面を取得して読み、そのdata.observationを次の操作に使います。再接続、操作引き継ぎ、画面変更後は更新が必要です。SESSION_PAUSED、CONTROL_HELD_BY_HUMAN、CONTROL_NOT_OWNED：入力を止め、現在の操作主体を尊重します。許可された返却後に再開して新しい画面を読みます。別のビューアーで一時停止を回避しないでください。PERMISSION_DENIED/CAPABILITY_UNAVAILABLE：対象の機能とアクセス許可を確認します。ビューアーを開いても未対応機能は増えません。UNICODE_INPUT_UNAVAILABLEでは対応する入力手段を選び、同じ操作を繰り返さないでください。
結果が不明な操作を確認する
結果確認が必要になり得る入力では、異なる操作ごとに固有の --request-id を事前に指定して保存し、例のリクエスト ID は自分の値に置き換えてください。エラー JSON が届いた場合は最上位の request_id を使えますが、応答が完全に失われ元の ID も保存していない場合、新しい ID で過去の操作を照会したり、確認せず再送したりしないでください。
操作中の REQUEST_TIMEOUT や SERVICE_UNAVAILABLE では元のリクエストIDを保持します。list でローカルサービスを確認し、元の処理を照会してから再試行を判断します。応答を失っていても入力は送信済みかもしれません。
rdp-cli operations status --session SESSION --request-id REQUEST_ID
rdp-cli status --session SESSION
rdp-cli screenshot --session SESSION
REQUEST_ID には照会自体のIDではなく、元の値を指定します。data.state、保存された data.result、新しい画面を確認します。OPERATION_NOT_FOUND は記録の期限切れやサービス変更でも起こり、未実行の証明ではありません。原因修正後、閉じていないセッションへ明示的に reconnect しても一時停止状態です。SESSION_CLOSED では新しく許可された接続を作り、再接続を連打しません。
証拠をそろえて次へ進む
解決しない場合はクライアント/サーバー版、プロトコル、時刻、エラーコードと機密情報を除いた状態・画像を添えてください。パスワード、アクセストークン、私的な画面情報を除去します。全サーバーの互換性や長期安定性を保証する案内ではありません。
ダウンロード · クイックスタート · コマンドリファレンス