Windows Server VPSにリモートデスクトップ接続できない時のRDPトラブルシューティング
Windows Server VPSにリモートデスクトップ接続できない場合、原因はたいてい次の5つのどれかです。3389ポートまでのネットワーク経路、RDPの無効化、Windowsファイアウォール、NLA/CredSSPの認証不一致、アカウントのロックアウトです。このRDPトラブルシューティングガイドでは、それぞれを順番に確認します。対象はWindows Server 2016/2019/2022で、ヨハネスブルグ・モスクワ・東京・ソウルのどのJUSTGクラウドサーバーでも同じ手順が使えます。例ではサーバーIPを203.0.113.10としているので、ご自身のIPに置き換えてください。
ステップ1：手元のPCからRDPの3389ポートをテストする
まず外側から確認します。TCPテストが失敗するならネットワーク経路かサーバー側の待ち受けの問題、成功するのにログインできないならステップ4へ進みます。
# On your own Windows PC (PowerShell)
Test-NetConnection -ComputerName 203.0.113.10 -Port 3389
# On macOS / Linux
nc -vz 203.0.113.10 3389TcpTestSucceeded : True と表示されればポートは開いています。Falseの場合は、クライアントエリアでVPSが起動中か、pingに応答するかを確認してください。社内ネットワークやプロバイダーが外向きの3389を遮断していることもあるので、スマートフォンのテザリングから一度試すと切り分けが早くなります。
ステップ2：リモートデスクトップが有効で待ち受けているか確認する
VNCコンソールでサインインし、PowerShellを管理者として起動します。Remote Desktop Services（TermService）の状態、fDenyTSConnections の値（0で許可、1で拒否）、そしてRDPが実際に使っているポートを確認します。
Get-Service -Name TermService
Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections
Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumber
Get-NetTCPConnection -LocalPort 3389 -State Listen以前にRDPポートを変更していれば PortNumber に新しい番号が表示されるので、接続時は IP:ポート の形式で指定します。RDPが無効、またはサービスが止まっている場合は次のコマンドで戻します。
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections -Value 0
Set-Service -Name TermService -StartupType Automatic
Start-Service -Name TermServiceステップ3：リモートデスクトップ用のWindowsファイアウォール規則を修正する
セキュリティ強化スクリプトや規則の整理で、組み込みのリモートデスクトップ規則が無効化されていることがよくあります。日本語版ではグループの表示名が翻訳されているため、どの言語でも同じように動くリソースIDベースのグループ名を使います。
# Language-independent group name for the built-in Remote Desktop rules
Enable-NetFirewallRule -Group "@FirewallAPI.dll,-28752"
Get-NetFirewallRule -Group "@FirewallAPI.dll,-28752" | Select-Object DisplayName, Enabled, Profile
# If the built-in rules were deleted, create one manually
New-NetFirewallRule -DisplayName "Allow RDP 3389" -Direction Inbound -Protocol TCP -LocalPort 3389 -Action AllowRDPポートを変更している場合は、3389ではなくそのポートを許可してください。そのあとステップ1をもう一度実行すれば、TCPテストは成功するはずです。
ステップ4：NLA・CredSSPの認証エラーを解決する
ポートは開いているのに「認証エラーが発生しました…CredSSP 暗号化オラクルの修復」やNLA関連のメッセージが出る場合は、クライアントとサーバーの更新レベルが合っていません。本来の対処はVNCコンソールからサーバーにWindows Updateを適用し、手元のPCも更新することです。一時的な回避策としてサーバー側でネットワークレベル認証（NLA）を無効にし、ログインして更新後に再度有効化する方法があります。
# Temporary: turn off Network Level Authentication (run in the VNC console)
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication -Value 0
# Turn it back on after the server is fully updated
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication -Value 1ステップ5：アカウントのロックアウトと「セッション数超過」
インターネットに公開されたRDPにはパスワード総当たりのボットが絶えずアクセスするため、ロックアウトポリシーでアカウントが止められていることがあります。VNCコンソールでポリシーとアカウントの状態、現在のセッションを確認しましょう。Windows Serverの既定では管理用セッションは2つまでなので、残っている古いセッションはIDを指定してログオフします。
net accounts
net user Administrator
qwinsta
logoff 2ローカルアカウントがロックされている場合は、lusrmgr.msc でユーザーのプロパティを開き「アカウントのロックアウト」のチェックを外すか、net accounts に表示されるロックアウト期間が過ぎるのを待ちます。総当たり対策としては、RDPを既定以外のポートに変更し、ファイアウォール規則の接続元を自分のIPに限定するのが有効です。
よくある質問
pingは通るのにリモートデスクトップ接続できないのはなぜですか？
pingはICMPが届いていることしか示しません。RDPにはTCP 3389（または変更後のポート）での待ち受けとファイアウォールの許可が必要です。VNCコンソールからステップ2と3を実施してください。
Windows Updateで再起動した後から接続できなくなりました。
再起動直後は数分待ってください。大きな更新では「更新プログラムを構成しています」の画面が長く続くことがあり、VNCコンソールで進行状況を見られます。その後CredSSPエラーが出るなら、手元のPCも更新してください。
JUSTGのWindows VPSにIPv6でRDP接続できますか？
できます。JUSTGのクラウドサーバーはすべてIPv6が無料です。サーバーに設定したあと、リモートデスクトップクライアントでアドレスを角かっこで囲んで入力します（例：[2001:db8::10]）。
これらを確認してもリモートデスクトップ接続できない場合は、ステップ1と2の出力結果を添えてチケットを送信し、JUSTGテクニカルサポートへご相談ください。
