اگر Remote Desktop به Windows Server وصل نمی‌شود، از تغییر تصادفی تنظیمات شروع نکنید. مسیر درست این است که اول دسترسی شبکه و پورت RDP را تست کنید، بعد فعال بودن Remote Desktop و Policyها را بررسی کنید، وضعیت سرویس TermService و Listener را ببینید و در نهایت Firewall، پورت واقعی و Event Logها را بررسی کنید. این ترتیب مشخص می‌کند مشکل در مسیر شبکه است، سرویس RDP بالا نیست، Listener گوش نمی‌دهد یا یک Policy/Firewall اتصال را مسدود کرده است.
این راهنما برای Windows Server 2019، 2022 و 2025 قابل استفاده است و سناریوی رایج آن زمانی است که VPS یا سرور ویندوزی روشن است اما اتصال RDP با Timeout، صفحه سیاه اولیه، پیام عدم دسترسی یا خطاهایی مثل An internal error has occurred برقرار نمی‌شود.
قبل از عیب‌یابی RDP چه چیزی لازم داریم؟
اگر سرور Production است، قبل از هر تغییری یک راه دسترسی خارج از RDP داشته باشید؛ مثلاً Console پنل VPS، KVM، Hyper-V Console یا کنسول ارائه‌دهنده. تغییر اشتباه Registry، Firewall یا پورت RDP می‌تواند همان دسترسی مدیریتی باقی‌مانده را هم قطع کند.
- PowerShell یا Windows Terminal را با دسترسی Administrator اجرا کنید.
- IP واقعی سرور را داشته باشید.
- اگر قبلاً پورت RDP را تغییر داده‌اید، شماره پورت جدید را بدانید.
- در محیط Domain بدانید که Group Policy ممکن است Registry محلی را Override کند.
اگر هنوز خود اتصال RDP را روی ویندوز سرور راه‌اندازی نکرده‌اید، ابتدا راهنمای پیکربندی Remote Desktop در Windows Server را بررسی کنید.
مرحله ۱: از سمت کلاینت پورت RDP را تست کنید
روی یک سیستم ویندوزی خارج از سرور، PowerShell را باز کنید و پورت پیش‌فرض RDP یعنی 3389 را تست کنید:
Test-NetConnection SERVER_IP -Port 3389اگر پورت قابل دسترس باشد، باید در خروجی ببینید:
TcpTestSucceeded : Trueاگر مقدار False است، هنوز نمی‌توان نتیجه گرفت خود سرویس RDP خراب است. این وضعیت می‌تواند از Firewall ویندوز، فایروال دیتاسنتر، Security Group، NAT، پورت اشتباه یا نبودن Listener باشد.
نکته: پاسخ ندادن Ping به‌تنهایی دلیل خرابی شبکه نیست؛ ICMP ممکن است عمداً Block شده باشد. برای RDP، تست TCP روی پورت واقعی مهم‌تر است.
اگر پورت RDP را قبلاً مثلاً به 3390 تغییر داده‌اید:
Test-NetConnection SERVER_IP -Port 3390مرحله ۲: مطمئن شوید Remote Desktop واقعاً فعال است
در Windows Server وضعیت fDenyTSConnections را بخوانید:
Get-ItemProperty 'HKLM:SYSTEMCurrentControlSetControlTerminal Server' -Name fDenyTSConnectionsمقدار 0 یعنی اتصال Remote Desktop مجاز است و مقدار 1 یعنی اتصال Remote Desktop در این سطح غیرفعال شده است.
اگر مقدار 1 است و مطمئن هستید Policy سازمانی آن را مدیریت نمی‌کند، می‌توانید آن را فعال کنید:
Set-ItemProperty -Path 'HKLM:SYSTEMCurrentControlSetControlTerminal Server' -Name fDenyTSConnections -Value 0بعد دوباره مقدار را Readback بگیرید:
Get-ItemProperty 'HKLM:SYSTEMCurrentControlSetControlTerminal Server' -Name fDenyTSConnectionsاگر مقدار بعد از مدتی دوباره به 1 برمی‌گردد، احتمالاً Group Policy آن را اعمال می‌کند. در این حالت Registry را بارها دستکاری نکنید و Policy مؤثر را پیدا کنید:
gpresult /rدر محیط Domain باید GPO مربوط به Remote Desktop را در منبع خودش اصلاح کنید؛ چون تغییر محلی ممکن است در Refresh بعدی Policy بازنویسی شود.
مرحله ۳: وضعیت سرویس‌های RDP را بررسی کنید
سرویس اصلی Remote Desktop Services با نام TermService اجرا می‌شود. وضعیت آن را بررسی کنید:
Get-Service TermService, UmRdpServiceبرای TermService معمولاً باید وضعیت Running ببینید. اگر متوقف است:
Start-Service TermServiceسپس دوباره بررسی کنید:
Get-Service TermServiceاحتیاط: روی سروری که Sessionهای فعال RDP دارد، بی‌دلیل Restart-Service TermService اجرا نکنید. Restart سرویس می‌تواند Sessionهای متصل را قطع کند. اول علت را پیدا کنید و در صورت نیاز تغییر را در Maintenance Window انجام دهید.
مرحله ۴: بررسی کنید RDP Listener وجود دارد
بالا بودن سرویس به‌تنهایی کافی نیست. Windows Server باید Listener مربوط به RDP را هم ساخته باشد. دستور زیر Sessionها و Listenerها را نمایش می‌دهد:
qwinstaدر حالت سالم معمولاً ردیفی برای rdp-tcp می‌بینید که در وضعیت Listen قرار دارد.
برای بررسی Listener TCP روی پورت 3389:
Get-NetTCPConnection -LocalPort 3389 -State Listenاگر این دستور چیزی برنگرداند، با روش کلاسیک هم بررسی کنید:
netstat -ano | findstr :3389وجود خطی با حالت LISTENING نشان می‌دهد یک Process روی این پورت گوش می‌دهد. اگر TermService در حال اجراست اما Listener ندارید، مرحله بعدی یعنی بررسی پورت واقعی و Event Log اهمیت بیشتری پیدا می‌کند.
مرحله ۵: پورت واقعی Remote Desktop را از Registry بخوانید
به حدس 3389 اکتفا نکنید. شماره پورت تنظیم‌شده برای RDP-Tcp را مستقیماً بخوانید:
Get-ItemProperty 'HKLM:SYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp' -Name PortNumber | Select-Object PortNumberمقدار پیش‌فرض 3389 است. اگر عدد دیگری می‌بینید، سه جا باید با همان عدد هماهنگ باشند: Listener سرور، Windows Firewall و تست کلاینت.
اگر عمداً قصد تغییر پورت دارید، راهنمای جداگانه تغییر پورت Remote Desktop را ببینید. تغییر پورت به‌تنهایی جایگزین Firewall و محدودسازی IP نیست.
مرحله ۶: Windows Firewall را بدون خاموش کردن کامل آن عیب‌یابی کنید
یکی از اشتباه‌های رایج این است که برای تست، Firewall ویندوز را کامل خاموش کنیم. این کار روی سرور اینترنتی ریسک امنیتی دارد و معمولاً هم تشخیص را مبهم می‌کند. ابتدا پروفایل‌های فعال را ببینید:
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundActionروی نسخه انگلیسی ویندوز می‌توانید Ruleهای گروه Remote Desktop را این‌طور ببینید:
Get-NetFirewallRule -DisplayGroup 'Remote Desktop' | Select-Object DisplayName, Enabled, Direction, Actionنام DisplayGroup در Windowsهای Localized ممکن است ترجمه شده باشد. در این حالت از Windows Defender Firewall with Advanced Security یا جست‌وجوی Ruleها بر اساس نام و پورت استفاده کنید.
اگر برای تست نیاز به Rule مشخص دارید، بهتر است به‌جای باز کردن RDP برای همه اینترنت، فقط IP مدیریت خودتان را Allow کنید:
New-NetFirewallRule -DisplayName 'OneServer-RDP-3389' -Direction Inbound -Protocol TCP -LocalPort 3389 -RemoteAddress ADMIN_PUBLIC_IP -Action AllowADMIN_PUBLIC_IP را با IP عمومی واقعی خودتان جایگزین کنید. اگر پورت RDP شما تغییر کرده، 3389 را هم با پورت واقعی عوض کنید.
Readback:
Get-NetFirewallRule -DisplayName 'OneServer-RDP-3389' | Select-Object DisplayName, Enabled, Direction, Actionاگر بعداً این Rule آزمایشی لازم نبود، فقط همان Rule را حذف کنید:
Remove-NetFirewallRule -DisplayName 'OneServer-RDP-3389'مرحله ۷: Event Logهای Remote Desktop را بخوانید
وقتی پورت و سرویس درست هستند ولی اتصال هنوز Fail می‌شود، Event Logها معمولاً سرنخ بهتری از تغییر تنظیمات تصادفی می‌دهند. در Event Viewer به این مسیرها سر بزنید:
Applications and Services Logs → Microsoft → Windows → TerminalServices-RemoteConnectionManager → OperationalApplications and Services Logs → Microsoft → Windows → TerminalServices-LocalSessionManager → OperationalWindows Logs → System
برای خواندن چند Event آخر RemoteConnectionManager از PowerShell:
Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational' -MaxEvents 30 |
Select-Object TimeCreated, Id, LevelDisplayName, Messageزمان Event را با زمان تلاش ناموفق برای اتصال تطبیق دهید. خطاهای مرتبط با Certificate، Authentication، Listener یا Service را جداگانه بررسی کنید؛ یک Event قدیمی لزوماً علت مشکل فعلی نیست.
اگر خطای An internal error has occurred می‌گیرید چه کار کنید؟
این پیام علت واحدی ندارد. برای جدا کردن مشکل شبکه از مشکل خود Windows Server، اگر به Console سرور دسترسی دارید یک تست محلی انجام دهید. اگر اتصال محلی هم Fail می‌شود، احتمال مشکل سمت Service، Listener، Policy یا تنظیمات امنیتی خود سرور بیشتر است. اگر تست محلی موفق است ولی اتصال از بیرون Fail می‌شود، مسیر شبکه، Firewall، NAT و فایروال دیتاسنتر را جدی‌تر بررسی کنید.
برای این خطا، غیرفعال کردن NLA، TLS یا تنظیمات امنیتی نباید اولین اقدام باشد. ابتدا شواهد شبکه، Listener و Event Log را جمع کنید؛ بعد فقط تنظیمی را تغییر دهید که با علت پیدا شده مرتبط است.
جدول تشخیص سریع مشکل RDP
| نتیجه تست | احتمال بیشتر | قدم بعدی |
|---|---|---|
Test-NetConnection=False | Firewall، NAT، مسیر شبکه، پورت اشتباه یا نبود Listener | پورت Registry، Listener و Firewall را بررسی کنید |
TermService=Stopped | سرویس RDP اجرا نمی‌شود | Start-Service و سپس Event Log |
| TermService Running ولی Listener ندارید | مشکل RDP-Tcp، پورت یا تنظیمات سرویس | PortNumber، qwinsta و Event Log را بررسی کنید |
| پورت Listen است ولی اتصال بیرونی Fail می‌شود | Firewall یا مسیر بیرونی | Ruleها، Security Group و فایروال دیتاسنتر را چک کنید |
fDenyTSConnections=1 | RDP غیرفعال یا Policy آن را بسته است | gpresult و Policy مؤثر را بررسی کنید |
| Registry بعد از تغییر برمی‌گردد | Group Policy Override | GPO را در منبع اصلی اصلاح کنید |
Verify نهایی بعد از رفع مشکل
بعد از هر اصلاح، فقط به باز شدن یک Session اکتفا نکنید. این Readbackها را انجام دهید:
Get-Service TermService
qwinsta
Get-ItemProperty 'HKLM:SYSTEMCurrentControlSetControlTerminal Server' -Name fDenyTSConnections
Get-ItemProperty 'HKLM:SYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp' -Name PortNumber | Select-Object PortNumberاز یک سیستم خارج از سرور هم دوباره تست کنید:
Test-NetConnection SERVER_IP -Port 3389و در نهایت یک Session جدید RDP بسازید. اگر مشکل از Policy بوده، خروجی gpresult /r را هم ذخیره کنید تا مطمئن شوید Policy مورد انتظار اعمال شده است.
Rollback و Recovery
اگر برای عیب‌یابی تغییری ایجاد کرده‌اید، مسیر برگشت آن را قبل از بستن Console مشخص کنید:
- اگر
fDenyTSConnectionsرا تغییر داده‌اید، مقدار قبلی را ثبت و در صورت نیاز برگردانید. - اگر پورت RDP را عوض کرده‌اید، پورت قبلی را همراه با Ruleهای Firewall هماهنگ برگردانید.
- اگر Rule آزمایشی
OneServer-RDP-3389ساخته‌اید و دیگر لازم نیست، فقط همان Rule را حذف کنید. - در محیط Domain، Rollback باید در GPO اصلی انجام شود؛ نه با جنگیدن با Registry محلی.
- تا پایان Verify، Console اضطراری سرور را باز نگه دارید.
قبل از تغییر مستقیم Registry در سرور مهم، Backup یا Snapshot مناسب داشته باشید. Microsoft نیز برای عیب‌یابی RDP نسبت به تغییر Registry هشدار می‌دهد و توصیه می‌کند قبل از تغییر از آن نسخه پشتیبان داشته باشید.
نکات امنیتی برای RDP روی سرور اینترنتی
- پورت RDP را بدون محدودیت برای کل اینترنت باز نگذارید؛ تا حد امکان Source IP را محدود کنید.
- NLA را بدون دلیل فنی مشخص غیرفعال نکنید.
- تغییر پورت 3389 می‌تواند نویز اسکن‌های ساده را کم کند، اما کنترل امنیتی اصلی محسوب نمی‌شود.
- برای محیط‌های سازمانی از VPN، RD Gateway یا مسیر مدیریت خصوصی استفاده کنید.
- Windows Update، Defender/EDR و سیاست رمز عبور و MFA را در معماری دسترسی مدیریتی جدی بگیرید.
اگر به یک Windows VPS با دسترسی کامل سیستم‌عامل و امکان مدیریت Firewall و RDP نیاز دارید، مشخصات سرور مجازی وان‌سرور را می‌توانید بر اساس RAM، CPU، فضای دیسک و لوکیشن بررسی کنید.
جمع‌بندی
برای رفع مشکل وصل نشدن Remote Desktop به Windows Server، بهترین روش حذف حدس و خطاست: ابتدا از کلاینت TCP Port را تست کنید، بعد فعال بودن RDP و اثر Group Policy را بررسی کنید، TermService و rdp-tcp Listener را Verify کنید، پورت واقعی را از Registry بخوانید و سپس Firewall و Event Logها را بررسی کنید. اگر هر تغییر را با Readback و تست مجدد همراه کنید، دقیقاً می‌فهمید کدام لایه اتصال را قطع کرده و بدون خاموش کردن کورکورانه Firewall یا NLA می‌توانید سرویس RDP را بازیابی کنید.