خطای cURL ۲۸ یعنی یک عملیات شبکه پیش از تمام‌شدن به محدودیت زمانی رسیده است. این پیام به‌تنهایی نمی‌گوید مقصر DNS، فایروال، سرویس مقصد یا کندی پاسخ است. در وردپرس ابتدا باید مشخص کنید کدام درخواست خروجی، در چه زمانی و از کدام بخش شکست می‌خورد؛ سپس همان مسیر را بررسی کنید. افزایش زمان انتظار بدون شناسایی مرحلهٔ کند، ممکن است فقط صف درخواست‌های PHP را طولانی‌تر کند.
۱. ابتدا درخواست شکست‌خورده را پیدا کنید
خطا هنگام به‌روزرسانی افزونه، دریافت پاسخ درگاه یا بررسی سلامت سایت یک معنی عملی یکسان ندارد. نام قابلیت، دامنهٔ مقصد، زمان با منطقهٔ زمانی و متن پاک‌سازی‌شدهٔ خطا را ثبت کنید. «بعد از ۱۰۰۰۰ میلی‌ثانیه» در یک پیام نمونه، سقف همان درخواست است؛ سقف ثابت همهٔ درخواست‌های وردپرس نیست.
- مشخص کنید خطا همیشگی است یا فقط در ساعت‌های شلوغ رخ می‌دهد.
- ببینید فقط یک مقصد مشکل دارد یا چند سرویس مستقل نیز ناموفق‌اند.
- اگر بخش مدیریت باز است، ابزارها ← سلامت سایت را بخوانید و متن آزمون مربوط را ثبت کنید.
- قبل از تلاش دوباره برای پرداخت، سفارش یا ارسال پیام، وضعیت عملیات را در مقصد بررسی کنید؛ timeout اثبات نمی‌کند هیچ تغییری در مقصد رخ نداده است.
۲. کد ۲۸ چه چیزی را ثابت می‌کند؟
در فهرست رسمی خطاهای libcurl، کد ۲۸ به پایان زمان مجاز عملیات مربوط است. با خطای گواهی یا نام دامنه یکسان نیست؛ هرچند تأخیر در آن مراحل هم می‌تواند به timeout برسد. کد HTTP مانند ۵۰۰ متعلق به پاسخ سرور است، اما ممکن است cURL پیش از دریافت هر پاسخ HTTP متوقف شود.
| نشانهٔ ثبت‌شده | مسیر بررسی |
|---|---|
| فقط یک دامنهٔ خارجی | دسترسی همان مقصد، محدودیت نرخ و زمان پاسخ آن |
| چند مقصد متفاوت | DNS و مسیر خروجی هاست، منابع PHP و محدودیت ارتباط |
| اتصال سریع و پاسخ دیرهنگام | زمان پردازش مقصد یا انتقال داده؛ نه الزاماً مشکل DNS |
| وقوع هم‌زمان با فشار سایت | زمان رخداد را با گزارش منابع و لاگ مرتبط تطبیق دهید |
نکته: این جدول فرضیه تولید می‌کند، نه حکم قطعی. تغییر فایروال یا خاموش‌کردن بررسی TLS با دیدن یک کد خطا توجیه نمی‌شود.
۳. زمان‌های اتصال را درست بخوانید
اگر دسترسی شل و اجازهٔ درخواست خواندنی به مقصد دارید، فرمان زیر فقط یک صفحهٔ عمومی نمونه را می‌خواند. نشانی را با مقصد عمومیِ مجاز جایگزین کنید؛ درخواست پرداخت، لینک دارای توکن یا عملیات تغییردهنده را برای آزمایش تکرار نکنید.
curl --silent --show-error --output /dev/null \
--connect-timeout 5 --max-time 15 \
--write-out 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total} http=%{http_code}\n' \
'https://example.com/'
طبق راهنمای curl، زمان‌ها بر حسب ثانیه و عمدتاً تجمعی از شروع عملیات‌اند؛ آن‌ها را با هم جمع نزنید. connect پایان برقراری اتصال و first زمان رسیدن نخستین بایت است. اختلاف first و connect به‌تنهایی «زمان PHP» نیست و در HTTPS مذاکرهٔ TLS را هم در بر می‌گیرد. در HTTP ساده، مقدار tls ممکن است صفر باشد. پراکسی، استفادهٔ دوباره از اتصال و redirect تفسیر را پیچیده‌تر می‌کنند؛ فرمان بالا عمداً redirect را دنبال نمی‌کند.
همین فرمان از لپ‌تاپ، مسیر شبکهٔ هاست را آزمایش نمی‌کند. اگر شل ندارید، از پشتیبانی بخواهید یک درخواست محدود و خواندنی از همان محیط PHP/هاست بررسی کند. در این مقاله فقط تولید خطای ۲۸ مقابل پاسخ‌دهندهٔ موقت محلی آزمایش شده؛ فرمان بالا روی هاست اجرا نشده است.
۴. تصویر سلامت را با آزمون مقصد اشتباه نگیرید
این کارت برای یافتن محدودیت‌های پیکربندی درخواست‌های HTTP مفید است، اما موفق‌بودنش تضمین نمی‌کند همهٔ دامنه‌ها یا همهٔ درخواست‌های افزونه‌ها پاسخ می‌دهند. جزئیات خطای همان افزونه و زمان وقوع همچنان لازم است. از نمایش کل لاگ، کلید API، کوکی یا نشانی دارای توکن در تیکت و تصویر عمومی خودداری کنید.
۵. گزارش قابل اقدام آماده کنید
- قابلیت شکست‌خورده و مقصد، بدون پارامتر محرمانه.
- زمان دقیق و تکرارپذیری؛ شروع مشکل بعد از چه تغییری بوده است؟
- متن خطا، مدت انتظار و اینکه پاسخ HTTP دریافت شده یا نه.
- نتیجهٔ مقایسهٔ مقصدها و نتیجهٔ سلامت سایت، همراه با محدودیت هر مشاهده.
اگر مشکل فقط در یک افزونه است، سازنده باید مسیر HTTP و سیاست timeout/retry همان افزونه را بررسی کند. اصلاح تنظیمات سرور یا کد به بکاپ، محیط آزمایشی و روش بازگشت نیاز دارد؛ این راهنما تغییری روی آن‌ها انجام نمی‌دهد.
۶. پرسش‌های کوتاه
آیا timeout یعنی هاست قطع است؟
خیر. یک درخواست می‌تواند ناموفق باشد در حالی که صفحات سایت باز هستند. مسیر خروجی سرور با مسیر بازدیدکننده به سایت فرق دارد.
آیا افزایش timeout راه‌حل است؟
فقط پس از اندازه‌گیری و برای عملیات واقعاً طولانی ممکن است مناسب باشد. کندی نامعلوم، بن‌بست یا مسدودشدن مسیر با افزایش عدد برطرف نمی‌شود.
۷. مسیر مطالعهٔ مرتبط
۸. منابع و دامنهٔ بررسی
منابع رسمی در ۳ نوامبر ۲۰۲۶ بررسی شدند. تصاویر سلامت سایت از وردپرس ۷.۱.۴ در ۳ نوامبر ۲۰۲۶ ثبت شده‌اند. کارت سالم، شاهد رفع یک خطای فرضی نیست. هیچ افزونه، تنظیم حفاظتی یا فایل سایت برای آزمایش تغییر نکرده است. آزمایش‌های دادهٔ نمونه محلی‌اند؛ نتیجهٔ آن‌ها سلامت همهٔ درخواست‌های سایت را ثابت نمی‌کند.
