📘 תיעוד 93

בקרת מטמון המקור (Origin Cache Control)

עודכן לאחרונה: 30 ביוני 2026

Origin Cache Control היא תכונה של Cloudflare. כאשר היא מופעלת באתר של לקוח Enterprise, היא מציינת ש-Cloudflare צריך לכבד באופן מחמיר הנחיות Cache-Control שהתקבלו משרת המקור. ללקוחות Free, Pro ו-Business התכונה מופעלת כברירת מחדל.

הנחיות Cache-Control בתגובת ה-HTTP משרת המקור מספקות הוראות מטמון ספציפיות לשירותי ביניים כמו Cloudflare.

כאשר תכונת Origin Cache Control מופעלת, הנחיות Cache-Control שמופיעות בתגובת שרת המקור יכובדו כפי שצוינו. לדוגמה, אם התגובה כוללת הנחיית max-age של 3,600 שניות, Cloudflare ימטמן את המשאב למשך הזמן הזה לפני שיבדוק שוב את שרת המקור לעדכונים.

Cache Rules של Cloudflare מאפשר למשתמשים להרחיב או לדרוס כותרות Cache-Control של שרת המקור, או מדיניות ברירת מחדל שקובעת Cloudflare.

הסעיפים הבאים מכסים:

• ההנחיות הנפוצות ביותר של Cache-Control.
• כיצד להפעיל את Origin Cache Control.
• כיצד Origin Cache Control מתנהג עם הנחיות Cache-Control.
• כיצד מוצרים אחרים של Cloudflare פועלים עם הנחיות Cache-Control.

#הנחיות Cache-control

כותרת Cache-Control יכולה לכלול מספר הנחיות, וההנחיה קובעת מי יכול למטמן משאב, וגם כמה זמן אפשר למטמן את המשאבים האלה לפני שחייבים לעדכן אותם.

הערה

למידע נוסף על הנחיות Cache-Control בשרתי מקור, עיינו בתיעוד Cache-Control של Mozilla.

אם מועברות כמה הנחיות יחד, כל הנחיה מופרדת בפסיק. אם להנחיה יש ארגומנט, הוא בא אחרי ההנחיה ומופרד בסימן שווה. לדוגמה: max-age=86400.

אפשר לחלק הנחיות לארבע קבוצות: יכולת מטמון, תפוגה, אימות מחדש, ואחר.

#יכולת מטמון

יכולת מטמון מתייחסת לשאלה אם משאב צריך להיכנס למטמון, וההנחיות להלן מציינות את יכולת המטמון של משאב.

• public: מציין שכל מטמון רשאי לאחסן את התגובה, גם אם התגובה בדרך כלל אינה ניתנת למטמון, או ניתנת למטמון רק במטמון פרטי.
• private: מציין שהודעת התגובה מיועדת למשתמש יחיד, כמו מטמון דפדפן, ואסור לאחסן אותה במטמון משותף כמו Cloudflare או פרוקסי ארגוני.
• no-store: מציין שכל מטמון, כמו מטמון לקוח או פרוקסי, אסור שיאחסן שום חלק מהבקשה המיידית או מהתגובה.

#תפוגה

תפוגה מתייחסת לכמה זמן משאב צריך להישאר במטמון, וההנחיות להלן משפיעות על משך הזמן שהמשאב נשאר במטמון.

הערה

Cloudflare מכבד את הערך הגבוה מבין השניים: Browser Cache TTL ב-Cloudflare, או כותרת max-age. אפשר גם לציין בו זמנית Cloudflare Edge Cache TTL שונה מ-Browser Cache TTL, בהתאמה, באמצעות כותרות Cache-Control של s-maxage ושל max-age.

כאשר משתמשים ב-Origin Cache Control ומגדירים max-age=0, Cloudflare מעדיף למטמן ולאמת מחדש. כאשר Origin Cache Control כבוי ו-max-age=0, Cloudflare יעקוף את המטמון.

כאשר מגדירים no-cache ו-Origin Cache Control כבוי, Cloudflare אינו ממטמן. כאשר מגדירים no-cache ו-Origin Cache Control פועל, Cloudflare ממטמן ותמיד מאמת מחדש.

• max-age=seconds: מציין שהתגובה מיושנת אחרי שהגיל שלה גדול ממספר השניות שצוין. גיל מוגדר כזמן בשניות מאז שהנכס הוגש משרת המקור. הארגומנט seconds הוא מספר שלם ללא מרכאות.
• s-maxage=seconds: מציין שבמטמונים משותפים, הגיל המרבי שמצוין בהנחיה זו דורס את הגיל המרבי שמצוין בהנחיית max-age או בשדה הכותרת Expires. הנחיית s-maxage גם מרמזת על הסמנטיקה של הנחיית התגובה proxy-revalidate. דפדפנים מתעלמים מ-s-maxage.

s-maxage מבטל את stale-while-revalidate

לפי RFC 9111, s-maxage כולל את הסמנטיקה של proxy-revalidate, כלומר מטמון משותף אסור שיגיש תוכן מיושן בלי לאמת מחדש תחילה מול המקור. לרשימה מלאה של הנחיות שמבטלות את stale-while-revalidate ולדרכי עקיפה, עיינו בשליטה בהתנהגות מיושנת.

• no-cache: מציין שאי אפשר להשתמש בתגובה כדי לספק בקשה עוקבת בלי אימות מוצלח בשרת המקור. זה מאפשר לשרת מקור למנוע ממטמון להשתמש במקור כדי לספק בקשה בלי ליצור איתו קשר, גם במטמונים שהוגדרו לשלוח תגובות מיושנות.

ודאו שכותרת ה-HTTP Expires מוגדרת בשרת המקור כך שתשתמש ב-Greenwich Mean Time (GMT), כפי שנקבע ב-RFC 2616.

#אימות מחדש

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

• must-revalidate: מציין שברגע שהמשאב מיושן, מטמון (לקוח או פרוקסי) אסור שישתמש בתגובה כדי לספק בקשות עוקבות בלי אימות מוצלח בשרת המקור.
• proxy-revalidate: בעל אותה משמעות כמו הנחיית התגובה must-revalidate, אלא שהוא אינו חל על מטמוני לקוח פרטיים.
• stale-while-revalidate=<seconds>: כאשר מופיע בתגובת HTTP, מציין שמטמונים רשאים להגיש את התגובה שבה הוא מופיע אחרי שהיא הופכת למיושנת, עד למספר השניות שצוין מאז שפג תוקף המשאב. אם Always Online מופעל, מתעלמים מההנחיות stale-while-revalidate ו-stale-if-error. הנחיה זו אינה נתמכת בעת שימוש במתודות Cache API cache.match או cache.put. למידע נוסף, עיינו בתיעוד Workers עבור Cache API.

הערה

stale-while-revalidate הוא כעת אסינכרוני במלואו. הבקשה הראשונה אחרי התפוגה מפעילה אימות מחדש ברקע, ומקבלת מיד תוכן מיושן עם סטטוס UPDATING, במקום לחסום. כל הבקשות במהלך האימות מחדש מוגשות כמיושנות עם סטטוס UPDATING עד ששרת המקור מגיב, ואחרי כן הן מקבלות HIT.

לפרטים נוספים, עיינו באימות מחדש.

• stale-if-error=<seconds>: מציין שכאשר נתקלים בשגיאה, אפשר להשתמש בתגובה מיושנת מהמטמון כדי לספק את הבקשה, בלי קשר למידע רעננות אחר. כדי להימנע מהתנהגות זו, כללו את ההנחיה stale-if-error=0 עם האובייקט שמוחזר מהמקור. הנחיה זו אינה נתמכת בעת שימוש במתודות Cache API cache.match או cache.put. למידע נוסף, עיינו בתיעוד Workers עבור Cache API.

קודי סטטוס של שגיאה

ההנחיה stale-if-error מופעלת כאשר המקור מחזיר קוד סטטוס 5xx (500, 502, 503, 504). תגובות אחרות, כמו 404, אינן נחשבות שגיאות למטרה זו: תגובת המקור מחליפה את התוכן המיושן שבמטמון. כרגע אין דרך להתאים אישית אילו קודי סטטוס מפעילים את stale-if-error.

מתעלמים מההנחיה stale-if-error אם Always Online מופעל, או אם מועברת הנחיה מפורשת בתוך הפרוטוקול. דוגמאות להנחיות מפורשות בתוך הפרוטוקול כוללות הנחיית no-store או הנחיית no-cache cache, cache-response-directive מסוג must-revalidate, או cache-response-directive ישים מסוג s-maxage או proxy-revalidate.

#אחר

הנחיות נוספות שמשפיעות על התנהגות המטמון מפורטות להלן.

• no-transform: מציין שמתווך, בין אם הוא מממש מטמון ובין אם לא, אסור שיהפוך את ה-payload.
• vary: כברירת מחדל, Cloudflare אינו מתחשב בערכי vary בהחלטות מטמון. ערכי Vary מכובדים כאשר מגדירים את הגדרת Vary ב-Cache Rules, כאשר Vary for images מוגדר, וכאשר כותרת vary היא vary: accept-encoding.
• immutable: מציין ללקוחות שגוף התגובה אינו משתנה לאורך זמן. המשאב, אם לא פג תוקפו, אינו משתנה בשרת. המשתמש לא צריך לשלוח בקשת אימות מחדש מותנית, כמו If-None-Match או If-Modified-Since, כדי לבדוק עדכונים, גם כאשר המשתמש מרענן את הדף במפורש. להנחיה זו אין השפעה על מטמונים ציבוריים כמו Cloudflare, אבל היא כן משנה את התנהגות הדפדפן.

#הבנת ההנחיות no-store ו-no-cache

לעיתים קרובות יש בלבול בין ההנחיות Cache-Control: no-store ו-Cache-Control: no-cache, במיוחד לגבי האופן שבו הן משפיעות על מטמון דפדפן ועל תכונות כמו Back-Forward Cache (BFCache).

#no-store

• אומר גם לדפדפנים וגם למתווכים (כמו CDN) לא לאחסן עותק של התגובה בשום מצב.
• התגובה לעולם אינה נכתבת לדיסק או לזיכרון, כלומר הדפדפן חייב להביא אותה מחדש בכל פעם.
• בדפדפנים רבים, no-store משבית את BFCache, כי שחזור דף מ-BFCache מחייב את הדפדפן לשמור עותק של מצב הזיכרון של הדף, וזה סותר את ההנחיה "אל תאחסן".
• הנחיה זו משמשת לנתונים רגישים מאוד או דינמיים (לדוגמה, אפליקציות בנקאיות, מידע אישי, לוחות מחוונים מאובטחים).

#no-cache

• מאפשר אחסון של התגובה (גם במטמון דפדפן וגם במטמוני ביניים), אבל דורש אימות מחדש מול שרת המקור לפני השימוש בה.
• זה מבטיח שהתוכן תמיד מעודכן, ועדיין עשוי לאפשר BFCache או צורות אחרות של אופטימיזציית ביצועים.
• הנחיה זו משמשת לנתונים שמשתנים לעיתים קרובות אבל אינם רגישים, ואפשר להגיש אותם מהר יותר אם הם מאומתים במקום להוריד אותם מחדש.

למידע נוסף על האופן שבו ההנחיות האלה מתנהגות כאשר Origin Cache Control מופעל או מושבת, עיינו בסעיף Directives.

#הפעלת Origin Cache Control

אם מפעילים את Origin Cache Control, Cloudflare ישאף לדבוק באופן מחמיר ב-RFC 7234. ללקוחות Enterprise יש אפשרות לבחור אם Cloudflare ידבוק בהתנהגות זו, באמצעות הפעלה או השבתה של Origin Cache Control לאתרים שלהם דרך כללי מטמון בלוח הבקרה או דרך API. ללקוחות Free, Pro ו-Business האפשרות הזו מופעלת כברירת מחדל, ואי אפשר להשבית אותה.

#התנהגות Origin Cache Control

הסעיף הבא מכסה את ההנחיות ואת תנאי ההתנהגות הקשורים להפעלה או להשבתה של Origin Cache Control.

נדרשים ערכים שלמים

ההנחיות max-age, s-maxage ו-stale-while-revalidate דורשות ערכים שלמים לפי RFC 9111. ערכי נקודה צפה (לדוגמה, max-age=2.5) אינם תקינים, ויתעלמו מהם, מה שעלול לגרום לעקיפת מטמון. ודאו שהמקור מחזיר ערכי TTL שלמים.

#הנחיות

הטבלה להלן מפרטת הנחיות ואת ההתנהגויות שלהן כאשר Origin Cache Control מושבת, וכאשר הוא מופעל.

#תנאים

תרחישים מסוימים משפיעים גם על התנהגות Origin Cache Control כאשר הוא מופעל או מושבת.

הערה

כאשר כותרת Cloudflare-Cdn-Cache-Control מוגדרת, OCC מופעל מופעל (בין אם OCC מופעל ובין אם מושבת). כתוצאה מכך, אנו מיישמים את לוגיקת כותרת Authorization שלנו (לפי RFC 7234, Section 3.2) כדי לאפשר רק את ההנחיות s-maxage, must-revalidate או public. אם קיימת הנחיה אחרת, איננו ממטמנים את הנכס, ובמקום זאת מחזירים BYPASS.

#דוגמאות

עברו על הדוגמאות שלמטה כדי ללמוד באילו הנחיות להשתמש עם הכותרת Cache-Control כדי לשלוט בהתנהגות מטמון מסוימת.

שמירת נכס סטטי במטמון.

Cache-Control: public, max-age=86400

ודאו שנכס סודי לעולם לא נשמר במטמון.

Cache-Control: no-store

שמירת נכסים במטמון בדפדפנים, אבל לא במטמון פרוקסי.

Cache-Control: private, max-age=3600

שמירת נכסים במטמון אצל הלקוח ובמטמוני פרוקסי, אבל העדפת אימות מחדש בעת ההגשה.

Cache-Control: public, no-cache

שמירת נכסים במטמוני פרוקסי, אבל דרישת אימות מחדש על ידי הפרוקסי בעת ההגשה.

Cache-Control: public, no-cache, proxy-revalidate או Cache-Control: public, s-maxage=0

שמירת נכסים במטמוני פרוקסי, אבל דרישת אימות מחדש על ידי כל מטמון בעת ההגשה.

Cache-Control: public, no-cache, must-revalidate

שמירת נכסים במטמון, אבל וידוא שהפרוקסי לא משנה אותם.

Cache-Control: public, no-transform

הגדרה זו גם משביתה המרה כמו דחיסת gzip או brotli מהקצה שלנו אל המבקרים שלכם, אם המטען המקורי הוגש ללא דחיסה.

שמירת נכסים במטמון עם אימות מחדש, אבל מתן אפשרות לתשובות מיושנות אם שרת המקור לא נגיש.

Cache-Control: public, max-age=3600, stale-if-error=60

עם הגדרה זו, Cloudflare מנסה לאמת מחדש את התוכן מול שרת המקור אחרי שהוא היה במטמון במשך 3600 שניות (שעה אחת). אם השרת מחזיר שגיאה במקום תשובות תקינות של אימות מחדש, Cloudflare ממשיכה להגיש את המשאב המיושן למשך דקה אחת בסך הכל מעבר לפקיעת התוקף של המשאב.

שמירת נכסים לפרקי זמן שונים ב-Cloudflare ובדפדפני המבקרים.

Cache-Control: public, max-age=7200, s-maxage=3600

שמירת נכס במטמון והגשתו בזמן שהנכס עובר אימות מחדש.

Cache-Control: max-age=600, stale-while-revalidate=30

הגדרה זו מציינת שהנכס טרי למשך 600 שניות. אפשר להגיש את הנכס כמיושן עד 30 שניות נוספות, בזמן ש-Cloudflare מאמתת מחדש את הנכס מול המקור ברקע. למידע נוסף, ראו אימות מחדש.

הערה

אל תשתמשו ב-s-maxage עם stale-while-revalidate. ההנחיה s-maxage מרמזת על proxy-revalidate, מה שמונע ממטמונים משותפים להגיש תוכן מיושן. לדרכי עקיפה, ראו שליטה בהתנהגות של תוכן מיושן.

#אינטראקציה עם תכונות אחרות של Cloudflare

סעיף זה מכסה את האופן שבו תכונות אחרות של Cloudflare מקיימות אינטראקציה עם הנחיות Cache-Control.

#Edge Cache TTL

כללי המטמון Edge Cache TTL גוברים על s-maxage ומשביתים הנחיות אימות מחדש אם הן קיימות. כאשר Origin Cache Control מופעל ב-Cloudflare, כותרת Cache-Control המקורית מועברת הלאה מהקצה שלנו גם אם קיימות דריסות של Edge Cache TTL. אחרת, כאשר Origin Cache Control מושבת ב-Cloudflare, Cloudflare דורסת את Origin Cache Control.

#Browser Cache TTL

כללי המטמון Browser Cache TTL גוברים על הגדרות max-age שמועברות הלאה מהקצה שלנו, בדרך כלל לדפדפנים של המבקר שלכם.

#Polish

Polish מושבת כאשר ההנחיה no-transform קיימת.

#Gzip ודחיסה אחרת

הדחיסה מושבתת כאשר ההנחיה no-transform קיימת. אם הנכס המקורי שנמשך מהמקור דחוס, הוא מוגש דחוס למבקר. אם הנכס המקורי אינו דחוס, לא מוחלת דחיסה.

#JavaScript Detections

הזרקה של JavaScript Detections מושבתת כאשר ההנחיה no-transform קיימת. השדה cf.bot_management.js_detection.passed יוצג כ-missing עבור בקשות מושפעות.