📘 תיעוד 68

עדיפות אישור ושם מארח

עודכן לאחרונה ב-16 באפריל 2026

כשנוצר אישור חדש, Cloudflare קודם פורסת את האישור ואחר כך מגישה אותו.

#פריסת אישור

עבור כל שם מארח נתון, Cloudflare משתמשת בסדר הבא כדי לקבוע איזה אישור (והגדרות TLS המשויכות) יוחלו על שם המארח הזה:

1. ספציפיות של שם המארח: אישור לתת דומיין ספציפי (www.example.com) מקבל עדיפות על פני אישור תו כללי (*.example.com) עבור בקשות אל www.example.com.
2. ספציפיות של אזור: אישור לתת דומיין ספציפי (www.example.com) מקבל עדיפות על פני אישור שם מארח מותאם אישית אם הדומיין פעיל כאזור ב-Cloudflare.
3. עדיפות אישור: אם שם המארח זהה, סוגים מסוימים של אישורים מקבלים עדיפות על פני אחרים.

4. תפוגת אישור: האישור שהוזמן לאחרונה מקבל עדיפות, אלא אם התרחשה מחיקת אישור. אם ומתי אישור נמחק, האישור עם תאריך התפוגה המאוחר ביותר נפרס.

הערה

במקרה זה, כשהאישור עם תאריך התפוגה הקרוב ביותר מתחדש, הוא יהפוך אז לאישור עם תאריך התפוגה המאוחר ביותר ויוצג.

#הצגת אישור

Cloudflare משתמשת בסדר הבא כדי לקבוע את האישור וההגדרות שבשימוש במהלך לחיצת יד TLS:

1. התאמת SNI: אישורים והגדרות שתואמים את שם המארח ב-SNI בדיוק מקבלים עדיפות.
2. התאמת תו כללי ב-SNI: אם אין התאמה מדויקת בין שם המארח לשם המארח ב-SNI, Cloudflare משתמשת באישורים ובהגדרות שתואמים תו כללי ב-SNI.
3. כתובת IP: אם לא מוצג SNI, Cloudflare משתמשת באישור על בסיס כתובת ה-IP (שם המארח יכול לתמוך בלחיצות יד TLS שנעשות בלי SNI).

#עדיפות שם מארח

כשיש כמה רשומות DNS במצב proxy עבור שם מארח, בכמה אזורים, בדרך כלל בגלל Cloudflare for SaaS, רק רשומה אחת תשלוט בהגדרות האזור ובשרת המקור המשויך.

Cloudflare קובעת את העדיפות בסדר הבא, בהנחה שכל רשומה קיימת ונמצאת במצב proxy (עננן כתום):

1. התאמה מדויקת של שם מארח:
   1. שם מארח מותאם אישית חדש (שייך לספק SaaS)
   2. שם מארח מותאם אישית מדור קודם (שייך לספק SaaS)
   3. DNS (שייך לאזור ה-DNS הלוגי)
2. התאמת שם מארח עם תו כללי:
   1. DNS (שייך לאזור ה-DNS הלוגי)
   2. שם מארח מותאם אישית חדש (שייך לספק SaaS)

אם רשומת משאב של שם מארח אינה במצב proxy (עננן אפור) עבור אזור ב-Cloudflare, הגדרות האזור הזה לא מוחלות, ובמקום זאת מוחלות הגדרות שהוגדרו במקור המשויך. מקור זה יכול להיות אזור אחר ב-Cloudflare או כל שרת אחר.

#תרחישי דוגמה

#תרחיש 1

Customer1 משתמש ב-Cloudflare כ-DNS סמכותי עבור האזור shop.example.com. Customer2 הוא ספק SaaS שיוצר ומאמת בהצלחה את שם המארח המותאם אישית החדש shop.example.com. לאחר מכן, התעבורה מתחילה להיות מנותבת דרך האזור של Customer2:

• אם Customer1 רוצה להחזיר לעצמו שליטה באזור, Customer1 פונה אל Customer2 ומבקש ממנו למחוק את רשומת שם המארח המותאם אישית. Customer1 צריך לוודא שיעד הרשומה שלו עודכן למשהו שאינו היעד של ספק ה-SaaS, אחרת Customer1 יקבל שגיאת 1014.
• אם ל-Customer1 כבר יש רשומה במצב proxy עבור www.example.com כש-Customer2 יוצר ומאמת שם מארח מותאם אישית חדש www.example.com, חל O2O.
• אם ל-Customer1 כבר יש רשומה במצב proxy עבור www.example.com בהגדרת שם מארח מותאם אישית מדור קודם (עם ספק SaaS אחר, Customer3) ו-Customer2 יוצר ומאמת שם מארח מותאם אישית עם תו כללי עבור *.example.com, שם המארח המותאם אישית מדור הקודם בפלטפורמה של Customer3 מקבל עדיפות בגלל התאמה מדויקת של שם המארח.

#תרחיש 2

ללקוח יש רשומת DNS במצב proxy עבור הדומיין שלו. האזור של הלקוח ב-Cloudflare משתמש בתוכנית Free.

הלקוח הזה משתמש גם בספק SaaS שמשתמש ב-Cloudflare for SaaS. ספק ה-SaaS משתמש בתוכנית Cloudflare Enterprise.

אם הספק משתמש בשם מארח מותאם אישית עם תו כללי, מגבלות התוכנית של הלקוח המקורי מקבלות עדיפות על פני מגבלות התוכנית של הספק (Cloudflare תתייחס לאזור כאזור Free). כדי להחיל את מגבלות Enterprise דרך Cloudflare for SaaS, האזור של הלקוח המקורי יצטרך להשתמש ברשומת DNS-only, או שספק ה-SaaS יצטרך להשתמש בהתאמה מדויקת של שם מארח.