اپلیکیشن شما روی آدرس پاستا در دسترس است، اما کاربران باید آن را با دامنه اصلی محصول، مثل app.example.com، باز کنند. اتصال دامنه SSL زمانی کامل است که DNS به مقصد درست اشاره کند، پاستا دامنه را بشناسد، گواهی TLS صادر شود و درخواست‌های HTTP به HTTPS هدایت شوند.
اگر ترتیب مراحل را رعایت نکنید، ممکن است دامنه به سرور قبلی برسد، صدور گواهی متوقف بماند یا ریدایرکت حلقه‌ای ایجاد شود. ابتدا سلامت سرویس را بررسی کنید، دامنه را در پاستا ثبت کنید، رکورد نمایش‌داده‌شده در کنسول را عیناً در DNS بسازید و پیش از اجباری‌کردن HTTPS، پاسخ دامنه را آزمایش کنید.
پاسخ سریع: برای اتصال دامنه SSL چه کاری باید انجام دهید؟
مطمئن شوید اپلیکیشن روی آدرس HTTPS ارائه‌شده توسط پاستا سالم است. سپس دامنه یا زیردامنه را به سرویس اضافه کنید و نوع، نام و مقدار رکورد DNS را از کنسول بردارید. این مقادیر را در DNS authoritative دامنه ثبت کنید و پس از انتشار رکورد، وضعیت دامنه و TLS را دوباره در کنسول ببینید.
نوع رکورد را حدس نزنید. مقصد دامنه ریشه، مانند example.com، ممکن است با مقصد زیردامنه‌ای مثل www.example.com فرق داشته باشد. بعضی DNS Providerها نیز برای دامنه ریشه رفتار متفاوتی دارند. پس از فعال‌شدن HTTPS، پاسخ نسخه HTTP را بررسی کنید. اگر به HTTPS هدایت نمیشود، باید ریدایرکت را در پلتفرم، CDN یا اپلیکیشن تنظیم کنید.
اتصال دامنه از چهار لایه مستقل تشکیل می‌شود
قفل مرورگر نتیجه کار چهار جزء است:
|
لایه |
وظیفه |
نشانه سلامت |
|
سرویس |
پاسخ‌دادن اپلیکیشن |
آدرس پاستا بدون خطای Runtime باز می‌شود |
|
DNS |
رساندن نام دامنه به مقصد پاستا |
Resolver عمومی مقدار مورد انتظار را برمی‌گرداند |
|
مسیریابی |
فرستادن درخواست دامنه به سرویس درست |
دامنه محتوای همان اپلیکیشن را نمایش می‌دهد |
|
TLS و ریدایرکت |
رمزنگاری ارتباط و هدایت HTTP |
HTTPS معتبر است و HTTP به مقصد امن می‌رود |
DNS گواهی صادر نمی‌کند و گواهی TLS هم تضمین نمی‌کند درخواست به سرویس درست رسیده باشد. در زیرساخت‌های Kubernetes، Ingress یا لایه ورودی معمولاً درخواست را بر اساس نام میزبان مسیریابی میکند. راهنمای «Ingress و Load Balancer؛ راهنمای عملی مسیریابی ترافیک» این بخش را توضیح می‌دهد.
پیش از تغییر DNS، سرویس را از دامنه جدا کنید
آدرس HTTPS فعلی سرویس روی دامنه پاستا را باز و مسیرهای مهم را آزمایش کنید. اگر Health Check، صفحه اصلی یا API در همین مرحله خطا دارد، تغییر DNS مشکل را حل نمی‌کند؛ فقط عیب‌یابی را سخت‌تر میکند.
برای یک فرانت‌اند React، Build موفق کافی نیست. فایل‌های استاتیک، مسیرهای SPA و درخواست‌های API را نیز بررسی کنید. راهنمای «دیپلوی اپلیکیشن React روی ابر ایران؛ راهنمای عملی» زمینه این بررسی را پوشش می‌دهد.
پیش از ادامه، این موارد را ثبت کنید:
-
دامنه نهایی، مانند app.example.com
-
وضعیت فعلی سرویس روی آدرس پاستا
-
DNS Provider authoritative دامنه
-
رکوردهای موجود با همان نام
-
سرویس واسط احتمالی مانند CDN یا Reverse Proxy
با این اطلاعات می‌توانید نتیجه تغییر را مقایسه کنید و در صورت نیاز به تنظیم قبلی برگردید.
چگونه دامنه را در پاستا و DNS تنظیم کنید؟
۱. دامنه دقیق را به سرویس اضافه کنید
در بخش دامنه سرویس، نام کامل دامنه را بدون http://، https://، مسیر یا اسلش پایانی وارد کنید:
app.example.com
اگر هم example.com و هم www.example.com باید کار کنند، آن‌ها را دو نام مستقل در نظر بگیرید. ثبت یکی لزوماً دیگری را پوشش نمی‌دهد.
کنسول باید دامنه را ثبت کند و دستور DNS لازم را نشان دهد. اگر وضعیت دامنه هنوز در انتظار است، حدس نزنید که باید از A، AAAA یا CNAME استفاده کنید.
۲. رکورد اعلام‌شده را عیناً در DNS بسازید
در پنل DNS، نوع، Name و Value نمایش‌داده‌شده در پاستا را وارد کنید:
-
رکورد دیگری با همان نام و نوع متعارض باقی نماند.
-
پنل DNS ممکن است نام دامنه را خودکار به فیلد Name اضافه کند.
-
اگر CDN یا Proxy دیگری جلوی دامنه فعال است، ممکن است بررسی اتصال مستقیم نتیجه متفاوتی داشته باشد.
-
هنگام ویرایش دامنه ریشه، رکوردهای ایمیل مانند MX و TXT را حذف نکنید.
-
پیش از تغییر Nameserver، همه رکوردهای موجود را بازبینی و ذخیره کنید.
اگر از CDN پاستا استفاده می‌کنید، رکوردهای DNS را پیش از تغییر Nameserver بررسی کنید. قابلیت‌های DNS، TLS، کش، Origin و فایروال به پلن فعال وابسته‌اند.
۳. انتشار DNS را از بیرون بررسی کنید
دستورهای زیر فقط DNS را می‌خوانند و اجرای دوباره آن‌ها تغییری ایجاد نمی‌کند:
dig +short app.example.com A
dig +short app.example.com AAAA
dig +short app.example.com CNAME
فقط یکی از این پاسخ‌ها الزاماً موردنیاز است. نتیجه را با رکوردی مقایسه کنید که کنسول پاستا برای همان دامنه نشان می‌دهد. پاسخ خالی، مقدار قدیمی یا مقصد متفاوت یعنی مسئله هنوز در لایه DNS است.
انتشار DNS همزمان نیست؛ Resolverهای مختلف ممکن است تا پایان TTL پاسخ‌های متفاوتی داشته باشند. مستندات رسمی Let’s Encrypt درباره روش‌های اعتبارسنجی دامنه نیز تفاوت زمان مشاهده رکوردها میان DNS Providerها و نقاط شبکه را توضیح می‌دهد.
۴. فعال‌شدن HTTPS را جداگانه آزمایش کنید
پس از تأیید DNS، وضعیت دامنه را در پاستا ببینید و آدرس HTTPS را باز کنید:
curl -I https://app.example.com
این فرمان فقط Headerهای پاسخ را می‌خواند. اگر گواهی هنوز معتبر نیست، به‌جای خاموش‌کردن بررسی TLS، وضعیت DNS، دامنه ثبت‌شده و مسیر اعتبارسنجی را بررسی کنید. نادیده‌گرفتن اعتبار گواهی، مشکل را پنهان میکند.
در پاستا SSL به‌صورت خودکار صادر و تمدید می‌شود
پس از اتصال صحیح دامنه، وضعیت HTTPS را در کنسول بررسی کنید و سپس نسخه عمومی سرویس را آزمایش کنید.
اتصال دامنه در پاستا
