آپدیت افزونه متوقف می شود یا سلامت سایت از یک درخواست ناموفق خبر می دهد، در حالی که صفحه اصلی بدون مشکل باز است. خطای cURL error 28 وردپرس یعنی یکی از درخواست های سایت در مهلت تعیین شده کامل نشده است. برای رفع آن، اول مقصد درخواست و مرحله توقف را پیدا کنید. افزایش یک عدد در تنظیمات، بدون دانستن اینکه وردپرس منتظر کدام سرویس مانده، ممکن است فقط انتظار کاربر را طولانی تر کند.
بخش مهم ماجرا همین است: مرورگر شما و سروری که وردپرس روی آن اجرا می شود، مسیر شبکه یکسانی ندارند. باز شدن نشانی روی لپ تاپ، دسترسی سرور به آن مقصد را ثابت نمی کند. این راهنما از همین تفاوت شروع می کند تا بتوانید مشکل را با گزارش قابل پیگیری به میزبان یا سازنده افزونه برسانید.
عدد ۲۸ دقیقا چه چیزی می گوید؟
در فهرست رسمی خطاهای libcurl، عدد 28 به رسیدن به محدودیت زمانی عملیات اشاره دارد. این عدد به تنهایی نمی گوید DNS خراب است، فایروال درخواست را بسته یا سرویس مقصد کند جواب داده است. متن کامل خطا، مدت انتظار و مقدار داده دریافت شده، سرنخ بیشتری از خود عدد دارند.
خطای ۲۸ را با HTTP 408 یا 504 یکی نگیرید. آن کدها پاسخ HTTP هستند، اما timeout ممکن است قبل از دریافت هر پاسخ HTTP رخ دهد. همچنین خطای اعتبار گواهی با عدد 60 مسیر بررسی دیگری دارد. اگر پس از یک تغییر، متن خطا عوض شد، همان متن تازه را مبنا قرار دهید؛ همه خطاهای ارتباطی یک درمان ندارند.
اول نام مقصد را پیدا کنید
قبل از غیرفعال کردن افزونه ها، بنویسید کدام کار شکست خورده است: بررسی آپدیت، اتصال پیامک، دریافت نرخ، پرداخت، بکاپ یا آزمون سلامت سایت؟ زمان دقیق همراه منطقه زمانی و متن کامل پیام را ثبت کنید. اگر خطا فقط با یک دکمه یا در ساعت مشخصی رخ می دهد، همین الگو برای محدود کردن بررسی ارزش دارد.
نشانی مقصد را از گزارش افزونه یا با کمک توسعه دهنده بگیرید. برای درخواست های HTTP وردپرس، هوک http_api_debug امکان مشاهده اطلاعات درخواست و پاسخ یا خطا را به کد عیب یابی می دهد. لازم نیست روی سایت زنده کد آماده ناشناس نصب کنید. از توسعه دهنده بخواهید ثبت موقت، محدود و بدون ذخیره رمز، توکن، کوکی یا اطلاعات مشتری انجام شود.
| درخواست ناموفق | مقصد واقعی | بررسی بعدی |
|---|---|---|
| درگاه، پیامک یا API افزونه | سرور یک شرکت دیگر | دسترسی خروجی هاست و وضعیت همان سرویس |
| آزمون loopback سلامت سایت | نشانی خود سایت | مسیر برگشت سرور به دامنه و محدودیت ورودی |
| دریافت آپدیت وردپرس | سرویس های مربوط به مخزن رسمی | نام میزبان دقیق خطادار و ارتباط خروجی |
| فقط یک عملیات خاص افزونه | ممکن است داخلی یا خارجی باشد | روش درخواست، پارامترها و زمان اجرای همان عملیات |
تست را از خود هاست انجام دهید
اگر دسترسی SSH دارید، یک نشانی عمومی و بدون اثر جانبی از همان مقصد را بررسی کنید؛ در غیر این صورت از پشتیبانی بخواهید تست را از سرور سایت انجام دهد. فرمان زیر برای پوسته لینوکس است. example.com را با دامنه و مسیر مجاز سرویس جایگزین کنید؛ این نمونه نباید برای ارسال دوباره پرداخت یا ساخت سفارش استفاده شود.
curl --connect-timeout 5 --max-time 20 --silent --show-error \
--output /dev/null \
--write-out 'http=%{http_code}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n' \
'https://example.com/'عددهای ۵ و ۲۰ فقط سقف این آزمون نمونه اند، نه تنظیم پیشنهادی همه افزونه ها. خروجی DNS، اتصال، TLS، نخستین بایت و زمان کل کمک می کند مسیر بررسی کوتاه شود. معنی گزینه ها در راهنمای curl آمده است. بیشتر این زمان ها از شروع درخواست محاسبه می شوند؛ نباید عدد connect و tls را مثل دو مدت مستقل با هم جمع کرد.
اگر آزمون قبل از دریافت پاسخ قطع شد، مقدار صفر یا HTTP برابر 000 را پاسخ واقعی مقصد فرض نکنید. اگر 403 دریافت کردید، اکنون یک پاسخ HTTP دارید و باید محدودیت دسترسی یا قانون امنیتی را بررسی کنید. کد 200 هم به تنهایی سلامت عملیات اصلی را ثابت نمی کند؛ شاید صفحه اصلی سرویس باز باشد ولی endpoint مورد استفاده افزونه مشکل داشته باشد.
موفقیت curl خط فرمان، سلامت محیط PHP وب را کامل ثابت نمی کند. نسخه کتابخانه، تنظیمات proxy، resolver، کاربر اجراکننده و سیاست دسترسی ممکن است متفاوت باشند. در صورت تفاوت نتیجه، آزمایش محدود همان نشانی از HTTP API وردپرس، با روش و تنظیمات مشابه درخواست اصلی، قدم بعدی توسعه دهنده است.
اگر سرویس بیرونی جواب نمی دهد
دو مقصد عمومی مجاز و مقصد خطادار را در یک بازه کوتاه مقایسه کنید. اگر فقط یک سرویس مشکل دارد، وضعیت سرویس، محدودیت مبدا، پورت مورد استفاده و IP خروجی سرور را بررسی کنید. بعضی سرویس ها فقط IP های ثبت شده را می پذیرند؛ انتقال هاست ممکن است IP خروجی را تغییر داده باشد، حتی وقتی دامنه سایت ثابت مانده است.
اگر چند مقصد مستقل از همان هاست timeout می شوند، بررسی resolver، مسیر خروجی، proxy و سیاست شبکه اولویت بیشتری دارد. این یک جهت بررسی است، نه اثبات خرابی میزبان. از پشتیبانی بخواهید نتیجه اتصال به مقصد مشخص و لاگ مسدودسازی مرتبط را ببیند؛ درخواست کلی «اینترنت سرور را درست کنید» اطلاعات کافی برای پیگیری ندارد.
وقتی مقصد هر دو رکورد IPv4 و IPv6 دارد، می توان با گزینه های -4 و -6 در curl نتیجه دو مسیر را مقایسه کرد. نبودن رکورد IPv6 یا نبودن مسیر آن در شبکه هم باید در تفسیر لحاظ شود. تفاوت نتیجه، سرنخی برای مدیر شبکه است؛ حذف عمومی IPv6 یا تغییر عجولانه DNS سایت درمان قطعی محسوب نمی شود.
اگر مشکل loopback است، دنبال سرویس خارجی نگردید
loopback یعنی وردپرس از سرور، به نشانی خودش درخواست می فرستد. در توضیح رسمی آزمون loopback، این ارتباط با کارهایی مانند WP-Cron و بررسی ویرایش کد مرتبط است. نام آن به معنی اتصال مستقیم به localhost نیست؛ درخواست می تواند از دامنه عمومی و لایه های جلوی سایت عبور کند.
از داخل سرور، بررسی کنید دامنه به مقصد مورد انتظار اشاره می کند و درخواست در لاگ وب سرور یا لایه امنیتی دیده می شود یا نه. احراز هویت محیط آزمایشی، قانون محدودکننده ربات، چالش مرورگر، محدودیت IP یا مسیر اشتباه از گزینه های بررسی اند. این موارد را با زمان و مسیر همان آزمون تطبیق دهید، نه با حدس.
همچنین ظرفیت اجرای PHP را ببینید. ممکن است درخواست اول منتظر پاسخ درخواست دوم به همان سایت باشد، اما پردازش آزاد کافی وجود نداشته باشد. در چنین وضعی صرفا بیشتر کردن timeout، صف انتظار را طولانی تر می کند. مدیر سرور باید زمان رخداد، ظرفیت پردازش و درخواست های طولانی را کنار هم ببیند. باز شدن صفحه اصلی از کش، این وضعیت را رد نمی کند.
ابزار بررسی سلامت سایت آفاق هاست برای مشاهده وضعیت عمومی از بیرون مفید است، ولی نتیجه آن جای آزمون loopback از داخل خود هاست را نمی گیرد. دو بررسی از دو سمت متفاوت انجام می شوند و باید جدا تفسیر شوند.
افزونه مقصر است یا فقط پیام را نشان می دهد؟
افزونه ای که خطا را نمایش داده، شاید فقط منتظر سرویس دیگری مانده باشد. پس از گرفتن بکاپ، روی کپی آزمایشی همان عملیات را با تغییر یک عامل تکرار کنید. ابتدا آخرین افزونه یا تنظیم مرتبط را بررسی کنید. خاموش کردن همه افزونه های فروشگاه زنده می تواند مسیر خرید را قطع کند و نتیجه قابل مقایسه ای هم ندهد.
از سازنده بپرسید درخواست با چه روش، مهلت زمانی و نشانی اجرا می شود. طبق مستندات HTTP وردپرس، درخواست می تواند تنظیمات timeout و روش متفاوت داشته باشد. اگر افزونه مهلت مشخصی تعیین کرده، افزودن یک فیلتر عمومی شاید روی آن اثر نکند یا درخواست های نامرتبط را هم تغییر دهد. اصلاح باید تا حد ممکن محدود به همان وابستگی باشد.
چه وقت افزایش timeout قابل قبول است؟
وقتی ارتباط سالم است و زمان طبیعی سرویس، با شواهد و مستندات آن، از مهلت فعلی بیشتر است، تغییر کنترل شده قابل بررسی است. مهلت اتصال با مهلت کل عملیات فرق دارد؛ اولی مرحله برقراری ارتباط را محدود می کند و داخل سقف کل قرار می گیرد. منتظر ماندن بیشتر، مقصد غیرقابل دسترس را قابل دسترس نمی کند.
برای کار طولانی، انتقال به صف یا اجرای پس زمینه با طراحی مناسب شاید بهتر از معطل گذاشتن صفحه کاربر باشد. درخواست پرداخت ناموفق را هم کورکورانه تکرار نکنید؛ ممکن است عملیات در مقصد انجام شده باشد ولی پاسخ به سایت نرسیده باشد. وضعیت تراکنش و روش جلوگیری از ثبت تکراری باید با مستندات همان سرویس بررسی شود.
کارهایی که خطا را پنهان می کنند
خاموش کردن سراسری فایروال یا اعتبارسنجی SSL راه رفع timeout نیست. برای قانون مسدودکننده، استثنای محدود به مقصد یا مسیر لازم و مطابق سیاست سرویس بسازید. اگر خطای گواهی هم وجود دارد، زنجیره اعتماد و نام دامنه را اصلاح کنید؛ راهنمای اعتبارسنجی TLS در curl بر حفظ بررسی گواهی در محیط عملیاتی تاکید دارد.
پرسش های رایج درباره خطای cURL error 28 وردپرس
چرا سایت برای مشتری باز است ولی آپدیت انجام نمی شود؟
نمایش صفحه به مشتری با اتصال خروجی سرور به مخزن آپدیت فرق دارد. مقصد دقیق خطادار را از گزارش بگیرید و همان را از محیط میزبانی بررسی کنید.
آیا تغییر هاست مشکل را حل می کند؟
فقط وقتی علت به محدودیت یا مسیر محیط فعلی مربوط باشد. ناسازگاری افزونه یا کندی سرویس بیرونی ممکن است پس از انتقال باقی بماند. پیش از انتخاب هاست لینوکس، وابستگی های مهم سایت را اعلام کنید.
چه گزارشی برای پشتیبانی بفرستیم؟
دامنه، زمان همراه منطقه زمانی، عملیات، مقصد بدون اطلاعات محرمانه، متن خطا و نتیجه آزمون از سرور را بفرستید. برای بررسی فنی سایت و سرور، این اطلاعات نقطه شروع مناسبی است. کار زمانی تمام است که همان عملیات اصلی چند بار در شرایط عادی موفق شود، نتیجه در مقصد تایید شود و تنظیمات موقت عیب یابی جمع شده باشند.
سرویس‌های مرتبط با این مطلب
برای بررسی راهکار مناسب، مشخصات و شرایط این خدمات را ببینید.
پرسش‌ها و دیدگاه‌های شما
سؤال یا تجربه مرتبط با این مطلب دارید؟ با ما و خوانندگان مجله آفاق هاست در میان بگذارید.