راهنمای خواندن نتایج بررسی شبکه SNSCDN: PASS، FAIL و SKIP
ابزار netcheck در SNSCDN کمک میکند نخستین مرحلهٔ غیرعادی در یک نوبت بررسی مشخص شود. این ابزار آزمون سرعت نیست و اعتبار اشتراک، تنظیمات برنامه یا دسترسپذیری در همهٔ مناطق را تأیید نمیکند.
پس از دریافت یا کپی کردن مخزن عمومی ابزارها، پوشهٔ اصلی مخزن را باز کنید. در macOS یا Linux این فرمان را اجرا کنید:
bash bin/netcheck.sh example.com 443در Windows PowerShell این فرمان را اجرا کنید:
.\bin\netcheck.ps1 example.com 443بهجای example.com نام میزبان عمومی مورد نظر برای آزمایش را بنویسید. هرگز از نشانی اشتراک، نشانی دارای توکن، نشانی بخش مدیریت، IP خصوصی یا هدف غیرعمومی دیگری استفاده نکنید.
این اسکریپتها نتیجه را به SNSCDN بارگذاری نمیکنند، اما پرسوجوی عادی DNS و اتصال به هدف انتخابشده را انجام میدهند. سرویس حل نام و سرور هدف ممکن است فرادادهٔ معمول پرسوجو یا اتصال را ببینند.
ابتدا مشخص کنید کدام نسخه را اجرا کردهاید
| رفتار | macOS / Linux | Windows PowerShell |
|---|---|---|
| DNS | از یک فرمان حل نام موجود در سیستم استفاده میکند | از حل نام DNS در .NET استفاده میکند |
| TCP | در صورت نصب بودن nc اجرا میشود | با مهلت زمانی حدود پنج ثانیه اجرا میشود |
| TLS | فقط برای درگاه 443 و در صورت نصب بودن OpenSSL یک سطر جداگانه نشان میدهد | سطر جداگانهای برای TLS ندارد |
| HTTP | curl یک درخواست عادی میفرستد؛ پاسخ 2xx یا 3xx بهصورت PASS نمایش داده میشود | Invoke-WebRequest یک درخواست HEAD میفرستد |
| SKIP | اگر فرمان لازم موجود نباشد یا شرط بررسی TLS برقرار نباشد ممکن است نمایش داده شود | در حال حاضر خروجی SKIP ندارد |
بعضی سرویسها درخواست HEAD را نمیپذیرند. در نتیجه نسخهٔ Windows ممکن است خطای 403، 405 یا یک خطای عمومی HTTP گزارش کند، در حالی که مرورگر با درخواست GET همچنان صفحه را باز میکند. این تفاوت بهتنهایی ثابت نمیکند که وبسایت از دسترس خارج است.
خروجی را از بالا به پایین بخوانید
DNS lookup failed
در این نوبت، برای نام میزبان هیچ IP به دست نیامده است. ابتدا املای نام میزبان را بررسی کنید، سپس بدون تغییر دادن متغیرهای دیگر نتیجه را در Wi-Fi و اینترنت همراه مقایسه کنید. اگر فقط یکی از شبکهها شکست میخورد، ابتدا همان شبکه یا مسیر حل نام آن را بررسی کنید. شکست در چند شبکه، بررسی وضعیت عمومی DNS دامنه را توجیه میکند. این سطر بهتنهایی ثابت نمیکند که سرور آفلاین است.
TCP port ... is unreachable
دستگاه نتوانسته است در مهلت تعیینشده به درگاه هدف متصل شود. دیوار آتش محلی، شبکهٔ دسترسی، مسیر، سیاست درگاه یا سرویس راه دور میتوانند علت باشند. ممکن است بررسی بعدی HTTP نیز در نتیجهٔ همین مشکل شکست بخورد؛ بنابراین بهجای آنکه هر سطر ناموفق را مشکلی مستقل بدانید، از نخستین خطای TCP شروع کنید.
TLS certificate received
این سطر فقط یعنی اسکریپت Bash در یک اتصال TLS، دادههای گواهی را دریافت کرده و OpenSSL توانسته است آنها را تجزیه کند. این بررسی زنجیرهٔ اعتماد، تطابق نام میزبان، دورهٔ اعتبار یا سازگاری با مرورگر را بهطور کامل اعتبارسنجی نمیکند؛ بنابراین معادل «گواهی کاملاً معتبر است» نیست.
اگر مرورگر همچنان هشدار گواهی نشان میدهد، ساعت دستگاه، نام میزبان، دورهٔ اعتبار و زنجیرهٔ اعتماد را جداگانه بررسی کنید. هشدار را نادیده نگیرید و برای دور زدن آن، اعتبارسنجی گواهی را غیرفعال نکنید.
TLS handshake or certificate check failed
اسکریپت Bash نتوانسته است دادهٔ گواهی قابل تجزیهای به دست آورد. نام میزبان، یک واسطهٔ شبکه، پیکربندی TLS یا سرویس راه دور میتوانند در این نتیجه نقش داشته باشند؛ این سطر بهتنهایی ثابت نمیکند که گواهی منقضی شده است. نسخهٔ Windows سطر TLS جداگانه ندارد و خطاهای مرتبط معمولاً در HTTP request failed: ... ظاهر میشوند.
یک وضعیت صریح HTTP 4xx یا HTTP 5xx
فقط دریافت یک کد وضعیت صریح HTTP تأیید میکند که ابزار پاسخی در لایهٔ HTTP دریافت کرده است. پاسخ 4xx معمولاً یعنی درخواست رد شده یا شرایط لازم نقطهٔ پایانی را نداشته است. پاسخ 5xx یعنی سرویس نتوانسته است درخواست را بهطور عادی پردازش کند. هیچکدام به معنی «شبکه کاملاً در دسترس نیست» نیست.
نسخهٔ Bash پاسخهای 2xx و 3xx را PASS و دیگر کدهای وضعیت صریح را FAIL نشان میدهد. این نسخه تغییر مسیر را دنبال نمیکند؛ بنابراین [PASS] HTTP 301 یا 302 فقط ثابت میکند که پاسخ تغییر مسیر دریافت شده است، نه اینکه مقصد تغییر مسیر کار میکند. نسخهٔ Windows از درخواست HEAD استفاده میکند و ممکن است پاسخهای ناموفق را در خلاصهٔ استثنا قرار دهد.
خطای عمومی HTTP request failed
این خطا ثابت نمیکند که درخواست به سرویس HTTP رسیده است. DNS، TCP، TLS، پایان مهلت، قطع اتصال، رد شدن درخواست HEAD یا یک وضعیت ناموفق، همگی میتوانند خطای عمومی ایجاد کنند. در PowerShell، خلاصهٔ استثنای همان سطر را بخوانید. نسخهٔ Bash خلاصهٔ خطای curl را نمایش نمیدهد؛ بنابراین نخستین نتیجهٔ DNS، TCP یا TLS در سطرهای بالاتر را بررسی کنید.
[SKIP] و سطر پایانی [PASS]
[SKIP] یعنی یک بررسی اجرا نشده است؛ به معنی موفق بودن آن نیست. اسکریپت Bash فقط موارد [FAIL] را میشمارد، بنابراین ممکن است پس از یک یا چند مورد اجرانشده همچنان [PASS] No blocking problem detected را نمایش دهد. بهجای خواندن فقط خلاصهٔ پایانی، همهٔ سطرها را بررسی کنید. نسخهٔ Windows در حال حاضر خروجی SKIP ندارد.
اگر همهٔ بررسیهای قابل اجرا PASS باشند، فقط به این معناست که این نوبت بررسی مشکل مسدودکنندهای پیدا نکرده است. ابزار پهنای باند را نمیسنجد، تنظیمات برنامه را اعتبارسنجی نمیکند و پایداری در شبکهها، منطقهها، مسیرها یا زمانهای دیگر را ثابت نمیکند. برای عیبیابی گستردهتر، راهنمای عیبیابی اتصال و پشتیبانی را بخوانید.
آماده کردن گزارش پشتیبانی با رعایت حریم خصوصی
فقط موارد زیر را ارائه کنید:
- سیستمعامل دستگاه و نسخهٔ آن؛
- نوع شبکه، مانند Wi-Fi خانگی یا اینترنت همراه؛
- تاریخ، ساعت و منطقهٔ زمانی؛
- نام میزبان عمومی و درگاه؛
- برچسبهای
[PASS]و[FAIL]هر بررسی، بهعلاوهٔ هر[SKIP]در نسخهٔ Bash؛ - متن کوتاه خطایی که همان زمان در مرورگر یا برنامه دیده شده است.
پیش از اشتراکگذاری، IPهای حلشده، نشانیهای کامل، جزئیات گواهی، ایمیل حساب، اطلاعات سفارش، نشانی اشتراک، کد QR، توکن دسترسی و دیگر اطلاعات احراز هویت را حذف کنید. خلاصهٔ استثنای PowerShell نیز ممکن است نشانی یا اطلاعات داخلی داشته باشد؛ ابتدا آن را بررسی و بخشهای حساس را بپوشانید. گزارش کامل را در Issue عمومی، انجمن یا گروه گفتوگو قرار ندهید. پرسشهای مربوط به حساب، سفارش و اشتراک را از طریق سامانهٔ تیکت پس از ورود ارسال کنید.