جدید!
سرور ابری ساعتی فعال شد. ۱۰۰ هزار تومان اعتبار هدیه بگیرید
به اشتراک بگذارید
جدید!
سرور ابری ساعتی فعال شد. ۱۰۰ هزار تومان اعتبار هدیه بگیرید
تست دسترسی سایت از ایران و خارج یعنی یک پاسخ را از چند نقطه دید جدا بگیرید و ببینید زنجیره کجا پاره می‌شود. نتیجه هر تست به شبکه‌ای وابسته است که از آن تست می‌کنید. در این راهنما یک نردبان عیب‌یابی را از رزولوشن دامنه تا لاگ وب‌سرور بالا می‌روید و در هر پله می‌فهمید مشکل از DNS است، از مسیر شبکه یا از خود اپلیکیشن.
| نشانه | پله‌ای که باید بررسی شود | ابزار |
|---|---|---|
| از یک شبکه باز می‌شود و از شبکه دیگر نه | رزولوشن DNS و مسیر شبکه | دستور dig و دستور curl |
| نام دامنه به هیچ IP نمی‌رسد | رکورد A و AAAA و سرورهای نام | دستور dig با گزینه trace |
| اتصال برقرار و گواهی خطا می‌دهد | لایه TCP و TLS | دستور nc و دستور openssl s_client |
| کد 403 یا 429 برمی‌گردد | فایروال، WAF و محدودیت نرخ | لاگ access و دستور nft |
💡 نکته کلیدی
در دسترس نبودن سایت سه علت با درمان‌های متفاوت دارد: نام به IP درست حل نمی‌شود، پاسخی از IP برنمی‌گردد، یا پاسخ خودش یک خطای اپلیکیشن است.
✅ اولین دستور را همین حالا بزنید: رکورد A دامنه را از دو ریزالور بگیرید و دو خروجی را مقایسه کنید.
✅ بعد همان تست را از دو شبکه جدا تکرار کنید؛ اینترنت ثابت و دیتای موبایل.
خطا را معمولاً از یک جا می‌بینیم و همان نما را به کل دنیا تعمیم می‌دهیم. نردبان زیر این عادت را می‌شکند و پایین‌ترین پله آن همیشه نام دامنه است، نه سرور.
📌 آنچه در این مقاله می‌خوانید
◀️ تفاوت داون شدن سایت با در دسترس نبودن از یک شبکه
◀️ نردبان عیب‌یابی از رزولوشن دامنه تا کد وضعیت HTTP
◀️ لاگ سرور، فایروال و محدودیت نرخ درخواست را چطور بخوانیم؟
◀️ تست از چند شبکه و اقدام بعد از پیدا کردن علت
تست دسترسی سایت از ایران با داون شدن سایت چه تفاوتی دارد؟
داون شدن سایت یعنی سرویس برای همه از کار افتاده است؛ در دسترس نبودن یعنی سرویس کار می‌کند و فقط یک مسیر یا گروهی از کاربران به آن نمی‌رسند. حالت اول رد روشنی در لاگ سرور می‌گذارد و حالت دوم ممکن است در لاگ مبدا هیچ سطری نداشته باشد.
سه لایه‌ای که ممکن است خراب باشند
هر درخواست وب از سه لایه مستقل عبور می‌کند. در لایه نام، ریزالور دامنه را به IP تبدیل می‌کند. در لایه شبکه، بسته‌ها باید به پورت 443 برسند. در لایه اپلیکیشن، وب‌سرور یک کد وضعیت تولید می‌کند.
- مشکل DNS: نام به IP حل نمی‌شود یا به IP قدیمی حل می‌شود.
- مشکل مسیر: نام درست حل می‌شود، اما اتصال TCP کامل نمی‌شود و تست با Timeout تمام می‌شود.
- خطای اپلیکیشن: سرور پاسخ می‌دهد، اما پاسخ یک کد 4xx یا 5xx است.
چرا نتیجه تست به نقطه دید وابسته است
دو کاربر می‌توانند در یک لحظه دو نتیجه متفاوت بگیرند، چون متغیرهای مسیرشان یکی نیست. هر نتیجه را با نام شبکه ثبت کنید، وگرنه داده‌ها قابل مقایسه نیست.
- ریزالور: پاسخ کش‌شده تا پایان TTL همان قبلی می‌ماند.
- مسیر: دو اپراتور ممکن است به یک IP از دو مسیر برسند.
- سیاست مبدا: قاعده فایروال یا محدودیت نرخ، بخشی از IPها را رد می‌کند.
- کلاینت: کش مرورگر و فایل hosts نتیجه را عوض می‌کنند.
فهرست علت‌های محتمل را در راهنمای دلایل غیر قابل دسترسی بودن سایت آورده‌ایم؛ این مقاله روی ترتیب تست تمرکز دارد. یک نکته زیرساختی هم از ابتدا بدانید: اگر سرویس باید از بیرون کشور پاسخ بدهد، IP سرور باید از اینترنت بین‌الملل در دسترس باشد؛ در سرور ایران با IP بین‌الملل وب‌داده هر سرور IP مستقیم دارد و IPv4 و IPv6 پشتیبانی می‌شود.
نردبان عیب‌یابی از رزولوشن دامنه تا کد وضعیت HTTP
نردبان یعنی ترتیب ثابت تست‌ها از پایین به بالا: اول نام دامنه، بعد TTL، بعد TCP و TLS و در آخر کد وضعیت HTTP. این ترتیب جلوی اشتباه رایج را می‌گیرد؛ عوض کردن تنظیمات وب‌سرور وقتی دامنه به IP اشتباه حل می‌شود.
پله اول: رکورد A و AAAA را از چند ریزالور بگیرید
پرسش‌هایی که کاربران درباره باز نشدن سایت و روش تست آن می‌پرسند:
dig A example.com @8.8.8.8
dig +short A example.com @1.1.1.1
dig +short AAAA example.com @8.8.8.8
dig NS example.com +short
dig +trace example.comگزینه +short خروجی را کوتاه می‌کند و گزینه +trace «مسیر واگذاری را از سرورهای ریشه» دنبال می‌کند؛ با +trace رکورسیون خاموش می‌شود و dig خودش پرس‌وجوی تکرارشونده می‌فرستد. اگر خروجی trace روی یک سرور نام بایستد، نقطه خرابی همان است. نوع رکورد در این دستور پیش‌فرض A است؛ برای IPv6 آن را با -t AAAA تکرار کنید.
⚠️ دو IP متفاوت همیشه خرابی نیست
سرویس‌های GeoDNS، anycast و CDN عمداً به ریزالورهای مختلف IPهای مختلف می‌دهند. پس اول رکورد را در پنل DNS خودتان ببینید: اگر geo-aware یا متعلق به CDN است، تفاوت پاسخ‌ها طبیعی است و باید سراغ پله بعد بروید.
پله دوم: مقدار TTL و همگام شدن رکوردها
خروجی پیش‌فرض dig بخش answer را نشان می‌دهد و گزینه +ttlid «مقدار TTL را هنگام چاپ رکورد نشان می‌دهد» (پیش‌فرض روشن است). پس برای دیدن TTL دستور را بدون +short اجرا کنید؛ در هر سطر بخش ANSWER، عدد بعد از نام دامنه همان TTL بر حسب ثانیه است. تست دسترسی سایت از ایران در بازه TTL نتایج متناقض می‌دهد و این تناقض خودش یک نشانه است.
dig A example.com +ttlid
dig A example.com @1.1.1.1 +noall +answer🔸 نکته فنی
رکورد جدید را روی سرور نام ثبت می‌کنید، اما ریزالورهایی که پاسخ قبلی را کش کرده‌اند تا پایان TTL همان IP قدیمی را می‌دهند؛ اگر زون سرور ثانویه دارد، انتقال زون هم زمان می‌برد.
یک رویه عملی (و نه حکم مستندات): پیش از تغییر رکورد، TTL را موقتاً پایین بیاورید.
پله سوم: اتصال TCP و لایه TLS
شکست در TCP با شکست در TLS یکی نیست، پس این پله دو تست دارد. اول با nc ببینید پورت 443 پاسخ می‌دهد یا نه؛ گزینه -z در مستندات رسمی nc «فقط به دنبال سرویس در حال شنود می‌گردد، بدون فرستادن هیچ داده‌ای» و گزینه -w مهلت را محدود می‌کند. بعد با s_client سراغ TLS بروید؛ -connect میزبان و پورت را می‌دهد و -servername مقدار SNI را تعیین می‌کند.
nc -z -v -w 5 example.com 443
timeout 15 openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null- دستور nc اتصال نمی‌گیرد: مشکل در لایه شبکه یا فایروال است و به TLS نرسیده‌اید.
- دستور nc موفق است اما s_client گواهی نمی‌دهد: شکست در دست‌دادن TLS است، نه در TCP.
- گواهی برای دامنه دیگری است: مقدار SNI یا تنظیم چنددامنه‌ای وب‌سرور را ببینید.
پله چهارم: کد وضعیت HTTP را بدون دخالت DNS بگیرید
برای جدا کردن سهم DNS از سهم سرور، پاسخ را مستقیم از یک IP مشخص بگیرید. گزینه resolve در curl «نشانی دلخواهی برای یک جفت میزبان و پورت» می‌دهد و در مستندات رسمی «جایگزینی برای فایل hosts روی خط فرمان» توصیف شده است. گزینه -I هم «فقط هدرها را دریافت می‌کند» و درخواست HEAD می‌فرستد.
curl -I --connect-timeout 5 https://example.com/
curl -I --connect-timeout 5 --resolve example.com:443:203.0.113.10 https://example.com/
curl -X GET -I --connect-timeout 5 https://example.com/اگر دستور اول خطا بدهد و دستور دوم کد 200 برگرداند، سرور سالم است و نام دامنه به IP اشتباه حل می‌شود.
یک تله هم هست: بعضی اپلیکیشن‌ها و WAFها به HEAD پاسخ دیگری می‌دهند و کد 405 یا 403 برمی‌گردانند. پس اگر 403 یا 405 گرفتید، دستور سوم را بزنید: گزینه -X «فقط کلمه متد در درخواست HTTP را عوض می‌کند»، پس متد GET می‌رود و خروجی هم‌چنان فقط هدر است. کد GET را مبنا بگیرید.
| کد وضعیت | نام ثبت‌شده در IANA | معنای عملی |
|---|---|---|
| 403 | Forbidden | قاعده دسترسی یا WAF درخواست را رد کرده است. |
| 404 | Not Found | سرور سالم است و مسیر یا میزبان مجازی اشتباه است. |
| 429 | Too Many Requests | محدودیت نرخ درخواست فعال شده است. |
| 502 | Bad Gateway | پاسخ معتبری از سرویس پشتی نرسیده است. |
| 503 | Service Unavailable | سرویس موقتاً پاسخ نمی‌دهد؛ محدودیت نرخ nginx هم همین کد را می‌دهد. |
| 504 | Gateway Timeout | سرویس پشتی در زمان مجاز پاسخ نداده است. |
نام رسمی هر کد و مرجع آن در فهرست کدهای وضعیت IANA ثبت شده است. کدهای 403 و 404 و 503 به RFC 9110 ارجاع دارند و کد 429 به RFC 6585.
لاگ سرور، فایروال و محدودیت نرخ درخواست را چطور بخوانیم؟
لاگ وب‌سرور تنها جایی است که می‌گوید درخواست به اپلیکیشن رسیده یا نه. اگر برای زمان خطا سطری در لاگ access باشد، علت در اپلیکیشن یا قواعد خود سرور است. اگر سطری نباشد، نوبت بررسی فایروال و لایه CDN می‌رسد. تست دسترسی سایت از ایران بدون این بررسی ناقص می‌ماند.
لاگ access وب‌سرور: سطر هست یا نیست؟
مستندات رسمی nginx قالب پیش‌فرض لاگ را با نام combined معرفی می‌کند، شامل $remote_addr و $status و $request و $http_user_agent. IP مبدا می‌گوید درخواست از کدام شبکه آمده و کد وضعیت می‌گوید سرور چه جوابی داده است. زمان خطا را به زمان سرور تبدیل کنید و با grep روی $time_local همان بازه را جدا کنید.
tail -n 200 /var/log/nginx/access.log
grep ' 403 ' /var/log/nginx/access.log | tail -n 20
tail -n 100 /var/log/nginx/error.logمحدودیت نرخ درخواست و کد 503
ماژول رسمی ngx_http_limit_req_module با دستورهای limit_req_zone و limit_req کار می‌کند. طبق مستندات خودش، کد پیش‌فرض پاسخ برای درخواست رد‌شده 503 است و سطح پیش‌فرض ثبت در لاگ error. پس اگر کاربری می‌گوید سایت «گاهی» باز نمی‌شود، لاگ error را بخوانید.
⚠️ دو خطای رایج در خواندن لاگ
سطری با کد 200 به این معنا نیست که کاربر صفحه را دیده است؛ پاسخ می‌تواند در مسیر بازگشت از دست برود.
نبودن سطر هم همیشه «نرسیده است» نیست: اگر CDN پاسخ را از کش داده باشد یا access_log خاموش باشد، لاگ مبدا خالی می‌ماند.
قواعد فایروال و بلاک شدن IP سرور
قاعده فایروال می‌تواند یک IP یا رنج را بدون فرستادن هیچ پاسخی (DROP) دور بریزد و تست از آن شبکه با Timeout تمام شود. ویکی رسمی nftables دستور nft list ruleset و همراه با شناسه هر قاعده دستور nft -a list ruleset را معرفی می‌کند. در خروجی خام، سطرهای drop و reject را جدا کنید.
nft list ruleset
nft -a list ruleset
nft list ruleset | grep -nE 'drop|reject'اگر سرور با iptables مدیریت می‌شود، به یک تله توجه کنید: روی میزبانی که قواعد در جدول‌های nftables نوشته شده‌اند، خروجی iptables -L می‌تواند خالی باشد و به اشتباه نتیجه بگیرید فایروالی نیست. اگر fail2ban فعال است، قواعد ممکن است خودکار اضافه شده باشند؛ این را روی سرور خودتان بررسی کنید.
برای IP سرور که در فهرست‌های بیرونی قرار گرفته، راهنمای رفع بلاک شدن IP سرور را ببینید.
🔶 یادداشت
یک قاعده اشتباه فایروال می‌تواند دسترسی خودتان را هم ببندد. در پنل سرور مجازی ایران وب‌داده کنسول VNC و حالت Rescue راه برگشت را باز می‌گذارند و تغییر IP هم از همان پنل انجام می‌شود.
تست از چند شبکه و اقدام بعد از پیدا کردن علت
یک نقطه دید برای نتیجه‌گیری کافی نیست؛ حداقل دو شبکه مستقل لازم است. تست دسترسی سایت از ایران و از بیرون، در کنار هم، مرز بین «سرویس خراب است» و «این مسیر خراب است» را مشخص می‌کند.
نقطه دیدهایی که همین حالا در اختیار دارید
- اینترنت ثابت در برابر دیتای موبایل یک اپراتور دیگر: دو مسیر و دو ریزالور متفاوت.
- سروری در لوکیشن دیگر: با SSH وصل شوید و همان دستورهای dig و curl را اجرا کنید.
- ریزالورهای عمومی مختلف، همان @8.8.8.8 و @1.1.1.1 پله اول.
- سرویس‌های چندنقطه‌ای مثل check-host؛ نتیجه آن‌ها نشانه است، نه حکم قطعی.
- همکار یا مشتری در شبکه‌ای دیگر: زمان دقیق خطا را از او بخواهید.
مسدودسازی بر اساس کشور در CDN یا در مبدا
یک قاعده کشوری در لایه CDN باعث می‌شود سایت همه جا باز شود و فقط در یک کشور خطا بدهد. مستندات رسمی Cloudflare برای این کار یک قاعده سفارشی با عبارتی شبیه (ip.src.country in {“KP”}) و اقدام Block معرفی می‌کند. قاعده پیش از رسیدن درخواست به مبدا اعمال می‌شود، پس انتظار منطقی این است که لاگ مبدا چیزی نشان ندهد؛ این استنتاج است، نه جمله‌ای از مستندات.
| نتیجه تست | علت محتمل | اقدام |
|---|---|---|
| دو ریزالور دو IP متفاوت می‌دهند | رکورد geo-aware، کش یا رکورد اشتباه | اول نوع رکورد را ببینید، بعد TTL را موقتاً کم کنید |
| خروجی trace روی یک سرور نام می‌ایستد | سرور نام یا واگذاری دامنه | سرورهای نام را در پنل ثبت دامنه ببینید |
| دستور nc اتصال نمی‌گیرد | فایروال یا اختلال مسیر | قواعد را با nft بخوانید و از شبکه دوم تکرار کنید |
| کد 403 برمی‌گردد | قاعده دسترسی، WAF یا قاعده کشوری | لاگ access و قواعد سفارشی CDN را بخوانید |
| کد 429 یا 503 برمی‌گردد | محدودیت نرخ یا فشار منابع | مقدار limit_req و لاگ error را بررسی کنید |
| با گزینه resolve کد 200 می‌گیرید | رزولوشن DNS | مشکل در لایه نام است؛ روی سرور چیزی عوض نکنید |
⚠️ محدودیت‌های این روش
هیچ تست از راه دور تجربه همه کاربران را بازتولید نمی‌کند؛ نتیجه هر دستور فقط برای همان نقطه دید معتبر است.
عوض کردن مسیر ترافیک با ابزارهای دورزدن هم راه‌حل نیست و علت را پنهان می‌کند.
روش ثبت و مقایسه نتیجه‌ها
- نتیجه هر تست را با زمان و نام شبکه ثبت کنید.
- در هر مرحله فقط یک متغیر را عوض کنید.
- پس از هر تغییر، همان دستور را از همان دو شبکه تکرار کنید.
- اگر علت در لایه نام بود، تا پایان TTL انتظار تناقض داشته باشید.
پرسش‌هایی که کاربران درباره باز نشدن سایت و روش تست آن می‌پرسند، بیشترشان به همین نردبان و همین سه لایه برمی‌گردد:
چرا سایت از یک شبکه باز می‌شود و از شبکه دیگر نه؟
چون ریزالور، مسیر شبکه و IP مبدا در دو شبکه یکی نیست. یک دستور ثابت را از دو شبکه اجرا و خروجی‌ها را مقایسه کنید.
هاست داون چیست و چه فرقی با در دسترس نبودن سایت دارد؟
هاست داون یعنی سرویس میزبانی پاسخ نمی‌دهد و همه کاربران خطا می‌گیرند. در دسترس نبودن یعنی سرویس کار می‌کند و فقط گروهی از کاربران به آن نمی‌رسند.
چطور بفهمم مشکل از DNS است یا از سرور؟
پاسخ را یک بار با نام دامنه بگیرید و یک بار با متصل کردن همان نام به IP سرور. اگر حالت دوم کد 200 بدهد و حالت اول خطا، مشکل در لایه نام است.
چرا سایت‌های خارجی روی سرور من باز نمی‌شوند؟
همان سه لایه را روی سرور تست کنید: رزولوشن، TCP و TLS، و در آخر کد وضعیت. گاهی سرویس مقصد خودش درخواست را با کد 403 رد می‌کند؛ راه‌حل پایدار میرور و نسخه کش‌شده است.
کد 403 به چه معناست و از کجا می‌آید؟
نام ثبت‌شده این کد در فهرست IANA برابر Forbidden است و مرجع آن RFC 9110. یعنی سرور یا یک لایه میانی مثل WAF درخواست را رد کرده است.
خطای «به علت تعداد زیادی تلاش ناموفق در دسترس نیست» از کجا می‌آید؟
این پیام معمولاً از خود اپلیکیشن یا افزونه محدودیت ورود می‌آید (مثل وردپرس یا پنل میزبانی)، نه از وب‌سرور. اگر منبع آن nginx و محدودیت نرخ درخواست باشد، کد پاسخ به‌طور پیش‌فرض 503 است و رد آن در لاگ error دیده می‌شود.
چرا بعضی سایت‌ها فقط برای بعضی کاربران باز نمی‌شوند؟
چون تصمیم در لایه‌هایی گرفته می‌شود که به IP مبدا، کشور یا تعداد درخواست وابسته‌اند. خواندن لاگ در همان بازه زمانی تفکیک را روشن می‌کند.
آیا تغییر ریزالور DNS روی کامپیوتر مشکل باز نشدن سایت را حل می‌کند؟
فقط وقتی مشکل در لایه نام باشد. اگر اتصال TCP کامل نمی‌شود یا سرور کد خطا برمی‌گرداند، عوض کردن ریزالور اثری ندارد.
انتشار رکورد DNS چقدر طول می‌کشد؟
به مقدار TTL همان رکورد بستگی دارد. ریزالورهایی که پاسخ قبلی را کش کرده‌اند تا پایان TTL همان IP قدیمی را می‌دهند. TTL را با dig و بدون +short ببینید.
جمع‌بندی؛ تست دسترسی سایت از ایران با نردبان، نه با حدس
باز نشدن سایت یک مسئله واحد نیست و همین باعث می‌شود تغییرهای حدسی کار را خراب‌تر کنند. ترتیبی که آمد، تصمیم را به داده وصل می‌کند: اول رکورد A و AAAA را از چند ریزالور می‌گیرید و خروجی trace را می‌خوانید، بعد TTL را بدون +short می‌سنجید، سپس اتصال TCP را با nc و گواهی را با s_client جدا بررسی می‌کنید و در آخر کد وضعیت را یک بار با نام دامنه و یک بار با اتصال مستقیم به IP می‌گیرید. اگر پاسخ به سرور رسیده باشد، لاگ access آن را نشان می‌دهد و کد وضعیت می‌گوید قاعده دسترسی، محدودیت نرخ یا سرویس پشتی مسئول است. اگر نرسیده باشد، قواعد فایروال و قواعد کشوری CDN دو جای اول برای نگاه کردن‌اند. یک نکته را هم صریح بگوییم: نتیجه هر تست فقط برای همان نقطه دید و همان لحظه معتبر است، و دو پاسخ متفاوت از دو ریزالور با GeoDNS و CDN طبیعی است. با همین نظم، «سایت باز نمی‌شود» به یک جمله دقیق تبدیل می‌شود: کدام لایه، برای کدام کاربران و با کدام کد.
🚀 سروری که از بیرون هم در دسترس است
اگر سرویس شما باید برای مشتری داخل و بیرون کشور پاسخ بدهد، سروری لازم است که IP آن از اینترنت بین‌الملل هم در دسترس باشد. پلن‌های سرور مجازی ایران وب‌داده را ببینید و با تست ساعتی رایگان، همین نردبان را روی سرور خودتان اجرا کنید.
اگر سوالی داشتید، در بخش نظرات با ما در ارتباط باشید.
- مستندات رسمی BIND 9 (ابزار dig): https://bind9.readthedocs.io/en/latest/manpages.html
- مستندات رسمی curl: https://curl.se/docs/manpage.html
- مستندات رسمی nginx (ماژول لاگ): https://nginx.org/en/docs/http/ngx_http_log_module.html
- فهرست کدهای وضعیت HTTP در IANA: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
- مستندات رسمی Cloudflare (مسدودسازی کشوری): https://developers.cloudflare.com/waf/custom-rules/use-cases/block-traffic-from-specific-countries/
