آموزش اتصال دامنه به سرور مجازی و بررسی صحت تنظیمات

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

این راهنما مسیر اتصال مستقیم یک وب‌سایت به VPS را توضیح می‌دهد؛ از پیدا کردن محل تنظیم رکوردها تا آزمایش DNS، محتوای سایت و HTTPS. مثال وب‌سرور برای Nginx نصب‌شده روی Ubuntu است. اگر کنترل‌پنل دارید، نام دامنه و تنظیمات وب را از همان پنل مدیریت کنید تا تغییر دستی فایل‌ها با تنظیمات تولیدشدهٔ پنل تداخل نداشته باشد.

پیش از تغییر، اطلاعات مقصد و رکوردهای فعلی را آماده کنید

به دسترسی مدیریت دامنه، پنل DNS فعال و تنظیمات وب‌سرور نیاز دارید. دامنه باید فعال باشد و سرور هم مسیر دسترسی عمومی مناسب برای وب داشته باشد. IP خصوصی ماشین، مانند نشانی‌های شبکهٔ داخلی، معمولاً مقصد مناسبی برای رکورد عمومی سایت نیست؛ در معماری دارای NAT باید آدرس عمومی و مسیر هدایت ترافیک را از ارائه‌دهندهٔ زیرساخت بگیرید.

در تمام مثال‌ها، example.com نام نمونه و 192.0.2.10 آدرس مستنداتی است؛ این IP برای اتصال واقعی قابل استفاده نیست. پیش از اجرا، نام دامنه، IP، مسیر فایل‌ها و نیم‌سرور نمونه را با اطلاعات واقعی پروژه جایگزین کنید. دستورهای DNS و curl روی دستگاه بررسی‌کننده اجرا می‌شوند؛ دستورهای sudo مربوط به خود سرور لینوکس‌اند.

از رکوردهای فعلی، به‌ویژه MX، TXT و زیردامنه‌های فعال، نسخه یا خروجی بگیرید. اگر سایت از قبل فعال است، مقصد جدید را پیش از تغییر عمومی آزمایش کنید و مقصد قبلی را تا پایان بررسی در دسترس نگه دارید. این کار جای برنامهٔ انتقال داده‌های سایت را نمی‌گیرد.

گام اول؛ محل درست تنظیم DNS را پیدا کنید

ابتدا ببینید نیم‌سرورهای فعال دامنه کدام‌اند. در ویندوز می‌توانید از دستور زیر استفاده کنید:

nslookup -type=NS example.com

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

اگر DNS فعلی را نگه می‌دارید، اتصال دامنه به VPS معمولاً فقط به تغییر رکوردهای وب نیاز دارد. خرید سرور از شرکت دیگر، الزاماً به معنای تغییر نیم‌سرورها یا انتقال ثبت دامنه نیست.

اگر ارائه‌دهندهٔ DNS را عوض می‌کنید، اول Zone جدید و همهٔ رکوردهای لازم را آماده کنید؛ سپس نیم‌سرورهای دقیق اعلام‌شدهٔ ارائه‌دهنده را در سامانهٔ ثبت‌کننده تغییر دهید. برای دامنهٔ ir، این کار از مسیر مجاز مدیریت دامنه نزد ثبت‌کننده یا ایرنیک انجام می‌شود. نام منوها به سامانه بستگی دارد. نام‌هایی مانند ns1.example.com را از روی حدس نسازید؛ راه‌اندازی نیم‌سرور اختصاصی، کار جداگانه‌ای است.

اگر DNSSEC فعال است، جابه‌جایی مرجع باید همراه با هماهنگی رکورد DS در سمت ثبت‌کننده و کلیدهای سرویس جدید انجام شود؛ باقی ماندن DS ناسازگار می‌تواند اعتبارسنجی را مختل کند. این بخش را مطابق راهنمای مهاجرت ارائه‌دهنده انجام دهید، نه با حذف بی‌برنامهٔ تنظیمات امنیتی.

گام دوم؛ رکورد دامنه و www را تنظیم کنید

در مثال اتصال مستقیم با IPv4، این دو رکورد یک انتخاب ساده‌اند. نماد @ در بسیاری از پنل‌ها به ریشهٔ Zone اشاره می‌کند؛ بعضی پنل‌ها به‌جای آن، فیلد خالی یا نام کامل دامنه می‌خواهند.

در فیلد مقدار رکورد A فقط IP وارد کنید؛ http، https، شمارهٔ پورت و مسیر صفحه بخشی از این مقدار نیستند. در CNAME هم نام مقصد وارد می‌شود، نه IP یا نشانی کامل صفحه. پنل ممکن است نام مقصد را به‌صورت کامل، با نقطهٔ پایانی، بپذیرد؛ پیش از ذخیره مطمئن شوید آن را به نامی مانند example.com.example.com تبدیل نکرده است.

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

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

اگر سرویس DNS شما قابلیت پراکسی دارد، مشخص کنید این راهنما را در حالت اتصال مستقیم دنبال می‌کنید یا از مسیر پراکسی استفاده می‌کنید. در حالت پراکسی، پاسخ عمومی می‌تواند IP واسطه باشد و تطبیق آن با IP اصلی VPS معیار مناسبی نیست. تفاوت فیلدها و حالت پراکسی را در راهنمای مدیریت رکوردهای کلودفلر به‌عنوان یک نمونهٔ مشخص بخوانید.

گام سوم؛ نام دامنه را در وب‌سرور تعریف کنید

یک IP می‌تواند چند سایت را میزبانی کند. وب‌سرور باید بداند درخواست example.com و www.example.com متعلق به کدام سایت است. در Nginx این تطبیق با server_name انجام می‌شود؛ شرح رفتار آن را در مستندات رسمی نام سرورها بخوانید.

اگر Nginx را از بستهٔ Ubuntu نصب کرده‌اید و سایت را بدون کنترل‌پنل مدیریت می‌کنید، یک فایل جدا در مسیر /etc/nginx/sites-available/example.com بسازید. نمونهٔ زیر فقط برای یک سایت ایستای ساده روی HTTP است. مسیر root باید به پوشهٔ واقعی محتوا اشاره کند و فایل index.html قابل خواندن برای وب‌سرور باشد. تنظیمات PHP، وردپرس یا پراکسی برنامه را با این نمونه جایگزین نکنید.

server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/example.com/html;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}

فعال‌سازی و بررسی پیکربندی Nginx

اگر فایل هنوز در sites-enabled پیوند ندارد، آن را فعال کنید:

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/example.com
sudo nginx -t

فقط پس از موفق بودن آزمون پیکربندی، تغییر را بارگذاری کنید:

sudo systemctl reload nginx

پیوند موجود را دوباره نسازید و فایل سایت‌های دیگر را حذف نکنید. خطای nginx -t را پیش از بارگذاری برطرف کنید. اگر قبلاً برای همین نام یک server block دارید، همان تنظیم موجود را بررسی کنید تا تعریف تکراری نسازید.

در Apache، همین نام‌ها در VirtualHost با ServerName و ServerAlias مشخص می‌شوند؛ راهنمای رسمی VirtualHost مبتنی بر نام مرجع این مسیر است. در IIS یا کنترل‌پنل نیز باید دامنه را در تنظیم سایت یا Binding مربوط تعریف کنید؛ فایل Nginx برای آن محیط‌ها کاربرد ندارد.

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

گام چهارم؛ پاسخ DNS را از مرجع و Resolver بررسی کنید

در لینوکس و مک، اگر dig نصب است، می‌توانید ابتدا پاسخ Resolver فعلی را ببینید:

dig example.com A +noall +answer
dig www.example.com A +noall +answer
dig example.com AAAA +noall +answer

در پاسخ نام اصلی، IP مقصد را بررسی کنید. برای www که CNAME دارد، زنجیرهٔ نام مستعار و آدرس نهایی را بخوانید. خالی بودن پاسخ AAAA در سناریویی که عمداً IPv6 تعریف نکرده‌اید، به‌خودی‌خود خطا نیست.

برای پرسش مستقیم از مرجع، نام نیم‌سرور واقعی را جایگزین ns1.dns-provider.example کنید و همین بررسی را برای نیم‌سرورهای مرجع دیگر هم انجام دهید:

dig @ns1.dns-provider.example example.com A +norecurse

علاوه بر بخش ANSWER، پرچم aa را بررسی کنید؛ این پرچم نشان می‌دهد پاسخ برای آن پرسش مرجع است. اگر رکورد در پنل جدید درست است اما هنوز مرجع فعال دیگری پاسخ می‌دهد، صرف انتظار برای کش مشکل تنظیم نیم‌سرورها را حل نمی‌کند. نحو تعیین سرور و نوع پرس‌وجو را در راهنمای رسمی dig بخوانید.

در ویندوز، بدون نصب dig می‌توانید از ابزار nslookup استفاده کنید:

nslookup -type=A example.com
nslookup -type=A www.example.com
nslookup -type=AAAA example.com
nslookup -type=A example.com ns1.dns-provider.example

در خروجی nslookup، آدرس ابتدای گزارش معمولاً متعلق به سرور DNS پاسخ‌دهنده است؛ آن را با IP دامنه اشتباه نگیرید. عبارت Non-authoritative answer نیز به‌تنهایی نشانهٔ خطا نیست؛ پاسخ می‌تواند از Resolver آمده باشد.

اگر پاسخ مرجع تازه است ولی Resolver هنوز مقدار قبلی را می‌دهد، کش و TTL را بررسی کنید. زمان نگهداری رکورد در کش روی دیده شدن تغییر اثر می‌گذارد؛ یک مهلت ثابت برای همهٔ دامنه‌ها وجود ندارد. پاک کردن کش دستگاه هم کش تمام Resolverهای اینترنت را پاک نمی‌کند.

گام پنجم؛ محتوای سایت و HTTPS را جداگانه آزمایش کنید

پیش از تغییر عمومی DNS هم می‌توانید از دستگاه خود، پاسخ وب‌سرور مقصد را با نام دامنه آزمایش کنید:

curl --resolve example.com:80:192.0.2.10 http://example.com/

گزینهٔ –resolve در همین درخواست، اتصال را به IP تعیین‌شده می‌برد و نام دامنه در درخواست حفظ می‌شود. طبق راهنمای رسمی curl، این گزینه جایگزینی موقت برای حل نام همان میزبان و پورت است؛ بنابراین موفقیت این آزمون، انتشار عمومی DNS را ثابت نمی‌کند. در Windows PowerShell، اگر curl به فرمان دیگری اشاره می‌کند، از curl.exe استفاده کنید.

محتوای برگشتی باید متعلق به سایت خودتان باشد؛ صرف دریافت وضعیت 200 یا دیدن صفحهٔ پیش‌فرض Nginx، تأیید اتصال درست سایت نیست. اگر HTTP به HTTPS هدایت می‌شود، مقصد هدایت را هم جدا بررسی کنید.

برای HTTPS، گواهی معتبر باید نام‌های مورد استفاده، از جمله www در صورت استفاده، را پوشش دهد. آن را روی محل پایان ارتباط TLS پیکربندی کنید. اگر از روش HTTP-01 برای صدور گواهی استفاده می‌کنید، مسیر اعتبارسنجی باید روی پورت ۸۰ قابل دسترسی باشد؛ روش DNS-01 از رکورد TXT استفاده می‌کند. شرایط هر روش را در مستندات Let’s Encrypt بخوانید. این دو روش را با تنظیم رکورد A یکسان ندانید.

پس از نصب گواهی، مقصد مستقیم را با این دستور آزمایش کنید:

curl --resolve example.com:443:192.0.2.10 https://example.com/

آزمون را برای www هم با جایگزینی نام در هر دو بخش دستور تکرار کنید. از گزینهٔ -k برای تأیید نهایی استفاده نکنید؛ آن گزینه بررسی اعتبار گواهی را کنار می‌گذارد. در معماری پراکسی یا CDN، آزمون مستقیم مبدأ و آزمون عمومی سایت دو بررسی متفاوت‌اند و گواهی هر بخش باید با طراحی همان بخش سازگار باشد.

در پایان، هر دو نام را بدون –resolve در مرورگر و با curl معمولی باز کنید. نام گواهی، صفحهٔ نمایش‌داده‌شده، مسیرهای هدایت و یک صفحهٔ داخلی مهم را از شبکهٔ کاربران هدف بررسی کنید. این مرحله نشان می‌دهد مسیر عادی دسترسی هم کار می‌کند.

اگر دامنه باز نشد، از نتیجهٔ آزمون به بررسی بعدی برسید

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

برای بررسی مسیر مدیریت دامنه، صفحهٔ DNS ابری ابر آراد را ببینید. اگر در انتخاب IP عمومی، مسیر شبکه یا محل تنظیم رکوردها ابهام دارید، نام دامنه، نیم‌سرورهای فعال و نتیجهٔ آزمون‌های بالا را برای بررسی آماده کنید و از مشاورهٔ ابر آراد کمک بگیرید.