【Windows 11/10】pingは通るのにリモートデスクトップ（RDP）が接続できない原因と対処法

社内ヘルプデスクで問い合わせの多いトラブルのひとつが、「pingは通るのにリモートデスクトップ（RDP）だけ繋がらない」、先日、システム部からそんな話がありました。接続しようとすると失敗する／タイムアウトするのに、対象PCへの ping だけはなぜか通る——。一度は出くわす、地味に厄介な状況です。

結論から言うと、この症状は原因の大半がたった2つのケースのどちらかに切り分けられます。本記事では、最短ルートで原因を特定する手順と、見落とされがちな2025〜2026年のWindows Update起因の不具合まで含めて整理します。

本記事では「pingが通る」を、接続先のIPアドレスへの応答がある状態を前提とします。ping ホスト名 が成功しているなら名前解決（DNS）も生きていますが、ping 192.168.x.x（IP直指定）だけ成功している場合は、名前解決の問題が残っている可能性があります（後述のケースB-4）。

なぜ「pingは通る」のにRDPは繋がらないのか
まず最初にやる切り分け：Test-NetConnection で3389番を叩く
「タイムアウト」「応答しません」と出る場合の見分け方
ケースA：TcpTestSucceeded が False（3389番に届いていない）
ケースB：TcpTestSucceeded が True なのに繋がらない（届くのに弾かれる）
見落としがち：2025〜2026年のWindows Update起因の不具合
それでも繋がらないときの最終チェック
まとめ
よくある質問（FAQ）

なぜ「pingは通る」のにRDPは繋がらないのか

pingとRDPは、そもそも使っている通信の種類が違います。

ping … ICMP というプロトコル。「相手PCが起動していて、IPレベルで到達できる」ことだけを確認する。
リモートデスクトップ … TCP の 3389番ポート（既定）。RDPサービスがそのポートで待ち受けていて、かつTCPで到達でき、さらに認証まで通る必要がある。

つまりpingが保証するのは「経路」と「電源」だけです。RDPサービスの起動・ファイアウォールの3389番・認証——この先のどこかで止まっていても、pingは平然と通り続けます。だからこの状況は「ネットワークそのものは正常。あとはRDP側のどこか」と切り分けられる、というのが本質です。

まず最初にやる切り分け：Test-NetConnection で3389番を叩く

いきなり設定を触る前に、接続元（クライアント）側で PowerShell を開き、

次を実行します。

Test-NetConnection 接続先IPアドレス -Port 3389

結果の TcpTestSucceeded の値ひとつで、原因の大半が2つに割れます。

TcpTestSucceeded	意味	主な原因	進む先
True	3389番までは届いている	アカウント権限・NLA・セッション数・名前解決	ケースB
False	3389番に届いていない	RDP無効・サービス停止・ファイアウォール・プロファイル	ケースA

旧来からよく紹介される netstat -an | find "3389" は、あくまで「そのPC自身が3389番を開いているか」を見るコマンドです。クライアントから接続先へ届くかの確認には Test-NetConnection が適しています。両者は確認している“場所”が違うので、混同せず使い分けてください。

「タイムアウト」「応答しません」と出る場合の見分け方

エラーメッセージの“出方”でも、ケースAかBかをある程度推測できます。

しばらく待たされてから失敗する／タイムアウトする … パケットが応答なく捨てられている状態。ファイアウォールが黙ってブロックしている、経路・ルーティングの問題などが典型で、ケースA（False）に多いパターンです。
即座に「接続できません」と返る … 接続は拒否されている（RSTが返っている）状態。3389番でサービスが待ち受けていない＝RDP無効・サービス停止が疑わしく、これもケースA側です。
画面は出るが、資格情報や認証で弾かれる／黒画面のまま固まる … 3389番までは到達できているのでケースB（True）。認証・NLA・セッション数を見ます。

「リモートデスクトップが応答しません」「タイムアウト」表示の多くは前者（ケースA）です。まずは Test-NetConnection の結果と突き合わせてください。

ケースA：TcpTestSucceeded が False（3389番に届いていない）

このパターンが原因の中心です。接続先PCで上から順に確認します。

A-1. リモートデスクトップ（ホスト）が有効か

Windowsは既定でRDPホスト機能が無効です。

Windows 11：設定 → システム → リモートデスクトップ →「リモートデスクトップ」をオン
Windows 10：設定 → システム → リモートデスクトップ →オン（※Windows 10は2025年10月に延長サポート終了。企業ではESU環境が多い点も念頭に）
どちらも SystemPropertiesRemote を実行すると、従来の［リモート］タブを直接開けます（Pro以上）

重要：Windows 11 / 10 の Home エディションは、RDPの“ホスト（接続される側）”になれません。クライアント（接続する側）としては使えますが、Home機を接続先にしたい場合はProへのアップグレードか、別のリモート手段が必要です。「pingは通るのに延々繋がらない」原因がこれ、というのは珍しくありません。

A-2. Remote Desktop Services（TermService）が動いているか

接続先で services.msc を開き、「Remote Desktop Services（TermService）」が実行中かを確認します。停止していれば開始してください。

接続先が実際に待ち受けているかを直接確認するなら、その端末で次を実行します。

netstat -ano | find "3389"

0.0.0.0:3389 ... LISTENING が表示されればホストは待ち受け中です。表示されなければ、サービス停止かRDP無効化を疑います。PowerShell派なら次でも同じことを確認できます（Windows Server 2025含め新しめの環境向き）。

Get-NetTCPConnection -LocalPort 3389 -State Listen

A-3. ファイアウォールで3389番がブロックされていないか

Windows Defender ファイアウォール（または wf.msc → 詳細設定）→ 受信の規則 で、次の規則が有効かを確認します。

リモートデスクトップ – ユーザーモード (TCP 受信) ← まずこれが必須
リモートデスクトップ – ユーザーモード (UDP 受信)
リモートデスクトップ – シャドウ (TCP 受信)

無効になっていれば、右クリック →「規則の有効化」。なお、ノートンなどサードパーティ製セキュリティソフトがWindowsとは別にブロックしているケースも多いため、そちらの受信ルールも合わせて確認します。

A-4. ネットワークプロファイルが「パブリック」になっていないか

ネットワークが「パブリック」判定だと、Windowsは既定でRDPの受信を絞ります。設定 → ネットワークとインターネット →（対象の接続）→ ネットワークプロファイルの種類を「プライベート」に変更します。社内LANなのにパブリック扱いになっている、はよくある落とし穴です。

ケースB：TcpTestSucceeded が True なのに繋がらない（届くのに弾かれる）

ポートには届いている＝経路もサービスもファイアウォールもクリア。ここから先は「認証と入口」の問題です。

B-1. アカウント・権限

接続するユーザーが、接続先の「Remote Desktop Users」グループに入っているか（管理者は既定で接続可）
そのアカウントにパスワードが設定されているか（空パスワードのアカウントは既定でRDP不可）

B-2. NLA（ネットワークレベル認証）の不一致

接続先がNLA必須なのに、クライアント側の資格情報・時刻同期・ドメイン信頼に問題があると、ログイン画面の手前で弾かれます。切り分けとして、接続先の［リモート］タブで「ネットワークレベル認証でリモート接続を許可する」を一時的に外して挙動を見る方法があります（セキュリティは下がるため、原因特定の検証目的のみ）。

B-3.「CredSSP暗号化オラクルの修正」エラー

更新プログラムの当たり方が接続元と接続先で食い違うと、CredSSP関連のエラーで接続を拒否されます。原則は両方を最新化するのが正攻法です。

B-4. 同時接続数の上限・名前解決

クライアントOS（Windows 10/11）は基本1セッションのみ。誰かがログイン中だと弾かれることがあります。
「ホスト名ではNGだがIP指定ならOK」の場合は名前解決（DNS/hosts）の問題。接続先をIPアドレスに変えて切り分けます。

B-5. イベントログで失敗理由を特定する

ケースB（ポートには届いている）では、接続先のイベントログに拒否理由が記録されています。原因が絞り切れないときの決め手になります。イベントビューアーを開き、次をたどります。

アプリケーションとサービス ログ
 └ Microsoft
    └ Windows
       └ TerminalServices-RemoteConnectionManager / TerminalServices-LocalSessionManager

NLAの失敗、認証エラー、セッション拒否、接続元IP・ユーザー名などはここに出ます。あわせて「Windows ログ → セキュリティ」のログオン失敗（イベントID 4625 など）も確認すると、資格情報側か権限側かを切り分けられます。

見落としがち：2025〜2026年のWindows Update起因の不具合

「昨日まで使えていたのに突然」というパターンでは、更新プログラム自体が原因のことがあります。直近で実際に発生した代表例です。

2025年1〜3月（KB5050094／KB5053598 ほか）：Windows 11 24H2 から Windows Server 2016以前へ UDPで接続すると、約65秒でセッションが切断される不具合。TCP接続では再現しないため、UDPを無効化すれば回避でき、MicrosoftはKnown Issue Rollback（KIR）と4月以降の累積更新で対処しました。
2025年2月前後：24H2でRDPログイン時にハング・再接続不可になる報告（KB5050094／KB5051987が関与）。接続ポートの変更で改善した例もありますが、万能ではありません。
2026年1月：1月の定例更新の適用直後から、Azure Virtual Desktop／Windows 365／「Windows アプリ」で接続不可・資格情報入力画面が出ない不具合。Microsoftが問題を認め、1月17日（日本時間18日）に緊急修正を配布しました。

対処の基本は、(1) 更新履歴で直近KBの適用日と症状発生日を突き合わせる → (2) Microsoftの修正/KIRを待つか、該当KBを一時アンインストールする → (3) 必要に応じてUDP無効化やポート変更で回避する、の順です。

補足：従来のストア版「リモートデスクトップ」アプリは「Windows アプリ（Windows App）」へ移行が進んでいます。AVDやWindows 365に繋ぐ用途では、まずアプリ側の不具合・バージョンも疑ってください。一方、社内LANの一般的なPCへ繋ぐ用途は、従来どおり mstsc.exe（リモートデスクトップ接続）で問題ありません。

それでも繋がらないときの最終チェック

VPN経由：VPNは繋がっているのにRDPだけNG → VPN側のルーティング、許可ポート、スプリットトンネル設定を確認
二重NAT・社外からの接続：ポートフォワードやルーター側のファイアウォール。なお3389番の直開放はセキュリティ上非推奨で、VPNやRDゲートウェイ経由が安全です
ポート競合・変更：3389番を別アプリが使用、または意図的に変更されている → 接続先のリッスンポートを確認し、IPアドレス:ポート番号 の形式で接続
代替経路：物理コンソール、iLO/iDRAC等の管理ボード、クラウドならVNCコンソールで一旦ログインして設定を直す

まとめ

「pingは通るのにRDPが繋がらない」の正体は、pingがICMP（経路と電源だけ）を見ているのに対し、RDPはTCP3389＋サービス＋認証まで必要、というギャップです。

遠回りせず、まず接続元で Test-NetConnection 接続先 -Port 3389 を実行し、

False → ホスト有効化・サービス・ファイアウォール・プロファイル（ケースA）
True → アカウント権限・NLA・セッション数・名前解決（ケースB）

と切り分けるのが最短ルートです。そして「突然繋がらなくなった」ときは、2025〜2026年に複数発生した更新起因の不具合も忘れずに疑いましょう。

よくある質問（FAQ）

pingは通るのにRDPが繋がらないのはなぜですか？

pingはICMPで「相手が起動していて経路がある」ことだけを確認します。RDPはTCP3389番＋RDPサービス＋認証が必要なため、ping成功はRDP成功を意味しません。まず接続元で Test-NetConnection 接続先 -Port 3389 を実行し、3389番への到達可否を確認してください。

3389ポートが開いているかを確認する方法は？

接続元からの到達確認は PowerShell の Test-NetConnection 接続先IP -Port 3389 で TcpTestSucceeded を見ます。接続先PC自身が待ち受けているかは、その端末で netstat -ano | find "3389" を実行し、0.0.0.0:3389 LISTENING が出るかで確認します。両者は確認する場所が異なります。