📘 תיעוד 33

כללי תגובת מטמון

עודכן לאחרונה ב-14 באוגוסט 2026. לפי התיעוד הרשמי של Cloudflare: Cache Response Rules.

Cache Response Rules מאפשרים להגדיר הגדרות מטמון לפי מאפייני בקשה ותגובה. הכללים האלה רצים לפני השמירה במטמון בשלב http_response_cache_settings, שרץ אחרי ש-Cloudflare מקבלת את תגובת המקור.

עם Cache Response Rules אפשר:

• לשנות הנחיות Cache-Control שנשלחות מהמקור שלכם.
• לשנות תגי מטמון בתגובות, לניקוי מטמון ממוקד (cache purging).
• להסיר כותרות (ETag, Set-Cookie, Last-Modified) מתגובות המקור לפני השמירה במטמון.

Cache Response Rules חלים גם על תגובות שנשמרות במטמון וגם על תגובות שלא נשמרות (דינמיות) מהמקור. לדוגמה, אפשר להסיר כותרות Set-Cookie מתגובות שאינן זכאיות לשמירה במטמון.

אפשר ליצור Cache Response Rules בלוח הבקרה, דרך API, או ב-Terraform.

הערה

Cache Response Rules דורשים שרשומות ה-DNS של הדומיין (או תת-הדומיין) יועברו דרך פרוקסי של Cloudflare.

#זמינות

הטבלה הבאה מתארת את זמינות Cache Response Rules לפי תוכנית.

#פתרון בעיות

כשפותרים בעיות ב-Cache Response Rules, השתמשו ב-Cloudflare Trace כדי לבדוק אם כלל מופעל עבור כתובת URL מסוימת.

#הקשר ל-Cache Rules

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

ההבדלים העיקריים:

• זכאות למטמון: Cache Rules נשארים המנגנון היחיד שמחליט אם תוכן זכאי לשמירה במטמון. עם זאת, Cache Response Rules יכולים להפוך נכס שניתן לשמירה במטמון לנכס שאינו ניתן לשמירה, על ידי הגדרת ההנחיה no-store באמצעות הפעולה set_cache_control.
• Origin Cache Control (OCC): אם כלל כלשהו בשלב http_response_cache_settings מתאים, Cloudflare עוברת כברירת מחדל להתנהגות Origin Cache Control (origin_cache_control = true).
• קדימות CDN-Cache-Control: הנחיות Cache-Control שמוגדרות על ידי Cache Response Rules גוברות על כותרות Cloudflare-CDN-Cache-Control ו-CDN-Cache-Control שהמקור הגדיר. למידע נוסף, ראו CDN-Cache-Control header precedence.
• הצטברות (stacking): Cache Response Rules מצטברים באותו אופן כמו Cache Rules. כשכמה כללים מגדירים את אותה הגדרה, הכלל האחרון שמתאים מנצח.

#דוגמה: קדימות OCC על Edge TTL

שקלו את התרחיש הבא:

1. כלל Cache Rule מגדיר את Edge TTL ל-override_origin עם ערך של 7200 שניות (שעתיים).
2. כלל Cache Response Rule משתמש ב-set_cache_control כדי להגדיר s-maxage ל-3600 שניות (שעה אחת) עם cloudflare_only מופעל.
3. המקור מגיב עם Cache-Control: s-maxage=600.

במקרה הזה, כלל Cache Response Rule גובר. Cloudflare שומרת את הנכס במטמון למשך 3600 שניות (שעה אחת) לפי הנחיית s-maxage שהוגדרה בכלל Cache Response Rule, והמבקרים עדיין מקבלים את s-maxage=600 המקורי מהמקור כי cloudflare_only מופעל.

#ההבדל מ-Workers ומ-Transform Rules

Workers ו-Response Header Transform Rules רצים אחרי שכבר התקבלה החלטת המטמון, ואינם יכולים להשפיע אם תגובה תישמר במטמון או איך היא תישמר. רק Cache Response Rules יכולים לשנות התנהגות מטמון לפי כותרות תגובה של המקור.

אם צריך לדרוס הנחיות Cache-Control מהמקור (למשל להסיר private או להוסיף s-maxage), השתמשו ב-Cache Response Rule, לא ב-Worker ולא ב-Transform Rule.

#הערות

• אם מסירים את Last-Modified, התכונה Smart Edge Revalidation תכובה.
• Cache Response Rules מתעלמים מקודי סטטוס HTTP מסוג 1xx כי הם נחשבים לתגובות מידע.
• אפשר ליצור גרסאות של Cache Response Rules. למידע נוסף, ראו את התיעוד של Version Management.