リモートデスクトップがポート3389で接続待受していない
この記事の結論
有効化済みの接続先へ到達できず、TCP 3389テストも失敗する場合の安全な切り分け手順。Remote Desktop無効、TermService停止、受信ファイアウォール規則無効、または上流ネットワーク遮断の可能性がある。設定変更前に現在値を控え、公式機能だけを使って確認する。
一般的な切り分けガイドです。特定の不具合が現在発生しているという告知ではありません。
対象製品・影響範囲
- 製品
- Remote Desktop
- 対象バージョン・条件
- Windows 11（対応機能はエディションとハードウェア要件を確認）
- 関連するエラーコード・識別子
- 0x204
発生する症状
- 有効化済みの接続先へ到達できず、TCP 3389テストも失敗する
- 再起動や再試行だけでは同じ状態が続くことがある
原因・発生条件
Remote Desktop無効、TermService停止、受信ファイアウォール規則無効、または上流ネットワーク遮断の可能性がある。
作業前の準備
- 開いている文書と作業を保存し、必要ならPCを再起動できる時間を確保する
- 管理者権限が必要な操作は、個人所有PCまたは管理者の許可を得た端末だけで行う
- 診断用コマンド「Get-NetTCPConnection -LocalPort 3389 -State Listen」の結果を保存し、変更前後を比較できるようにする
この操作の注意点
- レジストリ、システムフォルダー、資格情報、記憶域を手作業で一括削除しない
- インターネット上の非公式スクリプトや不明なドライバーを管理者権限で実行しない
使用するツール・公式ページ
この手順の公式要件、画面名、制限事項を確認する。
具体的な操作手順
この確認は接続元と接続先を区別して行います。Windows Homeは標準のリモートデスクトップ接続を受けるホストにはなれません。接続先が起動していること、必要なVPNへ接続していること、既定3389以外のポートが指定されていないかを先に確認します。
調べる場所を「接続するクライアント」と「接続されるホスト」に分けます。Get-NetTCPConnectionの待受確認は接続されるホストで実行するもので、クライアントで結果がないことは相手のRDP停止を証明しません。Test-NetConnectionはクライアントから意図したホストへ実行し、宛先名、ポート、結果を控えます。管理者から別の待受ポートを指定されている場合はその番号を使います。既定の3389に固定して失敗を繰り返す前に、現在の接続設計を確認することが必要です。
3389は既定ポートです。組織が変更している場合は接続先管理者に実際の番号を確認します。別のPCや古いIPアドレスへテストしていないかも確認し、クライアントからの接続テストとホスト内の待受確認を別々に記録します。
接続先で［設定］>［システム］>［リモートデスクトップ］を確認し、同一LANから試す。
Get-NetTCPConnectionは接続先RDPホストの管理者PowerShellで実行します。接続元で実行すると自分のPCの待受を調べるだけです。行が無ければホスト側サービス・RDP有効化を、Listen行があれば接続元からの経路を調べます。
ホストの待受が見つからない場合は、RDPが有効か、対応するWindowsエディションか、対象サービスが動いているかを管理者が確認します。接続先がスリープしていたり、VPNでしか到達できなかったりする状況も、同じタイムアウトに見える場合があります。サービスの状態を変更する前に、他の接続利用者がいないかも確認します。既存の遠隔作業を切断する操作を診断のためだけに行いません。ホストの画面へ直接入れないなら、クライアントだけで原因を確定したという報告は避けます。
Get-NetTCPConnection -LocalPort 3389 -State Listen接続先管理者としてRemote Desktopを有効化し、組み込みのRemote Desktopファイアウォール規則群を確認する。
ホスト内には待受があるがクライアントから届かない場合、ファイアウォール規則とネットワーク経路を確認する分岐です。規則は現在のネットワークプロファイルや接続元範囲に適用される必要があります。すべてのプロファイルやすべての接続元へ一律に許可する設定に広げる前に、必要な利用範囲を管理者と確認します。VPNや社内経路で接続する設計なら、その経路の状態を調べます。家庭ルーターでインターネットへRDPを直接公開する操作は、社内接続の復旧手順とは別です。
この手順で使う公式リンク
- General Remote Desktop connection troubleshooting
この手順の公式要件、画面名、制限事項を確認する。
- General Remote Desktop connection troubleshooting
接続先で［セキュリティが強化されたWindows Defenderファイアウォール］を開き、［受信の規則］のリモートデスクトップ規則を確認します。表示名はWindowsの言語で変わるため、英語のDisplayGroupで見つからなくても規則がないと断定しません。ファイアウォール全体を停止せず、管理者が接続先のプロファイルと許可元を確認します。
ホスト内で待受がなければ、ファイアウォールを開けてもRDPサービスの代わりにはなりません。待受はあるがクライアントから接続できない場合は、ネットワーク経路と適切なプロファイルの許可規則を調べます。ルーターでインターネットへポートを公開することを、この診断の前提にしません。
HOST_NAMEは例示用です。実際の接続先・機能名へ置き換えてから使用してください。
「Test-NetConnection <host> -Port 3389」で状態を確認し、最初に記録した操作を同じ条件で一度実行する。成功した場合も再起動後にもう一度確認し、変更した設定と結果を記録する。
TcpTestSucceeded が True なら指定ポートへ到達しています。Falseなら資格情報を変える前に、接続先名、VPN、接続先の待受、ファイアウォールを確認します。
クライアントの疎通が成功した後はRDP接続を一度試し、認証画面まで進むかを確認します。資格情報で拒否されるなら、待受と経路の調査を終えたうえで認証問題に引き継ぎます。接続できたセッションが別のPCでないか、ホスト名を確認することも必要です。残る問題を相談する際は、クライアントとホストの区別、実行した確認、実際のポート、時刻、VPN状態を渡します。「接続失敗」という一言にまとめず、待受なし、経路失敗、認証失敗のどこまで判明したかを示します。
Test-NetConnection HOST_NAME -Port 3389
改善したか確認する
- 意図したホストとポートへ接続し、RDPの認証画面まで進める
- 確認コマンドの出力が期待する有効・正常・接続済み状態を示す
- Windows再起動後にも同じ操作を再現でき、イベントログに同時刻の新しい重大エラーが増えない
改善しない場合・設定を戻す場合
- ホストを操作できない場合は待受結果と時刻を管理者へ確認依頼する
- ハードウェア要件、組織ポリシー、サーバー側設定が原因なら、クライアント側で回避せず所有者に変更を依頼する
このガイドの適用範囲
対処ガイド — 原因を切り分け、対象機能が正常に起動または接続でき、再起動後も同じ検証を通る状態を目標にする。
掲載内容は2026-10-13の情報確認に基づきます。以降の変更は公式出典でご確認ください。
よくある質問
3389が閉じていればファイアウォールが原因ですか？
サービスが待受していない場合もあります。接続先でRemote Desktop、TermService、リスナー、組み込み規則の順に確認します。
インターネットへ3389を直接公開してよいですか？
推奨しません。VPN、RD Gatewayなど管理された経路を利用し、ネットワーク管理者と設計してください。
クライアントで待受がないと言われたらホストのRDPは停止していますか？
いいえ。待受確認は接続されるホストで行います。クライアントでは相手への接続テストを行い、その結果とホスト内部の確認結果を分けて扱います。ホストを確認できない場合は管理者へ依頼します。
出典・情報の更新
- 主な出典の更新・解決日
- 公式ページで日付を特定できないため記載していません
- 本サイトの確認日
- 2026-10-13
公式情報を日本語で整理しています。メニュー名は製品の表示言語や版によって異なる場合があります。確認日は障害の発生日を意味しません。編集方針