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

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

در این راهنما ابتدا دامنه اصلی و نسخه www را تنظیم می‌کنیم، سپس با یک مثال روی Ubuntu 24.04 و Nginx سایت آزمایشی را بالا می‌آوریم و HTTPS را فعال می‌کنیم. در هر مرحله مشخص است چه چیزی را بررسی کنید تا بتوانید محل مشکل را پیدا کنید.

پیش از شروع چه چیزهایی لازم است؟

• دامنه‌ای که به پنل مدیریت DNS آن دسترسی دارید.

• یک VPS با IPv4 عمومی و امکان دریافت ترافیک ورودی وب.

• دسترسی SSH و کاربری با مجوز sudo برای بخش تنظیم Nginx.

• دسترسی به فایروال سیستم‌عامل و، در صورت وجود، فایروال پنل ارائه‌دهنده سرور.

بخش DNS برای سرویس‌های مختلف قابل استفاده است. دستورهای نصب و پیکربندی وب‌سرور برای یک VPS تازه با Ubuntu 24.04، بدون کنترل‌پنل میزبانی و بدون وب‌سرور دیگری روی پورت ۸۰ نوشته شده‌اند. اگر cPanel یا DirectAdmin دارید، دامنه را از بخش مدیریت دامنه همان پنل اضافه کنید؛ تنظیمات وب‌سرورِ تحت مدیریت پنل را با مثال این مقاله جایگزین نکنید.

اگر هنوز با نقش VPS آشنا نیستید، راهنمای سرور مجازی چیست نقطه شروع مناسبی است. برای آماده‌سازی دسترسی‌ها و امنیت اولیه نیز چک‌لیست راه‌اندازی و امنیت VPS را ببینید.

در مثال‌ها از این مقادیر استفاده می‌کنیم:

دامنه و IP بالا نمونه آموزشی هستند و متعلق به سرور شما نیستند. پیش از اجرای دستورها، همه موارد را با دامنه و IP واقعی خود جایگزین کنید. اگر سرور شما پشت NAT است، نگاشت پورت‌های وب هم باید توسط ارائه‌دهنده یا تنظیمات شبکه برقرار باشد.

مرحله اول: پنل DNS فعال دامنه را پیدا کنید

رکوردها باید در سرویسی تغییر کنند که DNS دامنه را واقعاً مدیریت می‌کند. این سرویس ممکن است شرکت ثبت دامنه، ارائه‌دهنده هاست یا یک سرویس مستقل مثل Cloudflare باشد. محل خرید دامنه همیشه همان محل مدیریت DNS نیست.

Nameserverهای دامنه را در پنل ثبت‌کننده بررسی کنید. در ترمینال لینوکس نیز می‌توانید بپرسید:

dig NS example.com +short

اگر روی Ubuntu دستور dig یا curl نصب نیست، ابزارهای مورد استفاده این راهنما را نصب کنید:

sudo apt update
sudo apt install dnsutils curl

خروجی NS به شما کمک می‌کند سرویس DNS فعلی را تشخیص دهید. اگر دامنه از Nameserverهای Cloudflare استفاده می‌کند، تغییر رکورد A در یک پنل DNS قدیمی روی پاسخ عمومی دامنه اثری ندارد. قالب پرس‌وجوهای این راهنما بر اساس مستندات ابزار dig است.

آیا برای اتصال دامنه باید Nameserver را عوض کنیم؟

اگر سرویس فعلی اجازه مدیریت رکورد A را می‌دهد، معمولاً نیازی به تغییر Nameserver نیست. تغییر NS زمانی مطرح می‌شود که بخواهید مدیریت DNS را به سرویس دیگری منتقل کنید.

در صورت انتقال، ابتدا رکوردهای دامنه را در سرویس جدید کامل کنید؛ به‌خصوص MX و رکوردهای مربوط به SPF، DKIM و DMARC. وضعیت DNSSEC و رکورد DS ثبت‌شده نزد ثبت‌کننده نیز باید با روش انتقال سازگار باشد. ناقص‌بودن این انتقال می‌تواند سایت یا ایمیل دامنه را مختل کند. برای انتقال به Cloudflare، مراحل را از راهنمای رسمی تغییر Nameserver دنبال کنید.

مرحله دوم: رکورد A و نسخه www را تنظیم کنید

در پنل DNS فعال، برای سناریوی ساده این مقاله دو رکورد زیر را بسازید یا رکوردهای موجودِ مربوط به همین نام‌ها را اصلاح کنید:

در بسیاری از پنل‌ها @ به معنی خودِ دامنه اصلی است. بعضی پنل‌ها به‌جای آن نام کامل دامنه یا فیلد خالی می‌خواهند؛ راهنمای همان فیلد را بررسی کنید.

رکورد A نام دامنه را به IPv4 وصل می‌کند. برای www از CNAME استفاده کرده‌ایم تا به نام دامنه اصلی اشاره کند. مقدار CNAME باید نام دامنه باشد؛ https://، شماره پورت و مسیر صفحه را در آن ننویسید. تعریف رکوردها را می‌توانید در مستندات انواع رکورد DNS ببینید.

اگر برای www رکورد A دارید، می‌توانید همان را به IP سرور جدید تغییر دهید؛ ساخت CNAME اضافه لازم نیست. برای یک نام، CNAME را کنار رکورد A یا AAAA همان نام قرار ندهید. راهنمای تعارض رکوردهای هم‌نام

اگر برای دامنه اصلی چند رکورد A دارید، مطمئن شوید همه مقصدها بخشی از طراحی شما هستند؛ باقی‌ماندن IP سرور قبلی می‌تواند بعضی درخواست‌ها را به مقصد قدیمی بفرستد. وابستگی ایمیل را هم بررسی کنید: اگر مقصد MX خود دامنه اصلی باشد، تغییر IP آن ممکن است مسیر دریافت ایمیل را عوض کند، حتی وقتی رکورد MX دست‌نخورده است.

رکورد AAAA چه زمانی لازم است؟

رکورد AAAA برای IPv6 است. فقط وقتی آن را به سرور مبدأ اضافه کنید که IPv6 سرور، مسیر شبکه، فایروال و وب‌سرور واقعاً آماده‌اند. نمونه اجرایی Nginx در این مقاله بر پایه IPv4 است.

در اتصال مستقیم، AAAA قدیمی یا اشتباه ممکن است بخشی از کاربران را به مقصد دیگری ببرد و صدور گواهی را هم دچار مشکل کند. اگر از IPv6 استفاده نمی‌کنید، رکورد اشتباه مربوط به همین سایت را پس از بررسی اصلاح یا حذف کنید. دلیل اهمیت این بررسی در مستندات IPv6 در Let’s Encrypt توضیح داده شده است.

اگر DNS روی Cloudflare است

در سناریوی اتصال مستقیم این آموزش، رکوردهای وب را روی DNS only قرار می‌دهیم تا نتیجه DNS با IP سرور قابل مقایسه باشد. این حالت IP مبدأ را عمومی می‌کند. اگر سایت موجودتان عمداً فقط پشت پراکسی کار می‌کند، برای اجرای این مثال وضعیت آن را بی‌برنامه تغییر ندهید.

در حالت Proxied، دیدن IPهای Cloudflare در نتیجه DNS طبیعی است. در این حالت پاسخ عمومی A یا AAAA لزوماً آدرس مبدأ شما نیست؛ برای بررسی مبدأ باید محتوای رکورد داخل پنل را ببینید. تفاوت DNS only و Proxied در Cloudflare

مرحله سوم: نتیجه DNS را بررسی کنید

پس از ذخیره رکوردها، از یک resolver عمومی پاسخ بگیرید:

dig @1.1.1.1 example.com A +short
dig @1.1.1.1 www.example.com A +short
dig @1.1.1.1 example.com AAAA +short
dig @1.1.1.1 www.example.com AAAA +short

در حالت اتصال مستقیم، پاسخ A باید به IPv4 واقعی VPS برسد. برای www ممکن است ابتدا نام دامنه اصلی و سپس IP آن را ببینید. اگر IPv6 تعریف نکرده‌اید، نداشتن پاسخ AAAA برای این سناریو طبیعی است. این مقایسه درباره رکوردهای Proxied صدق نمی‌کند.

اگر پاسخ خالی است، همان پرس‌وجو را بدون +short اجرا کنید تا وضعیت پاسخ هم دیده شود:

dig @1.1.1.1 example.com A

NXDOMAIN یعنی نام مورد پرس‌وجو در پاسخ DNS وجود ندارد؛ املای دامنه و تنظیمات DNS را بررسی کنید. SERVFAIL خطای پردازش DNS است و علت‌هایی مثل ناسازگاری DNSSEC یا مشکل Nameserver دارد. خروجی خالی به‌تنهایی برای تشخیص علت کافی نیست. تعریف کدهای پاسخ در استاندارد DNS، بخش ۴.۱.۱ آمده است.

اتصال دامنه چقدر طول می‌کشد؟

یک زمان ثابت برای همه تغییرها وجود ندارد. TTL مدت نگهداری رکورد در کش را مشخص می‌کند، اما کم‌کردن TTL رکورد جدید، پاسخ قدیمیِ از قبل کش‌شده را فوری پاک نمی‌کند. تغییر Nameserver نیز با تغییر یک رکورد A یکسان نیست. توضیح TTL در مستندات Cloudflare

اگر بعضی شبکه‌ها هنوز مقصد قبلی را می‌بینند، پاسخ چند resolver را مقایسه کنید. برای نمونه:

dig @8.8.8.8 example.com A +short

پاسخ صحیح از یک resolver، به معنی به‌روزشدن کش همه کاربران نیست. در مقابل، اگر همه پاسخ‌ها مقصد اشتباه دارند، پیش از منتظرماندن، محل و مقدار رکورد را دوباره بررسی کنید.

مرحله چهارم: دامنه را در Nginx تعریف کنید

این بخش را روی VPS تازه با شرایط گفته‌شده اجرا کنید. روی سروری که سایت فعال دارد، ابتدا از تنظیمات فعلی نسخه پشتیبان بگیرید و فقط تنظیمات همان سایت را تغییر دهید.

نصب و بررسی سرویس

sudo apt update
sudo apt install nginx nano
sudo systemctl status nginx --no-pager

وضعیت سرویس باید active (running) باشد. اگر Nginx بالا نیامد، قبل از ادامه علت را بررسی کنید؛ اشغال‌بودن پورت ۸۰ توسط وب‌سرور دیگر یکی از احتمال‌هاست. روش نصب و بررسی سرویس در راهنمای رسمی Ubuntu برای Nginx آمده است.

ساخت صفحه آزمایشی

پوشه و فایل سایت را ایجاد کنید. اگر این مسیر از قبل محتوایی دارد، فایل موجود را با صفحه آزمایشی جایگزین نکنید.

sudo mkdir -p /var/www/example.com/html
sudo nano /var/www/example.com/html/index.html

این محتوای ساده را داخل فایل بگذارید:

<!doctype html>
<html lang="fa" dir="rtl">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>آزمایش اتصال دامنه</title>
</head>
<body>
  <h1>دامنه به سرور متصل شد.</h1>
</body>
</html>

در nano با Ctrl+O و سپس Enter ذخیره کنید و با Ctrl+X خارج شوید.

ساخت تنظیمات دامنه

فایل تنظیمات سایت را باز کنید:

sudo nano /etc/nginx/sites-available/example.com

برای سایت جدید، این تنظیمات را قرار دهید:

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;
    }
}

این تنظیم یک سایت استاتیک آزمایشی است. اجرای وردپرس به PHP و پایگاه داده و اجرای برنامه‌هایی مثل Node.js به تنظیم متناسب با همان برنامه نیاز دارد.

برای فعال‌کردن سایت جدید، لینک تنظیمات را بسازید:

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

اگر پیام File exists گرفتید، لینک از قبل وجود دارد؛ آن را کورکورانه حذف یا بازنویسی نکنید. اگر آزمون nginx -t موفق بود، تنظیمات را بارگذاری کنید:

sudo systemctl reload nginx

ساختار فایل‌ها بر اساس راهنمای پیکربندی Nginx در Ubuntu است. مقدار server_name مشخص می‌کند درخواست این دامنه‌ها به کدام سایت برسد؛ به همین دلیل بازکردن IP به‌تنهایی ممکن است صفحه پیش‌فرض متفاوتی نشان دهد. نحوه انتخاب سایت در Nginx

مرحله پنجم: پورت‌های وب و دسترسی مستقیم را بررسی کنید

اگر UFW از قبل روی سرور فعال است، وضعیت آن را ببینید و پورت‌های وب را مجاز کنید:

sudo ufw status verbose
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

اگر UFW غیرفعال است، افزودن rule به‌تنهایی آن را فعال نمی‌کند. فعال‌سازی فایروال را با بررسی مجازبودن پورت واقعی SSH خودتان انجام دهید تا دسترسی مدیریتی قطع نشود. مراحل آن در آموزش فایروال UFW در اوبونتو آمده است. دستورهای بالا مطابق مستندات فایروال Ubuntu هستند.

اگر پنل ارائه‌دهنده VPS هم فایروال یا Security Group دارد، ورودی TCP پورت‌های ۸۰ و ۴۴۳ را آنجا نیز بررسی کنید. در این مرحله، بازبودن ۴۴۳ به‌تنهایی HTTPS را فعال نمی‌کند؛ هنوز باید گواهی و تنظیم TLS ساخته شود.

اکنون در مرورگر آدرس http://example.com را باز کنید. برای جداکردن تست وب‌سرور از وضعیت کش DNS، می‌توانید از یک دستگاه بیرون از VPS که curl دارد استفاده کنید:

curl --resolve example.com:80:203.0.113.10 http://example.com/
curl --resolve www.example.com:80:203.0.113.10 http://www.example.com/

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

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

مرحله ششم: HTTPS را با Certbot فعال کنید

ابتدا مطمئن شوید هر دو نام example.com و www.example.com از اینترنت با HTTP به همین سایت می‌رسند. اگر www هنوز تنظیم نشده، پیش از درخواست گواهی آن را اصلاح کنید.

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

نصب و صدور گواهی

برای نصب تازه Certbot از مسیر Snap روی Ubuntu استفاده می‌کنیم. اگر Certbot را قبلاً با روش دیگری نصب کرده‌اید، نصب دومِ موازی ایجاد نکنید و ابتدا روش موجود را با راهنمای رسمی تطبیق دهید.

sudo apt install snapd
sudo snap install --classic certbot

سپس گواهی دو نام را درخواست کنید:

sudo /snap/bin/certbot --nginx --redirect -d example.com -d www.example.com

پرسش‌های تعاملی مربوط به ایمیل و شرایط استفاده را با اطلاعات واقعی خودتان پاسخ دهید. این دستور پس از اعتبارسنجی موفق، تنظیمات Nginx را برای HTTPS تغییر می‌دهد. مسیر نصب در راهنمای رسمی Certbot برای Nginx و Snap آمده است.

گزینه --redirect انتقال HTTP به HTTPS را تنظیم می‌کند. این گزینه به‌تنهایی به معنی انتقال نسخه www به دامنه بدون www نیست؛ یکسان‌سازی این دو نام، تنظیم جداگانه‌ای دارد. راهنمای گزینه‌های Certbot

بررسی HTTPS و تمدید

curl -I http://example.com/
curl -I https://example.com/
curl -I https://www.example.com/
sudo /snap/bin/certbot renew --dry-run

در سایت آزمایشی این راهنما، HTTP باید به HTTPS هدایت شود و هر دو نشانی HTTPS صفحه را بدون خطای گواهی ارائه کنند. تست تمدید باید موفق باشد. بسته Certbot زمان‌بندی تمدید دارد؛ موفقیت --dry-run نشان می‌دهد مسیر تمدید در شرایط فعلی کار می‌کند و جای پایش بعدی گواهی را نمی‌گیرد.

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

فعال‌کردن پراکسی Cloudflare پس از راه‌اندازی

اگر می‌خواهید از پراکسی Cloudflare استفاده کنید، پس از اطمینان از HTTPS صحیح روی سرور مبدأ، رکوردهای وب را Proxied کنید و حالت رمزنگاری را روی Full (strict) قرار دهید. سرور مبدأ باید روی ۴۴۳ پاسخ دهد و گواهی معتبر و منطبق با نام دامنه داشته باشد؛ گواهی عمومی صادرشده در مرحله قبل برای این سناریو مناسب است. آماده‌بودن گواهی لبه Cloudflare را هم بررسی کنید. الزامات Full (strict)

پس از این تغییر، بازشدن سایت و آزمون تمدید را دوباره بررسی کنید؛ قوانین پراکسی و دسترسی نباید مسیر اعتبارسنجی را مسدود کنند.

اگر دامنه باز نشد، از کجا عیب‌یابی کنیم؟

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

برای مثال، ترکیب حالت Flexible با اجبار HTTPS در مبدأ می‌تواند حلقه تغییر مسیر بسازد. اصلاح را بر اساس تنظیمات واقعی انجام دهید؛ راهنمای رسمی خطای Too many redirects علت‌های مختلف را توضیح می‌دهد.

پرسش‌های متداول اتصال دامنه به VPS

برای اتصال دامنه باید DNS Server روی VPS نصب کنم؟

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

آیا ساخت رکورد A سایت را به‌طور کامل منتقل می‌کند؟

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

می‌توان چند دامنه را به یک IP وصل کرد؟

بله. هر دامنه می‌تواند به همان IP اشاره کند و وب‌سرور با تنظیمات نام‌محور، سایت مربوط به آن را انتخاب کند. پوشش گواهی برای نام‌های مورد استفاده نیز باید درست باشد. نمونه سازوکار آن در مستندات server_name در Nginx توضیح داده شده است.

آیا ping موفق یعنی سایت درست راه‌اندازی شده است؟

خیر. ping به‌تنهایی وضعیت HTTP، انتخاب سایت در Nginx یا اعتبار گواهی را بررسی نمی‌کند. برای ارزیابی سایت، پاسخ وب و محتوای واقعی آن را با مرورگر یا curl بررسی کنید. بسته‌بودن پاسخ ping نیز به‌تنهایی نشانه خرابی سایت نیست.

چرا بعد از تغییر DNS هنوز سایت قبلی باز می‌شود؟

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

پس از اتصال دامنه چه چیزی را بررسی کنیم؟

پیش از معرفی سایت به کاربران، دامنه اصلی و www را از یک شبکه دیگر باز کنید، محتوای درست سایت را ببینید و از معتبر بودن HTTPS و موفقیت تست تمدید مطمئن شوید. اگر دامنه ایمیل دارد، ارسال و دریافت ایمیل را هم بررسی کنید.

صفحه آزمایشی را با برنامه واقعی جایگزین کنید و پشتیبان‌گیری، به‌روزرسانی و پایش سرویس را ادامه دهید. برای بررسی تناسب ظرفیت سرور با برنامه‌ای که قرار است میزبانی کنید، راهنمای انتخاب RAM، CPU و فضای دیسک VPS را بخوانید. خدمات نتزو نیز از وب‌سایت نتزو قابل بررسی است.