اگه تو بخش «سلامت سایت» وردپرس پیام «Your site could not complete a loopback request» رو دیدی، نگران نباش؛ این یکی معمولاً قابل حله. رفع خطای Loopback Request از چند بررسی ساده شروع میشه: افزونه‌ها، آدرس سایت، SSL و محدودیت‌های هاست. تو این مقاله قدم‌به‌قدم می‌ریم جلو تا ریشه‌ی خطا رو پیدا کنی. فقط یادت باشه علت دقیق از سایتی به سایت دیگه فرق می‌کنه؛ پس اینا نقطه‌ی شروع عیب‌یابین، نه نسخه‌ی قطعی.
هشدار پیش‌نیاز: قبل از هر تغییری تو افزونه‌ها، قالب یا تنظیمات هاست، حتماً یه فول‌بکاپ (فایل‌ها و دیتابیس) بگیر. با بکاپ، اگه چیزی خلاف انتظار پیش رفت، می‌تونی به وضعیت قبل برگردی.
خطای Loopback Request در وردپرس چیست؟
درخواست لوپ‌بک (Loopback Request) یعنی سایتت از سمت سرور به آدرس خودش درخواست می‌فرسته. مثل اینه که با گوشیت به شماره‌ی خودت زنگ بزنی تا ببینی خط سالمه یا نه. اگه این درخواست جواب درستی نگیره، وردپرس خطای Loopback رو نشون میده.
درخواست Loopback چگونه کار می‌کند؟
Site Health برای تست Loopback یه درخواست HTTP از سمت سرور به آدرس خود سایت می‌فرسته و منتظر جواب می‌مونه. این درخواست از مرورگر خودت نمیاد؛ از خود سرور میاد. افزونه‌ها و قالب‌ها هم برای ویرایشگر کد و بعضی ابزارهای داخلی از همین مسیر استفاده می‌کنن. اگه جواب سالم (معمولاً با کد ۲۰۰) برگرده، همه‌چیز عادیه. اگه فایروال، افزونه‌ی امنیتی، آدرس اشتباه یا کندی سرور وسط راه باشه، درخواست رد میشه یا بی‌جواب می‌مونه.
ارتباط Loopback با WP-Cron و وظایف پس‌زمینه
WP-Cron سیستم زمان‌بندی وردپرسه؛ کارهایی مثل انتشار نوشته‌های زمان‌بندی‌شده یا بررسی آپدیت‌ها رو انجام میده. مثل کرون واقعی سرور مدام در حال اجرا نیست؛ با بازدید از سایت بیدار میشه و وردپرس تو بازدیدها یه درخواست HTTP غیرمسدودکننده به wp-cron.php می‌فرسته. لوپ‌بک دقیقاً همین‌جا وارد ماجرا میشه. پس اگه این درخواست مسدود بشه، کارهای زمان‌بندی‌شده دیر اجرا میشن یا اجرا نمیشن.
البته این تنها دلیل نیست؛ اگه DISABLE_WP_CRON تو wp-config.php روی true باشه، وردپرس خودش کرون رو اجرا نمی‌کنه و باید یه کرون واقعی سمت سرور تنظیم شده باشه. برای جزئیات می‌تونی مستندات رسمی Cron در وردپرس رو ببینی.
علت خطای Loopback Request در هاست اشتراکی چیست؟
تو هاست اشتراکی معمولاً یکی از این چهار دسته پشت خطاست:
- افزونه یا قالب
- فایروال و محدودیت منابع
- آدرس، DNS یا SSL
- خطای PHP
جدول زیر مقایسه‌ی سریعشونه؛ بعدش هر مورد رو جدا توضیح میدیم.
| علت احتمالی | نشانه‌ی رایج | اولین بررسی | نیاز به پشتیبانی هاست؟ |
|---|---|---|---|
| تداخل افزونه | خطا بعد از نصب یا آپدیت افزونه شروع شده | غیرفعال‌سازی مرحله‌ای | معمولاً خیر |
| قالب غیراستاندارد | خطا با تعویض قالب برطرف میشه | تست با قالب پیش‌فرض | معمولاً خیر |
| آدرس‌های نادرست | تفاوت http/https یا www | مقایسه‌ی دو آدرس | معمولاً خیر |
| SSL ناقص | cURL 60 یا هشدار مرورگر | بررسی اعتبار و نصب کامل گواهی | گاهی |
| فایروال یا محدودیت سرور | کد ۴۰۳ | بررسی افزونه‌های امنیتی، سپس لاگ | معمولاً بله |
| کمبود منابع | cURL 28 یا کندی | بررسی مصرف منابع در پنل | معمولاً بله |
| DNS | cURL 6 | بررسی نیم‌سرور و رکوردها | معمولاً بله |
تداخل افزونه‌ها یا قالب‌های غیراستاندارد
افزونه‌هایی که بیشتر درگیرش میشن:
- افزونه‌های کش
- افزونه‌های امنیتی
- افزونه‌های سئو
- افزونه‌های حالت تعمیر (Maintenance)
- افزونه‌های ریدایرکت
مثلاً یه افزونه‌ی امنیتی ممکنه درخواست خود سرور رو مشکوک ببینه، یا حالت تعمیر همه‌ی درخواست‌ها رو به صفحه‌ی «به‌زودی» بفرسته. قالب‌های غیراستاندارد هم گاهی همین‌جوری عمل می‌کنن. غیرفعال‌کردن موقت و تست مرحله‌ای معمولاً مقصر رو نشون میده.
محدودیت‌های فایروال و قوانین امنیتی سرور
بعضی فایروال‌ها (مثل ModSecurity؛ فایروال برنامه‌ی وب که درخواست‌های مشکوک به سرور را فیلتر می‌کند) یا سرویس‌هایی مثل Cloudflare ممکنه درخواست داخلی سایتت رو اشتباهی تهدید حساب کنن. بعضی هاست‌ها هم برای حفظ پایداری سرور، درخواست‌های داخلی رو محدود می‌کنن؛ برای همین پرسیدن از پشتیبانی بی‌فایده نیست.
محدودیت منابع هم نقش داره: اگه پردازش‌های هم‌زمان حسابت به سقف برسه، درخواست لوپ‌بک ممکنه معطل بمونه یا رد بشه. اگه می‌خوای این مفاهیم رو بهتر بشناسی، تفاوت PHP Worker و Entry Process و NPROC در هاست چیست؟ شروع خوبین.
اختلال در DNS، گواهینامه SSL یا آدرس سایت
اگه آدرس‌های تنظیمات وردپرس با آدرس واقعی سایت نخونه (مثلاً http در یکی و https در اون یکی)، درخواست گم میشه یا تو ریدایرکت‌های پشت‌سرهم می‌افته. مشکل DNS یعنی سرور نمی‌تونه دامنه‌ات رو به IP تبدیل کنه؛ بعد از جابه‌جایی هاست یا تغییر نیم‌سرور بیشتر پیش میاد. گواهی SSL منقضی یا ناقص هم می‌تونه خطایی مثل cURL error 60 بده.
خطاهای PHP و نشست‌های فعال سرور
خطای PHP (مثل Fatal Error) باعث میشه صفحه‌ای که درخواست بهش رفته جواب سالم نده. نشست‌های PHP (Session) هم مورد شناخته‌شده‌ای هستن: وقتی یه درخواست نشست رو باز نگه می‌داره، درخواست‌های هم‌زمان با همون نشست منتظر می‌مونن. این معمولاً وقتی پیش میاد که یه افزونه یا قالب session_start() رو بدون بستن نشست صدا بزنه. وردپرس خودش به‌طور پیش‌فرض از نشست PHP استفاده نمی‌کنه، پس مشکل معمولاً از خود وردپرس نیست.
چگونه خطای Loopback را در Site Health بررسی کنیم؟
نگران نباش، این مرحله ساده‌ست.
مسیر پیدا کردن پیام خطا در پیشخوان
- تو پیشخوان وردپرس برو به «ابزارها» > «سلامت سایت».
- روی تب «وضعیت» (Status) بزن.
- زیر «مشکلات بحرانی» یا «بهبودهای توصیه‌شده» دنبال پیامی شبیه «سایت شما نتوانست درخواست Loopback را کامل کند» بگرد.
- روی پیکان کنار پیام بزن تا جزئیات باز بشه.
عنوان دقیق پیام بسته به نسخه و زبان وردپرس فرق می‌کنه.
تفاوت پیام عمومی وردپرس با کدهای HTTP و cURL
پیام عمومی فقط می‌گه ارتباط برقرار نشده، ولی دلیلش رو نمی‌گه؛ مثل مکانیکی که بگه «ماشین روشن نمیشه». کد HTTP یا cURL مثل دستگاه دیاگ نشون میده سراغ کدوم قسمت بری. معمولاً زیر پیام، متن خطا یا کدی مثل ۴۰۳، ۵۰۰ یا cURL error 28 هم نمایش داده میشه؛ دنبالش بگرد. اگه کدی ندیدی، باید از لاگ‌ها کمک بگیری یا افزونه‌ها و تنظیمات رو مرحله‌ای تست کنی.
روش‌های عملی رفع خطای Loopback در وردپرس
رفع خطای Loopback Request معمولاً با سه بررسی شروع میشه: آدرس‌ها، افزونه‌ها و قالب. به همین ترتیب جلو برو و بعد از هر مرحله Site Health رو دوباره چک کن.
نکته ایمنی: تعویض موقت قالب یا غیرفعال‌کردن افزونه‌ها معمولاً به محتوای سایت (نوشته‌ها، صفحات، محصولات) آسیب نمی‌زنه. ولی ممکنه چیدمان ویجت‌ها و منوها موقتاً عوض بشه و بعضی امکانات مثل پرداخت یا فرم‌ها از کار بیفتن. اگه سایتت فروشگاهیه یا مشتری فعال داره، تست رو تو ساعت کم‌بازدید یا روی نسخه‌ی آزمایشی (Staging) انجام بده.
بررسی تطابق WordPress Address و Site Address
اول برو «تنظیمات» > «عمومی» و «نشانی وردپرس (URL)» و «نشانی سایت (URL)» رو مقایسه کن. معمولاً باید یکی باشن، مگه اینکه عمداً وردپرس رو تو زیرپوشه نصب کرده باشی. اگه یکی با https و اون یکی با http شروع بشه، درخواست داخلی ممکنه به مشکل بخوره.
اگه این فیلدها خاکستری و غیرقابل ویرایش بودن، احتمالاً آدرس‌ها تو wp-config.php با ثابت‌های WP_HOME و WP_SITEURL (ثابت‌هایی در فایل wp-config.php که آدرس اصلی وردپرس و آدرس سایت را مشخص می‌کنند) تنظیم شدن و باید از اونجا عوضشون کنی. رمز عبور سطح سرور (Basic Auth) هم می‌تونه جلوی درخواست داخلی رو بگیره و خطای ۴۰۱ بده.
تست غیرفعال‌سازی افزونه‌ها به روش کنترل‌شده
- برو «افزونه‌ها» > «افزونه‌های نصب‌شده» و تیک انتخاب همه رو بزن.
- از منوی «کارهای دسته‌جمعی» گزینه‌ی «غیرفعال‌سازی» رو انتخاب کن و «اجرا» رو بزن.
- Site Health رو دوباره چک کن. اگه خطا رفت، احتمالاً یکی از افزونه‌ها نقش داشته.
- افزونه‌ها رو یکی‌یکی فعال کن و بعد از هر کدوم، Site Health رو رفرش کن تا مورد مشکل‌ساز پیدا بشه.
اگه خطا با غیرفعال‌بودن همه‌ی افزونه‌ها هم موند، مشکل احتمالاً جای دیگه‌ایه (مثل قالب یا سرور).
بازگشت موقت به قالب پیش‌فرض
حالا نوبت قالبه. از «نمایش» > «پوسته‌ها» یه قالب رسمی وردپرس (مثل Twenty Twenty-Four) رو موقتاً فعال کن و Site Health رو چک کن. اگه خطا رفت، قالب فعلی احتمالاً نقش داره و بهتره کدهاش رو با طراح سایت بررسی کنی. بعد از تست، قالب اصلی رو برگردون.
بررسی سلامت REST API، پیوندهای یکتا و HTTPS
لوپ‌بک و REST API ارتباط نزدیکی دارن؛ اگه تو Site Health خطایی درباره‌ی REST API دیدی، اون رو هم بررسی کن. یه کار ساده‌ی دیگه: برو «تنظیمات» > «پیوندهای یکتا» و بدون تغییر چیزی، «ذخیره تغییرات» رو بزن. این کار قوانین بازنویسی آدرس‌ها رو دوباره می‌سازه و گاهی مسیریابی رو درست می‌کنه. ممکنه جواب نده، ولی ریسکش کمه. راهنمای رسمی صفحه‌ی Site Health هم برای آشنایی با این صفحه خوبه.
خلاصه‌ی سریع: اول آدرس‌ها، بعد افزونه‌ها، بعد قالب. بعد از هر مرحله Site Health رو چک کن و اگه نتیجه نگرفتی، سراغ لاگ‌ها و پشتیبانی هاست برو.
کدهای رایج خطای Loopback و راه تشخیص هرکدام
کد خطا بهترین راهنمای توئه. «علت احتمالی» تو جدول یعنی محتمل‌ترین حالت، نه تشخیص قطعی.
| کد خطا یا پیام | علت احتمالی | روش بررسی پیشنهادی |
|---|---|---|
| HTTP 403 | احتمالاً مسدودشدن توسط فایروال یا افزونه‌ی امنیتی | بررسی افزونه‌های امنیتی، سپس لاگ |
| HTTP 500 | خطای داخلی سرور؛ مثلاً خطای PHP یا تداخل افزونه و قالب | بررسی لاگ خطا و تست مرحله‌ای |
| cURL error 28 | پایان مهلت انتظار پیش از دریافت پاسخ کامل | بررسی کندی سرور و منابع |
| cURL error 52 | پاسخ خالی از سرور | بررسی لاگ PHP و وب‌سرور |
| cURL error 6 | حل‌نشدن نام دامنه (Could not resolve host)، معمولاً مربوط به DNS یا نیم‌سرور | بررسی DNS و نیم‌سرورها |
| cURL error 60 | تأیید گواهی SSL ناموفق بوده؛ مثلاً منقضی، زنجیره‌ی ناقص یا نامعتبر | بررسی اعتبار و نصب گواهی |
| خطای عمومی بدون کد | علت مشخص نیست | بررسی Site Health، لاگ‌ها و تست مرحله‌ای |
خطای 403 (مسدود شدن) و خطای 400
خطای ۴۰۳ یعنی سرور درخواست رو فهمیده ولی اجازه‌ی انجامش رو نداده؛ معمولاً کار فایروال یا افزونه‌ی امنیتیه. خطای ۴۰۰ یعنی سرور ساختار درخواست رو نفهمیده؛ می‌تونه به تنظیمات نادرست یا کش برگرده.
خطای 500 (پاسخ خالی) و بررسی لاگ‌ها
اینجا دو چیز رو از هم جدا کن: خطای ۵۰۰ یعنی مشکل داخلی سرور (مثلاً خطای PHP، تداخل افزونه یا قالب، یا کمبود منابع)، ولی «پاسخ خالی» به cURL 52 مربوطه. تو هر دو حالت اول لاگ خطا رو ببین؛ تو cPanel معمولاً بخش «Error Logs» همین کارو می‌کنه. اگه نشونه‌ی محدودیت منابع دیدی، رفع خطای ۵۰۸ در وردپرس هم می‌تونه کمک کنه.
خطاهای cURL 28 و cURL 52 در وردپرس
cURL 28 یعنی مهلت انتظار تموم شده؛ ممکنه اتصال برقرار بشه ولی پاسخ کامل نرسه. اگه سایتت خطای تایم‌اوت گیت‌وی هم میده، رفع خطای ۵۰۴ در وردپرس به کارت میاد. cURL 52 یعنی سرور پاسخ خالی برگردونده؛ معمولاً لاگ‌های PHP و وب‌سرور رو باید بررسی کرد.
اگر مشکل از سمت سرور بود، چه اقداماتی انجام دهیم؟
اگه بررسی‌های بالا جواب نداد، ممکنه محدودیتی سمت سرور باشه که از داخل وردپرس قابل تغییر نیست. بهترین کار تو این حالت تیکت به پشتیبانی هاسته. مثلاً هاست وردپرس ابرینا با دیسک NVMe می‌تونه سرعت پردازش رو بهتر کنه و تایم‌اوت‌های ناشی از کندی رو کم کنه. ولی این فقط یه عامله، نه راه‌حل خطای Loopback.
چک‌لیست اطلاعات ضروری برای تیکت پشتیبانی
تو تیکت این موارد رو بنویس تا پشتیبانی ابرینا سریع‌تر بررسی کنه:
- متن دقیق خطا (کپی کامل پیام Site Health، مخصوصاً کدهایی مثل 403 یا cURL 28)
- زمان دقیق وقوع خطا
- اقدامات انجام‌شده (مثل غیرفعال‌کردن افزونه‌ها)
- نسخه‌ی PHP و وردپرس
- فهرست افزونه‌های فعال
تنظیمات تخصصی که نیازمند دخالت مدیر سرور است
قوانین فایروال سرور (مثل ModSecurity)، محدودیت‌های PHP (مثل Max Execution Time؛ حداکثر مدت زمانی که یک اسکریپت PHP اجازه دارد برای اجرا صرف کند) و مشکلات DNS سرور فقط با دسترسی سطح سرور بررسی میشن؛ این‌ها رو به پشتیبانی بسپار.
چطور مطمئن شویم خطای Loopback برطرف شده است؟
بعد از رفع خطای Loopback Request دو چیز رو چک کن: Site Health و WP-Cron.
اجرای مجدد تست سلامت سایت
برو «ابزارها» > «سلامت سایت». وردپرس معمولاً با باز شدن صفحه، تست‌ها رو دوباره اجرا می‌کنه. اگه هشدار درخواست داخلی دیگه نیست، نشونه‌ی خوبیه.
بررسی عملکرد وظایف زمان‌بندی‌شده (WP-Cron)
این مرحله‌ش ساده‌ست:
- اگه کش صفحه فعاله، اول یه بار کش رو پاک کن.
- یه نوشته‌ی جدید بساز و انتشارش رو برای ۵ تا ۱۰ دقیقه‌ی بعد زمان‌بندی کن.
- چون WP-Cron با بازدید فعال میشه، تو این فاصله یه بار سایت رو باز کن.
- اگه نوشته به‌موقع منتشر شد، سیستم زمان‌بندی احتمالاً درست کار می‌کنه.
- بعد از تست، افزونه‌ها و قالب اصلی رو دوباره فعال کن.
برای ترفندهای بیشتر هم می‌تونی سری به مقالات آموزشی وردپرس و هاست بزنی.
سؤالات متداول درباره خطای Loopback وردپرس
۱. خطای Loopback Request در وردپرس به چه معناست؟
یعنی سایت نتونسته با خودش ارتباط برقرار کنه. درخواستی که وردپرس از سمت سرور به آدرس خودش می‌فرسته، یا مسدود شده یا جواب درستی نگرفته.
۲. آیا خطای Loopback می‌تواند باعث اجرا نشدن نوشته‌های زمان‌بندی‌شده شود؟
ممکنه. WP-Cron برای اجرای کارها از درخواست داخلی استفاده می‌کنه، پس اختلال تو اون می‌تونه انتشار زمان‌بندی‌شده رو دچار تاخیر کنه.
۳. چگونه بفهمیم خطای Loopback از افزونه است یا هاست؟
افزونه‌ها رو موقتاً غیرفعال کن. اگه خطا رفت، مشکل از افزونه‌ست؛ اگه موند، قالب، آدرس‌ها، فایروال و محدودیت‌های هاست رو بررسی کن.
۴. خطای cURL 28 در درخواست Loopback چه معنایی دارد؟
یعنی درخواست فرستاده شده ولی تو زمان مجاز پاسخ کامل نگرفته. علتش می‌تونه کندی سرور، محدودیت منابع یا مسدودشدن درخواست باشه.
۵. خطای cURL 52 در وردپرس چگونه بررسی می‌شود؟
یعنی سرور پاسخ خالی برگردونده. لاگ‌های PHP و وب‌سرور رو بررسی کن و اگه به دسترسی سرور نیاز بود، با پشتیبانی هاست هماهنگ شو.
۶. آیا خطای 403 در Loopback می‌تواند از فایروال هاست باشد؟
بله، یکی از علت‌های رایجشه. گاهی فایروال یا افزونه‌ی امنیتی درخواست داخلی رو اشتباهی تهدید می‌دونه، ولی برای اطمینان باید لاگ‌ها بررسی بشن.
جمع‌بندی: رفع خطای Loopback Request در وردپرس
رفع خطای Loopback Request در وردپرس معمولاً با یه مسیر ساده جلو میره. اول، متن کامل خطا و کد HTTP یا cURL رو از Site Health پیدا کن. دوم، آدرس‌های سایت، افزونه‌ها و قالب رو به‌ترتیب بررسی کن و بعد از هر مرحله، سلامت سایت وردپرس رو دوباره چک کن. سوم، اگه فایروال، محدودیت منابع، DNS یا SSL پشت ماجراست، با اطلاعات کامل به پشتیبانی هاست اشتراکیت تیکت بزن. یادت باشه علت خطای Loopback از سایتی به سایت دیگه فرق می‌کنه، ولی با بررسی مرحله‌ای معمولاً میشه ریشه‌ش رو پیدا کرد.
فراموش نکن قبل از هر تغییری بکاپ بگیری و با یه نوشته‌ی زمان‌بندی‌شده‌ی تستی مطمئن بشی WP-Cron هم درست کار می‌کنه. قدم‌به‌قدم برو جلو؛ خیلی از این خطاها با چند بررسی ساده حل میشن و سایتت دوباره روون کار می‌کنه.
