النطاقات المخصصة لـ SaaS: نطاقات فرعية بطاقة البطاقة والشهادات المؤتمتة

يكتب العميل app.theircustomer.com في متصفحه وينتظر. خلف تلك الثلاث ثواني من التحميل، يقوم البنية الأساسية الخاصة بك بتنسيق بحث DNS والتحقق من شهادة بطاقة وتوجيه عبر البروكسي العكسي وخدمة لوحة التحكم الخاصة بهم بعلامتهم التجارية — كل ذلك دون أن يعرفوا عنوان IP الفعلي للخادم. لقد نشرت هذا نمط النطاق المخصص أربع مرات عبر مكدسات مختلفة، وكل تطبيق كشف عن مشاكل لم تظهر أبداً في مواصفات المنتج: حدود معدل Let's Encrypt التي تحجب تسجيل العميل العاشر، سلوك تسطيح CNAME الذي ينكسر على موفري DNS المحددين، تأخيرات الانتشار التي تتراكم فيها تذاكر الدعم أثناء أسبوع الإطلاق. ستقوم بهندسة هذا مرة واحدة معتقداً أنها مشروع من مشروعين — قبل أن تكتشف حالات الحافة التي تحول أتمتة SSL إلى عطلة نهاية أسبوع من تصحيح أخطاء Cloudflare API والتحقق من سلسلة الشهادات.

هذه المقالة هي دليل العمل الذي تمنيت أن أملكه. سنغطي النطاقات الفرعية البطاقة لتطبيقات متعددة المستأجرين، وتوفير SSL المؤتمت مع Let's Encrypt والبدائل، والنطاقات المخصصة حيث يحضر العملاء نطاقاتهم الخاصة، والمخاوف التشغيلية التي ستعضك في الساعة 2 صباحاً إذا لم تخطط لها.

جدول المحتويات

• لماذا تهم النطاقات المخصصة لـ SaaS
• نظرة عامة على العمارة: ثلاثة طرق
• النطاقات الفرعية البطاقة لتعدد الإيجار
• SSL المؤتمت مع Let's Encrypt
• النطاقات المخصصة: التدفق الكامل
• أنماط البنية الأساسية حسب المنصة
• تكوين DNS والتحقق
• تصلب الإنتاج والمراقبة
• تحليل التكاليف في الحجم
• الأسئلة الشائعة

لماذا تهم النطاقات المخصصة لـ SaaS

النطاقات المخصصة ليست مجرد ميزة الغرور. إنها إشارة ثقة. عندما يزور عميل العميل الخاص بك portal.acmecorp.com بدلاً من acmecorp.your-saas.io، فإنه يعزز علامة العميل التجارية. يزيل الاحتكاك. وللعديد من الصفقات الكبيرة، فهي حرب صعبة — فريق التوريد لن يوافق على البرنامج الذي يفرض على الموظفين نطاق طرف ثالث.

هناك أيضاً زاوية SEO. إذا كنت تقوم بإنشاء SaaS يتضمن صفحات عامة (فكر في متاجر Shopify وأدوات بناء صفحات الهبوط وقواعد المعرفة أو بوابات العملاء)، يحتاج العملاء إلى نطاقاتهم الخاصة لبناء سلطة المجال. لا يمكنك القيام بذلك على نطاق فرعي لمنصة شخص آخر. حسناً، يمكنك، لكنها دون الأمثل.

الأنماط الثلاثة الأكثر شيوعاً التي أراها:

1. نطاقات منصة فرعية — customer.your-app.com (الأسهل)
2. نطاقات فرعية مخصصة — app.customer.com (التعقيد المتوسط)
3. نطاقات مخصصة القمة — customer.com (الأصعب، لأن سجلات CNAME لا تعمل في القمة)

ينتهي الأمر بمعظم منتجات SaaS الناضجة بدعم جميع الثلاثة.

نظرة عامة على العمارة: ثلاثة طرق

قبل أن نتعمق في تفاصيل التطبيق، دعونا ننظر إلى ثلاثة أساليب معمارية رئيسية وعندما يكون كل منها منطقياً.

الأسلوب	التعقيد	الأفضل لـ	طريقة SSL	متطلبات DNS
نطاق فرعي بطاقة	منخفض	نطاقات فرعية يتحكم فيها النظام الأساسي	شهادة بطاقة واحدة	سجل DNS بطاقة A/AAAA
بروكسي عكسي مع SNI	متوسط	نطاقات مخصصة على نطاق معتدل	شهادة لكل مجال عبر ACME	سجل CNAME أو A للعميل
CDN/Edge مع نطاقات مخصصة	منخفض متوسط	حجم عالي، توزيع عام	يدار من قبل موفر CDN	سجل CNAME أو A للعميل
محمل تحميل مخصص لكل مستأجر	عالي	متطلبات عزل المؤسسة	شهادة لكل مستأجر	تفويض DNS للعميل

بالنسبة لمعظم تطبيقات SaaS، ستبدأ بنطاقات فرعية بطاقة وستضيف في النهاية دعم النطاق المخصص المستند إلى البروكسي العكسي. دعونا نحفر في كل واحد.

النطاقات الفرعية البطاقة لتعدد الإيجار

هذه نقطة البداية. يحصل كل مستأجر على {slug}.yourapp.com. إليك كيفية إعداده بشكل صحيح.

تكوين DNS

تحتاج إلى سجل DNS بطاقة:

*.yourapp.com.  300  IN  A      203.0.113.10
*.yourapp.com.  300  IN  AAAA   2001:db8::1

هذا يعني أن أي نطاق فرعي لـ yourapp.com يتم حله إلى خادمك. يقرأ التطبيق الخاص بك بعد ذلك رأس Host لتحديد المستأجر المراد خدمته.

التوجيه على مستوى التطبيق

في تطبيق Next.js (الذي نقوم ببناء الكثير منه في Social Animal)، ستتعامل مع هذا في البرنامج الوسيط:

// middleware.ts
import { NextRequest, NextResponse } from 'next/server';

export function middleware(request: NextRequest) {
  const hostname = request.headers.get('host') || '';
  const subdomain = hostname.split('.')[0];
  
  // Skip for main domain and known subdomains
  if (['www', 'app', 'api'].includes(subdomain)) {
    return NextResponse.next();
  }
  
  // Rewrite to tenant-specific path
  const url = request.nextUrl.clone();
  url.pathname = `/tenant/${subdomain}${url.pathname}`;
  return NextResponse.rewrite(url);
}

export const config = {
  matcher: ['/((?!_next|api|static).*)'],
};

للمواقع المستندة إلى Astro (إطار عمل آخر نستخدمه بكثرة)، ستتعامل مع هذا في البرنامج الوسيط أو الحافة للخادم.

شهادة SSL بطاقة

تغطي شهادة بطاقة واحدة جميع النطاقات الفرعية:

certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  -d 'yourapp.com' \
  -d '*.yourapp.com'

ملاحظة: شهادات بطاقة Let's Encrypt تتطلب التحقق من تحدي DNS-01. لا يمكنك استخدام HTTP-01 للبطاقات. هذا يعني أنك تحتاج إلى وصول API إلى موفر DNS الخاص بك. يحتوي Certbot على البرامج المساعدة لـ Cloudflare وRoute53 وGoogle Cloud DNS وأكثر موفري الخدمات الرئيسيين.

شهادات Let's Encrypt البطاقة صالحة لمدة 90 يوماً، لذا قم بأتمتة هذا التجديد. جاد. قم بتعيين تنبيه مراقبة إذا فشل التجديد — لا تكن الشخص الذي يأخذ 500 موقع عميل لأن الشهادة انتهت صلاحيتها.

SSL المؤتمت مع Let's Encrypt

عندما يحضر العملاء نطاقاتهم الخاصة، تحتاج إلى شهادات لكل مجال. هنا حيث تصبح الأشياء مثيرة للاهتمام.

بروتوكول ACME

يستخدم Let's Encrypt بروتوكول ACME (بيئة إدارة شهادات مؤتمتة تلقائياً). التحديات اللتان ستعتني بهما:

• HTTP-01: تثبت ملكية المجال بخدمة ملف محدد في http://yourdomain.com/.well-known/acme-challenge/{token}. الأسهل للأتمتة، يعمل مع المجالات الفردية.
• DNS-01: تثبت الملكية بإنشاء سجل TXT محدد. مطلوب للبطاقات، أصعب للأتمتة للنطاقات المخصصة (لا تتحكم في DNS الخاص بهم).

للنطاقات المخصصة، ستستخدم HTTP-01 تقريباً دائماً. يبدو التدفق مثل هذا:

1. يضيف العميل CNAME يشير نطاقه إلى منصتك
2. نظامك يكتشف أن DNS يتم حله بشكل صحيح
3. تبدأ طلب شهادة ACME
4. يرسل Let's Encrypt تحدي HTTP-01
5. يستجيب الخادم الخاص بك برمز التحدي الصحيح
6. تم إصدار الشهادة وتخزينها
7. يبدأ البروكسي العكسي الخاص بك في خدمة HTTPS لهذا المجال

Caddy: الخيار الكسول (الذكي)

بصراحة، إذا لم تكن قد التزمت بـ nginx بالفعل، فقط استخدم Caddy. يتعامل مع HTTPS التلقائي بشكل افتراضي، بما في ذلك TLS عند الطلب للنطاقات غير المعروفة:

{
  on_demand_tls {
    ask http://localhost:5555/check-domain
    interval 2m
    burst 5
  }
}

https:// {
  tls {
    on_demand
  }
  reverse_proxy localhost:3000
}

نقطة الطلب ask حرجة — هنا حيث يتحقق Caddy من تطبيقك ما إذا كان النطاق بالفعل نطاقاً صحيحاً للعميل قبل طلب شهادة. بدون ذلك، يمكن لأي شخص أن يشير نطاقهم إلى عنوان IP الخاص بك وتشغيل طلبات شهادة، مما قد يحرق معدل حدود Let's Encrypt.

// /check-domain endpoint
app.get('/check-domain', async (req, res) => {
  const domain = req.query.domain;
  const isValid = await db.customDomains.findOne({ 
    domain, 
    verified: true,
    active: true 
  });
  
  if (isValid) {
    res.status(200).send('OK');
  } else {
    res.status(404).send('Not found');
  }
});

نهج Nginx + Certbot

إذا كنت تقوم بالفعل بتشغيل nginx، يمكنك استخدام certbot مع مكون webroot:

certbot certonly --webroot -w /var/www/certbot \
  -d customer-domain.com \
  --non-interactive --agree-tos \
  --email ssl@yourapp.com

ستحتاج إلى تحديث تكوينات nginx بشكل ديناميكي وإعادة تحميل:

server {
    listen 443 ssl;
    server_name customer-domain.com;
    
    ssl_certificate /etc/letsencrypt/live/customer-domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/customer-domain.com/privkey.pem;
    
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

هذا يعمل لكنه مؤلم للإدارة في الحجم. كل نطاق جديد يعني إنشاء تكوين وطلب شهادة وإعادة تحميل nginx. ستريد بناء الأتمتة حول هذا، وبصراحة فإن TLS عند الطلب في Caddy أسهل فقط.

حدود Let's Encrypt (2025)

هذه تهم وتحتاج إلى التخطيط حولها:

الحد	القيمة	ملاحظات
الشهادات في كل نطاق مسجل	50/أسبوع	لكل نطاقك الأساسي
شهادة مكررة	5/أسبوع	مجموعة أسماء المضيف نفسها بالضبط
التحققات الفاشلة	5/ساعة لكل حساب لكل اسم مضيف	يمكن أن تحجبك بسرعة
طلبات جديدة	300/3 ساعات	على مستوى الحساب
الترخيص المعلق	300/حساب	تنظيف القديمة

في 50 شهادة في الأسبوع، إذا كنت تقوم بتسجيل أكثر من ~7 نطاقات مخصصة يومياً، تحتاج إلى التفكير في هذا. خيارات:

• استخدم CA ACME مختلف (ZeroSSL, BuyPass) كخيار بديل
• تطلب زيادة حد معدل Let's Encrypt (يمنحونها لحالات استخدام SaaS المشروعة)
• التحقق المسبق من DNS قبل محاولة إصدار الشهادة
• تطبيق منطق إعادة المحاولة مع التراجع الأسي

النطاقات المخصصة: التدفق الكامل

إليك رحلة المستخدم الكاملة التي أوصي بها، بعد بناء هذا التدفق عدة مرات.

الخطوة 1: يدخل العميل النطاق في لوحة التحكم

قدم تعليمات واضحة. أريهم بالضبط ما سجل DNS لإنشاء:

النوع: CNAME
المضيف: بوابة (أو أي نطاق فرعي يريدونه)
القيمة: custom.yourapp.com
TTL: 300

للنطاقات القمة (مجرد customer.com)، يحتاجون إلى سجل A يشير إلى عنوان IP الخاص بك، أو يحتاجون إلى موفر DNS يدعم تسطيح CNAME (Cloudflare وسجلات ALIAS Route53 وما إلى ذلك).

الخطوة 2: التحقق من DNS

لا تتحقق مرة واحدة فقط. يمكن أن ينتشر DNS في غضون دقائق إلى ساعات. تنفيذ آلية الاستطلاع:

async function verifyDomain(domain: string, expectedTarget: string): Promise<boolean> {
  try {
    const records = await dns.promises.resolveCname(domain);
    return records.some(r => r === expectedTarget);
  } catch (err) {
    // For A records (apex domains)
    try {
      const aRecords = await dns.promises.resolve4(domain);
      return aRecords.some(r => EXPECTED_IPS.includes(r));
    } catch {
      return false;
    }
  }
}

// Poll every 30 seconds for up to 24 hours
async function waitForDNS(domain: string) {
  const maxAttempts = 2880; // 24 hours at 30s intervals
  for (let i = 0; i < maxAttempts; i++) {
    if (await verifyDomain(domain, 'custom.yourapp.com')) {
      return true;
    }
    await sleep(30000);
  }
  return false;
}

الخطوة 3: توفير الشهادات

بمجرد التحقق من DNS، اطلب الشهادة. مع Caddy، يحدث هذا تلقائياً عند الطلب الأول. مع nginx/certbot، قم بتشغيله برمجياً.

الخطوة 4: المراقبة المستمرة

يمكن كسر النطاقات. يغير العملاء سجلات DNS عن طريق الخطأ. تنتهي صلاحية الشهادات إذا فشل التجديد. تحتاج إلى مراقبة:

• DNS resolution لا يزال يشير إليك (تحقق يومياً)
• تواريخ انتهاء صلاحية الشهادات (التنبيه في 14 يوماً، حرجة في 7)
• نجاح SSL handshake (المراقبة الاصطناعية)
• رموز HTTP response في نطاقات العميل

أنماط البنية الأساسية حسب المنصة

يختلف الأسلوب بشكل كبير اعتماداً على المكان الذي تستضيف فيه.

Vercel

لدى Vercel دعم نطاق مخصص مدمج. بالنسبة لتطبيق Next.js متعدد المستأجرين، ستستخدم Domains API الخاص بهم:

curl -X POST "https://api.vercel.com/v10/projects/{projectId}/domains" \
  -H "Authorization: Bearer $VERCEL_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "portal.customer.com"}'

يتعامل Vercel مع SSL تلقائياً. القيد الرئيسي: أنت تخضع لأسعارهم. في خطة Pro ($20/عضو فريق/شهر)، تحصل على 50 نطاق لكل مشروع. Enterprise يعطيك أكثر. إذا كان لديك آلاف العملاء بنطاقات مخصصة، تتراكم التكاليف.

Cloudflare for SaaS (SSL for SaaS)

هذا ربما هو الخيار الأفضل للنطاق في 2025. منتج SSL لـ SaaS من Cloudflare (يُطلق عليه سابقاً اسم Custom Hostnames) يتعامل مع كل شيء:

• إصدار شهادة مؤتمت وتجديد
• CDN عام والحماية من DDoS
• التحقق من النطاق المدمج
• الإدارة البرمجية API

curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/custom_hostnames" \
  -H "Authorization: Bearer $CF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "hostname": "portal.customer.com",
    "ssl": {
      "method": "http",
      "type": "dv"
    }
  }'

التسعير: 0.10 دولار/نطاق مخصص/شهر بعد أول 100 (وهي مجانية في خطة Enterprise). بالنسبة لـ SaaS بـ 1000 نطاق مخصص، هذا حوالي 90 دولار/شهر. معقول جداً.

AWS (ALB + ACM + Route53)

إذا كنت على AWS، يمكنك استخدام:

• ALB للتوجيه مع اختيار الشهادة المستند إلى SNI
• ACM (AWS Certificate Manager) للشهادات المجانية
• Route53 للتحقق من DNS

العثرة: شهادات ACM قابلة للاستخدام فقط مع خدمات AWS (ALB وCloudFront و API Gateway). و ALB لها حد أقصى 25 شهادة لكل موازن تحميل بشكل افتراضي (يمكن زيادتها إلى 100). بالنسبة للنطاق الجدي، ستضع CloudFront في المقدمة مع حدها البالغ 100 شهادة لكل توزيع.

هذا يصبح مكلفاً ومعقداً. أود بصراحة أن أوصي به Cloudflare for SaaS على هذا النهج ما لم يكن لديك متطلبات AWS محددة.

Fly.io

لدى Fly.io أمر fly certs add رائع و API لإضافة نطاقات مخصصة:

fly certs add portal.customer.com

يتعامل مع Let's Encrypt تلقائياً. يعمل بشكل جيد لـ scale صغير إلى متوسط.

تكوين DNS والتحقق

قطعة DNS تعثر على فريق أكثر من أي جزء آخر من هذه الميزة. إليك ما تحتاج إلى معرفته.

مشكلة CNAME في القمة

سيريد العملاء حتماً استخدام النطاق العاري (customer.com، بدون نطاق فرعي). لا تسمح مواصفات DNS بسجلات CNAME في قمة المنطقة لأن سجلات CNAME يجب أن تكون حصرية — لا يمكنها التعايش مع أنواع سجلات أخرى، والقمة دائماً لديها سجلات SOA و NS.

الحلول:

1. تسطيح CNAME (Cloudflare) — يحل CNAME على مستوى DNS، ويعيد سجل A
2. سجلات ALIAS (Route53، DNSimple) — نوع سجل مملوك يعمل مثل CNAME في القمة
3. سجلات ANAME (بعض الموفرين) — مشابهة لـ ALIAS
4. سجل A — فقط أعطِ العملاء عنوان IP الخاص بك

الخيار 4 (سجلات A) هو الأكثر عالمية لكن الأقل مرونة. إذا غيرت عنوان IP خادمك، يحتاج كل عميل يستخدم سجل A إلى تحديث DNS الخاص به. مع CNAME، أنت فقط تحدث ما CNAME target يحل إليه.

توصيتي: دعم كلاهما. أخبر العملاء باستخدام CNAME للنطاقات الفرعية وسجل A (أو ALIAS/ANAME إذا دعمه موفرهم) للنطاقات القمة.

التحقق من الملكية

بالإضافة إلى التأكيد من أن النطاق يتم حله إلى البنية الأساسية الخاصة بك، قد تريد التحقق من أن الشخص الذي يقوم بتكوين النطاق في SaaS الخاص بك يتحكم به فعلاً. الأسلوب الشائع هو مطلوب سجل TXT:

_verification.customer.com  TXT  "yourapp-verify=abc123unique"

هذا يمنع شخصاً ما من أن يشير إلى نطاق لا يملكه عند منصتك والدعاء بأنه ملكهم.

تصلب الإنتاج والمراقبة

هذا القسم هو الفرق بين demo ونظام إنتاجي.

تخزين الشهادات

لا تخزن الشهادات على القرص إذا كنت تقوم بتشغيل عدة حالات. استخدم مخزن موزع:

• Caddy: يدعم أسطح ظهر التخزين لـ Redis وConsul وS3 وPostgreSQL
• المخصص: تخزين الشهادات في قاعدة بيانات مشفرة أو مدير الأسرار (AWS Secrets Manager، HashiCorp Vault)

الانسحاب بشكل أنيق

ماذا يحدث عندما يكون النطاق المخصص للعميل معطلاً؟ لا تظهر خطأ SSL. بدلاً من ذلك:

1. اكتشف فشل SSL handshake
2. إعادة التوجيه إلى صفحة الحالة التي تشرح المشكلة
3. إرسال إخطار إلى العميل
4. حاول إعادة توفير الشهادات تلقائياً

فحوصات الصحة

قم ببناء مهمة خلفية تتحقق بانتظام من كل نطاق مخصص:

async function healthCheckDomains() {
  const domains = await db.customDomains.find({ active: true });
  
  for (const domain of domains) {
    const checks = {
      dnsResolves: await checkDNS(domain.hostname),
      sslValid: await checkSSL(domain.hostname),
      httpOk: await checkHTTP(domain.hostname),
    };
    
    if (!checks.dnsResolves) {
      await alertCustomer(domain, 'DNS no longer points to our platform');
      await markDomain(domain, 'dns_error');
    } else if (!checks.sslValid) {
      await triggerCertRenewal(domain);
    }
    
    await db.domainHealthChecks.insert({
      domainId: domain.id,
      ...checks,
      checkedAt: new Date(),
    });
  }
}

شغل هذا كل ساعة. عند 10000 نطاق، تكتمل الفحوصات في بضع دقائق إذا قمت بالمتوازي بشكل صحيح.

تحليل التكاليف في الحجم

دعونا نتحدث عن الأرقام الحقيقية لتسعير 2025.

الحل	100 نطاق	1000 نطاق	10000 نطاق	ملاحظات
Caddy + Let's Encrypt (مُدار ذاتياً)	~$50/شهر خادم	~$200/شهر خوادم	~$1,000/شهر خوادم	عبء العمليات الخاص بك
Cloudflare for SaaS	مجاني (Enterprise)	~$90/شهر	~$990/شهر	أفضل قيمة في الحجم
Vercel (Pro)	مشمول	$0 إضافي	حاجة Enterprise	محدود بـ 50/مشروع على Pro
AWS CloudFront + ACM	~$100/شهر	~$300/شهر	~$2,000/شهر	تتضمن تكاليف نقل CDN
Fastly	~$150/شهر	~$500/شهر	تسعير مخصص	جيد إذا كنت بالفعل تستخدم Fastly

بالنسبة لمعظم منتجات SaaS، Cloudflare for SaaS يضرب النقطة الحلوة. تحصل على CDN عام وحماية DDoS والشهادات المؤتمتة لحوالي عشرة سنتات لكل نطاق شهرياً. يصعب ضربها.

إذا كنت تقوم ببناء على معمارية CMS بدون رأس — شيء نقوم به كثيراً — Cloudflare for SaaS يقترن بشكل خاص جيد لأنك تتعامل بالفعل مع الواجهات الأمامية المفصولة التي تستفيد من تخزين الحافة المؤقتة.

الأسئلة الشائعة

كم من الوقت يستغرق النطاق المخصص ليصبح نشطاً بعد تكوين DNS؟ عادة ما يستغرق انتشار DNS 5-30 دقيقة، على الرغم من أنه يمكن أن يستغرق ما يصل إلى 48 ساعة في الحالات النادرة. توفير الشهادات مع Let's Encrypt يضيف 30-60 ثانية أخرى بمجرد أن يتم حل DNS بشكل صحيح. عملياً، معظم النطاقات المخصصة نشطة بالكامل في غضون 15 دقيقة. أوصي باستطلاع DNS كل 30 ثانية وتشغيل توفير الشهادات على الفور عند نجاح الدقة.

هل يمكنني استخدام Let's Encrypt لآلاف النطاقات المخصصة على SaaS الخاص بي؟ نعم، لكنك تحتاج إلى التخطيط حول حدود المعدل. القيد الرئيسي هو 50 شهادة لكل نطاق مسجل في الأسبوع (لنطاقات النظام الأساسي الخاص بك) و 300 طلب جديد لكل 3 ساعات. بالنسبة للنطاقات المخصصة للعميل، فإن كل نطاق هو نطاق مسجل منفصل، لذا لا ينطبق حد كل نطاق بنفس الطريقة. يمكنك أيضاً التقديم إلى Let's Encrypt لزيادة حد المعدل إذا كان بإمكانك إثبات الحاجة المشروعة. ZeroSSL هو موفر ACME بديل قوي.

ما الفرق بين النطاقات الفرعية البطاقة والنطاقات المخصصة؟ النطاقات الفرعية البطاقة (*.yourapp.com) يتم التحكم فيها بالكامل من قبلك — سجل DNS واحد، شهادة SSL واحدة، توجيه بسيط. النطاقات المخصصة (portal.customer.com) هي نطاقات يتحكم فيها عملاؤك، مما يتطلب منهم تكوين DNS وأنت لتوفير شهادات فردية. تبدأ معظم منتجات SaaS بنطاقات فرعية بطاقة وتضيف دعم النطاق المخصص لاحقاً كميزة مميزة.

كيف أتعامل مع النطاقات المخصصة القمة (عارية)؟ النطاقات القمة (customer.com بدون www) لا يمكنها استخدام سجلات CNAME وفقاً لمواصفات DNS. خياراتك هي: اطلب من العملاء إنشاء سجلات A تشير إلى عنوان IP الخاص بك، أو استخدم موفري DNS الذين يدعمون سجلات ALIAS/ANAME، أو وصايا موفري الخدمات بتسطيح CNAME مثل Cloudflare. دعم دائماً كل من تكوينات القمة والنطاق الفرعي — سيريد العملاء كليهما.

هل يجب أن أستخدم Caddy أو nginx لـ SSL المؤتمت؟ إذا كنت تبدأ من جديد، استخدم Caddy. ميزة TLS عند الطلب الخاصة بها تم بناؤها حرفياً لحالة استخدام النطاق المخصص متعدد المستأجرين. Nginx على ما يرام إذا كان لديك بالفعل في المكدس الخاص بك، لكنك ستحتاج إلى بناء المزيد من الأتمتة حول certbot لإدارة دورة حياة الشهادات. Caddy يتعامل مع الإصدار والتجديد والتخزين و OCSP stapling تلقائياً.

كيف أمنع إساءة استخدام ميزة النطاق المخصص الخاصة بي؟ ثلاث طبقات: أولاً، تحقق من ملكية النطاق بسجل TXT قبل قبول نطاق مخصص. ثانياً، قم بتنفيذ نقطة "ask" (مثل ask on_demand_tls من Caddy) التي تتحقق من النطاقات قبل طلب الشهادات. ثالثاً، اعدل إضافة النطاق لكل حساب. بدون هذا، يمكن لشخص ما أن يشير إلى آلاف النطاقات عند عنوان IP الخاص بك وحرق معدل حدود الشهادات أو استخدام البنية الأساسية الخاصة بك لـ domain fronting.

ماذا يحدث إذا أزال العميل سجل DNS الخاص به؟ يجب أن تكتشف المنصة الخاصة بك هذا في غضون ساعات من خلال فحوصات الصحة العادية. عندما يتوقف DNS عن الحل إلى البنية الأساسية الخاصة بك، ضع علامة على النطاق كغير صحي، أخبر العميل، واتوقف عن محاولة تجديد الشهادات. لا حذف تكوين النطاق على الفور — يكسر العملاء أحياناً DNS مؤقتاً أثناء الترحيل. أوصي بفترة سماح مدتها 30 يوماً قبل إلغاء تفعيل النطاق المخصص بالكامل.

هل Cloudflare for SaaS يستحق كل هذا مقابل إدارة الشهادات الذاتية؟ بالنسبة لمعظم منتجات SaaS، نعم. بسعر 0.10 دولار/اسم مضيف/شهر، فإن التكلفة تافهة مقابل وقت الهندسة الذي ستقضيه في بناء وصيانة أتمتة الشهادات والتعامل مع حالات الحافة والمراقبة التجديدات والتعامل مع حدود المعدل. تحصل أيضاً على CDN عام وحماية DDoS مضمنة. السبب الرئيسي للإدارة الذاتية هو إذا كنت تحتاج إلى التحكم الكامل في البنية الأساسية الخاصة بك أو كان لديك متطلبات الامتثال المحددة التي تمنع استخدام بروكسي طرف ثالث. إذا كنت تريد مناقشة النهج الصحيح لمنتجك المحدد، تواصل معنا — لقد نفذنا كل من الأنماط.

النطاقات المخصصة هي واحدة من تلك ميزات SaaS حيث يكون الشيطان حقاً في التفاصيل. المسار السعيد مباشر، لكن الجاهزية الإنتاجية تعني التعامل مع تأخيرات انتشار DNS وفشل الشهادات وسوء التكوين من قبل العميل والمراقبة على الحجم. ابدأ بنطاقات فرعية بطاقة، أضف دعم النطاق المخصص عندما يطلب العملاء ذلك (وسوف يفعلون)، ولا تحاول بناء كل شيء من الصفر عندما توجد أدوات مثل Caddy و Cloudflare for SaaS. سيشكرك نفسك المستقبلي on-call.