خطای ERR_CONNECTION_TIMED_OUT؛ علت‌های سمت سرور و رفع آن

رشته ERR_CONNECTION_TIMED_OUT را کروم وقتی نشان می‌دهد که بسته شروع اتصال TCP رفته و تا پایان مهلت سیستم‌عامل هیچ پاسخی از سرور برنگشته است. پشت این سکوت معمولاً یکی از چند علت مشخص است: قانون فایروالی که بسته را بی‌صدا دور می‌ریزد، صف اتصال پرشده یا IP مسدودشده.

پیام مرورگر	چه چیزی برگشت	اول کجا را ببینید
تایم‌اوت اتصال (کد -118)	هیچ؛ نه SYN-ACK و نه RST	قانون DROP یا مسدودی بیرون از سرور
ERR_CONNECTION_REFUSED (-102)	بسته RST یا ICMP port-unreachable	سرویس خاموش یا REJECT پیش‌فرض
ERR_ADDRESS_UNREACHABLE (-109)	پیام ICMP از نوع host-prohibited	قانون REJECT با نوع غیرپیش‌فرض
ERR_CONNECTION_RESET (-101)	بسته RST وسط اتصال برقرارشده	وب‌سرور یا تجهیز میان راه
ERR_NAME_NOT_RESOLVED (-105)	جواب DNS بدون نشانی	رکورد دامنه، پیش از هر اتصال

هر پیام مرورگر به جای مشخصی روی سرور اشاره دارد. تایم‌اوتی را که فقط روی اینترنت همراه یا فقط از خارج کشور دیده می‌شود، از چند اتصال دیگر هم با تست دسترسی سایت از ایران امتحان کنید.

خطای اتصال را از روی پاسخی که برنگشته بشناسید

در فایل net_error_list.h پروژه Chromium، ERR_CONNECTION_TIMED_OUT کد -118 دارد با شرح «A connection attempt timed out». کروم این کد را وقتی برمی‌گرداند که سیستم‌عامل در مرحله connect خطای ETIMEDOUT بدهد؛ پس هیچ درخواست HTTPی به سرور نرسیده است.

سه اصطلاح که باید از هم جدا کنید

رد اتصال (ERR_CONNECTION_REFUSED، -102): شرح Chromium «A connection attempt was refused» است. سرور یا فایروالش با RST یا ICMP از نوع port-unreachable جواب داده و مسیر تا میزبان باز است.

ریست (ERR_CONNECTION_RESET، -101): شرحش «A connection was reset (corresponding to a TCP RST)» است. اتصال برقرار و بعد قطع شده است.

نشانی غیرقابل‌دسترس (ERR_ADDRESS_UNREACHABLE، -109): شرحش «The IP address is unreachable» است. REJECT با ICMP از نوع host-prohibited همین پیام را می‌سازد.

هم‌نوردی که در مه کوهستان صدایتان را با یک «نه» جواب می‌دهد، دست‌کم ثابت کرده آنجاست. سکوت کامل دو توضیح دارد: صدای شما نرسیده یا جواب او در راه گم شده.

انتظار طولانی پیش از نمایش خطا

مدت انتظار را سیستم‌عامل بازدیدکننده تعیین می‌کند. پیش‌فرض tcp_syn_retries در لینوکس 6 است و طبق مستندات ip-sysctl، هسته‌های فعلی اتصال را بعد از ۱۳۱ ثانیه رها می‌کنند. یادداشتی در کد Chromium این آستانه را بین سیستم‌ها از ۲۰ تا ۱۹۰ ثانیه می‌داند.

سرویس روی کدام نشانی و پورت گوش می‌دهد؟

وب‌سرور باید روی IP عمومی سرور یا همه نشانی‌ها به پورت 443 گوش بدهد. سرویسی که فقط به 127.0.0.1 بسته شده، از بیرون جوابی ندارد. اگر سیاست پیش‌فرض فایروال drop باشد، نتیجه برای بازدیدکننده ERR_CONNECTION_TIMED_OUT است و بدون فایروال، رد اتصال.

خواندن خروجی ss -ltnp

طبق صفحه راهنمای ss(8)، -l فقط سوکت‌های گوش‌دهنده را می‌آورد، -t سوکت‌های TCP را، -n پورت را عددی نگه می‌دارد و -p فرایند صاحب سوکت را چاپ می‌کند. فیلتر sport پورت را محدود می‌کند:

sudo ss -ltnp 'sport = :443'

آزمودن پورت از بیرون با nc و curl

آزمون را از ماشینی بیرون از سرور اجرا کنید. در nc نسخه OpenBSD، گزینه -z بدون فرستادن داده فقط گوش دادن سرویس را می‌سنجد و -w مهلت را بر حسب ثانیه می‌گذارد. در curl، --connect-timeout فقط مرحله اتصال را محدود می‌کند.

nc -zv -w 5 203.0.113.10 443
curl -v --connect-timeout 5 -o /dev/null https://example.com

در آزمایش ما روی loopback یک سرور Ubuntu با curl 8.5.0، فقط پورت پشت DROP تایم‌اوت ساخت و دو پورت دیگر در کسری از ثانیه رد شدند:

وضعیت پورت	خروجی nc	خروجی curl
پشت قانون DROP	پیام timed out بعد از ۵ ثانیه	کد خروج 28، Timeout was reached
پشت قانون REJECT	پیام Connection refused فوری	کد خروج 7، Couldn't connect to server
بدون سرویس و فایروال	پیام Connection refused فوری	کد خروج 7، Couldn't connect to server

رکورد A که هنوز به سرور قبلی اشاره دارد

سطر Trying در خروجی curl -v نشانی واقعی اتصال است. اگر با IP فعلی سرور فرق دارد، رکورد A هنوز به سرور قبلی اشاره دارد. جای ویرایش هر نوع رکورد در پنل دامنه را راهنمای تنظیمات DNS و مدیریت رکوردهای دامنه نشان می‌دهد.

قانون DROP در فایروال سکوت می‌سازد

قانون DROP بسته را بی‌هیچ پاسخی دور می‌ریزد. قانون REJECT طبق صفحه راهنمای iptables-extensions بسته خطایی برمی‌گرداند و جز همین پاسخ، کارش با DROP فرقی ندارد. هر DROP که جلوی پورت 443 بنشیند، در مرورگر بازدیدکننده به ERR_CONNECTION_TIMED_OUT می‌رسد.

دیدن SYN بی‌جواب با tcpdump

در صفحه راهنمای tcpdump، -i any همه رابط‌ها را می‌گیرد، -c تعداد بسته را محدود می‌کند و -n نشانی را عددی نگه می‌دارد. به جای 198.51.100.7، IP بازدیدکننده را بگذارید (IPv4 یا IPv6). فیلتر هر دو جهت و جواب‌های icmp قانون REJECT را می‌گیرد:

sudo tcpdump -i any -n -c 20 '(tcp port 443 or icmp or icmp6) and host 198.51.100.7'

این همان الگوی پیش‌فرض tcp_syn_linear_timeouts در مستندات ip-sysctl است؛ پورت بی‌سرویس اما بی‌درنگ Flags [R.] داد. SYN بدون [S.]: مشکل داخل سرور است. [S.] همراه تایم‌اوت: جواب در مسیر برگشت گم شده. نرسیدن SYN: بسته پیش از سرور گم شده است.

خواندن شمارنده قوانین iptables و nftables

در iptables گزینه -v کنار هر قانون شمارنده بسته را هم چاپ می‌کند و --line-numbers شماره قانون را می‌آورد. در nftables، nft list ruleset همه قوانین را یک‌جا چاپ می‌کند، ولی شمارنده فقط کنار قانونی می‌آید که عبارت counter دارد:

sudo iptables -L INPUT -n -v --line-numbers
sudo nft list ruleset

فرمان اول را دو بار بزنید و در فاصله‌شان از ماشین دیگری به 443 وصل شوید؛ قانونی که شمارنده‌اش بالا رفته، مقصر است. سطر Chain INPUT (policy DROP) یا policy drop; در nft یعنی پورت بدون قانون ACCEPT بی‌صدا بسته است.

صف اتصال پر در ساعت‌های شلوغ

شنونده TCP دو صف دارد: صف SYN برای اتصال نیمه‌کاره و صف accept برای اتصال کاملی که برنامه هنوز برنداشته است. طبق مستندات ip-sysctl هسته، tcp_syncookies پیش‌فرض 1 است و سرریز صف SYN با syncookie جبران می‌شود؛ پس مقصر معمول صف accept است. به گفته listen(2)، این صف به backlog سرویس و somaxconn محدود است و TCP با پر شدنش ممکن است درخواست را نادیده بگیرد؛ نتیجه، تایم‌اوت پراکنده در ساعت پربازدید است.

فهرست مسدودی‌ها؛ IP بازدیدکننده یا خود سرور

وقتی فقط یک مشتری ERR_CONNECTION_TIMED_OUT می‌گیرد و بقیه سایت را باز می‌کنند، فهرست بن fail2ban و فایروال پنل را برای IP او بگردید. اگر از هیچ شبکه‌ای SYN به سرور نمی‌رسد، مسدودی بیرون از سرور است.

جست‌وجوی یک IP در fail2ban

مستند fail2ban-client در Debian 12 زیرفرمان banned را برای یافتن jailهای یک IP دارد و set <JAIL> unbanip را برای آزاد کردنش. jail باید پورت 443 را پوشش بدهد؛ در jail.conf خود fail2ban، nginx-http-auth با port = http,https تعریف شده است:

sudo fail2ban-client banned 198.51.100.7
sudo fail2ban-client set nginx-http-auth unbanip 198.51.100.7

پیش از آزاد کردن، لاگ همان jail را بخوانید. مقدار blocktype در اکشن iptables خود fail2ban REJECT --reject-with icmp-port-unreachable است. اکشن nftables هم، که پیش‌فرض Debian و Ubuntu است، reject می‌کند؛ پس بن پیش‌فرض رد اتصال می‌سازد و تایم‌اوت از DROP خبر می‌دهد.

وقتی بسته پیش از سرور گم می‌شود

اگر tcpdump هنگام تلاش بازدیدکننده هیچ SYNی نشان نمی‌دهد، فایروال سرور بی‌تقصیر است. دو احتمال رایج، بسته بودن پورت در شبکه ارائه‌دهنده و فیلتر IP سرور روی یک اپراتور است. خروجی خالی tcpdump را با زمان تلاش‌ها برای پشتیبانی بفرستید.

سایتی که روی وای‌فای دفتر باز می‌شود و روی اینترنت همراه تایم‌اوت می‌دهد، مسیر یا فهرست مسدودی را مظنون می‌کند. تا تست دسترسی سایت از ایران روی هر دو اتصال اجرا نشده، به تنظیمات سرور دست نزنید.

جمع‌بندی؛ سکوتی که ERR_CONNECTION_TIMED_OUT گزارش می‌کند این پیام می‌گوید دست‌دادن TCP جوابی نگرفته، در حالی که رد اتصال و ریست حضور سرور را ثابت می‌کنند. روی سرور، ss نشانی و پورت وب‌سرور را می‌گوید و tcpdump رسیدن یا نرسیدن SYN را. SYNی که می‌رسد و بی‌جواب می‌ماند شما را به شمارنده DROP یا صف اتصال پر می‌برد. اگر فقط یک بازدیدکننده گرفتار است، IP او را در fail2ban بگردید و یادتان باشد بن پیش‌فرضش رد اتصال می‌سازد. وقتی هیچ SYNی نمی‌رسد، خروجی خالی tcpdump مدرک شما برای ارائه‌دهنده است.

فرمان ss روی سرور شما جلوی پورت 443 کدام نشانی را نشان داد؟

• Chromium: net/base/net_error_list.h
• ss(8), Linux manual page
• iptables-extensions(8), REJECT target
• tcpdump(1) manual page
• Linux kernel docs: ip-sysctl