Не работает подключение по удалённому рабочему столу (RDP) к компьютеру с Windows 10 Pro — какие шаги предпринять для диагностики и восстановления?

Третий день пытаюсь восстановить подключение к серверу по RDP: интернет и сеть работают, компьютер в сети и по указанному адресу пингуется. В административных шаблонах политика подключения включена, обновления не устанавливались, служба «Удалённые рабочие столы» запущена, у пользователя все права, брандмауэры и SmartScreen отключены; DISM и SFC проблем не выявили, откат системы не помог. Что это может быть — просто сбой или, как шутят, «заговор иллюминатов»? Может, кто-то уже сталкивался с подобным?<br/> <br/>Периодически ещё даёт сбои блок питания: после отключения электричества ПК иногда не стартует — может ли это как‑то быть связано с проблемой RDP?
  • 16 апреля 2026 г. 3:01
Ответы на вопрос 5
Коротко — давайте системно. Судя по тому, что вы описали, многое уже проверено, но есть ещё ряд «тонких» мест и инструментов для диагностики. Ниже — упорядоченный чек‑лист действий (с командами и что смотреть), возможные причины и комментарий по блоку питания.

1) Быстрая проверка слушателя RDP и порта
- На самом «сервере» (компьютере с Windows 10) выполните:
  - netstat -ano | findstr :3389
    - ожидаем видеть строку LISTENING на порту 3389 (или другой порт, если RDP перенастроен).
  - qwinsta
    - покажет состояние listener/сессий.
  - reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections
    - значение 0 = RDP включён, 1 = отключён.
  - reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber
    - номер порта (обычно 3389).
Если нет LISTENING на 3389 — RDP‑служба не принимает соединения на этом порту.

2) Проверка с клиента и сетевого уровня
- С клиента выполните:
  - Test-NetConnection -ComputerName <IP_сервера> -Port 3389  (PowerShell)
    - что показывает TcpTestSucceeded: True/False и время отклика.
  - telnet <IP> 3389  (если доступно) — должен быть установлен TCP‑сессия (даже если нет вывода).
- На сервере запустите Wireshark/tcpdump или временно включите сетевой монитор и посмотрите, приходят ли SYN от клиента на сервер (чтобы исключить сетевой фильтр/маршрутизатор).

3) Логи — очень важный пункт
- Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> TerminalServices-RemoteConnectionManager/Operational
- Event Viewer -> Microsoft -> Windows -> TerminalServices-LocalSessionManager/Operational
- System и Security на предмет ошибок TermService, RPC, EventID 1006/1026/1149/36874/36888 и т. п.
- Скопируйте/посмотрите последние ошибки при попытке подключения — они часто прямо указывают причину (например, отказ по NLA, проблемы с сертификатом, отказ службы).

4) Network Level Authentication (NLA) и безопасность
- Попробуйте временно отключить NLA:
  - Control Panel -> System -> Remote settings -> снять галочку "Allow connections only from computers running Remote Desktop with Network Level Authentication".
  - или в реестре: HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\UserAuthentication = 0
- Если после отключения NLA подключение появляется — проблема в аутентификации (CredSSP, сертификат, несовместимость клиента).

5) Сервис и зависимости
- Проверьте статус служб:
  - Get-Service TermService
  - Убедитесь, что RPC и Dependents работают (Remote Procedure Call).
- Посмотрите, не падает ли TermService при попытке подключения (Event Viewer).
- Проверьте права на ключи реестра Termsrv и на файлы termsrv.dll (иногда трогают сторонние патчи/RDP Wrapper).

6) Политики и GPO
- gpresult /h gp.html — откройте и посмотрите применённые политики по Remote Desktop/Terminal Services.
- В локальной политике (secpol.msc) — "Allow log on through Remote Desktop Services" — убедиться, что нужные группы/пользователи там есть.
- Поскольку вы упоминали, что административный шаблон «включен» — проверьте точно какие параметры включены (некоторые политики могут ограничивать IP, шифрование, протоколы и т.д.).

7) Сертификаты и SecurityLayer
- В HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp проверьте SecurityLayer и Certificate. При неправильном сертификате или настройке SSL/TLS соединение может отброситься.
- Можно временно поставить SecurityLayer = 0 (RDP) для диагностики.

8) Драйверы сети и профиль сети
- Проверьте, не мешает ли сетевой драйвер (обновите/переустановите), нет ли конфликтов нескольких адаптеров (VPN, виртуальные адаптеры).
- Убедитесь, что сетевой профиль не переведён в «Public» и не применены специфические правила блокировки.

9) Дополнительные тесты
- Попробуйте подключиться с другого компьютера в локальной сети — исключить проблему клиента/инетернета.
- На сервере попробуйте mstsc /v:127.0.0.1 или mstsc /v:<локальный IP> — если не получается локально, проблема на машине, если локально работает — проблема в сети/маршрутизации.
- Включите RDP логирование (в Event Log есть Operational логи для RemoteConnectionManager и LocalSessionManager).

10) Восстановление/сброс RDP конфигурации (осторожно)
- Бэкап реестра, затем:
  - Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name "fDenyTSConnections" -Value 0
  - Перезапустить службу TermService: net stop termservice & net start termservice
- Если подозреваете повреждение конфигурации RDP, можно (после бэкапа) удалить ветку HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp — она должна пересоздаться после перезапуска, но это рискованно — делать с резервной копией реестра.

11) Альтернативы для управляемого доступа
- Включите WinRM/PowerShell Remoting (Enable-PSRemoting) — для удаления логов/перезапуска служб, если RDP недоступен.
- Подключение через TeamViewer/AnyDesk/SSH/админский доступ, если нужно срочно попасть — но это временно.

12) Влияние проблем с блоком питания
- Неполадки блока питания могут приводить к:
  - Повторным некорректным завершениям работы -> повреждению файлов/реестра.
  - Повреждению диска, секторов, контроллера -> проблемы с произвольными компонентами Windows (включая RDP).
  - Аппаратные сбои, приводящие к ошибкам драйверов/компонентов.
Поэтому «просто сбой» вполне возможен, но постоянные "жёсткие" выключения увеличивают риск повреждения системных файлов, настроек или сетевых драйверов. Рекомендация: решить проблему питания (ИБП/новый БП), затем проверить диск (chkdsk /f, SMART), память (memtest) и повторить диагностику RDP.

13) Что предоставить, если хотите помощь дальше
Если хотите, пришлите выводы/файлы:
- Результат netstat -ano | findstr :3389
- Вывод Test-NetConnection -ComputerName <IP> -Port 3389
- reg query по ключам fDenyTSConnections и PortNumber
- Скрин/текст последних ошибок из Event Viewer (TerminalServices-RemoteConnectionManager, LocalSessionManager, System)
- gpresult /h gp.html (или ключевые политики)
С этими данными можно более точно указать причину.

Короткий итог и приоритетные шаги прямо сейчас
1. На сервере: netstat на порт 3389, reg query fDenyTSConnections, проверить TermService, просмотреть соответствующие журналы в Event Viewer.
2. С клиента: Test-NetConnection/Telnet на 3389, попробовать локальный mstsc на самом сервере.
3. Отключить NLA временно для проверки.
4. Если часто были “жёсткие” выключения — сначала устранить БП/ИБП и проверить диск/файловую систему.

Если хотите, могу разобрать конкретные логи/выводы — пришлите результаты команд выше, и я подскажу, где именно копать дальше.
порт слушает, сервис крутится, файрвол выключен — похоже на слетевший RDP-сертификат, особенно после скачков питания. <br/> <br/> В regedit зайди в <pre><code>HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp</code></pre> , удали значение <code>SSLCertificateSHA1Hash</code> и рестарни службу Remote Desktop Services. Windows сам перегенерирует. <br/> <br/> p.s. если не поможет — глянь Event Viewer → Microsoft → Windows → TerminalServices-RemoteConnectionManager → Operational, там будет конкретный код ошибки
Альтернативных файрволлов типа tinywall или не-приведи-Господи випнета нет? брандмауэр нужно "отсоединить" от сети, чтобы красным горел, как службу его не остановить.
ВПН включи... и проверь)
<a href="https://www.comss.ru/page.php?id=20291" rel="nofollow">Microsoft усилила защиту Windows от вредоносных RD...</a> - не проблема с последними обновлениями?
Похожие вопросы