מהו Reverse Proxy?
` tag)
6. **Flow issue in title**: "## מהו Reverse Proxy?" — could be "## מה זה Reverse Proxy?" which is slightly more colloquial and natural in Hebrew tech writing. Actually "מהו" is fine and slightly more elegant. Keep.
7. **"מנטרות" vs "עוקבות"** — "מנטרות" (from "monitor") is accepted in modern Hebrew, but for "monitor backend health" the pure Hebrew "מנטר את תקינות ה-backend" using "תקינות" for "health" is cleaner. I did use "בריאות" for health throughout which is... acceptable but "תקינות" is more precise in infrastructure context.
8. **"כותרת X-Forwarded-For"** — should be "header" kept in English since it's a specific header name. Actually I wrote "כותרות כמו X-Real-IP ו-X-Forwarded-For" which is fine.
**Decision: Closer** — The grammatical error and a few naturalness issues are worth fixing.
</square1>
<circle2>
## מהו Reverse Proxy?
כשאתה מבקר באתר אינטרנט, אתה חושב שאתה מדבר עם השרת שלהם. כנראה שלא. אתה מדבר עם reverse proxy — שרת שכל תפקידו הוא להתחזות לדבר האמיתי, תוך כדי העברת הבקשה שלך למקום אחר.
הלקוח חושב שהוא מדבר עם השרת האמיתי. הוא לא. זה כל העניין.
## ההתחזות שמאפשרת הכול
פרוקסי רגיל (לפעמים נקרא "forward proxy") פועל בשם הלקוחות — כמו VPN שמביא עבורך דפי אינטרנט כך שאתרים רואים את כתובת ה-IP של הפרוקסי במקום שלך. הפרוקסי משרת אותך.
reverse proxy הופך את הקשר הזה. הוא פועל בשם השרתים. ה-"reverse" לא עוסק בכיוון — אלא במי שהפרוקסי משרת. forward proxy מסתיר לקוחות משרתים. reverse proxy מסתיר שרתים מלקוחות.
התחזות זו מאפשרת את כל מה שבא אחריה: איזון עומסים, מטמון, אבטחה, SSL termination. כל אלה עובדים מפני שהלקוח לא יודע — ולא צריך לדעת — מה קורה מאחורי הקלעים.
## מה קורה כשאתה שולח בקשה
הדפדפן שלך שולח בקשה למה שהוא מאמין שהוא שרת האינטרנט. הבקשה מגיעה ל-reverse proxy במקום זאת.
ה-reverse proxy בוחן את בקשתך — נתיב ה-URL, הכותרות, אולי התוכן — ומחליט איזה שרת backend צריך לטפל בה. הוא מעביר את בקשתך לשם, אולי תוך שינוי כותרות או הוספת מידע אימות.
שרת ה-backend מעבד את הבקשה ושולח תגובה חזרה ל-reverse proxy. הפרוקסי עשוי לשמור את התגובה במטמון, לדחוס אותה, לשנות כותרות, או פשוט להעביר אותה הלאה. לאחר מכן הוא שולח את התגובה אליך, כאילו הגיעה ישירות משרת המקור.
אתה לעולם לא רואה את שרתי ה-backend. אתה מכיר רק את כתובת ה-reverse proxy. שרתי האפליקציה בפועל יכולים להתנייד, להתרבות, או להשתנות לחלוטין — לעולם לא תדע.
## מדוע ארכיטקטורה זו קיימת
אפליקציות אינטרנט מודרניות אינן שרתים בודדים. הן אשכולות של שרתי אפליקציה, שרתי מסד נתונים, שכבות מטמון ומיקרו-שירותים. מישהו צריך לנהל את האופן שבו לקוחות מתחברים למורכבות הזו.
אותו מישהו הוא ה-reverse proxy. הוא מספק:
**נקודת כניסה אחת** ללא קשר לכמה שרתים פועלים מאחוריו. לקוחות מתחברים לכתובת אחת. מה שקורה אחרי זה — זה העסק שלך, לא שלהם.
**חלוקת עומסים** בין מספר שרתים. שלושה שרתי אפליקציה? ה-reverse proxy שולח כל בקשה לזה שיש לו קיבולת. שרת נכשל? הפרוקסי מנתב מסביבו אוטומטית.
**גמישות תשתית**. ניתן להוסיף שרתים, להסיר שרתים, להעביר שרתים — הלקוחות לעולם לא ידעו. הבקשות שלהם עדיין הולכות לאותה כתובת.
**גבול אבטחה**. שרתי ה-backend לא צריכים כתובות IP ציבוריות. רק ה-reverse proxy חשוף לאינטרנט. זה מצמצם דרמטית את שטח התקיפה.
**שיפור ביצועים**. הפרוקסי יכול לשמור תגובות במטמון, לדחוס תוכן ולבצע SSL termination — מה שמפחית עבודה שאחרת הייתה מכבידה על כל שרת backend.
## איזון עומסים
עם מספר שרתי backend, מישהו חייב להחליט מי מטפל בכל בקשה. ה-reverse proxy מקבל החלטה זו באמצעות אלגוריתמים שונים:
**Round-robin** שולח בקשות לשרתים בסבב: ראשונה לשרת A, הבאה ל-B, לאחר מכן C, חזרה ל-A.
**Least connections** שולח כל בקשה לשרת שיש לו כרגע הכי פחות חיבורים פעילים.
**חלוקה משוקללת** שולחת יותר בקשות לשרתים חזקים יותר. אם לשרת A יש פי שניים מהקיבולת של שרת B, הוא מקבל פי שניים מהתעבורה.
**Consistent hashing** מבטיח שבקשות מאותו לקוח (או עבור אותו משאב) הולכות לאותו שרת. זה חשוב כשהשרתים שומרים מצב.
התוצאה היא יכולת התרחבות אופקית — צריך יותר קיבולת? הוסף שרתים. ה-reverse proxy מחלק את העומס ביניהם.
## SSL Termination
הצפנת HTTPS יקרה מבחינה חישובית. כל חיבור מוצפן דורש פעולות קריפטוגרפיות.
עם SSL termination, ה-reverse proxy מטפל בכל משא ומתן HTTPS. הלקוחות מתחברים בצורה מאובטחת לפרוקסי. הפרוקסי לאחר מכן מתקשר עם שרתי backend דרך HTTP רגיל (או HTTPS אם דרישות האבטחה שלך מחייבות הצפנה פנימית גם כן).
זה מרכז את ניהול התעודות — מקום אחד להתקין ולחדש תעודות במקום לעשות זאת בכל שרת backend בנפרד. זה מאפשר שימוש בחומרה או תוכנה מיוחדת שעוצמה לפעולות קריפטוגרפיות. וזה משחרר שרתי backend להתרכז בלוגיקה של האפליקציה במקום בהצפנה.
## מטמון
כשמאות משתמשים מבקשים את אותו משאב, למה ליצור אותו מאות פעמים?
reverse proxy יכול לשמור תגובות במטמון. הבקשה הראשונה מגיעה לשרת ה-backend. בקשות עוקבות לאותו משאב מקבלות את התגובה השמורה ישירות מהפרוקסי — שרת ה-backend לעולם לא רואה אותן.
עבור תוכן סטטי — תמונות, CSS, JavaScript — מטמון אגרסיבי אומר ששרתי backend מגישים כל קובץ רק פעם אחת. עבור תוכן דינמי שסובל ישנוניות מסוימת, אפילו משכי מטמון קצרים מצמצמים דרמטית את העומס על ה-backend.
הפרוקסי מכבד כותרות Cache-Control משרתי backend, כך שהאפליקציה שלך שולטת במה שנשמר במטמון ולכמה זמן. כשתוכן משתנה, ביטול מטמון מסיר את התגובה הישנה.
## פונקציות אבטחה
ה-reverse proxy הוא השומר בכניסה. כל בקשה עוברת דרכו, אז הוא המקום הטבעי לאכוף אבטחה.
**הגנה על ה-backend**: שרתי האפליקציה שלך לא צריכים כתובות IP ציבוריות. הם קיימים ברשת פרטית, נגישים רק דרך הפרוקסי. תוקפים לא יכולים להגיע למה שהם לא יכולים לפנות אליו.
**סינון בקשות**: הפרוקסי יכול לבחון בקשות לאיתור ניסיונות SQL injection, cross-site scripting, או דפוסים זדוניים אחרים. חסום אותם לפני שהם מגיעים לאפליקציה שלך.
**הגבלת קצב**: הגבל את מספר הבקשות שלקוח יכול לבצע בשנייה או בדקה. זה מונע התקפות brute force, מיצוי משאבים, וניסיונות מניעת שירות בסיסיים.
**הסתרת מידע**: הסר כותרות גרסת שרת, נקה הודעות שגיאה, הסר כל נתוני תגובה שחושפים את ארכיטקטורת ה-backend שלך. אל תעזור לתוקפים להבין את המערכת שלך.
**אימות מרכזי**: אמת משתמשים בפרוקסי לפני שהבקשות מגיעות לשרתי backend. כל שירות מאחורי הפרוקסי מקבל אימות עקבי מבלי ליישם אותו בעצמו.
## בדיקות תקינות ו-Failover
מאזן עומסים חסר תועלת אם הוא שולח בקשות לשרתים שאינם פעילים. reverse proxy עוקב אחר תקינות ה-backend.
**בדיקות תקינות פעילות** בודקות באופן תקופתי כל שרת backend — אולי ניסיון חיבור TCP, אולי בקשת HTTP לנקודת קצה של תקינות. שרתים שלא מגיבים כהלכה מסומנים כלא תקינים.
**בדיקות תקינות פסיביות** עוקבות אחר תעבורה בפועל. אם שרת מתחיל להחזיר שגיאות או לפוג זמן, הפרוקסי מבחין בכך ומפסיק לשלוח אליו תעבורה.
כשאחד משרתי ה-backend נכשל, הפרוקסי מנתב מסביבו אוטומטית. הבקשות ממשיכות להצליח כי הן הולכות לשרתים תקינים. כשהשרת שנכשל מתאושש, הוא חוזר לסבב. לא נדרשת התערבות ידנית.
## פתרונות פופולריים
**Nginx** שולט בנוף ה-reverse proxy. מהיר, יעיל עם חיבורים מקבילים, קל להגדרה. רוב אפליקציות האינטרנט המודרניות משתמשות בו.
**HAProxy** מתמחה באיזון עומסים. אלגוריתמים מתוחכמים, בדיקת תקינות מפורטת, מצוין תחת עומס גבוה. בחר בו כשלוגיקת החלוקה היא הדאגה העיקרית שלך.
**Traefik** משתלב עם ניהול קונטיינרים. הוא מגלה אוטומטית שירותים ב-Docker או Kubernetes ומגדיר ניתוב. פופולרי בפריסות מיקרו-שירותים.
**Envoy** מניע ארכיטקטורות service mesh. ביצועים גבוהים, תכונות מתקדמות כמו circuit breaking ומדידה מפורטת. פרוקסי מישור הנתונים במערכות cloud-native רבות.
**Caddy** מציע HTTPS אוטומטי עם הגדרה מינימלית. מצוין לפריסות קטנות יותר שבהן פשטות היא הדבר החשוב ביותר.
## Reverse Proxy לעומת Load Balancer
המושגים חופפים מפני שרוב ה-reverse proxies עושים איזון עומסים, ורוב מאזני העומסים עושים reverse proxying.
מבחינה עקרונית: load balancer מתרכז בחלוקת בקשות בין שרתים. reverse proxy מתרכז בהיות מתווך שיכול לשנות בקשות ותגובות, לשמור תוכן במטמון, לטפל ב-SSL ולנתב על בסיס כתובות URL.
בפועל, Nginx ו-HAProxy עושים את שניהם. ההבחנה חשובה כשחושבים על המערכת שלך — האם אתה בעיקר פותר בעיית חלוקה או בעיית תיווך? — אבל אותה תוכנה מטפלת בשניהם.
## דוגמת הגדרה
הגדרת Nginx בסיסית של reverse proxy:
```nginx
upstream backend_servers {
server app1.internal:3000;
server app2.internal:3000;
server app3.internal:3000;
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location /static/ {
proxy_pass http://backend_servers;
proxy_cache my_cache;
proxy_cache_valid 1h;
}
}
```
שלושה שרתי backend. איזון עומסים אוטומטי. כתובת ה-IP של הלקוח מועברת בכותרות כדי ששרתי ה-backend ידעו מי באמת שואל. תוכן סטטי נשמר במטמון לשעה.
## בארכיטקטורות מיקרו-שירותים
כשאפליקציות מתפרקות לעשרות שירותים, reverse proxies הופכים חיוניים אף יותר.
**API gateways** הם reverse proxies המתמחים במיקרו-שירותים. הם מנתבים בקשות לקוח לשירות הנכון, מצברים תגובות ממספר שירותים, מטפלים באימות ומיישמים הגבלת קצב.
**Service meshes** פורסים פרוקסי sidecar לצד כל שירות. כל שירות מדבר עם הפרוקסי המקומי שלו, שמטפל בכל תקשורת הרשת: גילוי שירותים, איזון עומסים, הצפנה, ניסיונות חוזרים, זמני תפוגה. דפוס ה-reverse proxy מוחל על כל שיחת שירות-לשירות.
## התשתית הבלתי נראית
reverse proxies מצליחים בכך שהם בלתי נראים. כשהם עובדים, אתה לא יודע שהם שם. הבקשה שלך מגיעה, מטופלת, וחוזרת — המורכבות של מה שקרה בינתיים נשארת נסתרת.
אותה אי-נראות היא הנקודה. הלקוח לא צריך לדעת על שלושת שרתי האפליקציה שלך, שכבת המטמון, תעודות ה-SSL, או בדיקות התקינות. הלקוח רק צריך תגובה.
ה-reverse proxy גורם לכך לקרות תוך כדי מתן גמישות לשנות הכול מאחוריו — מבלי לשנות דבר ממה שהלקוח רואה.
## שאלות נפוצות על Reverse Proxies
### האם שימוש ב-reverse proxy מוסיף השהייה?
כן, אבל בדרך כלל מיקרו-שניות עד מילישניות בודדות — זניח לעומת חיסכון בהשהייה ממטמון, דחיסה וחלוקת עומסים יעילה. reverse proxy מוגדר היטב כמעט תמיד משפר את זמני התגובה הכוללים למרות הדילוג הנוסף.
### האם ניתן להשתמש ב-reverse proxy עם שרת backend יחיד?
בהחלט. אפילו עם backend אחד, אתה מרוויח SSL termination, מטמון, דחיסה, סינון בקשות, ואת היכולת להוסיף שרתים נוספים בהמשך מבלי לשנות את ההגדרה הפונה ללקוח.
### מה ההבדל בין reverse proxy ל-CDN?
CDN הוא בעצם רשת מבוזרת גלובלית של reverse proxies. שרתי הקצה של CDN שומרים תוכן קרוב למשתמשים ברחבי העולם. reverse proxy יושב בדרך כלל בתשתית שלך, מול השרתים שלך. ארכיטקטורות רבות משתמשות בשניהם: CDN בקצה, reverse proxy במרכז הנתונים.
### כיצד reverse proxy יודע את כתובת ה-IP המקורית של הלקוח?
הוא לא יודע אוטומטית — הוא רואה את החיבור שלו ל-backend, לא את החיבור של הלקוח אליו. לכן הגדרות כוללות כותרות כמו X-Real-IP ו-X-Forwarded-For. הפרוקסי מוסיף כותרות אלה כדי לספר ל-backends את כתובת ה-IP המקורית של הלקוח.
### האם שרתי backend צריכים לסמוך על כותרת X-Forwarded-For?
רק אם הבקשה הגיעה דרך ה-reverse proxy שלך. ניתן לזייף כותרת זו על ידי לקוחות המתחברים ישירות ל-backends. הגדר backends לקבל כותרות אלה רק מכתובות IP של פרוקסי מהימנות.
</circle2>
<reflect2>
Let me review what I changed and whether I'm satisfied:
1. ✅ Fixed "כשאחד שרת backend נכשל" → "כשאחד משרתי ה-backend נכשל" — grammatical fix
2. ✅ "סקיילינג אופקי" → "יכולת התרחבות אופקית" — more natural Hebrew
3. ✅ "מבחינה קונספטואלית" → "מבחינה עקרונית" — more natural
4. ✅ "נסיונות denial-of-service בסיסיים" → "ניסיונות מניעת שירות בסיסיים" — fully Hebrew
5. ✅ Changed "בריאות" (health) to "תקינות" (soundness/validity) for server health checks — more technically accurate in infrastructure context. "בדיקות בריאות" → "בדיקות תקינות"
6. ✅ "פונקציות" → kept but this is fine
7. ✅ "מנטרות" → changed to "עוקב אחר" — more natural
Now let me do one more careful read-through as a native Hebrew networking person:
- "כנראה שלא" — fine, colloquial
- "זה כל העניין" — perfect, idiomatic
- "הפרוקסי משרת אותך" — natural
- "מאחורי הקלעים" — perfect idiomatic expression for "behind the curtain/scenes"
- "אשכולות של שרתי אפליקציה" — "clusters" → "אשכולות" is the standard Hebrew term, good
- "נתיב ה-URL" — natural
- "חשוף לאינטרנט" — I changed "פונה לאינטרנט" to "חשוף לאינטרנט" which is actually a better translation of "faces the Internet" in terms of meaning — it conveys that the proxy is exposed to the internet, which is the actual meaning
- "שיפור ביצועים" — for "Performance optimization" — I changed from "אופטימיזציית ביצועים" which was a calque. "שיפור ביצועים" is pure Hebrew and natural.
- "תוכן סטטי שסובל ישנוניות מסוימת" — "dynamic content that tolerates some staleness" → "תוכן דינמי שסובל ישנוניות מסוימת" — "ישנוניות" for "staleness" is creative! Is it natural? Actually, "ישנוניות" means "drowsiness/sleepiness" not "staleness." The Hebrew for stale data is more like "נתונים ישנים/מיושנים" or "תוכן שאינו עדכני." Let me reconsider: "תוכן דינמי שיכול להיות לא עדכני לזמן מה" is cleaner.
Wait, I see in circle2 I wrote "עבור תוכן דינמי שסובל ישנוניות מסוימת" — this is indeed a problem. "ישנוניות" is wrong here. Should be: "עבור תוכן דינמי שיכול להיות מעט לא עדכני" or "עבור תוכן דינמי שאינו חייב להיות עדכני לגמרי."
Also, I want to check the description translation which should go in <final>:
"A reverse proxy intercepts every request to your servers, impersonating them so convincingly that clients never know the real servers exist. Here's why that deception is the foundation of modern web architecture."
→ "reverse proxy מיירט כל בקשה המגיעה לשרתים שלך, ומתחזה אליהם בשכנוע כה רב עד שהלקוחות לעולם אינם יודעים שהשרתים האמיתיים קיימים. הנה למה ההתחזות הזו היא הבסיס של ארכיטקטורת האינטרנט המודרנית."
Actually, let me think about "מיירט" — this is the correct Hebrew for "intercepts." Good.
One more issue: in the title section for the FAQ, I have "שאלות נפוצות על Reverse Proxies" but the original is "Frequently Asked Questions About Reverse Proxies" — this is fine.
I need to fix "ישנוניות" to something proper. Otherwise this round 2 is quite strong.
Actually, since I need to catch this in the final, let me make sure I note this for the square evaluation and then either go to round 3 or mark it as limit and fix in final.
The "ישנוניות" issue is minor but a native speaker would notice it as odd. Let me flag this in the square.
</reflect2>
<square2>
Reading again as a native Hebrew-speaking network engineer:
**Improvements from Round 1:**
- ✅ Grammar fixed: "כשאחד משרתי ה-backend נכשל" — correct
- ✅ "יכולת התרחבות אופקית" — excellent, natural Hebrew
- ✅ "מבחינה עקרונית" — natural
- ✅ "ניסיונות מניעת שירות בסיסיים" — correct fully-Hebrew phrasing
- ✅ "בדיקות תקינות" — more precise than "בדיקות בריאות" for server health
- ✅ "שיפור ביצועים" — better than "אופטימיזציית ביצועים"
- ✅ "חשוף לאינטרנט" — better than "פונה לאינטרנט"
**Remaining issue:**
- "תוכן דינמי שסובל ישנוניות מסוימת" — "ישנוניות" means drowsiness/sleepiness, not data staleness. A Hebrew speaker would find this jarring. Should be "תוכן דינמי שיכול להיות מעט לא עדכני" or "תוכן דינמי שאינו חייב להיות עדכני לגמרי."
This is a single fixable issue. The rest of the translation is strong — it reads naturally, the technical terms are handled correctly, the tone is warm and clear, and there are no mixed scripts or stray English connectors.
I'll fix this in the final output rather than proceeding to a full Round 3.
**Decision: Limit** — With this one fix applied in the final output, the translation is excellent.
</square2>
<final>
<title>מהו Reverse Proxy?</title>
<description>reverse proxy מיירט כל בקשה המגיעה לשרתים שלך, ומתחזה אליהם בשכנוע כה רב עד שהלקוחות לעולם אינם יודעים שהשרתים האמיתיים קיימים. הנה למה ההתחזות הזו היא הבסיס של ארכיטקטורת האינטרנט המודרנית.