خطای 522 کلودفلر چیست؟ راهنمای پیدا کردن علت قطع ارتباط با سرور

سایت را باز می‌کنید و به‌جای صفحه اصلی، پیام Error 522: Connection timed out می‌بینید. این خطا معمولاً یعنی کلودفلر در ارتباط با سرور اصلی سایت به پایان زمان انتظار رسیده است. سرور اصلی یا Origin همان جایی است که سایت شما واقعاً اجرا می‌شود؛ کلودفلر واسطه‌ای میان مرورگر و آن سرور است.

از روی شماره ۵۲۲ نمی‌توان با اطمینان گفت هاست خراب است، سرور حتماً شلوغ شده یا فایروال مقصر است. نشانی اشتباه سرور، اختلال شبکه، پاسخ‌ندادن سرویس یا محدودشدن درخواست‌های کلودفلر از علت‌های ممکن‌اند. ابتدا شواهد را جمع می‌کنیم و بعد فقط بخش مسئول را اصلاح می‌کنیم.

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

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

برای مقایسه، در خطای 521 سرور اصلی اتصال کلودفلر را رد می‌کند و در 524 کلودفلر به سرور وصل شده ولی پاسخ مورد انتظار را در مهلت مربوط دریافت نکرده است. روش تشخیص جزئیات هرکدام فرق دارد. برای خطاهای ۵۰۲ و ۵۰۴ نیز اول متن دقیق خطا و محل تولید آن را مشخص کنید؛ عنوان مشابه همیشه به معنی ریشه یکسان نیست.

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

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

در پنل Cloudflare دامنه را انتخاب کنید و به DNS ← Records بروید. رکوردی را پیدا کنید که برای نام آسیب‌دیده استفاده می‌شود؛ مثلاً برای www.example.com معمولاً رکورد www مهم است. example.com در این آموزش نام نمونه است و باید با نام خودتان جایگزین شود.

مقدار رکورد مربوط را با نشانی سرور اصلی که در پنل میزبانی یا مستندات مدیر سایت ثبت شده مقایسه کنید. اگر اخیراً هاست را منتقل کرده‌اید، ممکن است رکورد هنوز به سرور قبلی اشاره کند. برای رکورد CNAME، مقصد و تنظیمات سرویس مقصد را نیز بررسی کنید. اگر از Origin Rule یا تنظیم خاص مسیر استفاده می‌کنید، همان قانون می‌تواند مقصد واقعی را تغییر دهد.

یک نکته مهم: برای رکوردی که از پراکسی Cloudflare عبور می‌کند، نتیجه DNS عمومی معمولاً نشانی لبه Cloudflare را نشان می‌دهد؛ این نتیجه الزاماً IP سرور اصلی نیست. نشانی اصلی را از پنل معتبر سرویس یا مدیر زیرساخت بگیرید، نه با حدس از نتیجه جست‌وجوی DNS عمومی.

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

اگر دسترسی مدیریتی سرور دارید، در ترمینال SSH ابتدا وضعیت سرویس واقعی وب را ببینید. نمونه زیر فقط زمانی مناسب است که Nginx روی همان سرور نصب و سرویس مسئول سایت باشد:

اگر سرویس شما Apache یا وب‌سرور دیگری است، نام واحد واقعی آن را در مستندات سرور پیدا کنید. وضعیت failed یا خطاهای شروع، شما را به گزارش همان سرویس هدایت می‌کنند؛ وضعیت active نیز به‌تنهایی دسترسی Cloudflare از اینترنت را ثابت نمی‌کند.

برای یک سرویس دارای systemd، گزارش اخیر را با نام واحد واقعی ببینید:

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

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

این فرمان برای همین درخواست، نام example.com را به IP داده‌شده وصل می‌کند و نام سایت و بررسی گواهی HTTPS را حفظ می‌کند. اگر پاسخ HTTP دریافت شود، نشان می‌دهد از همان شبکه آزمایش‌کننده سرور روی آن مسیر پاسخی داده است؛ به‌تنهایی ثابت نمی‌کند همه سرورهای Cloudflare هم می‌توانند وصل شوند یا همه صفحه‌های سایت سالم‌اند.

اگر اتصال مستقیم از شبکه شما در فایروال مجاز نباشد، شکست این آزمون می‌تواند نتیجه همان محدودیت باشد. همچنین بعضی سرورها از گواهی Origin CA استفاده می‌کنند که مرورگر یا curl معمولی لزوماً به آن اعتماد ندارد، هرچند Cloudflare بتواند آن را برای ارتباط با origin اعتبارسنجی کند. در این حالت خطای اعتماد گواهی را با خطای شبکه یکی ندانید و از مدیر سرور بخواهید با زنجیره مورد اعتماد مناسب آزمون کند. بررسی امنیت گواهی را برای راحت‌تر شدن تست خاموش نکنید.

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

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

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

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

اگر مشکل ادامه دارد، نشانی صفحه، زمان با منطقه زمانی، Ray ID، نتیجه بررسی DNS و گزارش‌های مرتبط را بدون رمز و اطلاعات شخصی به مدیر سرور و در صورت نیاز پشتیبانی Cloudflare بدهید. اگر تغییری نتیجه را بدتر کرد، آن را طبق مقدار ثبت‌شده به حالت قبل برگردانید.

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