خطای Connection Refused زمانی رخ می‌دهد که سیستم شما برای برقراری ارتباط با یک سرور تلاش می‌کند، اما اتصال در مقصد پذیرفته نمی‌شود. برای مثال، ممکن است هنگام اتصال با SSH به سرور لینوکس، باز کردن یک وب‌سایت یا ارسال درخواست به یک برنامه تحت وب با این خطا مواجه شوید.
این پیام معمولاً نشان می‌دهد که مقصد اتصال در دسترس شبکه قرار دارد، اما سرویس موردنظر روی پورت مشخص‌شده اتصال را نمی‌پذیرد. البته در برخی شرایط، فایروال یا تجهیزات شبکه نیز می‌توانند باعث ایجاد چنین وضعیتی شوند.
برای رفع خطای Connection Refused در سرور مجازی، باید مشخص کنید مشکل از کدام بخش است: سرویس اجرا نشده، پورت اشتباه است، فایروال اتصال را مسدود کرده یا تنظیمات برنامه به‌درستی انجام نشده‌اند.
اگر از سرور مجازی برای اجرای وب‌سایت، برنامه یا سرویس شبکه استفاده می‌کنید، آشنایی با این مراحل به شما کمک می‌کند بدون تغییرات غیرضروری، علت مشکل را پیدا کنید. در ادامه، روش‌های عیب‌یابی را از ساده‌ترین بررسی‌ها تا مراحل تخصصی‌تر توضیح می‌دهیم.
تفاوت Connection Refused با خطاهای رایج اتصال
پیش از شروع عیب‌یابی، بهتر است این خطا را از پیام‌های مشابه تشخیص دهید؛ زیرا هرکدام می‌توانند به علت متفاوتی ایجاد شوند.
- Connection Refusedاتصال به مقصد رد شده است؛ معمولاً سرویس روی پورت موردنظر فعال نیست یا اتصال توسط یک سیاست شبکه رد می‌شود.
- Connection Timed Outدر مدت مشخصی پاسخی دریافت نشده است. فایروال، مشکل مسیریابی یا در دسترس نبودن سرور از علت‌های احتمالی هستند.
- Network is Unreachableسیستم نمی‌تواند از مسیر شبکه موجود به مقصد دسترسی پیدا کند.
- Connection Resetاتصال برقرار شده یا در حال برقراری بوده، اما از سمت مقابل یا یکی از تجهیزات مسیر به‌صورت ناگهانی قطع شده است.
این تفاوت‌ها قطعی نیستند و به نحوه پیاده‌سازی شبکه و برنامه بستگی دارند؛ بااین‌حال، سرنخ مناسبی برای انتخاب روش عیب‌یابی فراهم می‌کنند.
دلایل بروز خطای Connection Refused
اجرا نبودن سرویس مقصد
یکی از رایج‌ترین علت‌ها، متوقف بودن برنامه‌ای است که قرار است اتصال را دریافت کند. برای مثال، اگر سرویس وب‌سرور Nginx متوقف شده باشد، درخواست به پورت ۸۰ یا ۴۴۳ ممکن است با خطای Connection Refused روبه‌رو شود.
این مشکل ممکن است بعد از راه‌اندازی مجدد سرور، خطای برنامه، تغییر تنظیمات یا توقف غیرمنتظره سرویس اتفاق بیفتد.
بسته بودن پورت موردنظر
هر سرویس شبکه معمولاً از یک پورت مشخص برای دریافت اتصال استفاده می‌کند. برای نمونه، SSH اغلب از پورت ۲۲ و وب‌سرورها از پورت‌های ۸۰ و ۴۴۳ استفاده می‌کنند.
اگر برنامه روی پورت دیگری اجرا شود، اما شما به پورت اشتباه متصل شوید، اتصال برقرار نخواهد شد. همچنین ممکن است سرویس فقط روی آدرس داخلی یا رابط شبکه خاصی گوش دهد و از طریق IP عمومی قابل دسترسی نباشد.
مسدود شدن اتصال توسط فایروال
فایروال می‌تواند دسترسی به پورت‌های مشخص را محدود کند. این محدودیت ممکن است در فایروال سیستم‌عامل، پنل مدیریت سرور یا زیرساخت شبکه ارائه‌دهنده اعمال شده باشد.
بسته به نوع و تنظیمات فایروال، اتصال مسدودشده ممکن است با خطای رد شدن اتصال یا پایان مهلت انتظار مواجه شود.
اشتباه بودن آدرس یا شماره پورت
اگر آدرس IP مقصد اشتباه باشد یا شماره پورتی را وارد کنید که سرویس روی آن فعال نیست، اتصال به مقصد موردنظر انجام نمی‌شود. این مسئله به‌خصوص هنگام استفاده از چند سرور، تغییر IP یا تغییر پورت SSH رخ می‌دهد.
مشکلات تنظیمات SSH و سرویس‌های شبکه
اگر فقط اتصال SSH برقرار نمی‌شود، ممکن است سرویس SSH متوقف شده باشد، پورت آن تغییر کرده باشد یا تنظیمات شبکه مانع دسترسی به آن شوند.
همچنین در برنامه‌های تحت وب، تنظیم نادرست آدرس اتصال، پروکسی معکوس (Reverse Proxy) یا پیکربندی سرویس اصلی می‌تواند باعث ایجاد این خطا شود.
آموزش رفع خطای Connection Refused در سرور مجازی
در این بخش، مراحل عیب‌یابی را به‌ترتیب بررسی می‌کنیم. دستورهای زیر برای سرورهای لینوکسی هستند و باید از طریق ترمینال اجرا شوند. اگر SSH در دسترس نیست، از کنسول تحت وب یا کنسول مدیریتی ارائه‌دهنده سرور استفاده کنید.
مرحله اول: بررسی دسترسی شبکه به سرور
ابتدا مطمئن شوید آدرس IP مقصد صحیح است. در صورت نیاز، می‌توانید از دستور ping برای بررسی اولیه پاسخ‌گویی شبکه استفاده کنید.
در سیستم خود، ترمینال ویندوز، لینوکس یا macOS را باز کنید و دستور زیر را اجرا کنید:
ping SERVER_IP
به‌جای SERVER_IP، آدرس IP واقعی سرور را قرار دهید.
اگر پاسخ دریافت شود، ارتباط شبکه‌ای اولیه برقرار است؛ اما این نتیجه به‌تنهایی فعال بودن SSH یا سایر پورت‌ها را ثابت نمی‌کند. اگر پاسخی دریافت نشود نیز لزوماً به معنای خاموش بودن سرور نیست، زیرا ممکن است پاسخ‌های ICMP مسدود شده باشند.
برای بررسی مستقیم یک پورت TCP، در صورت نصب بودن ابزار Netcat، از دستور زیر استفاده کنید:
nc -vz SERVER_IP 22
در این مثال، پورت ۲۲ بررسی می‌شود. اگر اتصال موفق باشد، معمولاً پیامی مبنی بر موفقیت اتصال نمایش داده می‌شود. اگر اتصال رد شود، باید وضعیت سرویس SSH و تنظیمات پورت را بررسی کنید. برای سرویس‌های دیگر، شماره پورت را متناسب با نیاز تغییر دهید.
مرحله دوم: بررسی وضعیت سرویس مقصد
اگر به کنسول سرور دسترسی دارید، وضعیت سرویس را بررسی کنید. برای نمونه، اگر اتصال SSH برقرار نمی‌شود، دستور زیر را اجرا کنید:
sudo systemctl status ssh
در برخی توزیع‌های لینوکس، نام سرویس sshd است؛ در این صورت از دستور زیر استفاده کنید:
sudo systemctl status sshd
اگر سرویس فعال باشد، معمولاً وضعیت active (running) نمایش داده می‌شود. وضعیت inactive یا failed نشان می‌دهد که سرویس در حال اجرا نیست یا با خطا مواجه شده است.
در صورت تأیید توقف سرویس، می‌توانید آن را اجرا کنید. برای سرویس SSH در اوبونتو و دبیان:
sudo systemctl start ssh
و برای سیستم‌هایی که نام سرویس آن‌ها sshd است:
sudo systemctl start sshd
پس از اجرا، وضعیت سرویس را دوباره بررسی کنید. اگر سرویس بلافاصله متوقف شد، به‌جای تکرار دستور، گزارش خطاها را بررسی کنید. اجرای دستور start نیز مستلزم نصب بودن سرویس مربوطه است.
مرحله سوم: بررسی پورت‌های در حال شنود
ممکن است سرویس فعال باشد، اما روی پورتی که شما به آن متصل می‌شوید گوش ندهد. برای بررسی پورت‌های TCP در حال شنود، دستور زیر را اجرا کنید:
sudo ss -lntp
این دستور پورت‌های TCP در وضعیت شنود و در صورت دسترسی، نام پردازش مربوط به آن‌ها را نمایش می‌دهد.
در خروجی، ستون Local Address:Port را بررسی کنید. برای مثال، اگر SSH روی پورت ۲۲ فعال باشد، باید ورودی مربوط به آن را مشاهده کنید.
همچنین به آدرس اتصال توجه کنید:
- 127.0.0.1:PORT یعنی سرویس فقط روی رابط محلی IPv4 گوش می‌دهد.
- 0.0.0.0:PORT یعنی سرویس روی تمام رابط‌های IPv4 گوش می‌دهد.
- [::]:PORT معمولاً نشان‌دهنده گوش دادن روی رابط‌های IPv6 است؛ رفتار آن برای IPv4 به تنظیمات سیستم بستگی دارد.
اگر سرویس فقط روی 127.0.0.1 گوش می‌دهد، اتصال از طریق IP عمومی معمولاً به آن نمی‌رسد. در چنین شرایطی، تنظیمات آدرس اتصال برنامه را بررسی کنید و از تغییر آن به‌صورت عمومی، بدون در نظر گرفتن ملاحظات امنیتی، خودداری کنید.
مرحله چهارم: بررسی و تنظیم فایروال
اگر سرویس فعال است و پورت صحیحی دارد، قوانین فایروال را بررسی کنید. در اوبونتو و توزیع‌های مبتنی بر دبیان، اگر UFW نصب و فعال باشد، می‌توانید وضعیت آن را با دستور زیر ببینید:
sudo ufw status verbose
این خروجی نشان می‌دهد UFW فعال است یا خیر و چه قوانینی برای ترافیک ورودی و خروجی تعریف شده‌اند.
اگر پورت SSH شما ۲۲ است و دسترسی به آن مجاز نیست، می‌توانید در شرایط مناسب، قانون زیر را اضافه کنید:
sudo ufw allow 22/tcp
این دستور اجازه اتصال TCP ورودی به پورت ۲۲ را در UFW صادر می‌کند. اگر SSH روی پورت دیگری تنظیم شده است، باید شماره پورت واقعی را جایگزین کنید.
نکته امنیتی: قبل از تغییر فایروال، مطمئن شوید قانون جدید با سیاست امنیتی سرور سازگار است. اگر SSH از قبل روی پورت دیگری فعال است، بی‌دلیل پورت ۲۲ را باز نکنید. برای محدود کردن دسترسی مدیریتی، در صورت امکان فقط IPهای مورداعتماد را مجاز کنید.
در سیستم‌هایی که از Firewalld استفاده می‌کنند، ابتدا وضعیت فایروال را بررسی کنید:
sudo firewall-cmd --state
اگر Firewalld فعال باشد، می‌توانید قوانین منطقه (Zone) مورد استفاده را بررسی کنید:
sudo firewall-cmd --list-all
اگر لازم است پورت مشخصی را باز کنید، ابتدا منطقه فعال و سیاست امنیتی سرور را بررسی کنید. باز کردن پورت در یک فایروال به معنای مجاز شدن آن در تمام لایه‌های شبکه نیست؛ ممکن است در پنل ارائه‌دهنده یا فایروال دیگری نیز محدودیت وجود داشته باشد.
مرحله پنجم: رفع مشکل اتصال SSH
اگر خطای Connection Refused هنگام اتصال SSH رخ می‌دهد، ابتدا مطمئن شوید نام کاربری، IP و شماره پورت را درست وارد کرده‌اید. برای اتصال به پورت پیش‌فرض، دستور زیر را اجرا کنید:
ssh username@SERVER_IP
به‌جای username نام کاربری معتبر و به‌جای SERVER_IP آدرس سرور را قرار دهید.
اگر SSH روی پورت دیگری تنظیم شده است، از گزینه -p استفاده کنید:
ssh -p 2222 username@SERVER_IP
در این مثال، اتصال از طریق پورت ۲۲۲۲ انجام می‌شود. این شماره صرفاً نمونه است و باید با پورت واقعی سرور جایگزین شود.
برای دریافت جزئیات بیشتر درباره فرایند اتصال نیز می‌توانید از حالت اشکال‌زدایی استفاده کنید:
ssh -vvv username@SERVER_IP
خروجی این دستور اطلاعات بیشتری درباره مراحل برقراری اتصال ارائه می‌کند. اگر پیام Connection refused پیش از برقراری ارتباط SSH نمایش داده شود، معمولاً باید سرویس، پورت و فایروال را بررسی کنید؛ تغییر کلید SSH یا رمز عبور معمولاً مشکل رد شدن اتصال در سطح TCP را حل نمی‌کند.
مرحله ششم: بررسی تنظیمات سرویس و گزارش خطاها
اگر سرویس اجرا نمی‌شود یا پس از راه‌اندازی دوباره متوقف می‌شود، گزارش‌های سیستم می‌توانند علت را مشخص کنند.
برای بررسی گزارش سرویس SSH در سیستم‌هایی که از نام ssh استفاده می‌کنند، دستور زیر را اجرا کنید:
sudo journalctl -u ssh -n 50 --no-pager
اگر نام سرویس sshd است، دستور را متناسب با آن تغییر دهید:
اگر سرویس اجرا نمی‌شود یا پس از راه‌اندازی دوباره متوقف می‌شود، گزارش‌های سیستم می‌توانند علت را مشخص کنند.
برای بررسی گزارش سرویس SSH در سیستم‌هایی که از نام ssh استفاده می‌کنند، دستور زیر را اجرا کنید:
sudo journalctl -u sshd -n 50 --no-pager
این دستور ۵۰ خط آخر گزارش سرویس را نمایش می‌دهد. پیام‌هایی درباره خطای تنظیمات، اشغال بودن پورت یا مشکل راه‌اندازی می‌توانند سرنخ مهمی باشند.
اگر مشکل مربوط به Nginx است، وضعیت سرویس و گزارش‌های آن را بررسی کنید:
sudo systemctl status nginx
sudo journalctl -u nginx -n 50 --no-pager
اگر سرویس فعال است، اما همچنان اتصال برقرار نمی‌شود، تنظیمات برنامه، آدرس IP مورد استفاده برای شنود، پورت مقصد و ارتباط میان وب‌سرور و برنامه اصلی را بررسی کنید. در صورت نیاز به تغییر تنظیمات، پیش از اعمال تغییرات نسخه پشتیبان تهیه کنید و فقط پس از اعتبارسنجی تنظیمات، سرویس را مجدداً بارگذاری یا راه‌اندازی کنید.
بدون دیدگاه