UrlEdge
רשת Edge

רשת Edge להפניות URL

הפניות צריכות להיות החלטה קצרה וקרובה למבקר. UrlEdge מחזירה יעד, status code ו-headers לפני שהבקשה מגיעה לשרת המקור.

ביצועי Edge

פחות עבודה לשרת המקור בכל הפניה

כאשר redirect rule לא דורש backend, אפשר להחזיר אותו ב-Edge ולחסוך round trip ל-origin.

החלטה קרובה למבקר

הכלל מותאם לפי source, path ותנאים לפני שהבקשה ממשיכה.

Origin לא חייב להשתתף

הפניות 301/302 בסיסיות לא צריכות להפעיל אפליקציה רק כדי להחזיר יעד.

Chain קצר וברור

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

השוואת מסלול

Edge
Origin
London152 מול 14
Tokyo245 מול 22
San Francisco110 מול 8
Singapore280 מול 18
Sydney215 מול 26
פחות hops
92%

פרסום כללים

שינוי redirect צריך לעבור בדיקה, שמירה והפצה לפני שהוא מקבל traffic.

עדכון תצורה

צוות SEO, growth או platform מעדכן כלל דרך dashboard, CSV או API.

שמירה מבוקרת

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

הפצה ל-Edge

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

כלל פעיל

בקשות חדשות מקבלות את היעד לפי הכלל המעודכן.

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

שאלות על Edge routing

מה קורה כאשר redirect rule רץ ברמת ה-Edge.

למה לבצע הפניה ב-Edge?

כדי לא לשלוח כל בקשה ל-origin רק בשביל לקבל Location header. זה שימושי בדומיינים קצרים, קמפיינים, QR ומיגרציות.

כמה זמן לוקח לכלל להתפרסם?

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

האם יש תמיכה ב-IPv6?

ההתנהגות תלויה בתצורת הדומיין וספק ה-DNS. בדקו את רשומות הדומיין בתיעוד לפני פרסום.

האם יש SLA?

יעדי זמינות הם claim מסחרי ומשפטי ותלויים בתוכנית. אין לפרסם הבטחות SLA בלי signoff.

העבירו redirect rules לשכבת ה-Edge

חברו דומיין, בדקו HTTPS ופרסמו כללים שמחזירים יעד בלי שינוי ב-Nginx או Apache.