وبلاگ نت‌آرامآموزش، تجربه و راهکارهای زیرساخت

خطای cURL error 28 در وردپرس چیست؟ از DNS تا پاسخ ندادن سرویس

مراحل پیدا کردن علت cURL error 28 در سلامت سایت وردپرس یا افزونه، با بررسی DNS، شبکه، پاسخ مقصد و نتیجه آزمایش.

انتشار:
توسط تیم فنی نت‌آرام
۹ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله خطای cURL error 28 در وردپرس چیست؟ از DNS تا پاسخ ندادن سرویس در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
در سلامت سایت وردپرس یا صفحه یک افزونه خطایی شبیه cURL error 28: Operation timed out می‌بینید. معنی ساده‌اش این است که درخواست در زمانی که برای آن تعیین شده بود کامل نشده است. این پیام نمی‌گوید حتماً اینترنت سرور قطع است؛ تأخیر ممکن است در پیدا کردن آدرس، برقراری اتصال، پاسخ سرویس مقصد یا بخش دیگری از مسیر رخ دهد.
در این راهنما اول مشخص می‌کنیم وردپرس به کجا می‌خواسته وصل شود و بعد متناسب با مرحله‌ای که متوقف شده راه را انتخاب می‌کنیم. افزایش بی‌حساب زمان انتظار، غیرفعال کردن گواهی SSL یا خاموش کردن فایروال شاید پیام را پنهان کند، اما بدون پیدا کردن علت، راه‌حل قابل اتکایی نیست.

اول مقصد و زمان خطا را مشخص کنید

متن کامل خطا، زمان، نام افزونه و کاری را که قبل از خطا انجام داده‌اید یادداشت کنید. به این تفاوت توجه کنید:
  • اتصال سایت به خودش: آزمایش Loopback در سلامت سایت یا کار زمان‌بندی‌شده به نشانی خود سایت درخواست می‌فرستد. ممکن است سایت برای بازدیدکننده باز شود اما سرور نتواند از مسیر خود به همان نشانی برگردد.
  • اتصال به سرویس بیرونی: افزونه پرداخت، ارسال پیام یا به‌روزرسانی می‌خواهد با سرور دیگری تماس بگیرد. باز شدن سایت خودتان ثابت نمی‌کند آن مقصد از سرور نیز قابل دسترسی است.
  • یک عملیات مشخص: اگر فقط یک درخواست سنگین خطا دارد ولی درخواست‌های سبک به همان مقصد کار می‌کنند، حجم کار یا زمان پاسخ آن عملیات نیز باید بررسی شود.
نشانی گزارش‌شده ممکن است کلید API، شناسه مشتری یا داده شخصی در خود داشته باشد. پیش از ارسال تصویر برای پشتیبانی، این موارد را حذف کنید. درخواست پرداخت، صدور فاکتور یا هر عملیاتی که ممکن است دوباره ثبت شود را فقط برای آزمایش پشت سر هم تکرار نکنید؛ وضعیت تراکنش قبلی را ابتدا در پنل مربوط ببینید.

قدم اول: متن خطا به کدام مرحله اشاره می‌کند؟

کد ۲۸ فقط تمام شدن زمان انتظار را اعلام می‌کند. جزئیات کنار آن ممکن است سرنخ بیشتری بدهد:
| عبارت همراه خطا | قدم مناسب | | --- | --- | | Resolving timed out | یافتن نشانی مقصد در زمان تعیین‌شده تمام نشده؛ DNS و مسیر resolver سرور را بررسی کنید. | | Connection timed out | اتصال به مقصد به‌موقع برقرار نشده؛ آدرس، پورت و مسیر شبکه را با دو طرف بررسی کنید. | | Operation timed out after ... with 0 bytes received | تا زمان پایان، داده‌ای دریافت نشده؛ باید معلوم شود اتصال در چه مرحله‌ای بوده و مقصد چه ثبت کرده است. | | خطای گواهی یا certificate verify failed | مسئله به اعتبار گواهی مربوط است و باید جداگانه بررسی شود؛ از غیرفعال کردن TLS استفاده نکنید. |
این جدول میان‌بُر تشخیص است، نه حکم قطعی. برنامه‌ها متن‌های متفاوتی نشان می‌دهند و ممکن است جزئیات بیشتری در گزارش همان افزونه یا سرویس باشد. تعریف رسمی خطای ۲۸ در curl تنها اتمام مهلت عملیات را مشخص می‌کند.

قدم دوم: از همان جایی آزمایش کنید که وردپرس اجرا می‌شود

اگر سایت روی هاست اشتراکی است و SSH یا ابزار لازم ندارید، از پشتیبانی بخواهید از همان سرور و در زمان خطا ارتباط به مقصد مشخص را آزمایش کند. نتیجه باز شدن مقصد روی لپ‌تاپ شما برای مقایسه مفید است، ولی مسیر شبکه لپ‌تاپ و سرور یکی نیست. اگر وردپرس در کانتینر یا پشت پراکسی اجرا می‌شود، حتی پوسته میزبان و محیط اجرای برنامه ممکن است مسیر متفاوتی داشته باشند.
اگر SSH مجاز به سرور لینوکسی دارید، یک نشانی عمومی و بی‌خطر را که متعلق به خودتان یا برای آزمایش مجاز است انتخاب کنید. دستور زیر یک درخواست GET می‌فرستد؛ از مسیر پرداخت، نشانی دارای رمز یا هر نشانی که GET آن عملیاتی را ثبت یا تغییر می‌دهد استفاده نکنید. example.com فقط نمونه است و باید با مقصد آزمایشی مناسب جایگزین شود:
کد / دستورcurl --connect-timeout 5 --max-time 20 -sS -o /dev/null -w 'HTTP=%{http_code} DNS=%{time_namelookup} TCP=%{time_connect} TLS=%{time_appconnect} FIRST=%{time_starttransfer} TOTAL=%{time_total}\n' https://example.com/
این درخواست بدنه پاسخ را نمایش نمی‌دهد، اما همچنان از مقصد دریافت می‌کند. گزینه connect-timeout برای مرحله اتصال و max-time برای کل عملیات سقف می‌گذارد. خروجی شامل کد HTTP و چند زمان بر حسب ثانیه است. این دستور خودکار دنبال ریدایرکت نمی‌رود؛ اگر پاسخ 301 یا 302 باشد، نشانی مقصد ریدایرکت را جداگانه و با در نظر گرفتن همان نکات امنیتی بررسی کنید.
مقادیر زمان از ابتدای درخواست تا رسیدن به هر مرحله اندازه‌گیری می‌شوند؛ برای مثال FIRST زمان خالص پردازش برنامه به‌تنهایی نیست. اگر مرحله‌ای کامل نشده باشد، مقدار صفر یا خالی آن را نباید «سریع بودن» آن مرحله تعبیر کرد. چند آزمایش در زمان‌های متفاوت و متن خطای کامل از یک عدد تنها مفیدترند. راهنمای زمان‌های خروجی curl معنی دقیق هر مقدار را توضیح می‌دهد.
پاسخ HTTP مانند 403 یا 500 یعنی پاسخی از یک نقطه مسیر دریافت شده است؛ علت همچنان باید با همان پاسخ و گزارش مقصد بررسی شود. این دستور بدون گزینه fail ممکن است برای کد HTTP خطا هم از نظر خود curl انتقال کامل‌شده تلقی شود، پس فقط به خروج بدون پیام خطا بسنده نکنید.

اگر مرحله پیدا کردن نام کند یا ناموفق است

روی سرور، نام مقصدی را که خطا می‌دهد با ابزار موجود سیستم بررسی کنید. برای مثال در بسیاری از لینوکس‌ها:
کد / دستورgetent ahosts example.com
این دستور نام را از مسیر حل نام سیستم می‌پرسد و ممکن است نتیجه‌ای از hosts، DNS یا سازوکار تنظیم‌شده دیگر بگیرد. اگر خروجی ندارد یا با تأخیر زیادی می‌آید، ساعت و نتیجه را ثبت کنید. آن را با نام دیگری که مجاز به آزمایش آن هستید مقایسه کنید. خطای فقط یک دامنه ممکن است به همان دامنه یا پاسخ آن مربوط باشد؛ خطای چند نام مستقل می‌تواند مسیر حل نام سرور را مطرح کند.
فایل resolver، سرویس DNS محلی و تنظیم شبکه ممکن است توسط systemd-resolved، NetworkManager یا ابزار دیگری مدیریت شوند. یک نشانی DNS عمومی را بدون شناخت محیط در فایل‌ها جای‌گذاری نکنید؛ ممکن است تنظیم بعداً بازنویسی شود یا نام‌های داخلی سازمان از کار بیفتند. از مدیر بخواهید مسیر resolver و خطای همان زمان را بررسی کند. اگر مقصد فقط در شبکه داخلی باید قابل دسترسی باشد، تغییر به DNS عمومی ممکن است مسئله را حل نکند.

اگر نام پیدا می‌شود اما اتصال کامل نمی‌شود

نام مقصد، پورت، زمان و IP پاسخ‌داده‌شده را با تنظیمات رسمی سرویس تطبیق دهید. ممکن است مقصد در دسترس نباشد، مسیر شبکه مشکل داشته باشد یا یک فایروال ارتباط مشخصی را محدود کرده باشد. مسئول سرور مبدأ و مقصد باید رویدادهای همان زمان را مقایسه کنند؛ یک timeout به‌تنهایی ثابت نمی‌کند کدام فایروال مقصر است.
اگر مقصد فقط از آدرس‌های مشخص اجازه می‌گیرد، IP خروجی واقعی سرویس را از مدیر شبکه بگیرید و طبق سیاست همان سرویس درخواست مجوز دقیق بدهید. همه پورت‌ها یا همه IPها را برای حل سریع باز نکنید. برای سایتی که پشت CDN است، مسیر بازگشت درخواست سرور به نام خودش و تنظیمات CDN نیز ممکن است با مسیر بازدیدکننده تفاوت داشته باشد.
اگر خطا به گواهی TLS اشاره می‌کند، نام مقصد و زنجیره گواهی را اصلاح کنید. راهنمای خطای گواهی curl توضیح می‌دهد چرا گزینه نادیده گرفتن اعتبار گواهی جای تعمیر درست را نمی‌گیرد.

اگر اتصال برقرار است ولی پاسخ دیر می‌آید

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

اگر خطا فقط در سلامت سایت و Loopback است

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

چطور نتیجه را تأیید کنیم؟

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

دیدگاه‌ها (۰)

دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام