RDP выдаёт ошибку 0x204 при подключении к Windows VPS

Что означает ошибка RDP 0x204 и как сразу понять, где искать проблему

Код 0x204 лучше воспринимать не как диагноз, а как признак того, что RDP-клиент не смог довести подключение до рабочей удалённой сессии. Причина может находиться до Windows VPS, непосредственно в сетевых настройках Windows или уже на этапе аутентификации.

Внешне сценарии часто похожи. Пользователь вводит IP сервера в Remote Desktop Connection или другом RDP-клиенте, некоторое время видит Connecting, а затем получает сообщение о невозможности соединиться. В другом случае ошибка появляется почти сразу. По одной скорости появления 0x204 нельзя надёжно определить причину, поэтому первое полезное действие — проверить не интерфейс RDP, а транспорт.

Нужно ответить на простой вопрос: принимает ли Windows VPS TCP-соединение на том порту, куда обращается клиент? Пока ответа нет, переходить к NLA, паролям и правам пользователя рано.

После такой развилки уже есть за что зацепиться. Если TCP не устанавливается, остаёмся на сетевом уровне. Если устанавливается, идём выше — к RDP listener, безопасности и входу пользователя.

Доступен ли Windows VPS по правильному IP и RDP-порту

При ошибке 0x204 первым делом проверьте фактический IP Windows VPS и TCP-порт RDP. Стандартный порт Remote Desktop — 3389, но на VPS его нередко меняют, поэтому автоматически считать правильным именно 3389 нельзя.

На компьютере с Windows откройте PowerShell и выполните:

Test-NetConnection SERVER_IP -Port 3389

Вместо SERVER_IP укажите публичный IPv4 вашего VPS. Главная строка в выводе:

TcpTestSucceeded : True

или:

TcpTestSucceeded : False

True означает, что TCP-соединение с указанным портом устанавливается. Это ещё не доказывает исправность всей RDP-сессии: после установления TCP остаются RDP negotiation, NLA, аутентификация и создание пользовательской сессии. Но базовый сетевой путь уже работает.

False означает, что TCP-соединение установить не удалось. Среди причин — неправильный порт, внешний firewall, Windows Firewall, отсутствующий listener, ограничение по исходному IP или фильтрация в сети пользователя.

Если администратор менял RDP-порт, тестировать нужно именно его:

Test-NetConnection SERVER_IP -Port 3390

Номер 3390 здесь приведён только как пример.

Почему одного ping недостаточно

Ситуация «сервер пингуется, но RDP не подключается» не противоречит сетевой диагностике. Ping использует ICMP, а RDP требует доступности своего TCP-порта. Успешный ping подтверждает только то, что сервер или сетевой периметр отвечает на ICMP.

Работает и обратный сценарий: VPS не отвечает на ping, но RDP открывается. ICMP может быть запрещён firewall, тогда как TCP-порт Remote Desktop разрешён.

Если используется hostname, а не IP, попробуйте подключиться непосредственно по IP. Когда SERVER_IP:PORT работает, а имя сервера нет, причину уже стоит искать в DNS, локальном кеше резолвера или устаревшей записи, а не в TermService.

Где блокируется RDP: на стороне VPS-провайдера, маршрута или внешнего firewall

IP правильный, VPS включён, но Test-NetConnection возвращает False. В этот момент менять NLA или пользователя бессмысленно: TCP-соединение ещё не дошло до стадии RDP-аутентификации.

У Windows VPS могут одновременно существовать несколько уровней фильтрации. Один firewall работает внутри Windows. Второй может находиться в панели VPS или облачной инфраструктуре. Поверх этого встречаются security groups, ACL, allowlist по IP, VPN и корпоративные правила исходящего трафика.

Начните с панели VPS. Проверьте, разрешён ли входящий TCP-трафик на фактический RDP-порт. Если правило ограничено конкретным Remote IP, сравните его с текущим публичным IP компьютера пользователя. После переподключения провайдера, смены офиса, подключения VPN или перехода на другой канал внешний адрес может измениться.

Почему RDP может работать через мобильный интернет, но не через Wi-Fi

Хороший изолирующий тест — тот же компьютер, тот же IP Windows VPS и тот же порт, но другая сеть. Например, из домашнего Wi-Fi получаем:

Test-NetConnection SERVER_IP -Port PORT

TcpTestSucceeded : False

Переключаем тот же ноутбук на мобильную точку доступа и повторяем:

Test-NetConnection SERVER_IP -Port PORT

TcpTestSucceeded : True

В таком сценарии сервер уже умеет принимать TCP-подключение на нужном порту. Значит, в первую очередь проверяем исходную сеть: VPN, корпоративный firewall, маршрутизатор, локальный security software или политику, запрещающую исходящее соединение.

Важно, что тест должен выполняться к одному и тому же IP:PORT. Если через Wi-Fi проверяли один сервер, а через мобильную сеть другой, сравнение теряет диагностический смысл.

Что показывает тест с включённым и выключенным VPN

VPN меняет маршрут, исходный публичный IP и иногда правила фильтрации. Поэтому полезно выполнить два последовательных теста, не меняя ничего другого:

Test-NetConnection SERVER_IP -Port PORT

Сначала с включённым VPN, затем после его отключения. Если результат меняется с False на True, Windows VPS трогать пока не нужно. Проверяйте VPN-маршрут, корпоративные ограничения и allowlist на стороне VPS.

Встречается и обратная ситуация: без VPN порт закрыт, а через VPN доступен. Например, внешний firewall сервера разрешает RDP только с адресов корпоративной сети. Это уже не неисправность RDP — срабатывает заданная политика доступа.

Успешное подключение к другому RDP-серверу не доказывает, что текущий Windows VPS доступен. Firewall фильтрует конкретные адреса и порты. Поэтому контрольная единица здесь всегда одна: нужный IP:PORT.

Разрешает ли Windows Defender Firewall входящие RDP-подключения

Порт слушается локально, а Test-NetConnection с внешнего компьютера возвращает False. Реестр в этот момент уже не главный подозреваемый: если listener есть, нужно проверить, выпускает ли Windows этот порт наружу.

Откройте PowerShell от имени администратора:

Get-NetFirewallRule -DisplayGroup "Remote Desktop"

Команда показывает правила группы Remote Desktop. На локализованных версиях Windows отображаемое имя группы может отличаться, поэтому при отсутствии результата откройте wf.msc и найдите входящие правила Remote Desktop вручную.

Для правил нужно проверить не только Enabled, но и направление, действие и профиль:

Get-NetFirewallRule -DisplayGroup "Remote Desktop" |
Select-Object DisplayName, Enabled, Direction, Action, Profile

Портовые фильтры:

Get-NetFirewallRule -DisplayGroup "Remote Desktop" |
Get-NetFirewallPortFilter

Адресные ограничения:

Get-NetFirewallRule -DisplayGroup "Remote Desktop" |
Get-NetFirewallAddressFilter

Через GUI те же настройки находятся в:

wf.msc

Далее: Inbound Rules → Remote Desktop.

Правило Remote Desktop включено, но порт всё равно закрыт

Enabled=True ещё не означает, что правило подходит текущему подключению. Обычно нужно проверить четыре вещи: профиль, LocalPort, Action и Scope.

Посмотрите активный сетевой профиль Windows:

Get-NetConnectionProfile

Если правило действует, например, только для Domain, а сетевой интерфейс Windows VPS находится в Public, оно не даст ожидаемого результата. В GUI это видно на вкладке профилей конкретного firewall rule.

Следующая точка — LocalPort. При стандартном RDP ожидается 3389. Если PortNumber уже изменён на 3390, а firewall продолжает разрешать 3389, правило формально включено, но фактический listener остаётся недоступным.

Потом проверьте Scope или RemoteAddress. Правило может разрешать соединения не с любого адреса, а только с заданной подсети или одного административного IP. Из офиса всё работает, дома появляется 0x204 — такой сценарий часто объясняется именно scope, а не поломкой RDP.

Особенно внимательно проверьте firewall после смены RDP-порта

Обычная конфигурационная ловушка выглядит так: PortNumber уже 3390, netstat показывает LISTENING на 3390, а Windows Firewall всё ещё пропускает только 3389. В этом состоянии перезапуск TermService ничего не меняет.

Здесь должны совпасть четыре значения: PortNumber, локальный LISTENING, LocalPort firewall rule и порт в RDP-клиенте. Плюс, если есть внешний firewall хостинга, то и его правило.

Слушает ли Windows VPS порт RDP и работает ли служба TermService

TermService показывает Running. Это только половина проверки. Для рабочего Remote Desktop служба должна не просто быть запущена — Windows должна создать RDP listener на фактическом порту.

Если RDP уже потерян, выполняйте команды через независимую консоль VPS.

Сначала состояние службы:

Get-Service TermService

Ожидаемый результат:

Status   Name         DisplayName
------   ----         -----------
Running  TermService  Remote Desktop Services

Альтернативная проверка:

sc query TermService

или:

services.msc

Если TermService остановлена или сразу останавливается

Однократно запустить службу можно через Services или PowerShell, но если она снова переходит в Stopped, повторный запуск уже не диагностика. Нужно посмотреть, почему Windows не удерживает службу в рабочем состоянии.

Проверьте конфигурацию службы:

sc qc TermService

И связанные службы:

Get-Service TermService -RequiredServices

После неудачной попытки запуска откройте Event Viewer → Windows Logs → System и отфильтруйте события по времени запуска. Сообщения Service Control Manager часто дают гораздо больше информации, чем само состояние Stopped: отказ запуска, проблема зависимости, ошибка конфигурации или системного компонента.

Если проблема появилась сразу после hardening, обновления политик или ручного изменения служб, сначала восстановите известную рабочую конфигурацию этого участка. Не стоит одновременно править TermService, firewall и RDP-Tcp — после этого трудно понять, где была исходная причина.

Как проверить RDP listener

Для стандартного порта:

Get-NetTCPConnection -LocalPort 3389 -State Listen

Либо:

netstat -ano | findstr :3389

У работающего listener должна присутствовать строка LISTENING. Например:

TCP    0.0.0.0:3389    0.0.0.0:0    LISTENING    820

PID можно сопоставить со службой:

tasklist /svc | findstr TermService

Для более подробного вывода:

netstat -anob | findstr 3389

Есть ещё одна полезная серверная проверка:

qwinsta

В нормальной конфигурации в выводе можно увидеть RDP listener rdp-tcp в состоянии ожидания подключений. Это другой взгляд на ту же серверную часть: netstat показывает сетевой сокет, а qwinsta — состояние терминальных сессий и listener.

TermService Running, PortNumber правильный, но LISTENING отсутствует

Вот здесь часто заканчиваются короткие инструкции, хотя именно комбинация самая интересная. Служба работает, порт в реестре известен, но никто его не слушает.

Сначала ещё раз получите фактический PortNumber:

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumber

Затем проверьте не только 3389, а именно полученное значение:

Get-NetTCPConnection -LocalPort PORT -State Listen

Если результата нет, посмотрите конфигурацию ветки:

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Для диагностики полезно проверить, не отключён ли сам RDP-Tcp listener. Один из связанных параметров — fEnableWinStation. При рабочей конфигурации RDP-Tcp должен быть разрешён. Реестр здесь лучше использовать как подтверждение состояния, а не как место для случайного перебора значений.

После изменения RDP-настроек или порта перезапустите Remote Desktop Services только если у вас есть независимый доступ к серверу. Затем снова выполните три проверки:

Get-Service TermService
qwinsta
Get-NetTCPConnection -LocalPort PORT -State Listen

Если TermService Running, rdp-tcp появился и порт находится в LISTENING — серверная часть listener восстановлена. Дальше уже проверяем доступность порта снаружи.

Если порт слушается локально — это уже конкретный результат. Реестр и TermService перестают быть первыми подозреваемыми, а диагностику переносим наружу, к firewall и сети.

Не изменился ли RDP-порт после настройки Windows VPS

Если Windows VPS с RDP раньше настраивали вручную, применяли hardening-скрипт или переносили из другого окружения, RDP может работать не на 3389. Клиент в таком случае безуспешно обращается к стандартному порту, хотя Remote Desktop на сервере исправен.

Текущий PortNumber:

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumber

Параметр хранится здесь:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Имя:

PortNumber

Если используется нестандартный порт, его нужно указать в RDP-клиенте:

SERVER_IP:PORT

Например:

203.0.113.10:3390

Нашли PortNumber 3390 — не спешите менять его обратно. Сначала проверьте, согласована ли вся цепочка:

1. PortNumber равен 3390;
2. Get-NetTCPConnection или netstat показывает LISTENING на 3390;
3. Windows Firewall разрешает входящий TCP 3390;
4. внешний firewall VPS, если он есть, тоже разрешает 3390;
5. клиент подключается к IP:3390;
6. Test-NetConnection IP -Port 3390 возвращает True.

Типичная ошибка как раз выглядит иначе: реестр уже показывает 3390, listener слушает 3390, а firewall по-прежнему открыт на 3389. В такой конфигурации менять пароль или NLA нет смысла — TCP до нужного listener не доходит.

После любого изменения порта повторите проверку именно снаружи:

Test-NetConnection SERVER_IP -Port PORT

Локальный LISTENING подтверждает только работу Windows. Внешний TCP-тест подтверждает, что к этому listener действительно можно добраться через весь сетевой периметр.

Включён ли Remote Desktop в Windows и не запрещён ли он политикой

Windows Firewall может разрешать порт, а TermService — работать, но Windows должна разрешать сами входящие Remote Desktop connections. Если listener не поднимается или ошибка появилась после применения security policy, эту ветку нужно проверить отдельно.

Начните с Settings → System → Remote Desktop. Remote Desktop должен быть включён.

Связанное состояние можно проверить в реестре:

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server

Параметр:

fDenyTSConnections

При разрешённых RDP-подключениях ожидается:

fDenyTSConnections = 0

Получить значение через PowerShell:

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections

Как понять, что локальную настройку переопределяет политика

Сложнее выглядит ситуация, когда Settings показывает ожидаемое состояние, администратор меняет локальный параметр, но после обновления политик проблема возвращается. Тогда нужно проверить не только локальную конфигурацию, но и фактически применённые Group Policy.

Для локальной политики можно открыть:

gpedit.msc

Нас интересуют политики Remote Desktop Services в разделе Windows Components. В доменной среде локальный редактор не показывает всей картины, поэтому полезнее посмотреть результирующую политику:

rsop.msc

или сформировать отчёт:

gpresult /h C:\gpresult.html

После создания откройте C:\gpresult.html и посмотрите, какая политика реально применяется к компьютеру.

Если доменная GPO запрещает Remote Desktop, локальное изменение может выглядеть рабочим только до очередного обновления политик. В таком сценарии бесконечно возвращать fDenyTSConnections вручную бесполезно — нужно исправлять источник политики.

Для контрольной проверки после изменения политики можно обновить её:

gpupdate /force

Затем снова проверить:

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections
Get-Service TermService
qwinsta

И уже после этого — внешний TCP-порт.

Характерная микросцена здесь простая: Remote Desktop визуально включён, администратор открывает firewall, но после применения security baseline listener снова исчезает или подключение остаётся запрещённым. В такой ситуации узкое место не в 3389, а в политике, которая управляет поведением RDP.

Может ли NLA или CredSSP мешать подключению к VPS

NLA и CredSSP проверяют только после подтверждения транспортного уровня: Test-NetConnection возвращает True, TermService работает и RDP listener существует. При закрытом порте никакое изменение NLA не поможет — клиент ещё не дошёл до стадии предварительной аутентификации.

Network Level Authentication переносит аутентификацию пользователя на ранний этап RDP-соединения. CredSSP участвует в передаче и согласовании учётных данных. Поэтому неисправность на этом уровне выглядит иначе, чем обычный timeout: TCP до сервера уже проходит, но RDP не может завершить security negotiation или вход пользователя.

Как отличить проблему NLA от сетевой ошибки и отказа учётной записи

Сначала зафиксируйте три результата:

Test-NetConnection SERVER_IP -Port PORT
Get-Service TermService
Get-NetTCPConnection -LocalPort PORT -State Listen

Если первый тест False, проблема ещё не на уровне NLA. Если все три проверки успешны, транспорт и listener уже подтверждены.

Для сравнения полезно использовать стандартный mstsc.exe на другом Windows-компьютере. Если тот же IP, порт и пользователь работают там, серверную конфигурацию NLA лучше пока не менять. Разница находится на клиентской стороне.

Проверьте также, используется ли реальный пароль учётной записи. PIN Windows Hello — это способ локальной разблокировки устройства и не всегда подходит как пароль для удалённой аутентификации к другой Windows-системе.

Как проверить, требует ли RDP Network Level Authentication

Связанный параметр RDP-Tcp можно посмотреть через PowerShell:

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication

Значение 1 означает требование NLA для RDP-Tcp. Эта проверка полезна именно как диагностика текущей конфигурации.

Через графический интерфейс настройку можно увидеть в свойствах Remote Desktop. На Windows Server конкретное расположение элемента зависит от версии и установленной роли, но смысл один: требовать Network Level Authentication для удалённых подключений.

Когда временная проверка без NLA действительно имеет смысл

Временно рассматривать NLA как гипотезу стоит только при выполнении всех базовых условий: порт доступен извне, listener работает, а сбой начинается уже после установления транспортного соединения.

Перед тестом желательно иметь доступ через консоль VPS. Затем можно временно изменить требование NLA, повторить подключение и сравнить поведение.

Если без NLA RDP начинает работать, это ещё не готовое исправление. Результат говорит, что нужно разбирать следующий слой: клиент, CredSSP, credentials, security policy или совместимость RDP-компонентов. Постоянно оставлять ослабленную конфигурацию ради обхода симптома не стоит.

Если же отключение NLA вообще не меняет поведение, возвращайте исходную настройку и продолжайте диагностику по журналам. Здесь уже нет смысла крутить один и тот же переключатель.

Где искать признаки проблемы CredSSP или security negotiation

Сделайте одну новую попытку подключения и сразу посмотрите:

Event Viewer → Applications and Services Logs → Microsoft → Windows → TerminalServices-RemoteConnectionManager

Дополнительно проверьте клиентское сообщение RDP. Ошибка, в которой прямо упоминаются credentials, authentication или CredSSP, гораздо полезнее общего 0x204 и должна изменить направление диагностики.

Когда TCP True, listener есть и RemoteConnectionManager видит обращение, сеть уже можно почти снять с подозрения. Дальше разбираем handshake и auth, а не возвращаемся в маршрутизатор после каждой неудачной попытки.

Есть ли у пользователя право входить на Windows VPS через Remote Desktop

Права пользователя нужно проверять только тогда, когда соединение дошло до этапа аутентификации. Если TCP-порт закрыт и Windows не видит RDP-запрос, членство в Remote Desktop Users ничего не изменит.

Участников локальной группы можно посмотреть командой:

net localgroup "Remote Desktop Users"

Управление локальными пользователями:

lusrmgr.msc

Администраторы обычно уже имеют право удалённого входа, а обычному пользователю может потребоваться членство в Remote Desktop Users.

Но группы недостаточно. Откройте:

secpol.msc

Далее:

Local Policies → User Rights Assignment → Allow log on through Remote Desktop Services

И обязательно:

Deny log on through Remote Desktop Services

Запрещающее право имеет приоритет. Пользователь может состоять в Remote Desktop Users и всё равно не проходить вход, если на него или его группу распространяется Deny.

В доменной среде эти настройки могут задаваться GPO. Тогда снова полезен результирующий набор политик, а не только локальный secpol.msc.

Проверьте формат имени пользователя

Для локальной учётной записи standalone Windows VPS можно явно указать локальный контекст:

.\username

или имя сервера:

SERVERNAME\username

Это особенно полезно, когда RDP-клиент автоматически подставляет сохранённый домен или другую учётную запись.

Если другой пользователь входит на тот же VPS с того же компьютера, сеть, firewall и listener уже практически исключаются. Не надо снова открывать 3389. Сравнивайте состояние учётных записей, формат login и User Rights Assignment.

Как понять, находится ли проблема на Windows VPS или на RDP-клиенте

Один ноутбук получает 0x204, другой сразу подключается к тому же IP и порту. Это уже сильный диагностический результат: основная серверная цепочка способна принять RDP-сессию.

Чтобы не менять сервер наугад, используйте матрицу «два клиента × две сети».

Если три комбинации работают, а одна стабильно нет, серверную конфигурацию лучше не трогать. Ищите отличающуюся переменную.

На проблемном компьютере сначала сравните TCP:

Test-NetConnection SERVER_IP -Port PORT

Если TCP тоже False только на этом устройстве, проверьте:

• VPN;
• локальный firewall;
• endpoint security;
• сетевой профиль;
• маршрут;
• корпоративные ограничения.

Если TCP True, но конкретный RDP-клиент выдаёт 0x204, сравните его со стандартным:

mstsc.exe

Создайте новое подключение вручную, не используя старый .rdp-файл. Так можно исключить сохранённые gateway-настройки, credentials и параметры конкретного профиля.

Если Windows-клиент работает, а приложение на macOS, iOS или другом устройстве нет, сначала обновите или пересоздайте подключение на проблемном клиенте. Код 0x204 может отображаться разными Microsoft Remote Desktop-клиентами, поэтому ориентироваться нужно не на название платформы, а на результаты TCP-теста и серверных журналов.

За один тест меняйте одну переменную. Сначала сеть. Потом клиент. Потом credentials. Если одновременно отключить VPN, поменять порт и перезапустить TermService, рабочее подключение можно получить, но причина так и останется неизвестной.

Какие события Windows проверить, если порт открыт, но RDP не работает

Test-NetConnection=True, TermService Running и RDP-порт LISTENING. Следующий вопрос: до какого этапа Windows доводит конкретную попытку подключения? Ответ лучше искать в журналах в момент воспроизведения ошибки.

Откройте:

eventvwr.msc

Основные журналы:

Applications and Services Logs → Microsoft → Windows → TerminalServices-RemoteConnectionManager → Operational

Applications and Services Logs → Microsoft → Windows → TerminalServices-LocalSessionManager → Operational

При проблемах с credentials и правами:

Windows Logs → Security

Как не утонуть в старых событиях

Запомните текущее время, очистить журнал для этого не нужно. Сделайте ровно одну попытку RDP, дождитесь ошибки, сразу обновите нужные журналы и смотрите события в диапазоне одной-двух минут вокруг теста.

Если записей много, используйте Filter Current Log и ограничьте период. Такая привязка ко времени намного полезнее, чем поиск случайного Event ID среди событий за несколько дней.

Что проверять после появления RDP-запроса в RemoteConnectionManager

Если новая попытка появляется в TerminalServices-RemoteConnectionManager, пакет уже дошёл до RDP-компонента Windows. В этот момент снова проверять внешний firewall без нового симптома обычно не нужно.

Полезный ориентир — событие 1149, которое обычно фиксирует успешную аутентификацию пользователя компонентом RemoteConnectionManager. Оно не означает, что полноценный рабочий стол уже обязательно открылся, но показывает, что соединение прошло заметно дальше простого TCP.

Если после этого пользователь всё равно не получает рабочую сессию, переходите в TerminalServices-LocalSessionManager. Там уже интересует создание и состояние пользовательской сессии.

Например, события LocalSessionManager могут показывать успешный вход в сессию, отключение или переподключение. Это позволяет отделить «аутентификация не прошла» от ситуации «пользователь вошёл, но сессия сразу оборвалась».

Когда нужен Security log

Если проблема выглядит как отказ конкретному пользователю, смотрите Windows Logs → Security. При включённом аудите входов там можно встретить:

• 4624 — успешный вход;
• 4625 — неудачная попытка входа.

Для Remote Desktop особенно интересен Logon Type 10 — RemoteInteractive. Но Event ID нельзя читать отдельно от деталей события: имя пользователя, источник, статус и substatus дают больше пользы, чем сам номер.

Если 4625 появляется ровно в момент теста, сеть уже не главный вопрос. Смотрите reason/status, правильность username, пароль, состояние аккаунта и права входа.

Если RemoteConnectionManager видит запрос, но Security вообще не фиксирует попытку пользователя, сбой может происходить раньше полноценного logon — например, на этапе NLA/security negotiation.

Так журналы превращаются не в список Event ID, а в продолжение той же диагностической цепочки: дошёл ли запрос, прошёл ли authentication, создалась ли сессия.

Как восстановить доступ к Windows VPS, если RDP 0x204 не удаётся устранить удалённо

Если RDP был единственным привычным способом управления сервером, не восстанавливайте его вслепую. Нужен независимый административный канал: web-консоль, VNC/noVNC, emergency console или другой способ, который предоставляет VPS-провайдер.

Через такую консоль можно проверить Windows локально даже при полностью закрытом внешнем RDP.

RDP 0x204: проверка Windows VPS за 10 минут

• VPS включён и открывается через панель или независимую консоль.
• Используется правильный публичный IP.
• Известен фактический RDP-порт.
• Выполнен Test-NetConnection IP -Port PORT.
• При False выполнена проверка из второй сети.
• Проверен внешний firewall или security group.
• Проверены профиль, LocalPort и Scope Windows Firewall.
• TermService находится в состоянии Running.
• qwinsta показывает RDP listener.
• Фактический RDP-порт находится в LISTENING.
• PortNumber совпадает с listener, firewall и настройкой клиента.
• Remote Desktop разрешён в Windows.
• Проверено, не переопределяет ли настройку GPO.
• При открытом порте проверены NLA, credentials и клиент.
• Права пользователя проверяются только после достижения стадии входа.
• TerminalServices logs просмотрены в момент новой попытки.
• При необходимости выполнен тест с другого клиента и другой сети.

Для нормальной диагностики 0x204 достаточно собрать несколько фактов: какой IP и порт используются, проходит ли TCP-тест, работает ли TermService, существует ли listener, разрешает ли трафик firewall и видит ли Windows новую RDP-попытку. После этого проблема уже не выглядит как «RDP просто не подключается» — она оказывается на конкретном участке цепочки.

TcpTestSucceeded: False означает, что сначала разбираем сеть, firewall, PortNumber и listener. True позволяет двигаться выше — к RDP negotiation, NLA, credentials, правам пользователя и журналам. Если тот же Windows VPS стабильно открывается с другого устройства или через другую сеть, серверную конфигурацию без нового доказательства лучше не трогать.

И перед любыми изменениями RDP-порта, firewall или политик Remote Desktop проверьте независимую консоль VPS. Если что-то пойдёт не так, именно она позволит вернуть рабочую конфигурацию, не превращая ошибку 0x204 в полную потерю административного доступа.