رفع خطای SSH Connection Timed Out؛ علت Timeout هنگام اتصال به سرور

بعضی وقتا شده که هنگام متصال شدن به سرور با SSH مدتی منتظر می‌مونیم و در نهایت با خطایی شبیه این مواجه می‌شویم:

ssh: connect to host 203.0.113.10 port 22: Connection timed out

یا در بعضی سیستم‌ها:

ssh: connect to host 203.0.113.10 port 22: Operation timed out

معمولاً ،مشکل هنوز به Password، Username یا SSH Key مربوط نیست.

در این وضعیت SSH Client تلاش کرده به IP و Port مقصد متصل شود، اما در زمان موردانتظار نتوانسته ارتباط لازم را برقرار کند.

رایج‌ترین علت‌ها عبارت‌اند از:

• IP سرور اشتباه است

• Port SSH اشتباه انتخاب شده

• سرور خاموش یا Network Interface آن Down است

• Firewall سرور Packetهای SSH را Drop می‌کند

• Cloud Firewall یا Security Group پورت SSH را بسته است

• Route بین Client و Server مشکل دارد

• ISP یا یک شبکه میانی پورت موردنظر را Filter می‌کند

• Domain به IP اشتباه Resolve می‌شود

• IPv6 یا IPv4 به‌درستی Route نمی‌شود

• SSH فقط روی Address دیگری Listen می‌کند

پس در این خطا بهتر است اول این سؤال را جواب بدیم:

آیا Packetهای من اصلاً به IP و Port صحیح سرور می‌رسند و پاسخی برمی‌گردد؟

خطای SSH Connection timed out دقیقاً یعنی چه؟

برای شروع یک SSH Session، Client ابتدا باید بتواند یک Connection با SSH Server برقرار کند.

به‌صورت ساده:

SSH Client
    │
    ▼
Local Network
    │
    ▼
Internet / Routing
    │
    ▼
Server Firewall
    │
    ▼
TCP Port 22
    │
    ▼
OpenSSH Server
    │
    ▼
Authentication

در خطای:

Connection timed out

این مسیر قبل از Authentication کامل نشده است.

OpenSSH گزینه‌ای به نام ConnectTimeout داره که مدت انتظار برای برقرارشدن اتصال اولیه را کنترل می‌کند؛ این Timeout به مرحله برقراری Connection و Handshake اولیه مربوط است، نه مدت زمانی که بعد از Login در Shell بیکار مانده‌اید. (OpenSSH)

بنابراین تغییر:

authorized_keys

یا ساخت یک SSH Key جدید معمولاً راه‌حل این خطا نیست.

Connection timed out با Connection refused چه تفاوتی دارد؟

این دو خطا را نباید یکسان عیب‌یابی کرد.

Connection refused

معمولاً Connection خیلی سریع Fail می‌شود:

ssh: connect to host SERVER_IP port 22: Connection refused

این وضعیت اغلب نشان می‌دهد:

Server reachable
↓
TCP response received
↓
اما Port اتصال را قبول نمی‌کند

برای مثال:

• sshd خاموش است

• Port اشتباه است

• هیچ Listener روی Port وجود ندارد

• Firewall اتصال را REJECT کرده است

Connection timed out

در Timeout معمولاً Client مدتی منتظر می‌ماند:

Connecting...
...
Connection timed out

این وضعیت بیشتر ما را به سمت:

Firewall DROP
Routing
Server Offline
Wrong IP
Cloud Firewall
Provider Filtering

می‌برد.

خلاصه:

این تفاوت مسیر Troubleshooting را بسیار کوتاه‌تر می‌کند.

قدم اول: IP سرور را دوباره بررسی کنید

قبل از تغییر Firewall یا SSH Configuration، مطمئن شوید واقعاً به Server صحیح وصل می‌شوید.

مثلاً:

ssh root@203.0.113.10

IP را با اطلاعات VPS در پنل ارائه‌دهنده مقایسه کنید.

یک اشتباه کوچک مثل:

203.0.113.10

به‌جای:

203.0.113.100

کافی است تا مدت زیادی دنبال مشکلی بگردید که اصلاً روی Server شما نیست.

اگر با سرور مجازی VPS کار می‌کنید، IP عمومی نمایش‌داده‌شده در پنل سرویس را با IP مورد استفاده در دستور SSH تطبیق دهید.

اگر با Domain وصل می‌شوید، DNS را بررسی کنید

ممکن است به‌جای IP بنویسید:

ssh root@server.example.com

در این حالت ابتدا Domain باید به IP تبدیل شود.

در Windows:

Resolve-DnsName server.example.com

یا:

nslookup server.example.com

در Linux:

dig server.example.com

یا:

getent hosts server.example.com

IP خروجی را با IP واقعی VPS مقایسه کنید.

اگر DNS هنوز به IP قدیمی اشاره کند، SSH ممکن است به Server اشتباهی متصل شود یا Timeout شود.

برای تست، مستقیماً از IP صحیح استفاده کنید:

ssh user@SERVER_IP

اگر با IP اتصال برقرار شد ولی Domain Timeout شد، مشکل احتمالاً در DNS یا انتخاب Address است.

قدم دوم: Port واقعی SSH را بررسی کنید

Port پیش‌فرض SSH:

22

است.

بنابراین:

ssh user@SERVER_IP

معمولاً معادل اتصال به Port 22 است.

اما اگر SSH روی Port دیگری اجرا شود، مثلاً:

2222

باید بنویسید:

ssh -p 2222 user@SERVER_IP

اگر Port را اخیراً تغییر داده‌اید، چهار بخش باید با هم هماهنگ باشند:

SSH Server
Firewall
Cloud Firewall
SSH Client

یعنی اگر Server روی 2222 Listen می‌کند ولی Cloud Firewall فقط 22 را Allow کرده، اتصال جدید ممکن است Timeout شود.

قدم سوم: Port را مستقیماً از Client تست کنید

یکی از بهترین تست‌ها این است که قبل از خود SSH بررسی کنیم TCP Port قابل دسترسی هست یا نه.

Linux و macOS

اگر nc دارید:

nc -vz -w 5 SERVER_IP 22

مثلاً:

nc -vz -w 5 203.0.113.10 22

اگر Port قابل دسترسی باشد، خروجی‌ای شبیه:

Connection to 203.0.113.10 22 port [tcp/ssh] succeeded!

می‌بینید.

اگر Test منتظر بماند و Timeout شود، مشکل در سطح Connection است.

تست Port 22 در Windows

در PowerShell:

Test-NetConnection -ComputerName 203.0.113.10 -Port 22

بخش مهم خروجی:

TcpTestSucceeded

است.

اگر:

TcpTestSucceeded : True

باشد، TCP Port قابل دسترسی است.

اگر:

TcpTestSucceeded : False

باشد، هنوز نباید سراغ Password یا SSH Key بروید.

اول باید Network Path یا Server-side Filtering را بررسی کنید.

خود SSH را با Timeout کوتاه‌تر تست کنید

برای اینکه برای هر Test مدت زیادی منتظر نمانید، می‌توانید موقتاً ConnectTimeout تعیین کنید:

ssh -o ConnectTimeout=10 user@SERVER_IP

یا همراه Port:

ssh -o ConnectTimeout=10 -p 2222 user@SERVER_IP

عدد 10 یعنی Client برای مرحله Connection مدت محدودتری منتظر بماند.

این گزینه مشکل را حل نمی‌کند؛ فقط Troubleshooting را سریع‌تر می‌کند.

مثلاً:

ssh -vvv -o ConnectTimeout=10 user@SERVER_IP

هم Verbose Output می‌دهد و هم Test را بی‌نهایت طولانی نمی‌کند.

OpenSSH نیز -v را برای Debug کردن مشکلات Connection، Authentication و Configuration در نظر گرفته است. (OpenSSH)

قدم چهارم: Ping را تست کنید؛ اما نتیجه را قطعی ندانید

می‌توانید اجرا کنید:

ping SERVER_IP

در Windows:

ping SERVER_IP

اگر Server پاسخ بدهد، حداقل بخشی از مسیر Network برقرار است.

اما اگر Ping جواب ندهد، نمی‌توانیم فوراً نتیجه بگیریم Server Offline است.

بسیاری از Serverها یا Firewallها ICMP Echo را Block می‌کنند.

ممکن است:

Ping ✗
SSH ✓

کاملاً امکان‌پذیر باشد.

بنابراین Ping فقط یک Signal کمکی است.

تست TCP Port اهمیت بیشتری دارد.

قدم پنجم: اتصال را از یک اینترنت دیگر امتحان کنید

این تست بسیار ارزشمند است.

مثلاً اگر روی اینترنت خانه Timeout دارید:

ADSL / Fiber
↓
SSH Timeout

یک بار از:

Mobile Hotspot

یا شبکه دیگری تست کنید.

اگر:

Network A → Timeout
Network B → Works

مشکل احتمالاً سمت Server عمومی نیست.

بیشتر باید مواردی مانند:

• ISP Filtering

• Router Firewall

• Corporate Network Policy

• مسیر Routing خاص

• محدودیت Port

را بررسی کنید.

این تست سریع کمک می‌کند مشخص کنیم مشکل وابسته به Source Network هست یا نه.

قدم ششم: اگر Console دارید، از داخل Server وضعیت شبکه را بررسی کنید

اگر SSH Timeout می‌شود، برای بررسی Server از:

Web Console
VNC
Serial Console
Recovery Console

در صورت ارائه توسط سرویس‌دهنده استفاده کنید.

بعد ابتدا Interfaceها را ببینید:

ip addr

باید Network Interface اصلی را در وضعیت:

UP

ببینید و IP مورد انتظار نیز روی آن وجود داشته باشد.

برای مثال:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP>

Ubuntu برای مشاهده Interfaceها و Addressهای شبکه نیز از ابزار ip استفاده می‌کند. (مستندات شبکه Ubuntu)

Route پیش‌فرض Server را بررسی کنید

اجرا کنید:

ip route

معمولاً باید یک Default Route ببینید:

default via 203.0.113.1 dev eth0

اگر Default Route از بین رفته یا Gateway اشتباه باشد، Server ممکن است Packet ورودی را دریافت کند اما نتواند Reply را از مسیر صحیح برگرداند.

برای مشاهده Route به یک Destination مشخص:

ip route get 1.1.1.1

نیز کاربردی است.

Routing دقیقاً تعیین می‌کند Packetها از چه مسیری به Destination ارسال شوند. مستندات Ubuntu نیز Routing Table و Default Gateway را از اجزای اصلی اتصال شبکه معرفی می‌کند. (Ubuntu)

بعد از تغییر Network Configuration با احتیاط عمل کنید

روی Ubuntu، Network Configuration معمولاً با Netplan مدیریت می‌شود.

فایل‌ها معمولاً در:

/etc/netplan/

قرار دارند.

اما اگر SSH تنها روش دسترسی شماست، تغییر Network Configuration از راه دور بسیار حساس است.

یک اشتباه در:

IP
Gateway
Route
DNS
Interface

ممکن است ارتباط Server را کاملاً قطع کند.

بنابراین برای Troubleshooting اولیه، بدون دلیل وارد تغییر Netplan نشوید.

اول:

ip addr
ip route

و اطلاعات پنل Provider را با وضعیت Server مقایسه کنید.

قدم هفتم: مطمئن شوید SSH Service واقعاً در حال اجراست

Timeout بیشتر ما را سمت Network هدایت می‌کند، اما Service را هم باید Verify کنیم.

در Ubuntu:

sudo systemctl status ssh

در AlmaLinux / Rocky Linux / RHEL معمولاً:

sudo systemctl status sshd

و برای Listener:

sudo ss -tlnp | grep sshd

یا:

sudo ss -tlnp | grep ':22'

اگر Server کاملاً سالم است و SSH روی Port 22 Listen می‌کند، باید چیزی شبیه:

0.0.0.0:22

یا:

[::]:22

مشاهده کنید.

اگر Listener وجود ندارد و Connection فوراً Fail نمی‌شود، احتمال دارد Firewall در مسیر Packet را Drop کند و Timeout واقعی را پنهان کرده باشد.

قدم هشتم: UFW را بررسی کنید

حالا به یکی از محتمل‌ترین علت‌ها می‌رسیم.

وضعیت UFW:

sudo ufw status verbose

اگر SSH روی Port 22 است، Rule مناسب باید وجود داشته باشد.

مثلاً:

sudo ufw allow 22/tcp

یا:

sudo ufw allow OpenSSH

اگر Port شما 2222 است:

sudo ufw allow 2222/tcp

بعد:

sudo ufw status numbered

را بررسی کنید.

Ubuntu در مستندات رسمی Firewall نیز ufw allow 22 و ufw status verbose را برای مدیریت دسترسی به Portها مستند کرده است. (Ubuntu Firewall)

تفاوت DROP و REJECT در این خطا مهم است

Firewall می‌تواند با Packet دو رفتار مهم داشته باشد.

DROP

Packet را بی‌صدا کنار می‌گذارد:

Client
→ SYN
→ Firewall
→ DROP
→ No response

Client منتظر می‌ماند و نهایتاً ممکن است:

Connection timed out

بدهد.

REJECT

Firewall پاسخ رد ارسال می‌کند:

Client
→ SYN
→ Firewall
→ REJECT
→ Response

در چنین حالتی ممکن است Fail سریع‌تری مثل:

Connection refused

ببینید.

مستندات Firewall اوبونتو نیز ACCEPT، DROP و REJECT را به‌عنوان رفتارهای تعیین‌کننده Packet Filtering مطرح می‌کند. (Ubuntu)

این تفاوت دلیل خوبی است که چرا:

Timeout معمولاً ما را بیشتر به سمت Silent Filtering و مشکلات مسیر شبکه می‌برد.

Firewall پنل Cloud را بررسی کنید

یکی از دلایل بسیار رایج SSH Timeout این است که Firewall داخل Linux درست است، ولی Firewall دیگری خارج از VPS وجود دارد.

مثلاً:

Internet
   │
   ▼
Cloud Firewall
   │
   ▼
VPS Firewall
   │
   ▼
SSH

Firewall خارجی ممکن است با نام‌هایی مثل این دیده شود:

Cloud Firewall
Security Group
Network ACL
Inbound Rules
Provider Firewall

بررسی کنید Inbound Rule مناسب برای Port SSH دارید.

برای Port 22:

TCP
Port 22
Source: IP موردنظر یا Range مجاز

اگر فقط IP شرکت خودتان Allow شده اما اکنون از اینترنت دیگری وصل می‌شوید، Timeout طبیعی است.

اگر Firewall را فقط برای IP مشخص باز کرده‌اید

این Configuration از نظر امنیت می‌تواند مفید باشد:

Allow TCP/22
Source: YOUR_PUBLIC_IP

اما Public IP Client ممکن است تغییر کرده باشد.

مثلاً ISP شما دیروز:

198.51.100.20

داشته و امروز:

198.51.100.87

است.

اگر Firewall فقط IP قدیمی را Allow کند، Connection جدید ممکن است Timeout شود.

Public IP فعلی خودتان را بررسی کنید و Rule را با سیاست امنیتی مناسب اصلاح کنید.

nftables یا iptables را هم در نظر بگیرید

ممکن است UFW بگوید:

Status: inactive

اما هنوز Rules دیگری روی سیستم فعال باشند.

برای nftables:

sudo nft list ruleset

و در سیستم‌هایی که از iptables استفاده می‌کنند:

sudo iptables -L -n -v

را می‌توان بررسی کرد.

اما Ruleها را بدون درک Configuration حذف نکنید.

Production Server ممکن است Rules مهم دیگری برای:

• Docker

• NAT

• VPN

• Security

• Routing

داشته باشد.

هدف ابتدا پیدا کردن Rule مشکل‌دار است، نه پاک کردن کل Firewall.

آیا Fail2ban باعث Timeout می‌شود؟

ممکن است.

اگر IP شما توسط Jail مربوط به SSH Block شده باشد:

sudo fail2ban-client status sshd

را بررسی کنید.

اما رفتار نهایی به Firewall Backend و Action تعریف‌شده بستگی دارد.

پس قبل از تمرکز روی Fail2ban، ترتیب زیر را رعایت کنید:

Port
Service
Listener
UFW
Cloud Firewall
Routing
↓
بعد Security Tools

قدم نهم: مسیر Network را بررسی کنید

اگر Server روشن است، Listener صحیح است و Firewallها هم ظاهراً درست‌اند، باید مسیر Network را بررسی کنیم.

در Linux:

traceroute SERVER_IP

در Windows:

tracert SERVER_IP

این ابزارها مسیر تقریبی Packet تا Destination را نمایش می‌دهند.

اما یک هشدار مهم:

توقف traceroute روی یک Hop الزاماً به معنی خرابی همان Router نیست.

بسیاری از Routerها به Packetهای Diagnostic پاسخ نمی‌دهند ولی Traffic واقعی را Forward می‌کنند.

پس Traceroute یک ابزار کمکی است، نه حکم قطعی.

یک Test بهتر: همان Server را از چند Location بررسی کنید

اگر امکان دارید SSH Port را از:

• کامپیوتر خودتان

• Mobile Internet

• Server دیگری

• شبکه شرکت

تست کنید.

مثلاً:

Home → Timeout
Mobile → Timeout
Another VPS → Timeout

احتمال Server-side Problem زیاد می‌شود.

اما:

Home → Timeout
Mobile → Works
Another VPS → Works

بیشتر Source Network یا مسیر خاص خانه را متهم می‌کند.

این تست در Troubleshooting شبکه بسیار ارزشمند است.

اگر فقط Port 22 Timeout می‌شود چه؟

فرض کنیم Server این موارد را دارد:

HTTP 80  → Works
HTTPS 443 → Works
SSH 22    → Timeout

این یک Signal خوب است:

خود Server احتمالاً Online است، اما SSH Port یا Traffic آن مشکل دارد.

در این حالت موارد زیر اولویت بیشتری دارند:

SSH Listener
UFW
Cloud Firewall
Provider filtering
SSH Port

دیگر لازم نیست ابتدا کل Network Interface سرور را متهم کنیم.

اگر تمام Portها Timeout می‌شوند چه؟

اگر:

22   → Timeout
80   → Timeout
443  → Timeout

و Console هم نشان می‌دهد Server مشکل Network دارد، دایره احتمالات عوض می‌شود:

Server Offline
Network Interface
IP Configuration
Route
Gateway
Provider Network
Cloud Firewall

در این شرایط بررسی sshd_config احتمالاً اولویت پایینی دارد.

IPv4 و IPv6 می‌توانند باعث Timeout گیج‌کننده شوند

فرض کنید Domain شما هر دو Record را دارد:

A
AAAA

ممکن است Client ابتدا IPv6 را امتحان کند، اما مسیر IPv6 Server درست نباشد.

برای تست فقط IPv4:

ssh -4 user@server.example.com

برای تست فقط IPv6:

ssh -6 user@server.example.com

اگر:

ssh -4 → Works
ssh -6 → Timeout

مشکل تقریباً مشخص است:

IPv6 Routing
IPv6 Firewall
AAAA Record
ListenAddress

را باید بررسی کنید.

Addressهایی که sshd روی آن‌ها Listen می‌کند را بررسی کنید

روی Server:

sudo ss -tlnp | grep sshd

و:

sudo sshd -T | grep -Ei '^(port|listenaddress|addressfamily)'

را اجرا کنید.

ممکن است SSH فقط روی IPv4 یا یک Address خاص Bind شده باشد.

مثلاً:

127.0.0.1:22

برای Remote Access مناسب نیست.

یا ممکن است فقط:

[::]:22

با Configuration خاص مشاهده شود و Behavior موردانتظار IPv4 وجود نداشته باشد.

Listener واقعی مهم‌تر از حدس از روی فایل Configuration است.

اگر Server پشت NAT باشد چه؟

در VPSهای دارای Public IP معمولاً مستقیم‌تر هستیم، اما در شبکه‌های خصوصی یا Serverهای On-Premise ممکن است SSH Server پشت NAT قرار داشته باشد.

ساختار:

Internet
   │
   ▼
Router / NAT
   │
Port Forward
   │
   ▼
Linux Server

در این حالت باید Router پورت External را به IP و Port داخلی Server Forward کند.

مثلاً:

Public 2222
→
192.168.1.10:22

Client:

ssh -p 2222 user@PUBLIC_IP

اگر Port Forward وجود نداشته باشد یا IP داخلی Server تغییر کرده باشد، اتصال ممکن است Fail یا Timeout شود.

برای یک VPS معمولی با Public IP مستقیم، این بخش معمولاً کاربردی نیست.

آیا تغییر Port SSH مشکل Timeout را حل می‌کند؟

نه، مگر اینکه دلیل واقعی مشکل به همان Port مرتبط باشد.

مثلاً اگر یک Network خاص Port 22 را Filter می‌کند و شما SSH را به‌صورت صحیح و امن روی Port دیگری تنظیم کرده باشید، ممکن است ارتباط برقرار شود.

اما این:

Timeout
→ Port را تصادفی تغییر بده

روش Troubleshooting خوبی نیست.

اول مشخص کنید:

Port واقعی چیست؟
آیا Listener وجود دارد؟
Firewall چه می‌کند؟
آیا Port از شبکه دیگری در دسترس است؟

بعد تصمیم بگیرید.

اگر اتصال فقط گاهی Timeout می‌شود چه؟

این حالت با Timeout دائمی کمی متفاوت است.

اگر مثلاً:

Attempt 1 → Works
Attempt 2 → Timeout
Attempt 3 → Works

دارید، موارد زیر را بررسی کنید:

• Packet Loss

• Network instability

• Load Balancer

• چند IP پشت DNS

• Firewall Rate Limit

• Fail2ban

• مسیرهای مختلف IPv4/IPv6

• Server Load

• Provider Network

اگر Domain چند IP دارد:

dig server.example.com

را بررسی کنید.

ممکن است یکی از Addressها سالم باشد و دیگری مشکل داشته باشد.

Timeout بعد از Login با Connection timed out اولیه فرق دارد

یک نکته مهم:

ممکن است SSH با موفقیت وصل شود ولی بعد از چند دقیقه Session قطع شود.

این موضوع با:

ssh: connect to host ... Connection timed out

در ابتدای Connection یکی نیست.

بعد از برقرارشدن Session، مواردی مانند:

ServerAliveInterval
ServerAliveCountMax
ClientAliveInterval
Network instability
NAT timeout

و استفاده از ابزارهایی مثل tmux اهمیت پیدا می‌کنند.

در این مقاله تمرکز ما روی Timeout هنگام برقراری اتصال اولیه SSH است.

اگر فقط می‌خواهید سریع علت را پیدا کنید، این ترتیب را بروید

روی Client

ابتدا:

ssh -vvv -o ConnectTimeout=10 user@SERVER_IP

سپس Port:

nc -vz -w 5 SERVER_IP 22

یا در Windows:

Test-NetConnection -ComputerName SERVER_IP -Port 22

بعد:

• IP را Verify کنید

• Domain DNS را Verify کنید

• از اینترنت دیگری Test کنید

• در صورت نیاز IPv4 و IPv6 را جدا تست کنید

روی Server از طریق Console

ip addr

سپس:

ip route

و:

sudo systemctl status ssh

بعد:

sudo ss -tlnp | grep sshd

سپس:

sudo ufw status verbose

و در نهایت Cloud Firewall و Provider Rules را بررسی کنید.

جدول تشخیص سریع SSH Timeout

اشتباهات رایج هنگام رفع SSH Timeout

تغییر SSH Key

اگر TCP Connection برقرار نشده، Key هنوز بررسی نشده است.

غیرفعال کردن کامل Firewall

این کار روی Production Server می‌تواند مشکل امنیتی ایجاد کند.

به‌جای:

sudo ufw disable

بهتر است ابتدا:

sudo ufw status numbered

را بررسی کنید و Rule مربوط به SSH را پیدا کنید.

تغییر هم‌زمان چند چیز

مثلاً:

SSH Port
Firewall
DNS
sshd_config
Network Config

را هم‌زمان تغییر ندهید.

در غیر این صورت اگر مشکل حل شود نمی‌دانید علت چه بوده، و اگر بدتر شود تشخیص مشکل سخت‌تر خواهد شد.

فرض اینکه Ping یعنی همه‌چیز

Ping ابزار مفیدی است، اما تست TCP Port برای SSH بسیار مرتبط‌تر است.

Restart کردن Network از راه دور بدون Console

تغییر Netplan یا Restart شبکه روی Server Remote می‌تواند آخرین ارتباط شما را نیز قطع کند.

قبل از تغییرات حساس Network، Console یا Recovery Access داشته باشید.

اگر هیچ Console یا دسترسی دیگری نداریم چه کنیم؟

اگر SSH Timeout می‌شود و تنها روش دسترسی شما SSH بوده، بسیاری از بررسی‌های Server-side را نمی‌توانید اجرا کنید.

در این حالت از پنل Provider دنبال مواردی مثل:

Web Console
VNC Console
Serial Console
Rescue Mode
Recovery

بگردید.

همچنین در پنل بررسی کنید:

• Server روشن است؟

• IP تغییر نکرده؟

• Network Interface متصل است؟

• Firewall خارجی فعال است؟

• Incident شبکه وجود دارد؟

اگر سرویس هیچ روش Recovery در اختیار شما نمی‌گذارد، ممکن است نیاز به بررسی توسط Provider داشته باشید.

جمع‌بندی

خطای:

ssh: connect to host SERVER_IP port 22: Connection timed out

معمولاً یعنی SSH Client در زمان مورد انتظار نتوانسته Connection اولیه را با مقصد برقرار کند.

در این مرحله تمرکز اصلی باید روی:

IP
Port
Network
Routing
Firewall
Cloud Firewall
IPv4 / IPv6
SSH Listener

باشد، نه Password و SSH Key.

برای شروع از Client:

ssh -vvv -o ConnectTimeout=10 user@SERVER_IP

و:

nc -vz -w 5 SERVER_IP 22

را امتحان کنید.

در Windows:

Test-NetConnection -ComputerName SERVER_IP -Port 22

و اگر Port در دسترس نیست، از Console سرور بررسی کنید:

ip addr
ip route
sudo systemctl status ssh
sudo ss -tlnp
sudo ufw status verbose

سپس Cloud Firewall و Route شبکه را بررسی کنید.

ترتیب پیشنهادی ما:

IP / DNS
↓
Port
↓
Client Network
↓
Server Network
↓
SSH Listener
↓
Host Firewall
↓
Cloud Firewall
↓
Routing / Provider

و مهم‌ترین نکته:

Connection timed out را با Connection refused یا Permission denied اشتباه نگیرید؛ هرکدام در مرحله متفاوتی از اتصال SSH رخ می‌دهند و مسیر عیب‌یابی متفاوتی دارند.

سوالات متداول

خطای SSH Connection timed out یعنی چه؟

معمولاً یعنی Client نتوانسته در زمان موردانتظار Connection اولیه را با IP و Port SSH مقصد برقرار کند. Firewall Drop، Routing، IP اشتباه، Server Offline یا Cloud Firewall از علت‌های رایج هستند.

آیا SSH Key اشتباه باعث Connection timed out می‌شود؟

معمولاً خیر. SSH Key بعد از برقرارشدن Connection و آغاز Authentication بررسی می‌شود. Key اشتباه بیشتر خطایی مثل Permission denied (publickey) ایجاد می‌کند.

چطور Port 22 را تست کنیم؟

در Linux/macOS:

nc -vz -w 5 SERVER_IP 22

در Windows:

Test-NetConnection -ComputerName SERVER_IP -Port 22

چرا Ping جواب می‌دهد ولی SSH Timeout می‌شود؟

چون Ping و SSH از Traffic یکسانی استفاده نمی‌کنند. ممکن است ICMP مجاز باشد ولی TCP Port 22 توسط Firewall یا Cloud Firewall Drop شود.

چرا SSH از یک اینترنت کار می‌کند ولی از اینترنت دیگر Timeout می‌شود؟

این حالت می‌تواند نشان‌دهنده محدودیت ISP، Firewall شبکه Client، Route متفاوت یا Rule محدودشده به Source IP باشد.

چرا با IP وصل می‌شوم ولی با Domain نه؟

احتمالاً DNS به IP اشتباه یا Address دیگری مثل IPv6 مشکل‌دار اشاره می‌کند. Recordهای A و AAAA را بررسی کنید.

ConnectTimeout چه کاری انجام می‌دهد؟

مدت انتظار SSH Client برای برقراری Connection و Handshake اولیه را محدود می‌کند. مثلاً:

ssh -o ConnectTimeout=10 user@SERVER_IP

برای Troubleshooting سریع‌تر مفید است، اما علت اصلی Network Timeout را برطرف نمی‌کند.