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

> خطای ERR_CONNECTION_TIMED_OUT یعنی سرور به درخواست اتصال جواب نداده. رفع قدم‌به‌قدم برای کاربر (پراکسی، DNS، hosts) و مدیر سرور (فایروال، CSF، منابع).

- صفحه: https://hakanserver.com/err-connection-timed-out/
- تاریخ انتشار: ۹ آبان ۱۴۰۵ (2026-10-31)
- دسته: سرور
- زمان مطالعه: حدود 23 دقیقه

![پنجرهٔ مرورگر با دوشاخهٔ جداشده و ساعت شنی کنار رک سرور و دیوار فایروال؛ نماد خطای ERR_CONNECTION_TIMED_OUT](https://hakanserver.com/wp-content/uploads/2026/10/err-connection-timed-out.jpg)

خطای **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](https://hakanserver.com/%D8%B1%D9%81%D8%B9-%D8%AE%D8%B7%D8%A7%DB%8C-connection-refused/) را ببینید. 504 و 408 هم کد وضعیت HTTP هستند؛ یعنی اتصال برقرار شده و سروری جواب داده است. جزئیات آن‌ها را در مقالهٔ [انواع خطاهای HTTP](https://hakanserver.com/types-of-http-errors/) آورده‌ایم.

| خطا | چه اتفاقی افتاده | محل معمول مشکل |
| --- | --- | --- |
| 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` را از همان اپراتور برای ارائه‌دهندهٔ سرور بفرستد. اگر بیشتر مخاطبان شما در ایران هستند، [سرور مجازی ایران](https://hakanserver.com/vps-iran/) ریسک اختلال ارتباط بین‌الملل را کم می‌کند؛ اگر مخاطب اصلی خارج از ایران است، سرور خارجی منطقی‌تر است.

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

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

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

مودم را حدود ۳۰ ثانیه خاموش و دوباره روشن کنید. کروم را کامل ببندید و دوباره باز کنید و به‌روز بودنش را در `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 در پنل ارائه‌دهنده را بررسی کنید. مبانی کار با فایروال را در راهنمای [فعال‌سازی فایروال در لینوکس](https://hakanserver.com/enabling-firewall-in-linux/) آورده‌ایم.

### ۴. 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](https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-5xx-errors/error-522/)، یکی از حالت‌های 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](https://www.cloudflare.com/ips/) بردارید و فقط برای پورت‌های 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 |

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

روی [هاست](https://hakanserver.com/buy-hosting-and-domain/) اشتراکی، فایروال و منابع سرور در اختیار ارائه‌دهنده است و کار شما جمع کردن اطلاعات است: IP عمومی خودتان، زمان دقیق خطا و نتیجهٔ تست با اینترنت همراه را در تیکت بفرستید. پشتیبانی فنی ۲۴ ساعته از طریق تیکت در دسترس است. برای بیشتر سایت‌های کوچک و متوسط هاست اشتراکی کافی است و یک timeout دلیل کوچ به سرور بزرگ‌تر نیست.

روی [سرور مجازی](https://hakanserver.com/buy-a-virtual-server/)، فایروال، وب‌سرور و رکورد 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 را بخوانید.

- مطلب قبلی: [امنیت وردپرس؛ ۲۰ اقدام عملی از هاست تا افزونه برای جلوگیری از هک](https://hakanserver.com/wordpress-security/index.md)
- مطلب بعدی: [کوبرنتیز چیست؟ معماری، تفاوت با داکر و آموزش نصب k3s روی سرور](https://hakanserver.com/what-is-kubernetes/index.md)

## مقاله‌های مرتبط

- [رفع خطای Connection Refused در اتصال به سرور مجازی از طریق SSH](https://hakanserver.com/%D8%B1%D9%81%D8%B9-%D8%AE%D8%B7%D8%A7%DB%8C-connection-refused/index.md)
- [اتصال به سرور مجازی ویندوز با ریموت دسکتاپ؛ از ویندوز، مک، گوشی و لینوکس](https://hakanserver.com/connect-windows-vps-to-rdp/index.md)
- [چگونه می‌توانیم VPN با آی پی ثابت را تشخیص دهیم؟](https://hakanserver.com/%D8%AA%D8%B4%D8%AE%DB%8C%D8%B5-vpn-%D8%A8%D8%A7-%D8%A2%DB%8C%D9%BE%DB%8C-%D8%AB%D8%A7%D8%A8%D8%AA/index.md)

## سرویس‌های مرتبط هاکان سرور

- [سرور مجازی](https://hakanserver.com/buy-a-virtual-server/index.md): ۵۲ لوکیشن در ایران و خارج
- [سرور اختصاصی](https://hakanserver.com/dedicatedserver/index.md): ایران و ۸ کشور دیگر
- [هاست و دامنه](https://hakanserver.com/buy-hosting-and-domain/index.md): هاست سی‌پنل ایران و اروپا

فهرست همهٔ مقاله‌ها: https://hakanserver.com/blog/index.md
فهرست همهٔ صفحه‌ها و راهنمای سایت: https://hakanserver.com/llms.txt