خطای 522 Connection Timed Out یکی از آن خطاهایی است که وقتی با آن روبه‌رو می‌شوم، بلافاصله به یاد پروژه‌ای می‌افتم که در آن یک هاست اشتراکی ارزان، درست در روز اوج ترافیک یک کمپین تبلیغاتی، سایت را به یک صفحه سفید با پیام «Connection timed out» تبدیل کرد. آن تجربه به من آموخت که این خطا تقریباً هرگز از سمت Cloudflare نیست؛ بلکه همیشه یک جای کار در لایه مبدأ (origin) می‌لنگد.

خطای 522 دقیقاً چیست و در کدام لایه شبکه رخ می‌دهد؟

خطای 522 Connection Timed Out یک کد وضعیت HTTP اختصاصی Cloudflare است که در محدوده کدهای 52x قرار می‌گیرد. این کدها برخلاف خطاهای استاندارد 500، 502 یا 504 که توسط خود سرور مبدأ تولید می‌شوند، توسط لبه شبکه Cloudflare ساخته می‌شوند. وقتی Cloudflare تلاش می‌کند یک اتصال TCP (Transmission Control Protocol) با سرور مبدأ برقرار کند و این اتصال در بازه زمانی مشخصی — که معمولاً حدود ۱۵ ثانیه است — کامل نشود، خطای 522 به کاربر نمایش داده می‌شود.

برای درک دقیق‌تر، باید فرآیند TCP Handshake را در نظر بگیریم. وقتی یک بازدیدکننده آدرس سایت را باز می‌کند، مرورگر او ابتدا یک بسته SYN به Cloudflare می‌فرستد. Cloudflare پاسخ SYN-ACK را برمی‌گرداند و مرورگر با ACK تأیید می‌کند. سپس Cloudflare به عنوان یک Reverse Proxy، یک اتصال جدید TCP با سرور مبدأ شما آغاز می‌کند. اینجاست که اگر سرور مبدأ در پاسخ به بسته SYN Cloudflare، بسته SYN-ACK را به موقع ارسال نکند، Cloudflare پس از سپری شدن مهلت مقرر، خطای 522 را ثبت و به کاربر نمایش می‌دهد.

نکته کلیدی این است که در خطای 522، برخلاف خطای 521 (Web Server Is Down)، سرور مبدأ کاملاً خاموش یا غیرقابل دسترس نیست. بلکه در دسترس است اما به قدری کند یا مشغول است که نمی‌تواند در زمان مقرر به درخواست اتصال پاسخ دهد. این تفاوت ظریف، مسیر عیب‌یابی را کاملاً تغییر می‌دهد. اگر خطای 521 دریافت می‌کنید، احتمالاً سرویس وب متوقف شده یا فایروال به طور کامل اتصال را رد می‌کند. اما در 522، سرور زنده است و گوش می‌دهد؛ فقط پاسخ‌دهی آن کند شده است.

از منظر معماری، خطای 522 یک Timeout در فاز CONNECT است، نه در فاز Read. یعنی Cloudflare حتی موفق نشده است اتصال TCP را کامل کند، چه برسد به اینکه درخواست HTTP را ارسال کند و منتظر پاسخ بماند. این تمایز مهم است، زیرا اگر اتصال TCP برقرار شده بود اما سرور مبدأ پاسخ HTTP را دیر می‌فرستاد، خطای 524 (A Timeout Occurred) رخ می‌داد، نه 522. بنابراین، 522 به لایه شبکه و پشته TCP مربوط می‌شود، نه به لایه اپلیکیشن و پردازش PHP.

ریشه‌های بروز خطای 522 Connection Timed Out

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

۱. اضافه‌بار سرور (Server Overload)

شایع‌ترین علت خطای 522، اشباع شدن منابع سرور مبدأ است. وقتی CPU به طور مداوم در حد ۱۰۰٪ کار می‌کند، حافظه RAM پر شده است و فرآیندهای وب‌سرور (مانند PHP-FPM یا Apache workers) توانایی پذیرش اتصال جدید را ندارند، بسته‌های SYN ورودی از Cloudflare در صف انتظار باقی می‌مانند و در نهایت تایم‌اوت می‌شوند. این وضعیت در هاست اشتراکی بسیار رایج‌تر است، زیرا منابع بین چندین سایت به اشتراک گذاشته می‌شود و یک همسایه پرمصرف می‌تواند کل سرور را تحت تأثیر قرار دهد.

در پروژه‌های وردپرسی، عواملی مانند نصب افزونه‌های سنگین، اجرای کوئری‌های غیربهینه در دیتابیس، یا حملات Brute Force به فایل xmlrpc.php می‌توانند به سرعت منابع سرور را تخلیه کنند. اگر با مشکل مصرف بالای CPU در وردپرس دست‌وپنجه نرم می‌کنید، مقاله رفع خطای افزایش مصرف CPU در وردپرس راهکارهای عملی را بررسی کرده است.

۲. فایروال و مسدودسازی IPهای Cloudflare

این مورد یکی از آن خطاهای پنهانی است که گاهی هفته‌ها طول می‌کشد تا کشف شود. وقتی Cloudflare را فعال می‌کنید، تمام ترافیک ورودی به سرور شما از IPهای Cloudflare می‌آید، نه از IP واقعی بازدیدکنندگان. اگر فایروال سرور (مثلاً iptables، UFW یا فایروال نرم‌افزاری در سطح سیستم‌عامل)، یک Web Application Firewall (WAF)، یا حتی یک افزونه امنیتی وردپرس، این محدوده‌های IP را به عنوان ترافیک مشکوک شناسایی و مسدود کند، عملاً تمام کاربران سایت شما قفل می‌شوند.

این مشکل به‌خصوص زمانی رخ می‌دهد که قوانین Rate Limiting بیش از حد سخت‌گیرانه تنظیم شده باشند. Cloudflare به عنوان یک واسط، تعداد زیادی اتصال همزمان از چند IP معدود برقرار می‌کند. یک فایروال ساده ممکن است این الگو را به عنوان حمله DDoS تفسیر کند و IPهای Cloudflare را بلاک کند. در چنین شرایطی، حتی اگر سرور کاملاً سالم باشد، هیچ درخواستی از Cloudflare عبور نمی‌کند و کاربر خطای 522 می‌بیند.

۳. تنظیمات نادرست DNS

رکورد A یا AAAA در منطقه DNS Cloudflare باید به IP صحیح سرور مبدأ اشاره کند. اگر سرور را مهاجرت داده‌اید و فراموش کرده‌اید رکورد DNS را به‌روزرسانی کنید، Cloudflare به طور مداوم درخواست‌ها را به یک IP اشتباه یا غیرفعال ارسال می‌کند. در این حالت، حتی اگر سرور جدید شما کاملاً آماده باشد، Cloudflare هرگز به آن نمی‌رسد و خطای 522 رخ می‌دهد.

نکته فنی مهم این است که در معماری Cloudflare، اگر رکورد DNS به IP اشتباهی اشاره کند که هیچ سرویسی روی پورت 80 یا 443 آن گوش نمی‌دهد، معمولاً خطای 521 یا 523 رخ می‌دهد. اما اگر آن IP اشتباه به سروری تعلق داشته باشد که فایروال آن بسته‌های SYN را بی‌صدا Drop می‌کند (بدون ارسال RST)، نتیجه یک Connection Timeout و خطای 522 خواهد بود. به همین دلیل، بررسی تطابق رکورد DNS با IP واقعی سرور، اولین قدم در عیب‌یابی است.

۴. غیرفعال بودن KeepAlive در سرور

Cloudflare از هدر HTTP Keep-Alive برای حفظ اتصالات پایدار TCP استفاده می‌کند. مزیت این مکانیزم آن است که برای هر درخواست جدید، نیازی به انجام مجدد TCP Handshake نیست و اتصال قبلی دوباره استفاده می‌شود. اگر سرور مبدأ شما KeepAlive را غیرفعال کرده باشد یا مقدار KeepAliveTimeout آن بسیار پایین باشد، سرور پس از هر درخواست اتصال را می‌بندد. در ترافیک بالا، Cloudflare مجبور می‌شود برای هر درخواست یک اتصال جدید برقرار کند و در این میان، برخی از این تلاش‌ها به دلیل اشباع شدن صف اتصالات، تایم‌اوت می‌شوند.

برای فعال‌سازی KeepAlive در Apache، می‌توانید به فایل .htaccess یا فایل پیکربندی httpd.conf مراجعه کنید. برای مثال، افزودن این خطوط به .htaccess می‌تواند اتصالات را پایدار نگه دارد:

<IfModule mod_headers.c>
    Header set Connection keep-alive
</IfModule>

در سرورهای Nginx، پارامتر keepalive_timeout در بلوک http یا server کنترل‌کننده این رفتار است. مقدار پیشنهادی معمولاً بین ۵ تا ۱۵ ثانیه است. اگر این مقدار بسیار پایین (مثلاً ۱ ثانیه) تنظیم شده باشد، عملاً KeepAlive بی‌اثر می‌شود.

۵. مشکلات شبکه و مسیریابی (Routing Issues)

گاهی اوقات، مشکل نه در سرور شما و نه در Cloudflare، بلکه در مسیر شبکه بین آن‌هاست. مشکلاتی مانند Packet Loss، پیکربندی نادرست BGP در سطح ISP، یا خرابی موقت در شبکه ارائه‌دهنده هاستینگ می‌تواند باعث شود بسته‌های SYN Cloudflare هرگز به سرور مبدأ نرسند یا پاسخ آن‌ها گم شود. در این حالت، هیچ تغییری در تنظیمات سرور شما مشکل را حل نمی‌کند و باید با پشتیبانی هاستینگ تماس بگیرید تا مسیر شبکه را بررسی کنند.

برای تشخیص این نوع مشکل، می‌توانید از ابزار Traceroute از سمت سرور به سمت IPهای Cloudflare یا برعکس استفاده کنید. اگر در خروجی Traceroute، در چند هاپ متوالی ستاره (* * *) مشاهده کردید، نشانه Packet Loss در آن مسیر است.

۶. آفلاین بودن سرویس وب (Web Server Offline)

اگرچه این مورد به خطای 521 (Web Server Is Down) نزدیک‌تر است، اما در برخی پیکربندی‌ها، وقتی سرویس وب متوقف می‌شود اما سیستم‌عامل همچنان فعال است و فایروال بسته‌ها را Drop می‌کند (نه Reject)، Cloudflare ممکن است به جای 521، خطای 522 دریافت کند. این وضعیت معمولاً پس از یک Crash در PHP-FPM یا اتمام حافظه رخ می‌دهد. بررسی لاگ‌های سیستم با دستور journalctl -u php-fpm یا tail -f /var/log/nginx/error.log می‌تواند سرنخ‌های ارزشمندی ارائه دهد.

روش‌های عملی تشخیص علت خطای 522

وقتی با خطای 522 مواجه می‌شوید، اولین واکنش بسیاری از توسعه‌دهندگان — و متأسفانه خود من در سال‌های ابتدایی — ری‌استارت کردن سرور است. این کار ممکن است موقتاً مشکل را حل کند، اما بدون شناخت ریشه‌ای، خطا دوباره بازمی‌گردد. روش صحیح عیب‌یابی را می‌توان در قالب یک فرآیند گام‌به‌گام دنبال کرد:

گام اول: بررسی دسترسی مستقیم به سرور

قبل از هر چیز، باید مشخص کنید که آیا سرور مبدأ از بیرون قابل دسترسی است یا خیر. اگر به SSH دسترسی دارید، با دستور curl -I http://localhost یا curl -I https://localhost بررسی کنید که سرویس وب روی خود سرور پاسخ می‌دهد یا خیر. اگر پاسخ دریافت کردید، بدانید که سرویس وب فعال است و مشکل احتمالاً در لایه فایروال یا DNS است. اگر پاسخی دریافت نکردید، سرویس وب متوقف شده یا روی پورت اشتباهی گوش می‌دهد.

اگر SSH ندارید، می‌توانید از یک ابزار آنلاین مانند Uptrends یا Downdetector استفاده کنید تا بررسی کنید که آیا سایت از نقاط مختلف جهان قابل دسترسی است یا خیر. اگر سایت از برخی نقاط پاسخ می‌دهد و از برخی دیگر نه، احتمال مشکل شبکه‌ای یا DNS تقویت می‌شود.

گام دوم: بررسی پورت‌های 80 و 443

با دستور netstat -tlnp | grep -E ':80|:443' بررسی کنید که آیا پورت‌های 80 و 443 در حالت LISTEN هستند. اگر هیچ سرویسی روی این پورت‌ها گوش نمی‌دهد، خطای 522 قطعی است. همچنین با دستور iptables -L -n یا ufw status قوانین فایروال را بررسی کنید. مطمئن شوید که محدوده IPهای Cloudflare در قوانین فایروال مسدود نشده باشند. لیست به‌روز IPهای Cloudflare در صفحه رسمی آن‌ها قابل دریافت است.

گام سوم: بررسی تنظیمات DNS در Cloudflare

وارد پنل Cloudflare شوید و به بخش DNS بروید. بررسی کنید که رکورد A یا CNAME دامنه اصلی و زیردامنه www به IP صحیح سرور مبدأ اشاره می‌کند. اگر اخیراً سرور را تغییر داده‌اید، احتمالاً این رکوردها هنوز به IP قدیمی اشاره می‌کنند. همچنین بررسی کنید که آیا رکورد AAAA (IPv6) وجود دارد یا خیر. اگر سرور شما از IPv6 پشتیبانی نمی‌کند اما رکورد AAAA فعال است، Cloudflare ممکن است تلاش کند از طریق IPv6 به سرور متصل شود و با Timeout مواجه شود. در این حالت، یا رکورد AAAA را حذف کنید یا IPv6 را روی سرور فعال کنید.

گام چهارم: بررسی لاگ‌های سرور

لاگ‌های وب‌سرور (مانند access.log و error.log در Apache یا Nginx) و لاگ‌های PHP (مانند php_errors.log) می‌توانند نشان دهند که آیا درخواست‌ها به سرور می‌رسند یا خیر. اگر در لاگ‌ها هیچ درخواستی از IPهای Cloudflare ثبت نشده باشد، بدانید که مشکل در لایه فایروال یا شبکه است. اگر درخواست‌ها ثبت شده‌اند اما با خطاهای Timeout یا اتمام منابع مواجه شده‌اند، ریشه مشکل در خود سرور است.

برای مشاهده لاگ‌های Nginx به صورت زنده:

tail -f /var/log/nginx/error.log

برای مشاهده لاگ‌های PHP-FPM:

tail -f /var/log/php8.2-fpm.log

گام پنجم: تست از بیرون با ابزارهای آنلاین

ابزارهایی مانند curl از یک سرور دیگر، یا سرویس‌های آنلاین مانند Pingdom یا GTmetrix می‌توانند به شما بگویند که آیا سایت از نقاط مختلف پاسخ می‌دهد یا خیر. اگر سایت از سرور خودتان (لوکال) پاسخ می‌دهد اما از بیرون نه، مشکل در فایروال یا NAT است. برای مثال:

curl -v -H "Host: example.com" http://YOUR_SERVER_IP

اگر این دستور پاسخ داد، یعنی سرور از بیرون قابل دسترسی است و مشکل احتمالاً در تنظیمات Cloudflare یا DNS است.

راه‌حل‌های اصولی رفع خطای 522

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

راه‌حل اول: کاهش بار سرور و بهینه‌سازی منابع

اگر تشخیص دادید که سرور Overload شده است، باید منابع را آزاد کنید. اولین قدم شناسایی فرآیندهای پرمصرف است. با دستور top یا htop می‌توانید ببینید کدام فرآیندها بیشترین CPU و RAM را مصرف می‌کنند. اگر PHP-FPM بیش از حد فرآیند ایجاد کرده است، مقدار pm.max_children را در فایل www.conf کاهش دهید. مقدار پیشنهادی برای یک سرور با ۲ گیگابایت RAM حدود ۱۰ تا ۱۵ فرآیند است.

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

راه‌حل دوم: پیکربندی صحیح فایروال و Whitelist کردن IPهای Cloudflare

اگر فایروال سرور، IPهای Cloudflare را مسدود کرده است، باید آن‌ها را در لیست سفید قرار دهید. لیست رسمی IPهای Cloudflare در آدرس https://www.cloudflare.com/ips/ قابل دریافت است. این لیست شامل محدوده‌های IPv4 و IPv6 است. بسته به نوع فایروال، روش افزودن این محدوده‌ها متفاوت است:

برای iptables:

for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
    iptables -I INPUT -p tcp -s $ip --dport 80 -j ACCEPT
    iptables -I INPUT -p tcp -s $ip --dport 443 -j ACCEPT
done

برای UFW:

for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
    ufw allow from $ip to any port 80,443 proto tcp
done

نکته مهم: اگر از یک افزونه امنیتی وردپرس مانند Wordfence یا Sucuri استفاده می‌کنید، مطمئن شوید که گزینه «Trust Cloudflare IPs» یا معادل آن فعال است. در غیر این صورت، افزونه ممکن است IPهای Cloudflare را به عنوان IP بازدیدکننده واقعی در نظر بگیرد و بر اساس آن‌ها Rate Limit اعمال کند.

راه‌حل سوم: تصحیح رکوردهای DNS

اگر رکورد DNS اشتباه است، آن را به IP صحیح سرور مبدأ تغییر دهید. توصیه می‌کنم قبل از تغییر، یک نسخه پشتیبان از تنظیمات DNS تهیه کنید. پس از تغییر، ممکن است چند دقیقه تا چند ساعت طول بکشد تا Propagation DNS کامل شود. برای بررسی وضعیت Propagation، از ابزارهایی مانند dnschecker.org استفاده کنید.

نکته فنی: اگر از Cloudflare به عنوان Reverse Proxy استفاده می‌کنید (ابر نارنجی فعال است)، باید رکورد A به IP سرور مبدأ اشاره کند، نه به IP Cloudflare. اشتباه رایجی که دیده‌ام این است که برخی توسعه‌دهندگان IP Cloudflare را به عنوان IP مبدأ وارد می‌کنند و باعث ایجاد یک حلقه بی‌پایان می‌شوند.

راه‌حل چهارم: فعال‌سازی KeepAlive در سرور

همان‌طور که اشاره شد، فعال‌سازی KeepAlive می‌تواند تعداد اتصالات TCP جدید را کاهش دهد و بار سرور را کم کند. در Apache، مطمئن شوید که ماژول mod_headers فعال است و خطوط زیر در .htaccess یا httpd.conf وجود دارد:

KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5

مقدار KeepAliveTimeout را بیش از حد بالا نبرید (مثلاً ۳۰ ثانیه)، زیرا این کار باعث اشغال بی‌مورد فرآیندهای سرور توسط اتصالات بیکار می‌شود. مقدار ۵ ثانیه یک تعادل منطقی است.

راه‌حل پنجم: تماس با پشتیبانی هاستینگ

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

  • آیا محدودیت Bandwidth یا Connection در سطح سرور اعمال شده است؟
  • آیا مسیر شبکه بین Cloudflare و سرور دچار Packet Loss است؟
  • آیا سرویس‌های جانبی مانند MySQL یا Redis باعث Timeout می‌شوند؟

در برخی موارد، هاستینگ‌های اشتراکی به دلیل محدودیت‌های سخت‌گیرانه‌ای که در قوانین خود دارند، به طور خودکار تعداد اتصالات همزمان از یک IP (یعنی Cloudflare) را محدود می‌کنند. اگر سایت شما ترافیک بالایی دارد، ممکن است نیاز به ارتقا به VPS یا سرور اختصاصی داشته باشید. مقاله هاست چیست و چگونه انتخاب درستی داشته باشیم؟ می‌تواند در این تصمیم‌گیری به شما کمک کند.

اشتباهات رایج در مواجهه با خطای 522

در طول سال‌ها، اشتباهات تکراری زیادی را دیده‌ام که توسعه‌دهندگان — از جمله خودم در گذشته — مرتکب شده‌اند. این اشتباهات نه‌تنها مشکل را حل نمی‌کنند، بلکه می‌توانند آن را پیچیده‌تر کنند.

اشتباه اول: ری‌استارت کورکورانه سرور

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

اشتباه دوم: غیرفعال کردن کامل Cloudflare

بعضی از توسعه‌دهندگان برای «تست» خطای 522، Cloudflare را به طور کامل غیرفعال می‌کنند (Pause Cloudflare). این کار ممکن است سایت را موقتاً بالا بیاورد، اما شما را از مزایای CDN، امنیت و کش محروم می‌کند و در عین حال مشکل اصلی را پنهان می‌سازد. بهتر است به جای غیرفعال کردن کامل، حالت Proxy را برای یک رکورد خاص به «DNS Only» تغییر دهید تا مشکل را ایزوله کنید.

اشتباه سوم: افزودن IPهای Cloudflare به Blacklist به جای Whitelist

این اشتباه به‌خصوص در فایروال‌های نرم‌افزاری رخ می‌دهد. وقتی یک Rule به اشتباه IPهای Cloudflare را Block می‌کند، نه‌تنها خطای 522 رخ می‌دهد، بلکه تمام بازدیدکنندگان واقعی نیز از دسترسی محروم می‌شوند. همیشه قوانین فایروال را با دقت بازبینی کنید و محدوده IPهای Cloudflare را در لیست سفید قرار دهید.

اشتباه چهارم: نادیده گرفتن تفاوت 522 و 524

همان‌طور که اشاره شد، خطای 522 مربوط به فاز CONNECT است، در حالی که 524 مربوط به فاز Read است. اگر برای رفع 524 (که معمولاً به دلیل اجرای طولانی یک اسکریپت PHP رخ می‌دهد) از راه‌حل‌های 522 (مانند بررسی فایروال) استفاده کنید، هرگز به نتیجه نمی‌رسید. ابتدا باید نوع دقیق خطا را از طریق ابزارهای توسعه‌دهنده مرورگر یا لاگ‌های Cloudflare شناسایی کنید.

اشتباه پنجم: عدم بررسی لاگ‌های Cloudflare

Cloudflare لاگ‌های دقیقی از خطاهای 5xx ارائه می‌دهد. در پنل Cloudflare، بخش Analytics → Traffic یا Logs (در پلن‌های Enterprise) می‌توانید ببینید که خطای 522 از کدام نقطه (Colo) و برای کدام URLها رخ می‌دهد. اگر خطا فقط برای یک مسیر خاص (مثلاً /wp-admin/admin-ajax.php) رخ دهد، احتمالاً یک افزونه یا اسکریپت خاص باعث Timeout می‌شود. اگر خطا برای تمام مسیرها رخ دهد، مشکل در سطح سرور یا فایروال است.

پرسش‌های پرتکرار درباره خطای 522

آیا خطای 522 از سمت Cloudflare است؟

خیر. خطای 522 یک کد اختصاصی Cloudflare است، اما نشان‌دهنده مشکل در ارتباط بین Cloudflare و سرور مبدأ شماست. در بیش از ۹۵٪ موارد، ریشه مشکل در سمت سرور مبدأ، فایروال، یا تنظیمات DNS قرار دارد، نه در زیرساخت Cloudflare. Cloudflare صرفاً این واقعیت را گزارش می‌کند که نمی‌تواند به موقع با سرور شما ارتباط برقرار کند.

تفاوت خطای 522 با 521 چیست؟

در خطای 521، سرور مبدأ به طور فعال اتصال را رد می‌کند (Connection Refused). این بدان معناست که سرویس وب روی پورت 80 یا 443 گوش نمی‌دهد یا فایروال به طور صریح بسته RST ارسال می‌کند. اما در خطای 522، سرور زنده است و بسته‌های SYN را دریافت می‌کند، اما در بازه زمانی مقرر پاسخ SYN-ACK را ارسال نمی‌کند. به عبارت دیگر، 521 یعنی «کسی در را باز نمی‌کند» و 522 یعنی «کسی در را باز می‌کند اما آن‌قدر کند که دیر می‌شود».

آیا خطای 522 می‌تواند ناشی از مشکل بازدیدکننده باشد؟

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

چگونه بفهمم خطای 522 از کدام نقطه جغرافیایی رخ می‌دهد؟

در پنل Cloudflare، بخش Analytics → Traffic را باز کنید. در نمودار Status Codes، می‌توانید تعداد خطاهای 522 را در بازه‌های زمانی مختلف ببینید. اگر روی بخش 522 کلیک کنید، می‌توانید ببینید که این خطاها از کدام دیتاسنترهای Cloudflare (مثلاً FRA برای فرانکفورت، AMS برای آمستردام) گزارش شده‌اند. اگر خطا فقط از یک دیتاسنتر خاص رخ می‌دهد، احتمالاً مشکل در مسیر شبکه بین آن دیتاسنتر و سرور شماست.

آیا افزونه‌های امنیتی وردپرس می‌توانند باعث خطای 522 شوند؟

بله. برخی از افزونه‌های امنیتی مانند Wordfence، Sucuri، یا iThemes Security دارای قابلیت Rate Limiting هستند. اگر این افزونه‌ها IPهای Cloudflare را به عنوان IP بازدیدکننده واقعی در نظر بگیرند (به جای IP واقعی کاربر که در هدر CF-Connecting-IP ارسال می‌شود)، ممکن است محدودیت نرخ را روی IPهای Cloudflare اعمال کنند و باعث مسدود شدن ترافیک شوند. برای جلوگیری از این مشکل، در تنظیمات افزونه امنیتی، گزینه «Trust Cloudflare IPs» یا «Use Cloudflare IP Header» را فعال کنید.

آیا تغییر سرور همیشه خطای 522 را حل می‌کند؟

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

نگاه مهندسی پیشرفته به خطای 522

از دیدگاه یک مهندس ارشد زیرساخت، خطای 522 یک پیام‌رسان است، نه یک بیماری. این خطا به شما می‌گوید که در لایه TCP/IP، یک گلوگاه وجود دارد. برای مهندسانی که در مقیاس بزرگ کار می‌کنند، این خطا معمولاً نشانه‌ای از یک Backpressure در سیستم است: سرور مبدأ نمی‌تواند به اندازه کافی سریع اتصالات جدید را بپذیرد.

یکی از مفاهیم کلیدی در این سطح، SYN Queue Overflow است. وقتی سرور لینوکس بسته SYN دریافت می‌کند، آن را در یک صف به نام syn backlog قرار می‌دهد. اگر نرخ ورود بسته‌های SYN از نرخ پردازش آن‌ها توسط کرنل بیشتر شود، این صف پر می‌شود و بسته‌های جدید Drop می‌شوند. نتیجه، Timeout از دید Cloudflare است. مهندسان می‌توانند با تنظیم پارامترهای کرنل مانند net.ipv4.tcp_max_syn_backlog و net.core.somaxconn اندازه این صف‌ها را افزایش دهند:

sysctl -w net.ipv4.tcp_max_syn_backlog=4096
sysctl -w net.core.somaxconn=4096

نکته مهم دیگر، تفاوت بین Timeout در لایه TCP و Timeout در لایه اپلیکیشن است. در خطای 522، Cloudflare در فاز TCP Handshake تایم‌اوت می‌کند. این بدان معناست که حتی اگر PHP-FPM شما پاسخ‌دهی سریعی داشته باشد، اگر پشته شبکه سرور نتواند اتصال را بپذیرد، خطا رخ می‌دهد. به همین دلیل، بررسی سلامت پشته TCP سرور (با ابزارهایی مانند ss -s و netstat -s) به همان اندازه بررسی لاگ‌های PHP اهمیت دارد.

در معماری‌های توزیع‌شده، خطای 522 می‌تواند نشانه‌ای از عدم تطابق ظرفیت بین لبه (Cloudflare) و مبدأ باشد. Cloudflare ظرفیت پذیرش میلیون‌ها اتصال همزمان را دارد، اما اگر سرور مبدأ شما فقط توان پذیرش چند صد اتصال را داشته باشد، این عدم تعادل منجر به Timeout می‌شود. راه‌حل بلندمدت، استفاده از یک لایه میانی مانند Load Balancer یا Reverse Proxy (مانند Nginx در حالت proxy_cache) است که بتواند اتصالات ورودی را بافر کند و به مبدأ فرصت پردازش دهد.

در نهایت، برای مهندسانی که با Kubernetes یا محیط‌های ابری کار می‌کنند، خطای 522 می‌تواند ناشی از تنظیمات نادرست Readiness Probe باشد. اگر Pod شما به اشتباه در حالت Not Ready قرار گیرد، Load Balancer ابری ترافیک را به آن ارسال نمی‌کند و Cloudflare با Timeout مواجه می‌شود. بررسی دقیق kubelet و endpoints در این سناریو ضروری است.

نتیجه‌گیری

خطای 522 Connection Timed Out، اگرچه در نگاه اول ترسناک به نظر می‌رسد، اما در واقع یک سیگنال قابل اعتماد است: سرور شما زنده است، اما نمی‌تواند به موقع پاسخ دهد. این خطا شما را از سردرگمی «آیا سرور خاموش است یا نه؟» نجات می‌دهد و مستقیماً انگشت اتهام را به سمت گلوگاه‌های عملکردی، فایروال، یا پیکربندی شبکه نشانه می‌رود.

تجربه من در ده‌ها پروژه نشان داده است که بیش از ۸۰٪ موارد خطای 522 با یکی از این سه اقدام حل می‌شود: بهینه‌سازی منابع سرور، Whitelist کردن IPهای Cloudflare در فایروال، و تصحیح رکوردهای DNS. اما برای حل ریشه‌ای، باید فراتر از این اقدامات رفت و به لایه‌های پایین‌تر پشته شبکه — از SYN Queue تا پیکربندی KeepAlive — نگاه کرد. تنها در این صورت است که می‌توان از بازگشت خطا در اوج ترافیک جلوگیری کرد.

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