מדריך nginx כ-Reverse Proxy
בעמוד זה
Reverse proxy יושב לפני האפליקציות שלכם ומעביר אליהן את הבקשות של המבקרים. כש-nginx עומד בחזית, אפליקציית Node.js, קונטיינר Docker או לוח בקרה שרץ על פורט כלשהו הופכים ל-https://app.example.com, עם HTTPS, כותרות תקינות ומקום אחד לנהל הכול.
המדריך הזה מגדיר צעד אחר צעד את nginx כ-reverse proxy ב-Ubuntu: בלוק ה-server, הכותרות, WebSockets, HTTPS בחינם והשגיאות שסביר שתיתקלו בהן.
מה reverse proxy עושה
- נקודת כניסה ציבורית אחת. nginx מאזין בפורטים 80 ו-443 ומעביר כל דומיין או נתיב לאפליקציה הנכונה, כך שהאפליקציות עצמן אף פעם לא חשופות לאינטרנט.
- HTTPS במקום אחד. nginx מטפל בתעודות; האפליקציות שמאחוריו יכולות לדבר HTTP רגיל על localhost.
- כמה אפליקציות על שרת אחד.
app.example.com,api.example.comו-example.com/blogיכולים להגיע כל אחד לשירות אחר. - תוספות: דחיסה, מטמון, מגבלות העלאה וכללי גישה, בלי לגעת באפליקציה.
שלב 1: התקנת nginx
sudo apt update sudo apt install nginx
פתחו את http://your-server-ip ואמור להופיע דף הפתיחה של nginx. אם אתם משתמשים ב-ufw, אפשרו תעבורת אינטרנט עם sudo ufw allow 'Nginx Full'.
ודאו שהאפליקציה שלכם רצה ונגישה מהשרת עצמו, למשל עם curl http://127.0.0.1:3000. אם זה נכשל, גם nginx ייכשל.
הריצו את nginx ואת האפליקציות שלכם עם root מלא: חבילות HytHost KVM VPS מתחילות מ-€2.92 לחודש.
לחבילות VPSשלב 2: יצירת בלוק server ל-proxy
ב-Ubuntu כל אתר מקבל קובץ ב-/etc/nginx/sites-available/, שמופעל באמצעות קישור ב-sites-enabled. צרו את /etc/nginx/sites-available/app.example.com:
server {
listen 80;
server_name app.example.com;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
הפעילו אותו, בדקו את התצורה וטענו מחדש:
sudo ln -s /etc/nginx/sites-available/app.example.com /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx
כוונו את רשומת ה-A של הדומיין לשרת שלכם, ו-http://app.example.com יציג עכשיו את האפליקציה. תמיד הריצו nginx -t לפני טעינה מחדש: הוא תופס שגיאות הקלדה לפני שהן מפילות את האתר.
הכותרות, והלוכסן בסוף
Hostמעביר את הדומיין שהמבקר ביקש. בלעדיו nginx שולח את הכתובת מ-proxy_pass, ואפליקציות שבונות קישורים לפי ה-host נשברות.X-Real-IPו-X-Forwarded-Forמעבירים את כתובת ה-IP של המבקר. בלעדיהם כל בקשה נראית כאילו הגיעה מ-127.0.0.1.X-Forwarded-Protoאומר לאפליקציה אם המבקר השתמש ב-HTTPS, כדי שלא תיכנס ללולאת הפניות.
חבילת nginx של Ubuntu כוללת את השורות האלה ב-/etc/nginx/proxy_params, כך ש-include proxy_params; הוא קיצור דרך.
הלוכסן בסוף חשוב. עבור אפליקציה תחת נתיב:
location /app/ {
proxy_pass http://127.0.0.1:3000/;
}
עם לוכסן אחרי הפורט, /app/login מגיע לאפליקציה כ-/login. בלעדיו, האפליקציה מקבלת את /app/login המלא.
WebSockets
אפליקציות צ׳אט, לוחות מחוונים חיים ופאנלי ניהול רבים משתמשים ב-WebSockets, שדורשים שתי כותרות נוספות. הוסיפו את ה-map הזה פעם אחת, בתוך בלוק http, למשל בקובץ חדש /etc/nginx/conf.d/websocket.conf:
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
ואז בתוך ה-location:
proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; proxy_read_timeout 1h;
nginx סוגר חיבור מועבר שלא שולח דבר במשך 60 שניות; ערך ארוך יותר ל-proxy_read_timeout משאיר WebSockets שקטים פתוחים. proxy_http_version 1.1 הוא ברירת המחדל רק מ-nginx 1.29.7, ו-Ubuntu 24.04 מגיע עם 1.24, אז השאירו את השורה.
שלב 3: HTTPS בחינם עם Certbot
sudo snap install --classic certbot sudo ln -s /snap/bin/certbot /usr/local/bin/certbot sudo certbot --nginx -d app.example.com
Certbot משיג תעודת Let's Encrypt בחינם, מוסיף את הגדרות ה-HTTPS לבלוק ה-server שלכם ויכול להפנות HTTP ל-HTTPS. הוא מחדש את התעודה אוטומטית; בדקו עם sudo certbot renew --dry-run. עוד על תעודות באיך להשיג תעודת SSL בחינם.
תיקון שגיאות 502, 504 ו-413
| שגיאה | סיבה נפוצה | פתרון |
|---|---|---|
| 502 Bad Gateway | nginx לא מצליח להגיע לאפליקציה: היא עצורה, קרסה, או מאזינה בפורט או בכתובת אחרים | הפעילו את האפליקציה, בדקו את הפורט עם curl http://127.0.0.1:PORT, קראו את /var/log/nginx/error.log |
| 504 Gateway Timeout | לאפליקציה לקח יותר מ-60 שניות לענות | האיצו את הבקשה, או הגדילו את proxy_read_timeout עבור אותו location |
| 413 Request Entity Too Large | ההעלאה גדולה ממגבלת ברירת המחדל של nginx, 1 MB | הגדירו client_max_body_size 50m; בבלוק ה-server |
| לולאת הפניות | האפליקציה לא יודעת שהמבקר השתמש ב-HTTPS | העבירו את X-Forwarded-Proto ואמרו לאפליקציה שהיא מאחורי proxy |
אחרי כל שינוי: sudo nginx -t, ואז sudo systemctl reload nginx.
הריצו את זה על HytHost VPS
Reverse proxy צריך שרת שבו אתם שולטים בפורטים 80 ו-443. חבילות HytHost VPS רצות על KVM עם גישת root מלאה, אחסון SSD והגנת DDoS; בחרו Ubuntu 24.04 ועקבו אחרי השלבים למעלה. מריצים את האפליקציות בקונטיינרים? התקינו קודם Docker בעזרת איך להתקין Docker על Ubuntu, וקשרו את הפורטים של הקונטיינרים ל-127.0.0.1 כך שרק nginx יוכל להגיע אליהם.
שאלות נפוצות
Reverse proxy מעביר בקשות לאפליקציה אחת או יותר שמאחוריו. Load balancer הוא reverse proxy שמפזר בקשות בין כמה עותקים של אותה אפליקציה. nginx יכול לעשות את שניהם, עם בלוק upstream שמפרט את העותקים.
nginx לא מצליח להגיע לאפליקציה שמאחוריו. בדקו שהאפליקציה רצה ומאזינה בכתובת ובפורט שב-proxy_pass, וקראו את /var/log/nginx/error.log כדי לגלות את הסיבה המדויקת.
לא, כשהאפליקציה רצה על אותו שרת. nginx מטפל ב-HTTPS מול המבקרים ומדבר עם האפליקציה ב-HTTP רגיל על 127.0.0.1, תעבורה שאף פעם לא יוצאת מהמכונה.
תנו לכל אפליקציה בלוק server משלה עם server_name משלה, כמו app.example.com ו-api.example.com, כל אחד עם proxy_pass לפורט אחר.
כן. פרסמו את הפורט של כל קונטיינר רק על 127.0.0.1 וכוונו אליו את proxy_pass. כך הקונטיינרים נשארים מחוץ לאינטרנט הציבורי, וזה חשוב כי פורטים ש-Docker מפרסם עוקפים את ufw.
אחסנו את האפליקציות שלכם מאחורי nginx
חבילות HytHost KVM VPS עם גישת root מלאה, אחסון SSD והגנת DDoS מתחילות מ-€2.92 לחודש.
Live chat 8 AM – 11 PM (Chișinău time) · tickets answered during business hoursהמדריך הזה עזר לך?