تست سایت پیش از تغییر DNS با curl –resolve

با curl --resolve می‌توانید یک نام و پورت مشخص را فقط در همان اجرای curl به IP انتخابی وصل کنید؛ بدون تغییر DNS عمومی یا فایل hosts. اگر URL دامنه را حفظ کنید، نام مورد استفاده برای HTTPS و بررسی گواهی هم حفظ می‌شود. این روش برای بررسی سرور مقصد پیش از جابه‌جایی مفید است، اما آزمون کامل مرورگر، پرداخت یا همهٔ فایل‌های سایت نیست.

پیش‌نیاز، نام دقیق سایت و IP مقصدی است که میزبان برای آزمون مجاز معرفی کرده است. فرمان‌ها فقط درخواست خواندنی به مسیر عمومی می‌فرستند؛ از مسیرهای انجام عملیات، لینک خروج، توکن و اطلاعات ورود استفاده نکنید. تفاوت تغییر واقعی DNS با انتخاب مقصد را در نیم‌سرور یا رکورد A ببینید.

۱. قبل از فرمان چه چیزهایی را بدانیم؟

• در ویندوز PowerShell از curl.exe استفاده کنید تا با نام مستعار احتمالی curl اشتباه نشود؛ در لینوکس و مک معمولاً نام فرمان curl است.
• با curl.exe --version نسخه را ببینید؛ برای لینوکس/مک نام فایل اجرایی را به curl تغییر دهید.
• نام دامنه باید در تنظیم مقصد پذیرفته شده و گواهی مناسب آن روی سرویس HTTPS آماده باشد؛ گزینهٔ resolve گواهی صادر نمی‌کند.
• اگر محیط از پراکسی اجباری استفاده می‌کند، مقصد اتصال ممکن است از مسیر آن عبور کند؛ تنظیم سازمانی را دور نزنید و نتیجه را پیش از تفسیر با مسئول شبکه تطبیق دهید.

در مرجع رسمی گزینهٔ resolve، کلید نگاشت، ترکیب نام و پورت است. نگاشت برای example.com:443 به‌خودی‌خود درخواست پورت ۸۰ یا www.example.com را پوشش نمی‌دهد.

۲. نام، پورت و IP مقصد را درست بنویسید

الگوی زیر فقط توضیح ساختار است. IP 192.0.2.10 از محدودهٔ مستندات است و سرور واقعیِ آمادهٔ آزمون نیست؛ آن را با IP مجاز میزبان خود عوض کنید و نام دامنه را هم در هر دو جای فرمان یکسان جایگزین کنید.

curl.exe --head --connect-timeout 8 --max-time 20 --resolve "example.com:443:192.0.2.10" "https://example.com/"

head درخواست HEAD می‌فرستد؛ connect-timeout مهلت اتصال و max-time مهلت کل اجرا را محدود می‌کنند. نتیجه شامل هدرهاست، نه بدنهٔ صفحه. بعضی برنامه‌ها HEAD را متفاوت از GET پاسخ می‌دهند؛ کد ۴۰۵ الزاماً نشانهٔ خرابی HTTPS نیست.

URL را به https://192.0.2.10/ تغییر ندهید و فقط هدر Host اضافه نکنید. توضیح رسمی curl دربارهٔ SNI و نام مقصد نشان می‌دهد چرا حفظ نام URL برای آزمون HTTPS مهم است. اگر IP مقصد IPv6 است، شکل آدرس در نگاشت باید با براکت و مطابق مستند ابزار نوشته شود.

۳. مقصد واقعی و کد پاسخ را ببینید

اگر فرمان اول به مقصد درست رسید، خروجی تشخیصی زیر را اضافه کنید. فرمان یک‌خطی است؛ شکست ظاهری خط در صفحه به معنی افزودن Enter داخل فرمان نیست.

curl.exe --head --silent --show-error --connect-timeout 8 --max-time 20 --resolve "example.com:443:192.0.2.10" --write-out "\nremote_ip=%{remote_ip}\nhttp_code=%{http_code}\nssl_verify_result=%{ssl_verify_result}\n" "https://example.com/"

remote_ip و http_code را همراه وضعیت خروجِ فرمان بخوانید. صفر بودن ssl_verify_result به‌تنهایی موفقیت نیست؛ اگر اتصال اصلاً برقرار نشده باشد هم نباید از آن اعتبار گواهی را نتیجه بگیرید. تعریف متغیرهای write-out در مستند رسمی خروجی curl آمده است.

۴. یک نمونهٔ واقعیِ محدود را ببینید

برای آزمون روش، A دامنهٔ عمومی example.com را خواندیم و یکی از IPهای همان پاسخ را به‌صورت دستی در resolve گذاشتیم. این آزمایش، سرور جدید یا مهاجرت واقعیِ رایکت نیست؛ فقط رفتار انتخاب مقصدِ همان فرمان را می‌سنجد.

در اجرای ثبت‌شده با curl نسخهٔ ۷٫۷۹٫۱ روی ویندوز و Schannel، درخواست HEAD با نگاشت به 104.20.23.154، وضعیت خروج صفر و نتیجهٔ زیر داشت. مقادیر DNS عمومی می‌توانند بعداً تغییر کنند؛ این IP را به‌عنوان مقصد هاست خود استفاده نکنید.

remote_ip=104.20.23.154
http_code=200
ssl_verify_result=0

این سه خط از خروجی واقعی استخراج شده‌اند؛ تصویر بالا اسکرین‌شات پاسخ DNS است، نه عکس ترمینال. آزمون روی سرور Staging اختصاصی، پرداخت، ورود یا مسیر بازیابیِ انتقال انجام نشده است.

۵. ریدایرکت و فایل‌های صفحه را فراموش نکنید

در فرمان‌های بالا عمداً دنبال‌کردن خودکار هدایت اضافه نشده است. ابتدا Location را بخوانید. اگر ادامه به www.example.com می‌رود، آن نام/پورت هم نگاشت جدا لازم دارد؛ در غیر این صورت، ادامهٔ درخواست ممکن است دوباره با DNS عادی به مقصد دیگری برسد. هدر پاسخ حاوی آدرس خصوصی یا توکن را هم پیش از ارسال برای پشتیبانی پاک‌سازی کنید.

curl با یک درخواست، همهٔ CSS، تصویر، درخواست API و رفتار جاوااسکریپت صفحه را مثل مرورگر اجرا نمی‌کند. حتی GET موفق یک صفحه، کارکرد سبد خرید یا ارسال ایمیل را ثابت نمی‌کند. بعد از تأیید HTTPS و مسیر پایه، سناریوهای کاربردی باید در محیط آزمایشیِ مجاز و با دادهٔ آزمایشی جدا بررسی شوند.

۶. خطای TLS را دور نزنید

اگر گواهی نام را پوشش نمی‌دهد یا زنجیره معتبر نیست، گزینهٔ -k یا --insecure را برای «سبزشدن آزمون» اضافه نکنید. راهنمای بررسی گواهی در curl توضیح می‌دهد که اعتبارسنجی پیش‌فرض بخشی از اتصال امن است. تفاوت نام یا اعتماد را جدا حل کنید و سپس همان فرمان را دوباره اجرا کنید.

برای وضعیت گواهی مقصد، راهنمای SSL در سی‌پنل کمک می‌کند. اگر هدف فقط شناخت IPهای فعلی است، آموزش nslookup کافی است؛ دریافت IP به معنی اجازهٔ آزمون هر سرور یا دسترسی به Origin محدودشده نیست.

۷. پایان آزمون و تصمیم انتقال

با پایان فرایند curl، نگاشت این فرمان ماندگار نمی‌ماند؛ چیزی در Zone یا hosts برای برگرداندن وجود ندارد. اما نتیجهٔ موفق این فرمان مجوز تغییر DNS نیست. پیش از انتقال واقعی باید نسخهٔ سالم داده، همگام‌سازی دیتابیس، نام‌های www/API، ایمیل، گواهی و طرح بازگشت بررسی شوند.

برای تفسیر زمان انتشارِ تغییر، TTL در DNS را ببینید. گزارش آزمون را با نام، IP، زمان، نسخهٔ ابزار، کد HTTP و محدودیت‌ها نگه دارید؛ عبارت «همه‌چیز تست شد» جای این شواهد را نمی‌گیرد.

۸. پرسش‌های رایج

این فرمان DNS بقیهٔ کاربران را عوض می‌کند؟

خیر. نگاشت در همان اجرای ابزار است؛ DNS عمومی، مرورگرها و فایل hosts تغییر نمی‌کنند.

چرا IP خروجی با IP نگاشت فرق دارد؟

نام/پورت نگاشت، هدایت به نام دیگر، وجود پراکسی یا تفاوت مسیر درخواست را بررسی کنید. قبل از اعلام موفقیت، مشخص کنید واقعاً کدام اتصال اندازه‌گیری شده است.