תשתיות
מה זה Cloudflare: מדריך מעשי לחיבור, SSL ומטמון
המדריך מיועד לבעלי אתרים ולמנהלי שיווק ששמעו על Cloudflare ורוצים להבין אם הוא מתאים להם ואיך מגדירים אותו נכון. תמצאו כאן הסבר על הרכיבים שלו, מה כולל המסלול החינמי, איך מחברים דומיין, איזה מצב SSL לבחור ואילו טעויות הגדרה כדאי לחסוך.
Cloudflare היא רשת שיושבת בין המבקרים לבין השרת של האתר ומספקת DNS, רשת CDN, הגנה מפני מתקפות DDoS, תעודת SSL וחומת אש לאפליקציות. מחברים אליה אתר על ידי החלפת שרתי השמות של הדומיין אצל הרשם. נכון לאוקטובר 2026 המסלול החינמי כולל את הרכיבים הבסיסיים האלה, ומצב ההצפנה המומלץ לאתר עסקי הוא Full (strict) עם תעודה תקפה בשרת.
תוכן עניינים 8 חלקים
מה זה Cloudflare ומה הוא עושה לאתר?
Cloudflare היא רשת גלובלית שיושבת בין המבקרים באתר לבין השרת שמריץ אותו. כשאתר מחובר ל-Cloudflare במצב פרוקסי, הבקשות של הגולשים מגיעות קודם לשרתים של Cloudflare, ומשם ממשיכות לשרת שלכם כשצריך. מי ששואל מה זה cloudflare מקבל בדרך כלל רשימה ארוכה של שירותים, אבל לאתר עסקי רגיל חשובים בעיקר שישה רכיבים: DNS, רשת CDN, פרוקסי הפוך, הגנה מפני מתקפות DDoS, תעודת SSL וחומת אש לאפליקציות (WAF).
חשוב להבין גם מה Cloudflare לא עושה. הוא לא מחליף אחסון אתרים, כי הקבצים, מסד הנתונים והקוד עדיין יושבים על השרת שלכם. הוא גם לא מחליף את הרשם, כי הדומיין נשאר רשום במקום שבו נרשם. Cloudflare מוסיף שכבה מעל שניהם, ולכן כדאי לחשוב עליו כעל שער הכניסה לאתר ולא כעל הבית עצמו.
| רכיב | מה הוא עושה | למה זה חשוב לעסק |
|---|---|---|
| DNS | מתרגם את הדומיין לכתובות השרתים של האתר והמייל | ניהול כל הרשומות במקום אחד, בממשק ברור |
| CDN | שומר עותקים של קבצים סטטיים בשרתים קרובים למבקר | פחות עומס על השרת והגשה קרובה יותר של תמונות וקבצים |
| פרוקסי הפוך | מקבל את הבקשות במקום השרת ומעביר אותן הלאה | כתובת ה-IP של השרת לא נחשפת ברשומות שעוברות דרכו |
| הגנת DDoS | מסנן הצפות תעבורה לפני שהן מגיעות לשרת | מקטין את הסיכוי שהצפה מכוונת תפיל את האתר |
| SSL | מצפין את החיבור בין המבקר לבין Cloudflare | חיבור מאובטח בכתובת HTTPS |
| WAF | בודק בקשות מול חוקים שמזהים דפוסי תקיפה מוכרים | חוסם חלק מהניסיונות לפני שהם מגיעים לאתר |
ההבדל בין רשומה שעוברת דרך הפרוקסי לבין רשומה שלא עוברת דרכו חשוב לכל מה שבא אחר כך. לפי התיעוד של Cloudflare, רשומה במצב Proxied, הענן הכתום בממשק, מחזירה כתובות של Cloudflare ומסתירה את כתובת השרת, ורק רשומות מסוג A, AAAA ו-CNAME יכולות לעבור דרך הפרוקסי. רשומה במצב DNS only חושפת את כתובת השרת האמיתית, ורשומות כמו MX של המייל נמצאות תמיד במצב הזה.
מה כולל המסלול החינמי של Cloudflare?
המסלול החינמי הוא נקודת הכניסה הטבעית לאתר עסקי קטן או בינוני. נכון לאוקטובר 2026, לפי עמוד המסלולים של Cloudflare, הוא כולל DNS, הגנה מפני מתקפות DDoS ללא הגבלת נפח, רשת הפצת תוכן ותעודת Universal SSL. בנוסף יש בו חומת אש עם סט חוקים מנוהל בגרסה החינמית, הגנה מפני בוטים פשוטים ומכסה מוגבלת של חוקים להפניות, למטמון ולשינוי כותרות. התמיכה במסלול הזה ניתנת דרך פורום הקהילה והתיעוד, בלי התחייבות חוזית לזמינות.
תעודת ה-Universal SSL מונפקת אוטומטית אחרי שהדומיין הופך לפעיל ב-Cloudflare. לפי התיעוד, בהגדרה מלאה היא מכסה את הדומיין הראשי ותת-דומיינים ברמה אחת, כמו www, והיא זמינה בכל המסלולים כולל החינמי. מה שהמסלול החינמי לא כולל, לפי אותו עמוד, הוא בין השאר אופטימיזציית תמונות ללא אובדן איכות והתחייבות לזמינות עם זיכוי. לאתר תדמית טיפוסי הרכיבים האלה מכסים את הבסיס, ואת המסלולים בתשלום כדאי לבחון רק מול צורך מוגדר.
איך מחברים אתר ל-Cloudflare?
החיבור הסטנדרטי נקרא הגדרה מלאה, ולפי התיעוד של Cloudflare זו האפשרות היחידה במסלולים Free ו-Pro. בהגדרה הזו Cloudflare הופך לספק ה-DNS של הדומיין, ולכן מחליפים את שרתי השמות אצל הרשם. בדומיין ישראלי זה נעשה דרך הרשם שבו הדומיין רשום, וכללי איגוד האינטרנט הישראלי מבטיחים למחזיק את הזכות להפנות את הדומיין לכל ספק DNS שיבחר. אם עוד לא רשמתם כתובת, כדאי לקרוא קודם את המדריך שלנו על קניית דומיין.
- הוספת הדומיין: פותחים חשבון, מוסיפים את הדומיין הראשי ובוחרים מסלול
- בדיקת הרשומות: Cloudflare סורק את רשומות ה-DNS הקיימות, אבל הסריקה עלולה לפספס חלק מהן, ולכן בודקים במיוחד את הדומיין הראשי, התת-דומיינים והמייל
- כיבוי DNSSEC: אם הוא פעיל אצל הרשם, מכבים אותו לפני החלפת שרתי השמות, כי לפי התיעוד החלפה בזמן ש-DNSSEC פעיל עלולה להפוך את הדומיין ללא זמין
- החלפת שרתי השמות: מזינים אצל הרשם את שני שרתי השמות ש-Cloudflare הקצה, בדיוק כפי שהם מופיעים
- המתנה להפעלה: לפי התיעוד, עדכון שרתי השמות אצל הרשם עשוי לקחת עד 24 שעות, ובסופו הדומיין מסומן כפעיל
- הפעלה מחדש של DNSSEC: אחרי שהדומיין פעיל, מפעילים אותו מחדש דרך Cloudflare
את ההחלפה עדיף לבצע בשעה שקטה, אחרי שבדקתם שכל רשומות המייל, האימות והתת-דומיינים הועתקו. רשומה אחת שנשכחה יכולה לעצור את קבלת המייל של העסק. כדאי לשמור ייצוא של אזור ה-DNS הישן כנקודת השוואה אם משהו לא עובד אחרי המעבר.
Flexible, Full או Full (strict): איזה מצב SSL לבחור?
מצב ההצפנה קובע איך Cloudflare מתחבר לשרת שלכם, וזו ההגדרה שהכי קל לטעות בה. החיבור בין המבקר לבין Cloudflare יכול להיות מוצפן בכל המצבים חוץ מ-Off, אבל החיבור בין Cloudflare לבין השרת תלוי במצב שבחרתם ובתעודה שמותקנת על השרת. לפי התיעוד של Cloudflare, נכון לאוקטובר 2026 אלה המצבים הקיימים:
| מצב | HTTPS למבקר | החיבור מ-Cloudflare לשרת | בדיקת התעודה בשרת |
|---|---|---|---|
| Off | לא | ללא הצפנה | לא רלוונטי |
| Flexible | כן | HTTP בלבד, ללא הצפנה | אין, כי החיבור לא מוצפן |
| Full | כן | לפי הפרוטוקול של המבקר | אין בדיקה: גם תעודה שפג תוקפה או חתומה עצמית מתקבלת |
| Full (strict) | כן | לפי הפרוטוקול של המבקר | תעודה בתוקף, מרשות מוכרת או מ-Cloudflare Origin CA, שתואמת לשם הדומיין |
| Strict (SSL-Only Origin Pull) | כן | תמיד HTTPS | בדיקה מלאה, כמו ב-Full (strict) |
ההמלצה של Cloudflare עצמה היא להשתמש ב-Full או ב-Full (strict) בכל מקום שאפשר, ו-Full (strict) הוא הבחירה הנכונה לאתר עסקי. ב-Full רגיל החיבור לשרת מוצפן, אבל לפי התיעוד, בלי בדיקת התעודה גורם זדוני יכול באופן תיאורטי להשתלט על החיבור ולהציג תעודה משלו. ב-Full (strict) התעודה בשרת חייבת להיות בתוקף ולהתאים לשם הדומיין, ולכן ההצפנה מגינה באמת לכל אורך הדרך.
יש שתי דרכים פשוטות לעמוד בדרישה. הראשונה היא תעודת ssl רגילה מרשות מוכרת, שמותקנת בשרת ומתחדשת אוטומטית אם חברת האחסון מציעה זאת. השנייה היא תעודת Origin CA של Cloudflare, שמצפינה רק את הקטע שבין Cloudflare לשרת. לפי התיעוד, אם משהים את Cloudflare או מעבירים רשומה למצב DNS only, המבקרים יראו שגיאת תעודה לא מהימנה, ו-Cloudflare לא שולח התראה כשתוקף התעודה הזו מתקרב לסיום, ולכן כדאי לרשום ביומן את תאריך התפוגה.
בחלק מהחשבונות מופיעה גם אפשרות בשם Automatic SSL/TLS, שמוצגת בתיעוד כברירת המחדל ובוחרת את המצב המאובטח ביותר שהשרת תומך בו. היא לא מתקינה תעודה בשרת, ולכן אם אין בו תעודה תקפה היא לא תגיע ל-Full (strict). כדאי לבדוק בעצמכם איזה מצב נבחר בפועל.
איך עובד המטמון של Cloudflare ומה אסור לשמור בו?
רשת ה-CDN של Cloudflare שומרת עותקים של קבצים בשרתים שלה, וכך בקשות חוזרות לא מגיעות כל פעם לשרת שלכם. נכון לאוקטובר 2026, לפי התיעוד של Cloudflare, ברירת המחדל היא לשמור קבצים לפי סיומת: תמונות, קבצי CSS ו-JavaScript, גופנים, מסמכים כמו PDF וקבצי מדיה. HTML ו-JSON לא נשמרים במטמון כברירת מחדל. גם תשובות שהשרת מסמן ב-Cache-Control כפרטיות או כאסורות לשמירה, ותשובות שמגיעות עם Set-Cookie, לא נשמרות.
כדי לשמור גם את עמודי ה-HTML במטמון צריך ליצור Cache Rule, וכאן נמצאת אחת הטעויות המסוכנות. חוק ששומר הכול בלי החרגות עלול לשמור עמוד שנוצר עבור משתמש מחובר ולהגיש אותו למבקרים אחרים, כולל עגלת קניות, אזור אישי או סרגל הניהול של וורדפרס. לכן כל חוק כזה צריך להחריג את אזור הניהול, את עמודי העגלה, התשלום והחשבון, ובקשות שמגיעות עם עוגיות של משתמש מחובר. בחנויות זה קריטי במיוחד, וזה אחד הדברים שכדאי לתכנן כבר כשבודקים איך לפתוח חנות אינטרנטית.
המטמון הוא רק חלק אחד מהמהירות. אתר עם תמונות כבדות או קוד עודף יישאר איטי גם מאחורי Cloudflare, כי חלק גדול מהעבודה קורה בשרת ובדפדפן, ואת העבודה הזו פירטנו בעמוד מהירות אתר. אחרי כל עדכון עיצוב או קוד, נקו את המטמון ב-Cloudflare כדי שהמבקרים יקבלו את הגרסה החדשה.
איך מוסיפים כותרות אבטחה דרך Cloudflare?
כותרות אבטחה הן הוראות שהשרת שולח לדפדפן יחד עם כל עמוד, והן מגבילות מה הדפדפן מרשה לעמוד לעשות. אפשר להגדיר אותן בשרת או בתוסף, אבל ב-Cloudflare הן חלות על כל התשובות שעוברות דרך הפרוקסי, כולל קבצים מהמטמון, ולא תלויות בתבנית או בתוסף שעלולים להשתנות. לפי התיעוד, Response Header Transform Rules מאפשרים להוסיף כותרת, לשנות את הערך שלה או להסיר אותה. אלה הכותרות שכדאי להכיר:
- X-Content-Type-Options: מונעת מהדפדפן לנחש סוג קובץ שונה מזה שהשרת הצהיר עליו
- Referrer-Policy: קובעת כמה מידע על העמוד הנוכחי נשלח לאתר אחר בלחיצה על קישור
- X-Frame-Options או frame-ancestors ב-CSP: מגבילות הצגה של האתר בתוך מסגרת באתר זר
- Permissions-Policy: מגבילה גישה של העמוד ליכולות כמו מצלמה, מיקרופון ומיקום
- Strict-Transport-Security (HSTS): מורה לדפדפן להתחבר לאתר רק ב-HTTPS
ל-Cloudflare יש גם Managed Transform מוכן בשם Add security headers, אבל כדאי לבדוק מה הוא מוסיף לפני שמפעילים אותו. לפי התיעוד הוא מוסיף סט קבוע של כותרות, וחלקן כבר נחשבות מיושנות בדפדפנים עדכניים. חוק מותאם נותן שליטה מדויקת יותר בכל כותרת ובערך שלה.
את HSTS מפעילים בעמוד Edge Certificates שבהגדרות ה-SSL/TLS, ורק אחרי שהאתר עובד ב-HTTPS בכל הכתובות שלו. לפי התיעוד, הדפדפנים זוכרים את ההגדרה לפרק הזמן שנקבע בה, ואם אחר כך מכבים את HTTPS, משהים את Cloudflare או מעבירים רשומות למצב DNS only, המבקרים עלולים לא להגיע לאתר. זו הגדרה שמפעילים בסוף תהליך ההשקה, אחרי שכל השאר נבדק.
אילו טעויות נפוצות כדאי להכיר לפני שמחברים אתר?
תקלות עם Cloudflare נובעות פעמים רבות מהגדרה שלא מתאימה לשרת, ולא מהשירות עצמו. הטבלה הבאה מרכזת את הטעויות שכדאי לבדוק לפני ההשקה ואחריה, יחד עם הסימן שמעיד עליהן והדרך לתקן. רובן נפתרות בשינוי הגדרה אחד, בתנאי שיודעים איפה לחפש.
| טעות | הסימן | התיקון |
|---|---|---|
| מצב Flexible מול שרת שמפנה ל-HTTPS | לולאת הפניות ושגיאת ERR_TOO_MANY_REDIRECTS | מעבר ל-Full (strict) עם תעודה תקפה בשרת |
| מטמון של כל ה-HTML בלי החרגות | מבקרים רואים עגלה או אזור אישי של מישהו אחר | החרגת ניהול, עגלה, תשלום וחשבון ובקשות של משתמשים מחוברים |
| רשומה במצב DNS only שמצביעה לשרת האתר | כתובת השרת חשופה ואפשר לעקוף דרכה את ההגנה | בדיקה אילו רשומות חושפות את השרת והעברתן לפרוקסי כשאפשר |
| רשומות מייל שלא הועתקו | מיילים מפסיקים להגיע אחרי החלפת שרתי השמות | השוואת רשומות MX ו-TXT מול הספק הקודם לפני המעבר |
| תעודת Origin CA שפג תוקפה | שגיאת חיבור בין Cloudflare לשרת והאתר לא נטען | תיעוד תאריך התפוגה וחידוש מראש |
| Email Address Obfuscation פעיל | קישורים לנתיב /cdn-cgi/l/email-protection בדוחות סריקה | כיבוי התכונה או החרגה של עמודים מסוימים |
הטעות האחרונה בטבלה דורשת הסבר. לפי התיעוד של Cloudflare, נכון לאוקטובר 2026, Email Address Obfuscation מופעל אוטומטית כשנרשמים, והוא משכתב כתובות מייל בקוד העמוד לצורה מקודדת שנפתחת בדפדפן בעזרת סקריפט. בפועל הקישורים המקודדים מפנים לנתיב /cdn-cgi/l/email-protection באתר, וכלי סריקה שלא מריצים JavaScript רואים אותם כקישורים פנימיים ועלולים לדווח עליהם כשגיאות. אם אין לכם צורך בתכונה, אפשר לכבות אותה בעמוד הגדרות האבטחה או להחריג עמודים מסוימים בעזרת Configuration Rule, ואחרי כל שינוי כזה כדאי לעקוב אחרי דוחות הסריקה ב-Google Search Console.
לאתר עסקי, Cloudflare הוא שכבה שימושית מעל האחסון, בתנאי שמבינים מה כל מתג עושה ובודקים את האתר אחרי כל שינוי. כשאנחנו מקימים אתר חדש, החשבונות נפתחים על שם העסק וכל עמוד נבדק ב-11 רוחבי מסך לפני ההשקה. אם אתם רוצים לחבר אתר חדש בצורה נכונה מההתחלה, השאירו פרטים וקבעו שיחת אפיון.
שאלות נפוצות
האם Cloudflare מחליף חברת אחסון?
לא. Cloudflare יושב לפני השרת ומטפל ב-DNS, במטמון, בהצפנה ובסינון תעבורה, אבל הקבצים, מסד הנתונים והקוד של האתר עדיין צריכים שרת אחסון. אם השרת לא זמין, האתר לא יעבוד כרגיל גם מאחורי Cloudflare, ולכן הוא משלים את האחסון ולא מחליף אותו. גם הדומיין נשאר רשום אצל הרשם שבו נרשם.
האם המסלול החינמי של Cloudflare מספיק לאתר עסקי?
לאתר תדמית או לאתר תוכן טיפוסי, המסלול החינמי מכסה את הבסיס. נכון לאוקטובר 2026 הוא כולל DNS, CDN, הגנת DDoS ללא הגבלת נפח, תעודת SSL אוניברסלית וחומת אש עם סט חוקים מנוהל בגרסה בסיסית. מה שחסר בו הוא בעיקר התחייבות לזמינות, תמיכה ישירה ויכולות מתקדמות, ולכן אתר עם דרישות מיוחדות צריך לבחון מסלול בתשלום מול צורך מוגדר.
מה ההבדל בין Full ל-Full (strict)?
בשני המצבים החיבור בין Cloudflare לשרת מוצפן. ההבדל הוא בבדיקת התעודה: ב-Full מתקבלת כל תעודה, גם חתומה עצמית או כזו שפג תוקפה, וב-Full (strict) התעודה חייבת להיות בתוקף, מרשות מוכרת או מ-Cloudflare Origin CA, ולהתאים לשם הדומיין. בלי הבדיקה הזו החיבור חשוף באופן תיאורטי להתחזות, ולכן Full (strict) הוא המצב המומלץ לאתר עסקי.
למה מופיעים באתר שלי קישורים ל-cdn-cgi/l/email-protection?
אלה תוצרים של התכונה Email Address Obfuscation, שלפי התיעוד של Cloudflare מופעלת אוטומטית בהרשמה. היא מקודדת כתובות מייל בקוד העמוד כדי להקשות על בוטים לאסוף אותן, ומפענחת אותן בדפדפן בעזרת סקריפט. כלי סריקה שלא מריצים JavaScript רואים את הקישורים המקודדים ועלולים לדווח עליהם כשגיאות. אם אין לכם צורך בתכונה, אפשר לכבות אותה בהגדרות האבטחה.
האם Cloudflare משפר את הקידום בגוגל?
לא באופן ישיר. Cloudflare אינו כלי SEO, וגוגל לא הגדיר שימוש בו כגורם דירוג. הוא יכול לתמוך בחוויית גלישה טובה דרך HTTPS תקין, מטמון לקבצים סטטיים והגנה מפני תעבורה זדונית, אבל הגדרה שגויה, כמו לולאת הפניות או חסימה של סורקים, יכולה גם להזיק. לכן בודקים את דוחות הסריקה אחרי כל שינוי משמעותי בהגדרות.
אולי יעניין אתכם גם
דומייניםקניית דומיין
איך קונים דומיין ישראלי נכון: בחירת סיומת, רשם מוסמך, רישום על שם העסק, WHOIS וחידוש בזמן.
לקריאה
מהירותמהירות אתר
מה גורם לאתר איטי, איך מודדים מהירות אתר נכון ומה כולל תהליך שיפור שמחזיק לאורך זמן.
לקריאה
אבטחהתעודת SSL
מה תעודת SSL עושה, איזה סוג צריך עסק, איך מוודאים חידוש אוטומטי ועוברים ל-HTTPS בלי תקלות.
לקריאההקמת אתר אינטרנט מתחילה בשיחה
ספרו לנו מה העסק עושה ולאן הוא רוצה להגיע. נחזור אליכם עם כיוון ראשוני ושאלות חכמות, בלי התחייבות.