رفع خطای ERR_CONNECTION_TIMED_OUT در کروم؛ چک‌لیست کاربر و مدیر سرور

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

کروم این خطا را با عنوان «This site can’t be reached» و توضیح «example.com took too long to respond» نشان می‌دهد؛ Edge هم همین کد را دارد و فایرفاکس «The connection has timed out» می‌نویسد. بخش اول مقاله برای بازدیدکننده است و بخش دوم برای مدیر سایت و سرور.

به‌طور خلاصه: این خطا یعنی اتصال TCP به سرور برقرار نشده است، نه اینکه سایت کند باشد.

• بازدیدکننده: سایت را با اینترنت همراه یا دستگاه دیگر باز کنید. اگر باز شد، به ترتیب پراکسی و VPN، افزونه‌ها، کش DNS، فایل hosts، آنتی‌ویروس و در آخر DNS سیستم را بررسی کنید.
• مدیر سایت: پورت 443 را از بیرون با curl تست کنید؛ بعد فایروال (ufw، firewalld، CSF)، مسدود بودن IP بازدیدکننده، رکورد A و پر شدن منابع سرور را بررسی کنید.
• بالا بردن max_execution_time این خطا را حل نمی‌کند.

ERR_CONNECTION_TIMED_OUT دقیقاً یعنی چه؟

مرورگر اول با DNS نشانی IP سرور را پیدا می‌کند، بعد با «دست‌دادن سه‌مرحله‌ای» (TCP Handshake) اتصال می‌سازد: بستهٔ SYN می‌فرستد و منتظر SYN-ACK می‌ماند. TLS و درخواست HTTP فقط بعد از این مرحله فرستاده می‌شوند.

Chromium این خطا را با کد -118 و توضیح «A connection attempt timed out» تعریف کرده است. سیستم‌عامل SYN را چند بار تکرار می‌کند و اگر پاسخی نرسد، پس از حدود ۲۰ ثانیه در ویندوز تا حدود ۲ دقیقه در لینوکس (با تنظیم پیش‌فرض) دست می‌کشد. پس یا بسته‌ها در مسیر یا روی سرور بی‌صدا دور ریخته شده‌اند (Drop)، یا سرور خاموش یا بیش از حد شلوغ است، یا دامنه به IP اشتباهی اشاره می‌کند.

فرق با ERR_CONNECTION_REFUSED و 504

اگر روی آن پورت سرویسی گوش ندهد یا فایروال بسته را با پاسخ منفی رد کند (Reject)، مرورگر فوراً ERR_CONNECTION_REFUSED می‌گیرد: در refused جواب منفی آمده و در timed out هیچ جوابی نیامده است. برای این حالت در اتصال SSH، راهنمای رفع خطای Connection Refused را ببینید. 504 و 408 هم کد وضعیت HTTP هستند؛ یعنی اتصال برقرار شده و سروری جواب داده است. جزئیات آن‌ها را در مقالهٔ انواع خطاهای HTTP آورده‌ایم.

خطا	چه اتفاقی افتاده	محل معمول مشکل
ERR_CONNECTION_TIMED_OUT	به درخواست اتصال پاسخی نرسید	شبکه، فایروال با Drop، سرور خاموش یا IP اشتباه
ERR_CONNECTION_REFUSED	اتصال فوراً رد شد	سرویس خاموش یا پورت بسته با Reject
ERR_NAME_NOT_RESOLVED	دامنه به IP تبدیل نشد	DNS
ERR_TIMED_OUT (کد -7)	timeout عمومی‌تر، حتی بعد از اتصال	شبکهٔ ناپایدار یا پاسخ کند
504 Gateway Timeout	اتصال برقرار شد، سرور پشتی دیر جواب داد	PHP، دیتابیس، upstream
408 Request Timeout	سرور منتظر کامل شدن درخواست کلاینت ماند	کلاینت یا شبکهٔ کند
522 کلودفلر	Cloudflare به سرور اصلی وصل نشد	فایروال یا بار سرور اصلی

تشخیص در ۳ دقیقه: مشکل از شماست یا از سایت؟

1. یک سایت داخلی و یک سایت خارجی دیگر را باز کنید. اگر هیچ‌کدام باز نشد، مشکل از اتصال اینترنت شماست.
2. همان سایت را با اینترنت همراه گوشی باز کنید (Wi-Fi خاموش). اگر باز شد، مشکل از شبکهٔ اول است: مودم، پراکسی، DNS یا مسدود بودن IP آن شبکه روی سرور مقصد.
3. با دستگاه دیگری روی همان Wi-Fi امتحان کنید. اگر باز شد، تنظیمات دستگاه اول مقصر است.
4. سایت را از بیرون بسنجید. check-host.net از چند کشور به پورت سایت وصل می‌شود و در زمان نگارش این مقاله گره‌هایی در تهران، اصفهان و شیراز هم دارد. اگر از همه‌جا timeout است، مشکل از سمت سرور است.

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

اختلال، فیلترینگ و اپراتورها در ایران

بخشی از timeoutها در ایران از کنترل بازدیدکننده و صاحب سایت خارج است. در زمان اختلال ارتباط بین‌الملل، سایت‌های میزبانی‌شده در خارج ممکن است از داخل timeout بدهند؛ برعکس، سرور داخل ایران ممکن است از خارج، از جمله برای ربات‌های موتور جست‌وجو، در دسترس نباشد. برای دامنه‌های فیلترشده هم DNS ممکن است نشانی خصوصی برگرداند (پژوهش‌ها 10.10.34.34 تا 10.10.34.36 را گزارش کرده‌اند)؛ در این حالت مشکل نه از سیستم شماست و نه از سرور سایت.

اگر سایتی روی یک اپراتور باز می‌شود و روی دیگری نه، معمولاً مسیریابی بین آن اپراتور و دیتاسنتر مشکل دارد؛ صاحب سایت باید خروجی tracert یا mtr را از همان اپراتور برای ارائه‌دهندهٔ سرور بفرستد. اگر بیشتر مخاطبان شما در ایران هستند، سرور مجازی ایران ریسک اختلال ارتباط بین‌الملل را کم می‌کند؛ اگر مخاطب اصلی خارج از ایران است، سرور خارجی منطقی‌تر است.

بخش اول: راه‌حل برای بازدیدکنندگان

بعد از هر قدم سایت را دوباره امتحان کنید تا بدانید کدام تغییر مشکل را حل کرد.

۱. ری‌استارت مودم و مرورگر

مودم را حدود ۳۰ ثانیه خاموش و دوباره روشن کنید. کروم را کامل ببندید و دوباره باز کنید و به‌روز بودنش را در chrome://settings/help ببینید. در ویندوز، گزینهٔ «Running Windows Network Diagnostics» در صفحهٔ خطا را هم یک بار اجرا کنید.

۲. خاموش کردن پراکسی و VPN

یک VPN یا پراکسی قطع یا کند، همهٔ اتصال‌ها را به timeout می‌کشاند. برنامهٔ VPN را کامل ببندید و تنظیمات پراکسی را بررسی کنید:

• ویندوز ۱۰ و ۱۱: Settings › Network & internet › Proxy. اگر خودتان یا شبکهٔ شرکت پراکسی تنظیم نکرده‌اید، «Use a proxy server» و «Use setup script» باید خاموش باشند.
• macOS: System Settings › Network › سرویس شبکه › Details › Proxies.
• کروم: تنظیمات مؤثر پراکسی را در chrome://net-internals/#proxy می‌بینید.

۳. پنجرهٔ ناشناس، افزونه‌ها و کش

سایت را در پنجرهٔ ناشناس (Incognito) باز کنید: Ctrl+Shift+N در ویندوز و Cmd+Shift+N در مک. افزونه‌ها در این حالت اجرا نمی‌شوند، مگر اینکه خودتان اجازه داده باشید. اگر سایت باز شد، در chrome://extensions افزونه‌ها را یکی‌یکی خاموش کنید؛ افزونه‌های پراکسی، VPN و مسدودکنندهٔ تبلیغات مظنون اصلی‌اند.

پاک کردن کش مرورگر معمولاً بی‌اثر است، چون مشکل پیش از دریافت محتوا رخ می‌دهد؛ مگر اینکه سایت قبلاً با ریدایرکت دائمی (301) به نشانی یا پورتی رفته باشد که حالا در دسترس نیست. مرورگر این ریدایرکت را از کش می‌خواند؛ با Ctrl+Shift+Delete گزینهٔ «Cached images and files» را پاک کنید.

۴. پاک کردن کش DNS

اگر سایت به‌تازگی به سرور جدیدی منتقل شده باشد، ممکن است سیستم شما هنوز IP قدیمی را در حافظه داشته باشد. در ویندوز، Command Prompt را با Run as administrator باز کنید:

ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

در macOS این دستور را در Terminal اجرا کنید؛ خروجی‌ای نمایش نمی‌دهد:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

کروم کش جداگانه‌ای هم دارد: در chrome://net-internals/#dns روی «Clear host cache» و در chrome://net-internals/#sockets روی «Flush socket pools» بزنید. در اندروید حالت پرواز را چند ثانیه روشن و خاموش کنید یا گوشی را ری‌استارت کنید.

۵. بررسی فایل hosts

رکوردهای فایل hosts بر پاسخ DNS مقدم‌اند. هنگام انتقال سایت معمولاً خطی در آن اضافه و بعد فراموش می‌شود؛ نتیجه این است که فقط همان رایانه به IP قدیمی می‌رود. برای جست‌وجو:

# Windows (Command Prompt)
findstr /i "example.com" C:\Windows\System32\drivers\etc\hosts

# macOS / Linux
grep -i "example.com" /etc/hosts

اگر سطری مثل 203.0.113.10 example.com پیدا شد، آن را حذف یا با # غیرفعال کنید. در ویندوز Notepad را با Run as administrator باز کنید تا بتوانید فایل را ذخیره کنید؛ در مک از sudo nano /etc/hosts استفاده کنید.

۶. آنتی‌ویروس و فایروال سیستم

قابلیت‌هایی مثل محافظت وب یا بررسی اتصال‌های رمزگذاری‌شده در برخی آنتی‌ویروس‌ها اتصال را معطل نگه می‌دارند. فقط همان قابلیت را چند دقیقه خاموش کنید و سایت را امتحان کنید. اگر مقصر همین بود، قابلیت را دوباره روشن و دامنه را به فهرست استثنا اضافه کنید.

۷. تغییر DNS

این قدم فقط وقتی کمک می‌کند که DNS فعلی شما نشانی قدیمی یا اشتباه برگرداند. پاسخ DNS خودتان را با یک DNS عمومی مقایسه کنید و اگر فرق داشت، هر نشانی را جداگانه روی پورت 443 بسنجید:

nslookup example.com
nslookup example.com 1.1.1.1

# Windows PowerShell: test each returned address
Test-NetConnection 203.0.113.10 -Port 443
# macOS
nc -vz -G 5 203.0.113.10 443

نشانی‌های متفاوت به‌تنهایی نشانهٔ خرابی نیستند؛ سایت‌های پشت CDN به‌طور عادی از DNSهای مختلف نشانی‌های متفاوت می‌گیرند. فقط اگر نشانیِ DNS شما پاسخ نمی‌دهد و نشانی دیگر پاسخ می‌دهد، DNS را مثلاً به 1.1.1.1 و 8.8.8.8 یا DNS اپراتور خود تغییر دهید:

• ویندوز ۱۱: Settings › Network & internet › Wi-Fi یا Ethernet › نام شبکه › کنار DNS server assignment روی Edit بزنید، Manual و IPv4 را انتخاب کنید و Preferred DNS و Alternate DNS را بنویسید.
• macOS: System Settings › Network › سرویس شبکه › Details › DNS.
• اندروید: Private DNS در Settings › Network & internet فقط نام میزبان می‌پذیرد، نه IP، و DNS رمزگذاری‌شده در ایران اغلب در دسترس نیست؛ برای عیب‌یابی آن را روی Off یا Automatic بگذارید. DNS معمولی هر Wi-Fi در جزئیات همان شبکه، بخش IP settings › Static، تغییر می‌کند؛ نام گزینه‌ها در گوشی‌ها فرق دارد.
• کروم: Settings › Privacy and security › Security › Use secure DNS؛ اگر ارائه‌دهندهٔ سفارشی انتخاب شده و از شبکهٔ شما در دسترس نیست، برای تست آن را خاموش کنید.

اگر با DNS جدید هم همان خطا ماند، DNS علت نیست؛ تنظیم قبلی را برگردانید.

۸. بازنشانی تنظیمات شبکهٔ ویندوز

اگر روی یک رایانهٔ ویندوزی هیچ سایتی پایدار باز نمی‌شود، این دستورها را در Command Prompt با دسترسی مدیر اجرا و سیستم را ری‌استارت کنید (راه گرافیکی ویندوز ۱۱: Settings › Network & internet › Advanced network settings › Network reset):

netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

هشدار: اگر IP یا DNS را دستی (Static) تنظیم کرده‌اید، قبل از اجرا خروجی ipconfig /all را یادداشت کنید؛ این دستورها ممکن است آن تنظیمات را پاک کنند.

بخش دوم: عیب‌یابی سمت سرور برای مدیران سایت

این بررسی‌ها را به ترتیب انجام دهید. دستورها برای Ubuntu 24.04 و 26.04 و Debian 12/13 است و تفاوت خانوادهٔ RHEL (AlmaLinux، Rocky) جدا آمده؛ به‌جای example.com و 203.0.113.10 دامنه و IP خودتان را بگذارید. dig، tcpdump و mtr روی نصب‌های حداقلی معمولاً نیستند:

sudo apt install bind9-dnsutils tcpdump mtr-tiny   # Ubuntu / Debian
sudo dnf install bind-utils tcpdump mtr            # AlmaLinux / Rocky

۱. تست اتصال از بیرون، نه با ping

ping از ICMP استفاده می‌کند که بسیاری از شبکه‌ها آن را می‌بندند؛ ping ناموفق به معنای خاموش بودن سرور نیست و ping موفق هم سلامت وب‌سرور را ثابت نمی‌کند. خود پورت وب را از سیستمی بیرون از سرور تست کنید:

curl -sS -o /dev/null -w 'connect=%{time_connect}s code=%{http_code}\n' \
  --connect-timeout 10 https://example.com/

# healthy:
connect=0.084512s code=200
# timeout (no answer to SYN):
curl: (28) Failed to connect to example.com port 443 after 10002 ms: Timeout was reached
connect=0.000000s code=000
# refused (port closed or REJECT):
curl: (7) Failed to connect to example.com port 443 after 45 ms: Couldn't connect to server
connect=0.000000s code=000
# (the -w line is still printed on failure)

برای سنجش مستقیم IP سرور بدون DNS، مثلاً بعد از انتقال سایت، از --resolve استفاده کنید. در ویندوز، Test-NetConnection در PowerShell همین کار را می‌کند و خط TcpTestSucceeded مقدار True یا False می‌گیرد:

curl -sSI --connect-timeout 10 --resolve example.com:443:203.0.113.10 https://example.com/

# Windows PowerShell
Test-NetConnection example.com -Port 443

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

۲. وب‌سرور روشن است و روی پورت درست گوش می‌دهد؟

sudo systemctl status nginx --no-pager     # or: apache2 (Ubuntu), httpd (RHEL)
sudo ss -tlnp '( sport = :80 or sport = :443 )'

State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0      511          0.0.0.0:443       0.0.0.0:*    users:(("nginx",pid=812,fd=7))
LISTEN 0      511          0.0.0.0:80        0.0.0.0:*    users:(("nginx",pid=812,fd=6))

# test from the server itself:
curl -sSI --resolve example.com:443:127.0.0.1 https://example.com/

اگر روی 443 سرویسی گوش نمی‌دهد، خطای پیکربندی را با sudo nginx -t یا sudo apachectl configtest پیدا کنید. سرویسی که فقط روی 127.0.0.1 گوش می‌دهد، از بیرون در دسترس نیست. اگر از داخل سرور پاسخ می‌گیرید و از بیرون timeout، مشکل در فایروال یا شبکه است.

۳. فایروال سرور: ufw، firewalld و CSF

در ufw سیاست پیش‌فرض ورودی deny است و بسته‌های مجاز نشده بی‌صدا دور ریخته می‌شوند؛ یعنی دقیقاً timeout. حالت رایج: فقط پورت 80 باز شده و بعد از نصب SSL، پورت 443 فراموش شده است؛ http باز می‌شود و https نه، و با HSTS حتی http هم به https می‌رود.

sudo ufw status verbose

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere

# 443 is missing above; open it:
sudo ufw allow 443/tcp
# or use the Nginx profile shipped by Ubuntu/Debian (80 and 443):
sudo ufw allow 'Nginx Full'

هشدار: قبل از ufw enable پورت SSH را باز کنید تا دسترسی خودتان قطع نشود. روی پورت‌های وب هم از ufw limit استفاده نکنید؛ این قاعده IPهایی را که ظرف ۳۰ ثانیه ۶ اتصال یا بیشتر بسازند رد می‌کند و کاربران پشت یک IP مشترک، مثل شبکهٔ یک شرکت، به‌راحتی از این حد می‌گذرند.

در خانوادهٔ RHEL با firewalld:

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all
sudo firewall-cmd --permanent --add-service=http --add-service=https
sudo firewall-cmd --reload

firewalld به‌طور پیش‌فرض بسته‌های مجاز نشده را Reject می‌کند، مگر اینکه target زون DROP باشد. قواعد خام را با sudo nft list ruleset یا sudo iptables -S INPUT ببینید.

در CSF، پورت‌های ورودی مجاز در متغیر TCP_IN فایل /etc/csf/csf.conf تعریف می‌شوند و 80 و 443 باید در آن باشند:

sudo grep -E '^TCP_IN' /etc/csf/csf.conf
TCP_IN = "20,21,22,25,53,80,110,143,443,465,587,..."
sudo csf -ra      # restart csf and lfd after editing csf.conf

اگر قواعد سرور درست است اما بسته‌ها به سرور نمی‌رسند (قدم ۷)، فایروال شبکه یا Security Group در پنل ارائه‌دهنده را بررسی کنید. مبانی کار با فایروال را در راهنمای فعال‌سازی فایروال در لینوکس آورده‌ایم.

۴. IP بازدیدکننده مسدود شده؟

نشانهٔ کلاسیک: سایت از اینترنت شرکت باز نمی‌شود اما با اینترنت همراه باز می‌شود. معمولاً یک برنامهٔ ایمیل با رمز اشتباه یا چند ورود ناموفق به cPanel یا FTP باعث شده lfd (سرویس پایش CSF) IP عمومی شرکت را مسدود کند. در تنظیم پیش‌فرض CSF روی cPanel، مثلاً ۵ ورود ناموفق به cPanel یا WHM به مسدودسازی دائمی با هدف DROP می‌رسد؛ یعنی دقیقاً همین خطا. IP عمومی بازدیدکننده را بگیرید (با جست‌وجوی what is my ip از همان شبکه) و روی سرور:

sudo csf -g 198.51.100.25                   # search firewall rules for this IP
sudo csf -t                                 # list temporary bans
sudo grep 198.51.100.25 /var/log/lfd.log    # why it was blocked
sudo csf -dr 198.51.100.25                  # remove a permanent ban (csf.deny)
sudo csf -tr 198.51.100.25                  # remove a temporary ban

در WHM همین کار از Plugins › ConfigServer Security & Firewall با «Search for IP» و «Quick Unblock» انجام می‌شود؛ اگر Imunify360 نصب است، IP را در فهرست‌های آن (WHM › Plugins › Imunify360) هم بگردید. بعد علت را برطرف کنید، وگرنه IP دوباره مسدود می‌شود. csf -a همهٔ پورت‌ها را برای یک IP باز می‌کند؛ پس فقط IP ثابت و مطمئن شرکت را با آن مجاز کنید.

نکته: سازندهٔ CSF از ۳۱ اوت ۲۰۲۵ نگه‌داری آن را متوقف کرد و حالا cPanel نسخهٔ نگه‌داری‌شده را با بستهٔ cpanel-csf منتشر می‌کند؛ دستورهای بالا تغییری نکرده‌اند. نسخه‌های 14.x و 15.00 با به‌روزرسانی خودکار خودشان منتقل می‌شوند؛ وگرنه با sudo yum install cpanel-csf (AlmaLinux/Rocky) یا sudo apt install cpanel-csf (Ubuntu) نصبش کنید.

برای fail2ban:

sudo fail2ban-client status                   # list jails
sudo fail2ban-client status sshd              # banned IPs in one jail
sudo fail2ban-client unban 198.51.100.25      # unban from all jails (0.10+)

هر jail فقط پورت‌های خودش را می‌بندد؛ بن در jail مربوط به sshd فقط SSH را می‌بندد و روی سایت اثری ندارد. سایت فقط وقتی باز نمی‌شود که IP در jailهای وب، jail مربوط به recidive یا jailی با banaction_allports بن شده باشد. اقدام پیش‌فرض fail2ban هم Reject است و بن‌هایش معمولاً refused دیده می‌شوند، مگر اینکه blocktype روی DROP باشد.

۵. رکورد DNS به IP درست اشاره می‌کند؟

اگر بعد از انتقال سرور یا تغییر IP، رکورد A هنوز به IP قدیمی اشاره کند، هرکس آن نشانی را دریافت کند timeout می‌گیرد.

dig +short NS example.com                       # authoritative name servers
dig +short A example.com @ns1.your-dns-host.com # ask one of them directly
dig +short A example.com @1.1.1.1
dig +short A example.com @8.8.8.8
dig +short AAAA example.com
dig +noall +answer A example.com                # 2nd column = remaining TTL

example.com.    287    IN    A    203.0.113.10

خروجی را با IP عمومی سرور در پنل ارائه‌دهنده مقایسه کنید. اگر نام‌سرور اصلی IP قدیمی می‌دهد، رکورد را اصلاح کنید؛ اگر فقط برخی DNSهای عمومی قدیمی‌اند، تا پایان TTL صبر کنید (همان «انتشار DNS»). در ویندوز از nslookup example.com 1.1.1.1 استفاده کنید.

رکورد AAAA اشتباه را هم حذف کنید: کروم معمولاً سریع به IPv4 برمی‌گردد، اما برخی کلاینت‌ها و ربات‌ها گیر می‌کنند. تغییر نام‌سرور دامنه‌های .ir از طریق nic.ir یا نماینده‌تان ممکن است زمان‌بر باشد، اما تغییر رکورد A فقط تابع TTL است. اگر دامنه پشت پروکسی Cloudflare است، dig نشانی‌های Cloudflare را نشان می‌دهد و IP اصلی را باید در داشبورد Cloudflare دید.

۶. سرور زیر بار است یا منابعش تمام شده؟

اگر Apache مستقیم اتصال‌ها را می‌گیرد و همهٔ پردازه‌هایش مشغول‌اند، یا سقف اتصال LiteSpeed یا worker_connections در Nginx پر شده، اتصال‌های تازه در صف کرنل (Listen Backlog) می‌مانند و با پر شدن صف، SYNها بی‌صدا دور ریخته می‌شوند؛ نتیجه timeoutهای متناوب در ساعت‌های شلوغ است. اما اگر Nginx جلوی PHP-FPM است، پر شدن pm.max_children معمولاً به‌شکل بارگذاری طولانی و سپس 502 یا 504 دیده می‌شود، نه این خطا. کمبود حافظه و پر شدن جدول conntrack هم اتصال‌ها را بی‌پاسخ می‌گذارند.

uptime
free -h
sudo journalctl -k --since "1 hour ago" | grep -i -E 'out of memory|oom|table full'
nstat -az TcpExtListenOverflows TcpExtListenDrops
sudo sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
sudo grep -h -E 'MaxRequestWorkers|max_children|worker_connections' \
  /var/log/apache2/error.log /var/log/nginx/error.log /var/log/php*-fpm.log 2>/dev/null | tail -n 20

این مسیرهای لاگ برای Ubuntu و Debian است. در خانوادهٔ RHEL لاگ Apache در /var/log/httpd/error_log و لاگ PHP-FPM در /var/log/php-fpm/ است، روی cPanel (EasyApache 4) در /etc/apache2/logs/error_log و در LiteSpeed در /usr/local/lsws/logs/error.log. بالا رفتن شمارندهٔ ListenOverflows یعنی صف اتصال پر می‌شود. پیام‌های مهم لاگ:

پیام لاگ	معنی	اقدام
server reached MaxRequestWorkers setting	همهٔ پردازه‌های Apache مشغول‌اند	کش و بهینه‌سازی؛ افزایش فقط اگر RAM اجازه دهد
server reached pm.max_children setting	PHP-FPM پر است؛ پشت Nginx معمولاً 502 یا 504	یافتن درخواست‌های کند، بعد تنظیم بر اساس RAM
worker_connections are not enough	سقف اتصال Nginx پر شده	افزایش worker_connections
nf_conntrack: table full, dropping packet	جدول ردیابی اتصال پر است	بررسی حمله، افزایش nf_conntrack_max
Out of memory: Killed process	کرنل پردازه‌ای را به‌خاطر حافظه کشته	کاهش مصرف یا افزایش RAM

علتی خاص سرورهای داخل ایران: افزونه‌هایی که هنگام ساخت صفحه به سرویس خارجیِ در دسترس‌نبوده (به‌دلیل تحریم یا فیلترینگ) درخواست می‌فرستند و تا پایان مهلت اتصال، پردازهٔ PHP را اشغال می‌کنند. اول با افزونه‌ای مثل Query Monitor درخواست خروجی کند را پیدا کنید. در وردپرس می‌توانید درخواست‌های خروجی را در wp-config.php ببندید و فقط میزبان‌های لازم را مجاز کنید، با دو احتیاط:

• این ثابت فقط درخواست‌های HTTP API وردپرس (wp_remote_get و مانند آن) را می‌بندد؛ افزونه‌ای که مستقیم از cURL استفاده کند، از آن عبور می‌کند.
• در فروشگاه، میزبان درگاه پرداخت، سامانهٔ پیامک و سرویس ارسال را هم در WP_ACCESSIBLE_HOSTS بیاورید و بعد یک پرداخت آزمایشی کامل انجام دهید؛ وگرنه تأیید پرداخت سفارش‌ها شکست می‌خورد.

define( 'WP_HTTP_BLOCK_EXTERNAL', true );
define( 'WP_ACCESSIBLE_HOSTS', '*.wordpress.org,gateway.example.ir,sms.example.ir' );

۷. آزمون قطعی: بستهٔ SYN به سرور می‌رسد؟

اگر قدم‌های قبلی علت را نشان ندادند، روی سرور tcpdump را اجرا کنید و هم‌زمان از سیستم بازدیدکننده سایت را باز کنید:

sudo tcpdump -ni any 'tcp port 443 and tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn'

10:42:17.512345 eth0  In  IP 198.51.100.25.51844 > 203.0.113.10.443: Flags [S], seq 2148106273, win 64240, length 0

# to see whether the server answers, watch both directions for that client:
sudo tcpdump -ni any 'tcp port 443 and host 198.51.100.25'

• SYN می‌رسد ولی پاسخی برنمی‌گردد: مشکل روی خود سرور است؛ فایروال محلی با DROP یا صف اتصال پر (tcpdump بسته را پیش از فایروال محلی می‌بیند).
• SYN-ACK از سرور خارج می‌شود اما همان SYN دوباره تکرار می‌شود: پاسخ در مسیر برگشت گم می‌شود؛ مسیریابی نامتقارن، فیلتر خروجی ارائه‌دهنده یا سمت بازدیدکننده را بررسی کنید.
• هیچ SYNی نمی‌رسد: بسته پیش از سرور متوقف می‌شود؛ فایروال شبکهٔ ارائه‌دهنده، IP اشتباه در DNS یا مشکل مسیر. اگر از همه‌جا همین است، از ارائه‌دهنده بپرسید IP به‌دلیل حمله، گزارش سوءاستفاده یا تعلیق سرویس null-route نشده باشد.

در دو حالت آخر، خروجی mtr -rwc 50 -T -P 443 example.com (لینوکس، با sudo) یا tracert example.com (ویندوز) را از سمت بازدیدکننده بگیرید و برای ارائه‌دهندهٔ سرور بفرستید.

کلودفلر و خطای 522 چه رابطه‌ای دارند؟

اگر سایت پشت Cloudflare با پروکسی روشن (ابر نارنجی) است، بازدیدکننده به Cloudflare وصل می‌شود، نه به سرور شما؛ پس وقتی سرور اصلی جواب نمی‌دهد، او به‌جای ERR_CONNECTION_TIMED_OUT خطای 522 را می‌بیند. طبق مستندات Cloudflare، یکی از حالت‌های 522 این است که Cloudflare ظرف ۱۹ ثانیه پس از ارسال SYN پاسخ SYN+ACK نگیرد و رایج‌ترین علتش مسدود شدن یا محدودیت نرخ روی IPهای خود Cloudflare است. چون همهٔ بازدیدها از همین IPها می‌آیند، قواعد محدودیت اتصال در CSF (CT_LIMIT، PORTFLOOD) یا jailهای fail2ban ممکن است خود Cloudflare را ببندند. برعکس، اگر سایت پشت پروکسی است و بازدیدکننده‌ای ERR_CONNECTION_TIMED_OUT می‌بیند، مشکل معمولاً بین او و Cloudflare است، نه در سرور شما.

کد	معنی	علت رایج
521	سرور اصلی اتصال را رد کرد	وب‌سرور خاموش یا رد شدن IPهای Cloudflare
522	اتصال در ۱۹ ثانیه برقرار نشد	Drop شدن IPهای Cloudflare، بار زیاد، IP اشتباه
524	اتصال برقرار شد، پاسخ HTTP در ۱۲۵ ثانیه نیامد	درخواست‌های خیلی طولانی

محدوده‌ها را از فهرست رسمی IPهای Cloudflare بردارید و فقط برای پورت‌های 80 و 443 مجاز کنید، نه همهٔ پورت‌ها. در CSF آن‌ها را در csf.ignore هم بگذارید تا lfd دوباره مسدودشان نکند:

# ufw, repeat per range
sudo ufw allow proto tcp from 173.245.48.0/20 to any port 80,443

# CSF: /etc/csf/csf.allow, one line per range and port
tcp|in|d=443|s=173.245.48.0/20
tcp|in|d=80|s=173.245.48.0/20

max_execution_time به این خطا ربط دارد؟

بسیاری از راهنماها برای این خطا افزایش max_execution_time را توصیه می‌کنند، اما این تنظیم فقط مدت اجرای اسکریپت PHP را محدود می‌کند. وقتی اسکریپت به این سقف می‌رسد، اتصال TCP مدت‌هاست برقرار شده و نتیجه معمولاً خطای 500 است، نه ERR_CONNECTION_TIMED_OUT.

تنظیم	پیش‌فرض	نتیجهٔ عبور از آن
max_execution_time در PHP	۳۰ ثانیه	توقف اسکریپت، معمولاً 500
fastcgi_read_timeout و proxy_read_timeout در Nginx	۶۰ ثانیه	504 Gateway Time-out
Proxy Read Timeout در Cloudflare	۱۲۵ ثانیه	524

تنها ارتباط غیرمستقیم همان قدم ۶ است: درخواست‌های طولانی پردازه‌ها را اشغال می‌کنند. روی لینوکس، max_execution_time زمان انتظار برای شبکه، دیتابیس و فراخوانی‌های سیستمی را نمی‌شمارد؛ پس درخواستی که منتظر یک سرویس خارجیِ در دسترس‌نبوده مانده، با آن متوقف نمی‌شود و بالا بردنش هم کمکی نمی‌کند. برای آزاد کردن پردازه‌های گیرکرده، request_terminate_timeout را در pool مربوط به PHP-FPM تنظیم کنید که زمان واقعی را می‌سنجد، و کارهای طولانی مثل بکاپ و درون‌ریزی را به cron یا WP-CLI بسپارید.

; /etc/php/8.3/fpm/pool.d/www.conf (Ubuntu 24.04)
request_terminate_timeout = 60s

sudo systemctl reload php8.3-fpm

جدول عیب‌یابی: نشانه، علت، راه‌حل

نشانه	علت محتمل	راه‌حل
هیچ سایتی باز نمی‌شود	اینترنت یا مودم	ری‌استارت مودم، تماس با اپراتور
فقط روی یک دستگاه	پراکسی، VPN، hosts یا آنتی‌ویروس	قدم‌های ۲ تا ۸ بخش اول
با اینترنت همراه باز می‌شود، با اینترنت شرکت نه	IP شرکت در CSF مسدود است	csf -g و csf -dr، اصلاح رمز ایمیل
سایت‌های خارجی باز نمی‌شوند، داخلی باز می‌شوند	اختلال ارتباط بین‌الملل	خارج از کنترل شما
فقط روی یک اپراتور	مسیریابی	ارسال خروجی mtr به ارائه‌دهنده
http باز می‌شود، https نه	پورت 443 در فایروال بسته است	ufw allow 443/tcp
بعد از انتقال سرور، برای برخی کاربران	رکورد A قدیمی یا کش DNS	اصلاح رکورد، صبر تا پایان TTL
متناوب و در ساعت‌های شلوغ	پر شدن صف اتصال یا منابع	بررسی لاگ‌ها، کش، ارتقای منابع
از ایران باز می‌شود، از خارج نه (یا برعکس)	محدودیت مسیر یا قاعدهٔ کشوری فایروال	تست چندکشوری، بررسی CC_DENY در CSF
بازدیدکنندگان خطای 522 می‌بینند	IPهای Cloudflare مسدود شده‌اند	مجاز کردن محدوده‌های Cloudflare روی 80 و 443

اگر سایت شما روی هاکان سرور است

روی هاست اشتراکی، فایروال و منابع سرور در اختیار ارائه‌دهنده است و کار شما جمع کردن اطلاعات است: IP عمومی خودتان، زمان دقیق خطا و نتیجهٔ تست با اینترنت همراه را در تیکت بفرستید. پشتیبانی فنی ۲۴ ساعته از طریق تیکت در دسترس است. برای بیشتر سایت‌های کوچک و متوسط هاست اشتراکی کافی است و یک timeout دلیل کوچ به سرور بزرگ‌تر نیست.

روی سرور مجازی، فایروال، وب‌سرور و رکورد A در اختیار خود شماست و بخش دوم همین مقاله چک‌لیست شماست. IP سرویس تا زمانی که سرویس تمدید شود ثابت می‌ماند. اگر بعد از بهینه‌سازی، لاگ‌ها هنوز کمبود منابع نشان دادند، ارتقای منابع سرویس با ثبت تیکت انجام می‌شود.

پرسش‌های متداول

خطای ERR_CONNECTION_TIMED_OUT از سمت من است یا از سایت؟

سایت را با اینترنت همراه گوشی باز کنید. اگر باز شد، مشکل از شبکه یا دستگاه شماست؛ اگر از هیچ شبکه‌ای و از ابزارهای تست چندکشوری هم باز نشد، مشکل از سمت سرور سایت است.

چرا سایت با اینترنت همراه باز می‌شود اما با وای‌فای نه؟

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

افزایش max_execution_time این خطا را رفع می‌کند؟

خیر. این تنظیم بعد از برقراری اتصال عمل می‌کند و عبور از آن خطای 500 می‌دهد. اگر پردازه‌های PHP منتظر سرویس‌های خارجی گیر کرده‌اند، راه‌حل پیدا کردن درخواست کند و تنظیم request_terminate_timeout در PHP-FPM است.

رفع خطای ERR_CONNECTION_TIMED_OUT در اندروید چگونه است؟

حالت پرواز را روشن و خاموش کنید، برنامه‌های VPN را ببندید، Private DNS را در Settings › Network & internet روی Off یا Automatic بگذارید و در تنظیمات کروم، Use secure DNS را بررسی کنید. اگر با اینترنت همراه باز می‌شود و با Wi-Fi نه، مشکل از همان شبکه است.

چرا سایت وردپرسی من گاهی این خطا را می‌دهد؟

خطای متناوب معمولاً از پر شدن صف اتصال یا پردازه‌ها در ساعت‌های شلوغ است و روی سرور داخل ایران، افزونه‌هایی که منتظر سرویس خارجیِ در دسترس‌نبوده می‌مانند آن را بدتر می‌کنند. لاگ وب‌سرور را ببینید و درخواست‌های کند را با Query Monitor پیدا کنید.

عبارت «took too long to respond» یعنی سرور کند است؟

نه لزوماً. یعنی سرور به درخواست اتصال اصلاً جواب نداد. سرور کند معمولاً صفحه را دیر بارگذاری می‌کند یا خطای 504 می‌دهد.

این خطا به سئوی سایت آسیب می‌زند؟

قطعی‌های کوتاه و نادر مشکل جدی ایجاد نمی‌کنند، اما اگر ربات گوگل بارها به سرور وصل نشود، خزش سایت کند می‌شود. وضعیت را در Search Console از مسیر Settings › Crawl stats › Host status و نمودار Server connectivity ببینید.

جمع‌بندی

ERR_CONNECTION_TIMED_OUT یک پیام دارد: درخواست اتصال بی‌جواب ماند. بازدیدکننده با تست اینترنت همراه شروع می‌کند و پراکسی، افزونه‌ها، کش DNS، hosts و آنتی‌ویروس را به ترتیب کنار می‌گذارد. مدیر سایت پورت 443 را از بیرون تست می‌کند و بعد وب‌سرور، فایروال، فهرست مسدودی CSF، رکورد DNS و منابع سرور را بررسی می‌کند؛ اگر هیچ‌کدام علت را نشان نداد، tcpdump معلوم می‌کند بسته به سرور می‌رسد یا باید با خروجی mtr سراغ ارائه‌دهنده رفت.

برای جلوگیری از تکرار، پورت 443 را هم از داخل و هم از خارج ایران پایش کنید؛ مانیتور خارجی به‌تنهایی اختلال‌های داخلی را نمی‌بیند. دست‌کم یک دورهٔ TTL پیش از انتقال سرور، TTL رکورد A را به حدود ۳۰۰ ثانیه برسانید و سرور قدیمی را تا جابه‌جایی کامل ترافیک روشن نگه دارید. بعد از هر تغییر فایروال هم از بیرون با curl تست کنید و ایمیل‌های هشدار lfd را بخوانید.