Произошла внутренняя ошибка RDP: причины и способы решения

При подключении к удалённому компьютеру или серверу через Remote Desktop (RDP) иногда появляется сообщение «Произошла внутренняя ошибка» (An internal error has occurred). При этом RDP-клиент не сообщает никаких дополнительных сведений, по которым можно было бы сразу определить причину проблемы.

Такая ошибка может возникать как на стороне компьютера, с которого выполняется подключение, так и на стороне удалённого сервера. Причиной могут быть проблемы с сетью, DNS, VPN, настройками RDP, NLA и CredSSP, Kerberos-аутентификацией, сертификатами или TLS.

В этой статье подробно разберём основные причины появления внутренней ошибки RDP и последовательно рассмотрим способы её диагностики и устранения в Windows 10, Windows 11 и Windows Server.

Почему возникает ошибка «Произошла внутренняя ошибка» в RDP

Ошибка «Произошла внутренняя ошибка» может возникать по разным причинам, связанным как с настройками RDP/RDS-сервера, так и с компьютером пользователя.

Обычно сообщение появляется после ввода учётных данных в окне mstsc.exe либо сразу после нажатия кнопки Connect (Подключить).

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

Проверка журналов RDP и Schannel

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

Сообщение «Произошла внутренняя ошибка» является общей ошибкой клиента Remote Desktop и обычно не указывает на реальную причину сбоя. Во многих случаях более подробную информацию можно найти в журналах событий Windows.

Откройте Event Viewer (Просмотр событий). Для этого нажмите Win + R и выполните команду:

eventvwr.msc

В первую очередь проверьте следующие журналы:

Applications and Services Logs (Журналы приложений и служб) → Microsoft → Windows:

• TerminalServices-LocalSessionManager
• TerminalServices-RemoteConnectionManager
• RemoteDesktopServices-RdpCoreTS

Дополнительно проверьте системные журналы:

• Windows Logs → System — здесь ищите события источника Schannel;
• Windows Logs → Security — события входа и аутентификации.

Основные события RDP в журнале Windows

Event ID	Источник	Описание
226	RemoteDesktopServices-RdpCoreTS	Проблемы с транспортом RDP или разрывом соединения
142	RemoteDesktopServices-RdpCoreTS	Ошибка чтения TCP-сокета
36871	Schannel	Критическая ошибка при создании SSL/TLS-учётных данных, часто связанная с сертификатом или закрытым ключом
36888	Schannel	Критическое TLS-оповещение, возникшее во время согласования защищённого соединения
4625	Security	Неудачная попытка входа в систему
5379	Security	Использование сохранённых учётных данных Credential Manager
1026	TerminalServices-RemoteConnectionManager	Возможные проблемы с аутентификацией или лицензированием

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

• если появляются ошибки Schannel, в первую очередь следует проверить TLS и сертификаты;
• если регистрируются события RemoteDesktopServices-RdpCoreTS, необходимо проверить работу RDP через UDP, VPN, фрагментацию пакетов и значение MTU;
• если ошибки появляются в журнале Security, проверьте учётные данные пользователя, NLA, Kerberos и синхронизацию времени.

Порядок диагностики внутренней ошибки RDP

Поскольку сообщение «Произошла внутренняя ошибка» может появляться по разным причинам, удобнее последовательно исключать возможные источники проблемы.

Рекомендуемый порядок диагностики:

1. Проверить журналы событий Windows.
2. Проверить доступность TCP-порта 3389.
3. Попробовать подключиться без использования VPN.
4. Отключить использование UDP для RDP.
5. Проверить учётные данные пользователя и NLA.
6. Проверить TLS и сертификаты.
7. Проверить MTU и возможную фрагментацию пакетов.
8. Перезапустить службы Remote Desktop Services.

Устранение внутренней ошибки на стороне RDP-клиента

Если ошибка «Произошла внутренняя ошибка» возникает только на одном компьютере, а с других устройств подключение к тому же RDP-серверу выполняется без проблем, в первую очередь необходимо проверить настройки проблемного клиента.

Очистка DNS-кэша и подключение по IP-адресу

Для начала очистите локальный DNS-кэш компьютера. Запустите командную строку от имени администратора и выполните:

ipconfig /flushdns

Если в окне подключения к удалённому рабочему столу указано имя компьютера или его полное доменное имя FQDN, попробуйте подключиться непосредственно по IP-адресу.

Если подключение по IP-адресу выполняется успешно, а по имени — нет, проверьте разрешение DNS-имени удалённого компьютера:

nslookup yourRDShost

Убедитесь, что команда возвращает правильный IP-адрес RDP-сервера.

Проверка доступности порта RDP 3389 через PowerShell

Далее необходимо убедиться, что стандартный порт RDP — TCP/3389 — доступен на удалённом компьютере и соединение не блокируется межсетевым экраном.

Откройте PowerShell и выполните команду:

Test-NetConnection yourRDShost -Port 3389

Если порт доступен, в результатах проверки будет указано:

TcpTestSucceeded : True

Это означает, что TCP-соединение с удалённым узлом по порту 3389 устанавливается успешно.

Если параметр TcpTestSucceeded имеет значение False, проблема находится на сетевом уровне. Необходимо проверить Windows Defender Firewall или другой межсетевой экран, сетевую доступность удалённого компьютера и наличие прослушивания RDP-порта на сервере.

Отключение и повторное подключение VPN

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

Активные VPN-подключения, созданные штатными средствами Windows, можно отключить с помощью PowerShell:

foreach ($item in Get-VpnConnection | Where-Object { $_.ConnectionStatus -eq "Connected" })
{
    Rasdial $item.Name /disconnect
}

Если используется сторонний VPN-клиент, отключите активное соединение через его интерфейс.

Проверка без VPN позволяет определить, связана ли внутренняя ошибка RDP непосредственно с VPN-туннелем. В частности, причиной могут быть особенности передачи UDP-трафика или фрагментация пакетов внутри туннеля.

Изменение настроек клиента Remote Desktop

Откройте клиент подключения к удалённому рабочему столу:

mstsc.exe

Перейдите на вкладку Experience (Взаимодействие) и убедитесь, что включён параметр Reconnect if the connection is dropped (Переподключаться при разрыве соединения).

Затем перейдите на вкладку Advanced (Дополнительно) и в разделе Server Authentication (Проверка подлинности сервера) временно установите:

If server authentication fails → Connect and don't warn me (Если проверка подлинности сервера завершилась ошибкой → Подключаться без предупреждения).

Удаление сохранённого пароля RDP из Credential Manager

Причиной ошибки также могут быть ранее сохранённые учётные данные RDP. В этом случае удалите их из Credential Manager (Диспетчер учётных данных) и выполните подключение повторно.

Откройте Control Panel (Панель управления) → Credential Manager (Диспетчер учётных данных) → Windows Credentials (Учётные данные Windows).

Также окно управления сохранёнными учётными данными можно открыть командой:

rundll32.exe keymgr.dll,KRShowKeyMgr

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

TERMSRV\your_rdp_host_name

или:

TERMSRV\your_rdp_IP_address

Удалите соответствующую запись, после чего снова запустите RDP-подключение и введите имя пользователя и пароль вручную.

Очистка кэша RDP с помощью BAT-файла

Если предыдущие способы не помогли, можно очистить пользовательские параметры и кэш клиента Remote Desktop.

Для этого создайте BAT-файл со следующим содержимым:

@echo off
reg delete "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default" /va /f
reg delete "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers" /f
reg add "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers"
attrib -s -h "%userprofile%\documents\Default.rdp"
del /f /q "%userprofile%\documents\Default.rdp"
del /f /s /q /a "%userprofile%\AppData\Local\Microsoft\Terminal Server Client\Cache"

Сохраните файл, например, под именем reset_mstsc_cache.bat и запустите его.

Скрипт удаляет историю RDP-подключений из реестра, сохранённые параметры удалённых серверов, файл Default.rdp и графический кэш клиента Remote Desktop. Сохранённые пароли из Credential Manager он не удаляет — их мы удаляли отдельно выше.

После очистки кэша снова запустите mstsc.exe, заново укажите адрес удалённого компьютера и проверьте подключение.

Если внутренняя ошибка RDP продолжает возникать, необходимо переходить к диагностике настроек на стороне удалённого компьютера или RDS-сервера.

Проверка настроек удалённого RDP-сервера

Если ошибка «Произошла внутренняя ошибка» возникает при подключении с разных компьютеров, скорее всего, причину следует искать на стороне удалённого RDP/RDS-сервера.

Самый простой способ проверить это — перезагрузить удалённый сервер. Однако в рабочей среде выполнить перезагрузку сразу возможно далеко не всегда.

В таком случае попробуйте перезапустить службу Remote Desktop Services (Службы удалённых рабочих столов):

net stop termservice
net start termservice

Также перезапустить службу можно через графическую оснастку:

services.msc

Найдите Remote Desktop Services (Службы удалённых рабочих столов) и выполните её перезапуск.

Настройка параметров RDP с помощью групповых политик

Некоторые параметры RDP можно изменить через Local Group Policy Editor (Редактор локальной групповой политики):

gpedit.msc

В доменной среде соответствующие параметры также можно настроить централизованно через Group Policy Management Console (Консоль управления групповыми политиками):

gpmc.msc

1. Отключение UDP для RDP-подключений на сервере

Откройте:

Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Connections.

Откройте политику Select RDP transport protocols, установите Enabled и выберите Use only TCP.

2. Отключение UDP на стороне RDP-клиента

Откройте:

Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Connection Client.

Откройте политику Turn Off UDP On Client (Отключить UDP на клиенте) и установите Enabled (Включено).

Если после отключения UDP внутренняя ошибка исчезла, это хороший признак того, что проблема связана с передачей UDP-трафика. В таком случае дополнительно проверьте VPN, MTU и возможную фрагментацию пакетов.

3. Проверка режима FIPS

Политика находится по пути:

Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options.

Найдите System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing.

4. Отключение режима H.264/AVC 444

Перейдите:

Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Remote Session Environment.

Найдите политику Prioritize H.264/AVC 444 Graphics mode for Remote Desktop Connections и установите Disabled (Отключено).

5. Временное переключение на RDP Security Layer

Откройте:

Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Security.

Откройте политику Require use of specific security layer for remote (RDP) connections.

Установите Enabled и выберите Security Layer: RDP Security Layer.

После изменения групповых политик выполните:

gpupdate /force

Проверка Network Level Authentication (NLA)

Для повышения безопасности RDP используется Network Level Authentication (Проверка подлинности на уровне сети, NLA).

Однако в отдельных случаях NLA может препятствовать подключению устаревших или несовместимых RDP-клиентов. Для диагностики можно временно отключить NLA и проверить соединение.

Снимите флажок Allow connections only from computers running Remote Desktop with Network Level Authentication.

Проверка настроек CredSSP

Credential Security Support Provider (CredSSP) используется при RDP-подключениях для безопасной передачи учётных данных пользователя удалённому компьютеру и тесно связан с NLA.

Откройте Local Group Policy Editor:

gpedit.msc

Перейдите:

Computer Configuration → Administrative Templates → System → Credentials Delegation.

Откройте политику Encryption Oracle Remediation (Исправление уязвимости шифрующего оракула).

Исключительно для диагностики можно временно установить Enabled → Protection Level: Vulnerable.

gpupdate /force

Для диагностического теста тот же параметр можно задать через реестр:

REG ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters" /v AllowEncryptionOracle /t REG_DWORD /d 2 /f

Проверка Kerberos-аутентификации и проблем с SPN

Если внутренняя ошибка RDP возникает ещё на этапе NLA, причиной может быть проблема с Kerberos-аутентификацией.

Для корректной работы Kerberos необходимо, чтобы DNS правильно разрешал имя удалённого компьютера, время на клиенте, сервере и контроллерах домена было синхронизировано, а необходимые Service Principal Name (SPN) были корректно зарегистрированы в Active Directory.

Шаг 0. Проверяем, используется Kerberos или NTLM

На RDP-сервере откройте Event Viewer → Windows Logs → Security и найдите событие успешного входа Event ID 4624.

В поле Authentication Package проверьте, указан ли Kerberos или NTLM.

Дополнительно на клиенте можно посмотреть Kerberos-билеты:

klist

При необходимости очистите Kerberos-кэш:

klist purge

Шаг 1. Проверяем зависимость ошибки от имени сервера

Попробуйте подключиться по короткому имени, FQDN и IP-адресу.

server01
server01.contoso.com
192.168.1.10

Проверьте разрешение имени:

nslookup server01.contoso.com

или:

Resolve-DnsName server01.contoso.com

Шаг 2. Проверяем синхронизацию времени

Проверьте состояние службы времени Windows:

w32tm /query /status

Источник времени:

w32tm /query /source

При необходимости выполните:

w32tm /resync

Шаг 3. Проверяем регистрацию SPN

Для RDP используются SPN с классом службы TERMSRV.

TERMSRV/server01
TERMSRV/server01.contoso.com

Проверить зарегистрированные SPN можно командой:

setspn -L server01

Для точного поиска:

setspn -Q TERMSRV/server01
setspn -Q TERMSRV/server01.contoso.com

Для поиска дубликатов:

setspn -X

Если SPN действительно отсутствует и вы уверены, что он должен принадлежать именно этому объекту компьютера, используйте параметр -S:

setspn -S TERMSRV/server01 server01
setspn -S TERMSRV/server01.contoso.com server01

Шаг 4. Проверяем DNS-псевдонимы CNAME

Если пользователи подключаются к серверу через DNS-псевдоним, проверьте его:

nslookup rdp.contoso.com

Проверьте SPN:

setspn -Q TERMSRV/rdp.contoso.com

Если архитектура действительно требует этого, SPN псевдонима регистрируется на объекте, который обслуживает соответствующее имя:

setspn -S TERMSRV/rdp.contoso.com server01

Шаг 5. Проверяем ограничения Kerberos и NTLM

Откройте Local Security Policy (Локальная политика безопасности):

secpol.msc

Перейдите в Local Policies → Security Options и проверьте политики ограничения NTLM.

Для проверки применённых политик:

gpresult /h C:\Temp\gpresult.html

или:

gpresult /r

Шаг 6. Проверяем журналы событий Kerberos

Обратите внимание на события:

• 4624 — успешный вход;
• 4625 — неудачный вход;
• 4768 — запрос Kerberos TGT;
• 4769 — запрос сервисного билета Kerberos;
• 4771 — ошибка предварительной аутентификации Kerberos;
• 4776 — проверка учётных данных через NTLM.

Шаг 7. Сопоставляем результаты диагностики

Не следует делать вывод только по одному событию или тесту. Наиболее точный результат даёт сопоставление нескольких признаков.

Если RDP работает по IP, но не работает по FQDN, TCP/3389 доступен, а Kerberos-билет TERMSRV отсутствует — проблема, скорее всего, связана с Kerberos, DNS или SPN.

Если ошибка возникает через VPN, в журнале появляются события RDP-транспорта, а после отключения UDP соединение начинает работать — вероятнее проблема сетевого транспорта, MTU или фрагментации пакетов.

Проверка сетевых настроек RDP-сервера

Если используется NIC Teaming и проблема появилась именно на такой конфигурации, одним из диагностических тестов может быть проверка влияния Receive Side Scaling (RSS).

Откройте:

devmgmt.msc

Найдите используемый сетевой адаптер или Microsoft Network Adapter Multiplexor Driver, если он присутствует в вашей конфигурации, откройте вкладку Advanced и проверьте параметр Receive Side Scaling.

Также в отдельных сценариях с большим количеством одновременных подключений может использоваться параметр MaxOutstandingConnections:

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server" -Name MaxOutstandingConnections -Value 10000 -PropertyType DWORD -Force

Если проблема возникает через VPN или другой туннель, проверьте MTU:

netsh interface ipv4 show subinterfaces

Для стандартного MTU 1500 можно начать проверку прохождения IPv4-пакета без фрагментации так:

ping yourRDShost -f -l 1472

Если пакет не проходит без фрагментации, постепенно уменьшайте размер:

ping yourRDShost -f -l 1460
ping yourRDShost -f -l 1400
ping yourRDShost -f -l 1372

После определения подходящего значения MTU его при необходимости можно изменить для нужного интерфейса:

netsh interface ipv4 set subinterface "Ethernet" mtu=1400 store=persistent

Проверка сертификатов RDS

Внутренняя ошибка RDP также может быть связана с сертификатами. Проверьте срок действия используемого сертификата, наличие закрытого ключа и его корректность.

Пересоздание сертификата RDP

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

certlm.msc

Перейдите в Remote Desktop (Удалённый рабочий стол) → Certificates (Сертификаты).

Найдите самоподписанный сертификат RDP.

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

net stop termservice
net start termservice

После запуска службы Windows должна создать новый самоподписанный сертификат для RDP.

RDP и шифрование TLS

Ещё одной причиной ошибки «Произошла внутренняя ошибка» могут быть настройки TLS.

Особенно это актуально для устаревших RDS-инфраструктур с RD Connection Broker и Windows Internal Database (WID).

В некоторых старых конфигурациях отключение TLS 1.0 может приводить к проблемам компонентов RDS. Поэтому временное включение TLS 1.0 можно использовать как диагностический тест только для такой устаревшей инфраструктуры.

reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v Enabled /t REG_DWORD /d 1 /f

Часто задаваемые вопросы

Почему Remote Desktop показывает ошибку «Произошла внутренняя ошибка»?

Это общее сообщение RDP-клиента. Причиной могут быть проблемы с сетью, DNS, VPN, UDP, NLA, CredSSP, Kerberos, SPN, сертификатами или TLS. Поэтому искать решение лучше последовательно, начиная с журналов событий и сетевой доступности.

Как исправить внутреннюю ошибку RDP в Windows 10 или Windows 11?

Сначала проверьте журналы событий, очистите DNS-кэш, попробуйте подключиться по IP-адресу, проверьте TCP/3389 и удалите сохранённые учётные данные RDP. Если это не помогает, переходите к проверке UDP, VPN, NLA, CredSSP, Kerberos и TLS.

Может ли VPN вызывать ошибку «Произошла внутренняя ошибка»?

Да. Через VPN проблема может быть связана с передачей UDP-трафика, MTU или фрагментацией пакетов. Если без VPN RDP работает, а через туннель — нет, проверяйте именно сетевой тракт.

Помогает ли отключение UDP для RDP?

Иногда да. Если после принудительного перехода RDP на TCP ошибка исчезает, это важный диагностический признак. В таком случае стоит искать причину в VPN, сетевом оборудовании, MTU, фрагментации или прохождении UDP-трафика, а не обязательно оставлять UDP отключённым навсегда.

Может ли NLA вызывать внутреннюю ошибку RDP?

Да. Если после временного отключения NLA соединение начинает работать, проверьте CredSSP, Kerberos, NTLM, DNS, SPN и учётные данные. Оставлять NLA отключённым постоянно не рекомендуется.

Что делать, если RDP работает по IP, но не работает по имени сервера?

Проверьте DNS-разрешение имени, FQDN, Kerberos и регистрацию SPN TERMSRV. Успешное подключение по IP помогает локализовать проблему, но само по себе не подтверждает корректную работу Kerberos.

Какую роль TLS играет в RDP-подключениях?

TLS используется для защиты соединения и проверки подлинности сервера. Ошибки могут быть связаны с сертификатом, закрытым ключом, настройками Schannel или несовместимой конфигурацией протоколов TLS.

Как пересоздать сертификат RDP в Windows Server?

Если используется стандартный самоподписанный сертификат RDP, откройте certlm.msc, перейдите в Remote Desktop → Certificates, удалите проблемный самоподписанный сертификат и перезапустите TermService. Не используйте этот способ вслепую, если сервер работает с корпоративным или публичным сертификатом.

Что означает Event ID 5379?

Событие 5379 связано с обращением Windows к сохранённым учётным данным в Credential Manager. Само по себе оно не означает ошибку RDP, но может быть полезно при диагностике сохранённых учётных данных TERMSRV.

Заключение

Ошибка «Произошла внутренняя ошибка» при подключении по RDP неприятна прежде всего тем, что её сообщение практически ничего не говорит о реальной причине проблемы. За одной и той же ошибкой могут скрываться совершенно разные неисправности — от неправильного DNS-разрешения или недоступного TCP-порта 3389 до проблем с UDP, VPN, Kerberos, SPN, NLA, CredSSP, сертификатами и TLS.

Поэтому не стоит начинать диагностику с отключения механизмов безопасности или случайного изменения групповых политик. Сначала проверьте журналы RemoteDesktopServices-RdpCoreTS, Schannel и Security, доступность TCP/3389 и сетевое подключение.

Если RDP работает по IP-адресу, но не работает по имени — проверьте DNS, Kerberos и SPN. Если проблема возникает только через VPN или исчезает после отключения UDP — проверьте MTU и фрагментацию пакетов. Если подключение появляется после отключения NLA — переходите к диагностике CredSSP и Kerberos. А события Schannel и успешное подключение после временного переключения на RDP Security Layer указывают на необходимость проверки TLS и сертификата RDP.

Главное — рассматривать «Произошла внутренняя ошибка» не как конкретную неисправность, а как общий симптом. Последовательная диагностика от сетевого уровня к аутентификации и шифрованию позволяет найти настоящую причину проблемы, не снижая безопасность RDP-сервера постоянным отключением NLA, TLS или других защитных механизмов.

Вам понравилась эта статья? Тогда вам, скорее всего, будет интересна другая полезная статья Как настроить источник времени NTP на контроллере домена.