وقتی در Ubuntu، Debian، AlmaLinux یا یک VPS لینوکسی با خطای Network is unreachable روبه‌رو می‌شوید، نخست مسیر خروجی، آدرس IP و وضعیت کارت شبکه را بررسی کنید. این خطا معمولاً به این معنی است که کرنل برای مقصد موردنظر مسیر قابل استفاده‌ای پیدا نکرده است؛ برخلاف خطای DNS، حتی اتصال مستقیم به یک IP نیز ممکن است شکست بخورد. پیش از تغییر تنظیمات، از کنسول ارائه‌دهنده سرور یا دسترسی بازیابی مطمئن شوید.
برای تشخیص سریع، این دستورات فقط‌خواندنی را اجرا کنید:
ip -br link
ip -br addr
ip -4 route show
ip -4 route get 1.1.1.1
ip -4 rule showاگر دستور چهارم RTNETLINK answers: Network is unreachable برگرداند، بررسی Gateway، Default Route و Policy Routing را ادامه دهید. اگر مسیر نمایش داده شد ولی اتصال برقرار نیست، ممکن است مسئله از Gateway، فایروال، سمت مقابل یا شبکه دیتاسنتر باشد؛ صرف وجود Route به معنای سلامت کامل اتصال نیست.
خطای Network is unreachable در لینوکس دقیقاً یعنی چه؟
در فراخوانی connect()، خطای ENETUNREACH به نبود مسیر شبکه قابل استفاده اشاره می‌کند. در ابزارهایی مانند curl، ping، apt و سرویس‌های برنامه‌نویسی ممکن است عبارت «Network is unreachable» را ببینید. این خطا را با Connection refused (پاسخ منفی از پورت مقصد)، Connection timed out (عدم دریافت پاسخ در زمان مقرر)، No route to host و Could not resolve host (مشکل نام دامنه) یکی ندانید.
در راهنمای رسمی ip-route(8)، مسیرهای ویژه مانند throw و رفتار ip route get توضیح داده شده‌اند. وجود یک Rule یا جدول Routing اختصاصی می‌تواند نتیجه اتصال را با جدول اصلی متفاوت کند.
پیش‌نیاز و سناریوی واقعی VPS
فرض کنید پس از تغییر تنظیمات شبکه یا افزودن IP دوم به سرور، curl https://example.com خطا می‌دهد و اتصال به 1.1.1.1 هم برقرار نمی‌شود. نام کارت شبکه ممکن است ens3، eth0 یا enp1s0 باشد. هیچ دستور اصلاحی را با نام رابط یا Gateway فرضی کپی نکنید. ابتدا IP، Prefix، Gateway اعلام‌شده توسط دیتاسنتر و نوع مدیریت شبکه (Netplan، NetworkManager، systemd-networkd یا ifupdown) را ثبت کنید.
هشدار: تغییر Default Route از طریق SSH می‌تواند دسترسی شما را قطع کند. پیش از هر تغییری از کنسول KVM/VNC یا پنل ریکاوری اطمینان بگیرید و خروجی دستورات زیر را ذخیره کنید:
date -Is
ip -br addr
ip -4 route show table all
ip -4 rule show
ip -6 route show
ls -l /etc/netplan/ 2>/dev/nullاز فایل‌های تنظیمات شبکه نیز بکاپ بگیرید؛ در صورت استفاده از Netplan، پیش از ویرایش یک نسخه از YAML موجود در مسیر امن نگهداری کنید.
مرحله اول: بررسی Link و آدرس IP روی Interface
ip -br link
ip -br -4 addr
ip -br -6 addr
ip link showدر خروجی سالم، رابط اصلی معمولاً UP است و آدرس IPv4/IPv6 متناسب با سرویس دارد. اگر رابط DOWN است، پیش از فعال‌سازی بررسی کنید آیا نام صحیح را انتخاب کرده‌اید، آیا کابل مجازی/اتصال شبکه در پنل فعال است و آیا Network Manager دیگری آن را کنترل می‌کند. ip link set dev IFACE up فقط Link را فعال می‌کند؛ IP و Gateway را خودکار نمی‌سازد. اگر رابط آدرس ندارد، به‌جای حدس زدن IP، فایل کانفیگ و تنظیمات شبکه دیتاسنتر را بررسی کنید.
مرحله دوم: پیدا کردن Default Route و Gateway
ip -4 route show table main
ip -4 route get 1.1.1.1
ip -4 route show table all
ip -4 rule showنمونه خروجی سالم (صرفاً مثال، نه تنظیم واقعی سرور شما):
default via 192.0.2.1 dev ens3
192.0.2.0/24 dev ens3 proto kernel scope link src 192.0.2.10رنج 192.0.2.0/24 برای مستندسازی رزرو شده است. اگر default وجود ندارد، سرور برای مقصدهای خارج از شبکه محلی مسیر عمومی ندارد. اگر Default Route به رابط اشتباه اشاره می‌کند، باید آن را با اطلاعات معتبر ارائه‌دهنده اصلاح کنید. اگر Default Route موجود است، با ip route get بررسی کنید کرنل برای مقصد مشخص کدام dev و src را انتخاب می‌کند.
مرحله سوم: بررسی دسترسی به Gateway بدون دستکاری Route
Gateway واقعی را از خروجی Route یا پنل سرویس پیدا کنید. سپس متناسب با شبکه خود بررسی کنید:
ip neigh show
ping -c 3 1.1.1.1
tracepath 1.1.1.1عدم پاسخ Ping به‌تنهایی خرابی Gateway را ثابت نمی‌کند؛ ICMP ممکن است محدود باشد. اگر Gateway در همان شبکه L2 است، وضعیت Neighbor/ARP می‌تواند سرنخ بدهد. در برخی دیتاسنترها Gateway خارج از Prefix یا مسیر onlink تعریف می‌شود؛ این تنظیم خاص را بدون دستور رسمی ارائه‌دهنده تغییر ندهید. اگر Route درست است اما ترافیک عبور نمی‌کند، وضعیت فایروال و شبکه دیتاسنتر را نیز بررسی کنید.
مرحله چهارم: اصلاح موقت Route فقط پس از تأیید اطلاعات
در صورت اطمینان از Gateway و Interface واقعی و وجود دسترسی کنسول، می‌توان برای تست یک Route موقت ایجاد کرد. در نمونه زیر REAL_GATEWAY و REAL_IFACE را با مقادیر معتبر جایگزین کنید:
sudo ip route replace default via REAL_GATEWAY dev REAL_IFACE
ip -4 route get 1.1.1.1این تغییر معمولاً با ریبوت یا بازسازی تنظیمات شبکه پایدار نمی‌ماند. اگر قبلاً Default Route دیگری وجود داشت، مقدار قبلی را برای Rollback یادداشت کنید. برای چند Gateway، چند IP یا Policy Routing، تغییر Default Route ممکن است مسیر برگشت SSH را خراب کند. هرگز به امید رفع مشکل DNS، Route را بی‌دلیل عوض نکنید.
مرحله پنجم: بررسی Policy Routing و جدول‌های غیر از main
روی سرورهایی که چند IP یا چند کارت شبکه دارند، تنها ip route show کافی نیست. Ruleها می‌توانند ترافیک را به جدول دیگری هدایت کنند:
ip -4 rule show
ip -4 route show table all
ip -4 route get 1.1.1.1
ip -6 rule showدر خروجی به Ruleهای from، fwmark، اولویت و جدول مقصد دقت کنید. اگر جدول انتخاب‌شده Default Route ندارد، ترافیک همان Source IP ممکن است به ENETUNREACH برسد، در حالی که جدول main سالم است. قبل از حذف Rule، دلیل ایجاد آن را مشخص کنید؛ شاید متعلق به نرم‌افزار شبکه، دیتاسنتر یا تنظیم چند IP باشد. دستورها و منطق انتخاب جدول در مستندات ip-rule(8) آمده است.
اگر Route صحیح است اما پاسخ از مسیر دیگری برمی‌گردد، راهنمای مرتبط رفع مشکل rp_filter و Asymmetric Routing در VPS لینوکس را بررسی کنید؛ این مسئله با نبود Route تفاوت دارد.
مرحله ششم: تفکیک مشکل IPv4 از IPv6
گاهی IPv4 سالم است اما برنامه ابتدا IPv6 را امتحان می‌کند و برای IPv6 مسیر پیش‌فرض ندارید. هر دو خانواده آدرس را جدا تست کنید:
ip -4 route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111
curl -4 -I --max-time 10 https://example.com
curl -6 -I --max-time 10 https://example.comاگر فقط curl -6 شکست می‌خورد، به‌جای غیرفعال‌کردن عجولانه IPv6، بررسی کنید آیا ارائه‌دهنده واقعاً IPv6، Prefix و Gateway مناسب داده است. اگر سرور IPv6 ندارد، عدم وجود مسیر IPv6 به‌تنهایی به معنای خرابی IPv4 نیست. DNS می‌تواند آدرس AAAA برگرداند؛ به همین دلیل تست جداگانه مهم است.
مرحله هفتم: پایدارسازی تنظیمات در Ubuntu با Netplan
در Ubuntuهایی که واقعاً با Netplan مدیریت می‌شوند، ابتدا فایل‌های موجود و Renderer را شناسایی کنید. نمونه زیر فقط الگوست و IPها مستندسازی هستند؛ هرگز آن را بدون جایگزینی و تطبیق با کانفیگ فعلی روی VPS اعمال نکنید.
network:
version: 2
ethernets:
ens3:
addresses:
- 192.0.2.10/24
routes:
- to: default
via: 192.0.2.1
nameservers:
addresses:
- 1.1.1.1
- 9.9.9.9اگر آدرس از DHCP می‌آید، به‌جای تحمیل IP ثابت، تنظیم dhcp4 و دریافت Gateway از DHCP را بررسی کنید. روی سرورهای cloud-init، تغییر فایل اشتباه ممکن است پس از ریبوت بازنویسی شود. برای اعتبارسنجی از sudo netplan generate و سپس با دسترسی کنسول از sudo netplan try استفاده کنید؛ این فرمان برای تأیید تغییرات و بازگشت در صورت عدم تأیید طراحی شده است، اما به رفتار نسخه/Renderer توجه کنید. جزئیات ساختار YAML در مستندات Netplan آمده است.
در Debian با /etc/network/interfaces یا توزیع‌های مبتنی بر NetworkManager، Netplan لزوماً ابزار مدیریت شبکه نیست؛ تنظیم پایدار را در همان سیستم مدیریت فعال اعمال کنید. تغییر هم‌زمان چند ابزار مدیریت شبکه می‌تواند باعث تضاد شود.
مرحله هشتم: اگر فقط برنامه یا Docker خطا می‌دهد
اگر ip route get روی میزبان درست است ولی یک کانتینر یا سرویس خاص خطا می‌دهد، Network Namespace، شبکه Docker، تنظیم Network= در systemd یا Policy Routing مختص آن سرویس را بررسی کنید. اجرای تست روی Host لزوماً وضعیت شبکه کانتینر را نشان نمی‌دهد. برای تفاوت خطای Route با خطای کمبود پورت‌های موقت، مقاله رفع خطای Cannot assign requested address و Ephemeral Port Exhaustion را ببینید.
اگر مسیر درست است اما اتصال‌های متعدد به‌صورت پراکنده قطع می‌شوند، عیب‌یابی nf_conntrack: table full نیز می‌تواند به تشخیص کمک کند؛ پر شدن جدول Connection Tracking با نبود Route یکسان نیست.
تست نهایی و خروجی مورد انتظار
پس از اصلاح، ابتدا مسیر و سپس اتصال را تست کنید:
ip -br addr
ip -4 route get 1.1.1.1
ping -c 2 1.1.1.1
curl -4 -I --max-time 10 https://example.com
getent ahostsv4 example.comخروجی مورد انتظار ip route get شامل via (در صورت نیاز)، dev و src معتبر است؛ curl باید پاسخ HTTP یا خطای مشخص لایه بالاتر بدهد، نه Network is unreachable. شکست Ping با موفقیت curl می‌تواند به محدودیت ICMP مربوط باشد. اگر IP کار می‌کند اما نام دامنه نه، مسیر شبکه را دوباره دستکاری نکنید و DNS را جداگانه عیب‌یابی کنید.
Rollback و بازیابی امن اگر SSH قطع شد
اگر تغییر Route باعث قطع ارتباط شد، از کنسول خارج از باند وارد شوید و با مقایسه خروجی ذخیره‌شده، تنظیم قبلی را بازگردانید. برای Route موقت، در صورت داشتن مقدار قبلی می‌توان دستور ip route replace default via OLD_GATEWAY dev OLD_IFACE را با مقادیر واقعی و ثبت‌شده اجرا کرد. اگر Netplan را تغییر داده‌اید، YAML قبلی را برگردانید و با netplan generate و netplan try بررسی کنید. در شبکه‌های دارای چند IP، Ruleها و جدول‌های اختصاصی را نیز بازبینی کنید. از اجرای کورکورانه flush روی Route یا Rule خودداری کنید.
اگر در VPS به کنسول بازیابی نیاز دارید یا قصد دارید شبکه سرور مجازی را از ابتدا اصولی طراحی کنید، جزئیات سرویس‌های سرور مجازی وان‌سرور را متناسب با نیازتان بررسی کنید.
اشتباه‌های رایج هنگام رفع Network is unreachable
- تغییر DNS وقتی اتصال مستقیم به IP هم Route ندارد.
- فرض کردن اینکه نام کارت شبکه همه سرورها
eth0است. - کپی‌کردن Gateway نمونه اینترنتی بدون بررسی Prefix و تنظیمات دیتاسنتر.
- تغییر Default Route روی SSH بدون دسترسی کنسول و مسیر بازگشت.
- نادیده گرفتن
ip ruleو جدول‌های اختصاصی روی سرور چند IP. - یکی گرفتن خطای IPv6 با خرابی کامل IPv4.
- اعمال Netplan روی سروری که با NetworkManager یا ifupdown مدیریت می‌شود.
پرسش‌های رایج
خیر. اغلب ابتدا باید IP، Link، Default Route و Policy Routing سرور بررسی شود؛ خرابی شبکه بالادست فقط یکی از احتمال‌هاست.
اگر ip route get خطای Network is unreachable می‌دهد، مشکل در انتخاب مسیر شبکه است و درست بودن DNS آن را رفع نمی‌کند. اگر Route سالم است، ICMP یا فایروال را جدا بررسی کنید.
معمولاً خیر. برای تنظیم پایدار باید ابزار مدیریت شبکه فعال مانند Netplan، NetworkManager یا ifupdown را با اطلاعات واقعی Gateway و Interface اصلاح کنید.