وقتی در بخش ابزارها ← سلامت سایت (Site Health) پیام «Your site could not complete a loopback request» یا «Loopback Request Failed» دیده می‌شود، ابتدا باید مشخص کنید درخواست HTTP از خود سرور به دامنه سایت در کدام مرحله شکست می‌خورد. این خطا الزاماً به معنی خرابی وردپرس یا نیاز به تعویض هاست نیست. مشکل ممکن است از DNS، گواهی SSL، فایروال، احراز هویت HTTP، ریدایرکت‌های اشتباه یا محدودیت ارتباط خروجی باشد. در این راهنما با تست‌های قابل تکرار، علت را جدا می‌کنیم و بعد از هر اصلاح نتیجه را می‌سنجیم.
Loopback Request در وردپرس چیست و چرا خطا می‌دهد؟
درخواست بازگشتی یعنی خود سایت با HTTP/HTTPS به یکی از آدرس‌های خودش درخواست بفرستد. WordPress Site Health برای بررسی این قابلیت، یک درخواست داخلی به مسیر مدیریتی wp-admin/admin-ajax.php می‌فرستد. این قابلیت برای بعضی عملیات زمان‌بندی‌شده و برخی افزونه‌ها اهمیت دارد؛ اما هر خطای WP-Cron یا REST API لزوماً همان خطای Loopback نیست. راهنمای رسمی وردپرس درباره Loopback Requests مبنای بررسی است.
سناریوی نمونه: سایت از بیرون باز می‌شود و مدیر به پیشخوان دسترسی دارد، اما Site Health خطای Loopback و گاهی cURL error 28 یا 403 نشان می‌دهد. باز شدن سایت در مرورگر، اتصال «سرور به خودش» را تضمین نمی‌کند.
پیش‌نیازها و اقدامات احتیاطی
- دسترسی مدیر وردپرس و ترجیحاً SSH یا ترمینال هاست؛ برای WP-CLI باید در ریشه نصب وردپرس باشید.
- دامنه واقعی را جای
example.comبگذارید؛ خروجی هر تست را قبل از تغییر تنظیمات ذخیره کنید. - از فایل‌های تنظیمات وب‌سرور و قوانین WAF نسخه پشتیبان بگیرید. در سایت پرترافیک، تغییرات را در بازه کم‌ریسک اجرا کنید.
- اگر از Cloudflare، Reverse Proxy یا Load Balancer استفاده می‌کنید، IP مبدا و مقصد درخواست را در لاگ‌ها تفکیک کنید.
مرحله اول: متن دقیق خطا را از Site Health بخوانید
در پیشخوان به ابزارها ← سلامت سایت ← وضعیت بروید و بخش «Loopback request» را باز کنید. متن خطا، کد HTTP و زمان تست را یادداشت کنید. اگر پیام شامل cURL error 6 باشد، ابتدا DNS را بررسی کنید؛ cURL error 28 معمولاً به timeout اشاره می‌کند؛ cURL error 60 به مشکل اعتبارسنجی TLS مربوط است؛ و 401/403 می‌تواند از Basic Auth یا WAF باشد. این نشانه‌ها سرنخ هستند، نه تشخیص قطعی.
اگر مشکل در یک سایت وردپرسی بعد از تغییر HTTPS یا پروکسی شروع شده، ابتدا راهنمای رفع خطای Too Many Redirects در وردپرس را هم بررسی کنید؛ چرخه ریدایرکت می‌تواند درخواست داخلی را مختل کند.
مرحله دوم: از خود سرور DNS، اتصال و TLS را تست کنید
دستورهای زیر را روی همان سروری اجرا کنید که PHP وردپرس روی آن کار می‌کند، نه روی لپ‌تاپ شخصی:
getent ahostsv4 example.com
curl -I --connect-timeout 5 --max-time 15 https://example.com/
curl -sS -o /dev/null -w 'HTTP=%{http_code} TIME=%{time_total}' --max-time 15 https://example.com/wp-json/; echo
خروجی مورد انتظار: دامنه به IP مورد انتظار Resolve شود، ارتباط HTTPS در زمان معقول برقرار گردد و /wp-json/ یک پاسخ HTTP معتبر بدهد (معمولاً 200؛ وضعیت دقیق به تنظیمات سایت بستگی دارد). اگر curl در DNS یا TLS خطا بدهد، پیش از دست‌کاری افزونه‌ها همان مشکل شبکه را حل کنید.
برای بررسی مسیر مدیریتی می‌توانید curl -I https://example.com/wp-admin/admin-ajax.php را هم اجرا کنید؛ پاسخ 400 بدون پارامتر action ممکن است طبیعی باشد و به‌تنهایی اثبات‌کننده خرابی Loopback نیست. این تست فقط برای دیدن دسترسی، ریدایرکت و رفتار وب‌سرور مفید است.
مرحله سوم: با WP-CLI درخواست HTTP را از داخل PHP امتحان کنید
در پوشه وردپرس، ابتدا URLهای ذخیره‌شده را بررسی کنید:
wp option get home
wp option get siteurl
wp cron event list --fields=hook,next_run_relative,recurrence --format=table
سپس با HTTP API خود وردپرس، یک درخواست آزمایشی به سایت بفرستید:
wp eval '$r=wp_remote_get(home_url("/wp-json/"),["timeout"=>15]);if(is_wp_error($r)){echo $r->get_error_code().": ".$r->get_error_message().PHP_EOL;}else{echo "HTTP ".wp_remote_retrieve_response_code($r).PHP_EOL;}'
تفسیر: اگر curl موفق است ولی wp_remote_get خطا می‌دهد، تنظیمات PHP، CA bundle، افزونه‌هایی که HTTP API را فیلتر می‌کنند یا تفاوت محیط اجرای PHP را بررسی کنید. این تست دقیقاً معادل آزمون احرازهویت‌شده Site Health نیست؛ برای تأیید نهایی باید همان آزمون پیشخوان را دوباره اجرا کنید. همچنین غیرفعال بودن WP-Cron به‌تنهایی اثبات نمی‌کند که Loopback خراب است؛ برای زمان‌بندی به راهنمای اختصاصی WP-Cron مراجعه کنید.
مرحله چهارم: مشکل DNS، آدرس سایت یا مسیر شبکه را اصلاح کنید
اگر getent IP اشتباه، قدیمی یا IPv6 غیرقابل دسترس برمی‌گرداند، رکوردهای DNS و تنظیمات Resolver سرور را با آدرس‌های واقعی هاست مقایسه کنید. مقدار home و siteurl هم باید با دامنه و پروتکل نهایی سازگار باشد. قبل از تغییر URL در دیتابیس، از پایگاه داده بکاپ بگیرید.
برای تشخیص اینکه اختلال در CDN/Proxy است یا Origin، فقط در صورت داشتن IP واقعی Origin و اجازه مدیریتی می‌توان تست موقت زیر را انجام داد:
curl -I --connect-timeout 5 --max-time 15 --resolve example.com:443:203.0.113.10 https://example.com/
آدرس 203.0.113.10 صرفاً نمونه مستندسازی است و باید با IP واقعی Origin جایگزین شود. این دستور DNS را فقط برای همان درخواست آزمایشی دور می‌زند؛ تنظیم دائمی DNS یا /etc/hosts نیست. اگر Origin پاسخ درست می‌دهد ولی مسیر معمولی نه، لاگ CDN، Firewall و Load Balancer را بررسی کنید.
مرحله پنجم: خطاهای 401 و 403 را در WAF و احراز هویت پیدا کنید
در محیط Staging، Basic Authentication می‌تواند باعث شود درخواست داخلی وردپرس به صفحه ورود برخورد کند. همچنین افزونه امنیتی، ModSecurity یا قانون Cloudflare WAF ممکن است درخواست POST به /wp-admin/admin-ajax.php را مسدود کند. از روی زمان خطا، مسیر درخواست و شناسه Rule در لاگ‌ها علت را پیدا کنید. فقط برای Rule مشخص، استثنای محدود و موقت تعریف کنید؛ غیرفعال کردن سراسری WAF، ModSecurity یا احراز هویت راه‌حل امنی نیست.
اگر مشکل به احراز هویت REST API مربوط است، آن را از Loopback جدا کنید و راهنمای رفع خطای 401 و 403 در WordPress REST API را ببینید. این دو مسیر ممکن است علل مشترک داشته باشند، ولی تست و Endpoint آن‌ها یکسان نیست.
مرحله ششم: Timeout، ریدایرکت و محدودیت سرور را بررسی کنید
اگر خطا cURL error 28 است، لاگ وب‌سرور و PHP-FPM را در زمان اجرای Site Health بررسی کنید. مصرف CPU/RAM، صف PHP-FPM، ارتباط خروجی روی پورت 443 و ریدایرکت‌های پی‌درپی می‌توانند باعث تأخیر شوند. به‌جای افزایش کورکورانه Timeout، با دستورهای بالا مشخص کنید تأخیر در DNS، TCP، TLS یا پاسخ اپلیکیشن رخ می‌دهد.
اگر به‌تازگی افزونه امنیتی، Cache یا تنظیمات Proxy تغییر کرده، در محیط Staging تغییر را به‌صورت کنترل‌شده بازگردانید و نتیجه Site Health را قبل و بعد مقایسه کنید. برای بررسی هشدارهای دیگر سلامت سایت، مقاله رفع هشدار Autoload در Site Health وردپرس نیز مفید است؛ آن هشدار مستقل از Loopback است و نباید با آن یکی فرض شود.
جدول تشخیص سریع بر اساس علامت خطا
| نشانه | اولین بررسی | تست تأیید |
|---|---|---|
| cURL error 6 | DNS و Resolver | getent ahostsv4 |
| cURL error 28 | Timeout، Firewall، PHP-FPM | curl --max-time 15 و لاگ‌ها |
| cURL error 60 | CA bundle و زنجیره SSL | curl -I https://... بدون -k |
| 401 یا 403 | Basic Auth، WAF، ModSecurity | لاگ درخواست و Rule ID |
| 301/302 تکراری | HTTPS/Proxy و URLهای وردپرس | curl -IL و بررسی Location |
| 500/502/503 | PHP-FPM، وب‌سرور و افزونه‌ها | error log و تست Origin |
چگونه مطمئن شویم مشکل واقعاً برطرف شده است؟
- دوباره ابزارها ← سلامت سایت را باز کنید و نتیجه Loopback را تازه‌سازی کنید؛ پیام خطا باید برطرف شده باشد.
- دستور
wp_remote_getو تستcurlرا تکرار کنید و زمان پاسخ را با قبل مقایسه کنید. - لاگ‌های WAF، وب‌سرور و PHP-FPM را بررسی کنید که درخواست داخلی دیگر مسدود یا Timeout نمی‌شود.
- اگر مشکل روی زمان‌بندی اثر گذاشته بود، اجرای یک رویداد کم‌خطر Cron را جداگانه بررسی کنید؛ سلامت Loopback به‌تنهایی تضمین‌کننده سلامت تمام Cron Jobها نیست.
Rollback و بازیابی امن
اگر با تغییر DNS، Rule فایروال یا تنظیمات Proxy مشکل تازه‌ای ایجاد شد، آخرین تغییر را بر اساس بکاپ/Change Log بازگردانید، سرویس وب را فقط در صورت نیاز Reload کنید و دوباره تست کنید. استثناهای آزمایشی WAF را پس از تشخیص محدود یا حذف کنید؛ فایل /etc/hosts را با IP موقت رها نکنید. اگر دسترسی به پیشخوان از بین رفت، از SSH یا پنل هاست فایل تنظیمات را به نسخه سالم قبلی برگردانید. برای سایت‌هایی که دسترسی فنی سرور ندارند، استفاده از هاست وردپرس و سرویس میزبانی متناسب با نیاز سایت می‌تواند بررسی محدودیت‌های محیط میزبانی را ساده‌تر کند؛ پیش از خرید، علت خطا را با پشتیبانی مشخص کنید.
پرسش‌های متداول
آیا Loopback Request Failed یعنی سایت برای بازدیدکنندگان قطع است؟
خیر. ممکن است سایت از بیرون باز شود اما درخواست HTTP از خود سرور به دامنه سایت به دلیل DNS، TLS، Firewall یا احراز هویت شکست بخورد.
آیا پاسخ 400 از admin-ajax.php نشان‌دهنده خرابی Loopback است؟
نه لزوماً. درخواست بدون پارامتر action یا بدون نشست معتبر ممکن است پاسخ 400 بدهد؛ نتیجه اصلی را باید در آزمون Site Health و لاگ درخواست احرازهویت‌شده بررسی کرد.
آیا برای رفع خطای Loopback باید Cloudflare یا افزونه امنیتی را خاموش کنم؟
خیر. ابتدا Rule یا مسیر مسدودشده را در لاگ شناسایی کنید و فقط استثنای محدود، موقت و قابل بازگشت اعمال کنید.