אירוח אתרים עם בלוקים של Nginx (Hosts וירטואליים)

בלוקים של Nginx הם מנגנון המאפשר לכם לארח מספר דומיינים או אתרי אינטרנט בהגדרות נפרדות, תחת התקנה אחת של Nginx. לדוגמה, אתם יכולים להגדיר תיקי שורש שונים, קבצי יומן, תעודות SSL והגדרות PHP עבור example.com, blog.example.com ו-second-site.com באותו VPS. בקצרה, הפתרון הוא ליצור תיק נפרד לכל אתר, להפנות את רשומות ה-DNS של הדומיינים לכתובת ה-IP של השרת, לכתוב בלוק שרת נפרד תחת /etc/nginx/sites-available, לקשר אותו לתיקיית sites-enabled, לבדוק את ההגדרה ולחדש את שירות Nginx.

במדריך זה, נתייחס לתהליך אירוח מספר אתרים עם בלוקים של Nginx בדרך שמתאימה לסביבת ייצור. המטרה היא לא רק להקים תצורה פועלת, אלא ליצור מבנה ניהול, מאובטח, מהיר, מגובה ומדרגי. במיוחד נדבר על צעדים מעשיים עבור סוכנויות, מפתחים, בעלי חנויות מקוונות, עסקים המנהלים מותגים מרובים ומנהלי מערכת הפועלים על מספר פרויקטים בשרת אחד. אם עדיין אין לכם שרת, אתם מוזמנים לבדוק את עמודי שרת VPS כדי לבחור מקור ו[ iç-link: Domain Registration] לניהול דומיינים.

מהם בלוקים של Nginx?

בלוקים של Nginx הם קטעי תצורה המוגדרים בתוך תצורת Nginx כבלוק שרת, ומכתיבים לאיזה אתר יופנה בקשה שהתקבלה ב-HTTP או HTTPS. זה דומה למושג VirtualHost ב-Apache. כאשר מבקר כותב דומיין בדפדפן, ה-DNS פותר את הדומיין לכתובת ה-IP של השרת. לאחר מכן, Nginx בודק את כותרת ה-Host בבקשה ומפעיל את בלוק השרת העונה על ערך server_name המתאים.

באמצעות זה, ניתן לפרסם עשרות אתרים שונים על אותו כתובת IP ובאותו שרת פיזי או וירטואלי. ניתן להגדיר תיק שורש נפרד, יומן גישה, יומן שגיאות, כללי הפניה, תעודת SSL, מדיניות מטמון וכללי אבטחה עבור כל אתר. לדוגמה, ניתן לשמור את האתר התאגידי שלכם בתוך /var/www/corporate/public, את הבלוג שלכם ב-/var/www/blog/public ואת סביבת הבדיקה שלכם ב-/var/www/staging/public.

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

מתי משתמשים בבלוקים של Nginx?

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

• אם אתם רוצים לפרסם מספר דומיינים על אותו VPS.
• אם אתם רוצים להפנות דומיינים עם www ודומיינים ללא www לכתובת קנונית אחת.
• אם אתם רוצים לחבר תתי דומיינים לתיקיות או יישומים שונים.
• אם אתם רוצים להגדיר תעודת SSL ומדיניות אבטחה נפרדת לכל אתר.
• אם אתם רוצים לעקוב אחרי פרויקטי לקוחות עם יומני שגיאות נפרדים.
• אם אתם רוצים להריץ יישומים שונים כמו Laravel, WordPress, HTML סטטי ו-Node.js על אותו שרת.

למשל, זה טכנית אפשרי לסוכנות דיגיטלית לארח 8 אתרי תאגידים עם תעבורה נמוכה על VPS של 4 גיגה-בייט RAM. עם זאת, יש לחשב את התעבורה, השימוש בדיסק, מספר תהליכי PHP, העומס על בסיס הנתונים ותדירות הגיבויים עבור כל אתר. אם הפרויקטים מקבלים תעבורה גבוהה או אם בידוד המשאבים הוא קריטי, יש לשקול פתרונות VPS חזקים יותר, שרתי ענן או פתרונות אירוח מנוהלים. בשלב זה, ניתן להשוות בין אחסון אתרים ל-אחסון עסקי.

דרישות לפני התחלה

במדריך זה נניח שיש לכם שרת Linux מבוסס Ubuntu או Debian. הפקודות עשויות להראות מעט שונות בהתאם להפצה, אך הלוגיקה היא אותה לוגיקה. לפני ביצוע פעולות בסביבת ייצור, יש לגבות את המידע. תצורת Nginx שגויה עלולה לגרום לכך שכל האתרים יהיו בלתי נגישים זמנית.

הכנות טכניות נדרשות

• חשבון משתמש ב-Linux עם הרשאות root או sudo.
• שירות Nginx מותקן ומופעל.
• דומיין אחד לפחות שמופנה לכתובת ה-IP של השרת.
• פורט 80 ו-443 פתוחים בחומת האש.
• מבנה תיקיות מאורגן עבור קבצי האתר.
• תעודה תקפה עבור SSL או שימוש ב-Let’s Encrypt בחינם.
• התקנת PHP-FPM עבור יישומים מבוססי PHP.

בצד ה-DNS, רשומת A מפנה את הדומיין הראשי לכתובת IPv4, ורשומת AAAA אם יש, לכתובת IPv6. עבור תתי דומיינים כמו www ניתן להשתמש ברשומת CNAME או A. הפצת ה-DNS בדרך כלל מסתיימת תוך מספר דקות עד 24 שעות. כאשר מקימים התקנה חדשה, הכנת רשומות ה-DNS קודם, ולאחר מכן מעבר לתצורת בלוקי השרת של Nginx, יכולה להאיץ את התהליך.

מבנה תיקיות מומלץ

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

מבנה לדוגמה יכול להיראות כך: /var/www/site1.com/public, /var/www/site1.com/logs, /var/www/site2.com/public ו-/var/www/site2.com/logs. ערך ה-root של Nginx צריך לציין ישירות את תיקיית public. כך, קבצי היישום, קבצים רגישים כמו .env וגיבויים לא יהיו נגישים ישירות דרך האינטרנט.

ניתן להניח קובץ index.html פשוט בכל תיקיית אתר לדוגמה של דף בדיקה סטטי. בתוכו כיתבו את שם האתר כך שתוכלו לאמת במהירות איזה בלוק שרת פועל. בסביבות ייצור, הבעלות על תיקיות אלה בדרך כלל מנוהלת על ידי המשתמש www-data או משתמש פרטי שמבצע את הפריסה. עבור רשיונות קבצים, תיקיות צריכות להיות 755 וקבצים 644, וזה מספק לרוב תרחישים סטטיים. ביישומים כמו WordPress שדורשים כתיבה, יש לשקול אזורים כמו תיקיית uploads בנפרד.

שלב אחר שלב יצירת בלוק שרת Nginx

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

1. צור את תיקיית האתר

השלב הראשון הוא ליצור את התיקייה שבה ישמרו קבצי האינטרנט. לדוגמה: sudo mkdir -p /var/www/site1.com/public. לאחר מכן, לצורך בדיקה, ניתן ליצור קובץ /var/www/site1.com/public/index.html ולכתוב בתוכו טקסט מזוהה כמו "זה דף הבדיקה של site1.com".

כדי להגדיר את הבעלות על הקובץ בצורה נכונה, ניתן להשתמש בפקודה sudo chown -R www-data:www-data /var/www/site1.com. אם אתם מבצעים את תהליך הפריסה עם משתמש שונה, יש להתאים את ההגדרות בהתאם. בסביבת ייצור, יש להימנע מרשיונות 777 שבהם כולם יכולים לכתוב. רשיונות אלה עלולים לאפשר לתוקפים לנצל את תיקיות ההעלאה.

2. צור את קובץ בלוק השרת

עקרון העבודה הנפוץ ב-Nginx הוא לשמור תצורות לא פעילות תחת /etc/nginx/sites-available ולחבר את אלה שפעילות לתוך /etc/nginx/sites-enabled באמצעות קישור סימבולי. קובץ לדוגמה: /etc/nginx/sites-available/site1.com.

בלוק שרת HTTP פשוט נכתב כך: server { listen 80; server_name site1.com www.site1.com; root /var/www/site1.com/public; index index.html index.htm; access_log /var/log/nginx/site1.com.access.log; error_log /var/log/nginx/site1.com.error.log; location / { try_files $uri $uri/ =404; } }

בתצורה זו, listen 80 מקשיב לתעבורת HTTP, server_name מציין אילו דומיינים שייכים לבלוק זה, root מציין את התיקייה שבה נמצאים קבצי האינטרנט, ו-index מגדיר את הקובץ ברירת המחדל. try_files מחזיר 404 אם הקובץ או התיקייה המבוקשת לא נמצאים. מבנה זה מספק עבור אתרים סטטיים.

3. הפעל את האתר

כדי להפעיל את התצורה, יש ליצור קישור סימבולי: sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/site1.com. שיטה זו בריאה יותר מאשר העתקת קבצים, מכיוון שאתם עובדים על קובץ תצורה מרכזי אחד. כאשר אתם מבצעים שינוי, הקובץ הקשור נשאר עדכני.

אם אינכם רוצים שהדף המוגדר כברירת מחדל של Nginx יופיע לפני האתר שלכם, אתם יכולים לנטרל את התצורה של default. לשם כך ניתן להסיר את הקישור /etc/nginx/sites-enabled/default. עם זאת, לפני שתעשו זאת, ודאו שהבלוק שרת שלכם פועל כראוי.

4. בדוק את התצורה וחדש את Nginx

לאחר כל שינוי, יש לבצע בדיקת תחביר באמצעות הפקודה sudo nginx -t. אם הבדיקה מצליחה, ניתן לחדש את השירות באמצעות sudo systemctl reload nginx. פקודת reload היא בדרך כלל בטוחה יותר מאשר restart מכיוון שהיא מנהלת חיבורים פעילים בצורה חלקה יותר.

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

הוספת אתר שני ושלישי

היופי של אירוח מספר אתרים הוא שההליך ניתן לחזרה לאחר ההתקנה הראשונה הנכונה. אתם יוצרים את התיקייה /var/www/site2.com/public, כותבים את קובץ /etc/nginx/sites-available/site2.com, משנה את הערכים root ו-log ל-site2.com, יוצרים קישור סימבולי ומבצעים בדיקת Nginx.

עבור האתר השני, המבנה הפשוט ייראה כך: server { listen 80; server_name site2.com www.site2.com; root /var/www/site2.com/public; index index.html; access_log /var/log/nginx/site2.com.access.log; error_log /var/log/nginx/site2.com.error.log; location / { try_files $uri $uri/ =404; } }

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

הגדרת SSL ו-HTTPS

על פי תקני SEO 2026, HTTPS הוא כבר לא רק תכונת אבטחה אלא גם אינדיקטור לאמון המשתמש ואיכות טכנית. דפדפנים מסמנים אתרי HTTP כלא מאובטחים; פרויקטים הכוללים תשלומים, הרשמה, טפסים או לוחות ניהול דורשים SSL. בעת אירוח מספר אתרים, יש להגדיר תעודה נכונה עבור כל דומיין. תוכלו לבדוק את צורכי ה-SSL שלכם בעמוד תעודות SSL של Hostragons.

אם אתם משתמשים ב-Let’s Encrypt, ניתן לקבל תעודה עבור כל דומיין באמצעות Certbot. בתהליך לדוגמה, הפקודה certbot --nginx -d site1.com -d www.site1.com מזהה את התצורה של Nginx ויכולה להוסיף אוטומטית את בלוק ה-HTTPS. עם זאת, מומלץ לבדוק את הקובץ לאחרי העריכה האוטומטית. עשויות להתעורר בעיות של הפניות שגויות או בלוקים חוזרים.

בהגדרת HTTPS, בדרך כלל תעבורת הפורט 80 מופנה לצמיתות לפורט 443. הפניית 301 מספקת אות של העדפה קבועה מבחינת SEO. קבעו אם להשתמש ב-www או לא, ואספו את כל הווריאציות לכתובת קנונית אחת. לדוגמה, אם אתם מעדיפים להשתמש ב-https://site1.com במקום https://www.site1.com, הפנו גם את תעבורת ה-http וגם את תעבורת ה-https www לכתובת ללא www. זה מפחית את הסיכון לתוכן כפול.

בלוקים של Nginx עבור אתרי PHP ו-WordPress

בהגדרה של אתרי HTML סטטיים, התצורה היא פשוטה; אבל ב-WordPress, Laravel או יישומים מותאמים אישית, יש צורך באינטגרציה עם PHP-FPM. במקרה זה, קובץ index.php מוגדר והבקשות ל-PHP מופנות לסוקט המתאים. לדוגמה, ב-Ubuntu, נתיב הסוקט עבור PHP 8.3 עשוי להיות /run/php/php8.3-fpm.sock. הגרסה תלויה בשרת.

לוגיקה לדוגמה מבוססת על PHP: server { listen 80; server_name wordpress-site.com www.wordpress-site.com; root /var/www/wordpress-site.com/public; index index.php index.html; location / { try_files $uri $uri/ /index.php?$args; } location ~ php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.3-fpm.sock; } }

כדי להפעיל קישורים קבועים ב-WordPress, חשוב להשתמש במבנה try_files $uri $uri/ /index.php?$args. כמו כן, יש לשקול אמצעי אבטחה כמו הגבלת גישה ל-xmlrpc.php, הגבלת קצב לגישה ל-wp-login.php, ומניעת הרצת PHP בתיקיית uploads. אם אתם מארחים מספר אתרי WordPress על אותו VPS, השתמשו בבסיס נתונים נפרד, משתמש נפרד ומדיניות עדכון סדירה לכל אתר. עבור מחפשי חלופות לאירוח WordPress, אחסון WordPress יכול להיות אופציה ניהולית יותר.

השוואת בלוקי Nginx ל-VirtualHost של Apache

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

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

שיטות עבודה מומלצות לאבטחה

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

• צור בסיס נתונים נפרד ומשתמש נפרד עבור כל אתר.
• הגבל את תיק השורש של האינטרנט לתיקיית public בלבד.
• שמור על גיבויים, קבצי .env, .git, config וקבצי SQL מחוץ להגעה מהאינטרנט.
• חדש את תעודות ה-SSL באופן סדיר והכרח הפניית HTTPS.
• השתמש בחומת אש כמו UFW או דומה; פתח רק את הפורטים הנדרשים.
• עדכן את Nginx ואת מערכת ההפעלה באופן סדיר.
• שמור על access_log ו-error_log נפרדים עבור כל אתר.
• הוסף הגבלת IP או אימות נוסף ללוחות ניהול.
• הימנע מרשיונות רחבים כמו 777.

כמו כן, חשוב להוסיף כותרות אבטחה בסיסיות. כותרות כמו X-Frame-Options, X-Content-Type-Options, Referrer-Policy ו-Content-Security-Policy יכולות להיחשב בפרויקטים מתאימים. עם זאת, יש להיזהר במיוחד כאשר יש ליישם את Content-Security-Policy כראוי, אחרת זה עלול לחסום קבצי סקריפט וסגנון; לכן יש לבדוק זאת קודם בסביבת בדיקה. עבור תוכן נוסף על אבטחה, ניתן לקשר למאמרים על אבטחת אתרים.

ביצועים ו-SEO: דברים שצריך לשים לב אליהם

בלוקים של Nginx משפיעים לא רק על הפרסום אלא גם על איכות הביצועים וה-SEO. שרשרות הפניות שגויות, העדפות canonical שגויות, חוסר ב-gzip או דחיסת brotli, קבצי יומן גדולים והגדרות מטמון לא מספיקות עלולות להוריד את מהירות האתר. אותות חוויית הדף של גוגל מתמקדים במשתמש; אתרים המגיבים במהירות, מאובטחים ויציבים נוטים להציג ביצועים טובים יותר.

קודם כל, יש לקבוע גרסה קנונית אחת עבור כל דומיין. הפנה ממש HTTP ל-HTTPS, מ-www ללא www או ההפך, בהפניית שלב אחד. השרשרת לא צריכה להיות כך: http://site.com קודם http://www.site.com, לאחר מכן https://www.site.com, ולאחר מכן https://site.com. במקום זאת, יש להפנות ב-301 ישירות ליעד.

עבור קבצים סטטיים, ניתן להשתמש בכותרות cache-control. תמונות, קבצי CSS ו-JS יכולים להישמר בדפדפן למשך זמן מסוים. אך עבור קבצים שמשתנים לעיתים קרובות, יש להשתמש באסטרטגיית גרסה או מיתוג שאלה. דחיסת gzip מצמצמת את רוחב הפס בקבצים מבוססי טקסט כמו HTML, CSS, JS ו-JSON. עבור אתרים עם תעבורה גבוהה, ניתן לשקול שימוש ב-microcache, FastCGI cache או CDN ב-Nginx. ניתן לקשר לתוכן כמו מה זה CDN עבור צורכי גישה גלובלית.

ניהול יומנים ומעקב

ניהול יומנים באירוח אתרים מרובים הוא המפתח לפתרון בעיות. יומנים נפרדים מציגים בצורה ברורה באיזה אתר התרחשה איזו שגיאה. access_log רושם את בקשות המבקרים, ו-error_log רושם שגיאות בתצורה, הרשאות, חוסרים בקבצים ושגיאות upstream. שגיאת 502 Bad Gateway בדרך כלל נוגעת לשירות PHP-FPM או לחיבור לשירות אחורי. שגיאה 403 Forbidden עשויה להעיד על בעיה בהרשאות או בקובץ index. שגיאת 404 Not Found עשויה להעיד על בעיה בנתיב הקובץ, rewrite או שגיאה שקשורה ל-DNS לאחר שגיאה בשורש.

כדי למנוע מהיומנים לגדול ללא גבול, יש לבדוק את תצורת logrotate. בפרויקטים קטנים, סיבוב יומי או שבועי עשוי להיות מספק. באתרים עם תעבורה גבוהה יש להשתמש באיסוף יומנים מרכזי, ניטור מדדים ומערכות התראה. תפיסת דיסק עלולה לגרום לכך ש-Nginx לא יוכל לרשום יומנים, שהמאגר ייתקע והאתרים יהיו בלתי נגישים. לכן, קביעת ערכי סף לשימוש בדיסק היא אמצעי מעשי.

שגיאות נפוצות ופתרונות מהירים

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

• הדומיין פותח אתר שגוי: בדקו את התנגשויות server_name ואת בלוק ה-default.
• שגיאת 403 Forbidden: בדקו את תיק השורש, הרשאות הקבצים והאם קובץ index קיים.
• שגיאת 404 Not Found: בדקו את נתיב השורש ואת כלל try_files.
• שגיאת 502 Bad Gateway: ודאו ששירות PHP-FPM פועל ושהנתיב לסוקט נכון.
• תעודת SSL שייכת לאתר שגוי: בדקו את server_name בפורט 443 ואת קבצי התעודה.
• נוצרה שרשרת הפניות: פשטו את כללי ההפנייה HTTP-HTTPS ו-www.
• לא ניתן לחדש את Nginx: תקנו את השגיאה לפי מספר השורה בקלט sudo nginx -t.

יש רשימת בדיקה פשוטה שמנהלתי מעריכים: האם ה-DNS נכון? האם תצורת Nginx פעילה? האם תיק השורש קיים? האם ההרשאות נכונות? האם השירות עבר את הבדיקה? מה אומר היומן? התקדמות בסדר זה תאפשר לכם לפתור בעיות במהירות בלי להיכנס לפאניקה.

רשימת בדיקה פרקטית עבור סביבת ייצור

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

• רשומת A או AAAA של הדומיין מפנה לכתובת IP הנכונה.
• אחד משני הגרסאות עם www או ללא www נבחרה כקנונית.
• תעבורת HTTP מופנית ל-HTTPS ב-301.
• תעודת SSL תקפה וחידוש אוטומטי פעיל.
• הוגדרו תיקי root ויומנים נפרדים עבור כל אתר.
• תצורת Nginx אושרה באמצעות sudo nginx -t.
• נקבעה תוכנית גיבוי ובוצע בדיקת שיחזור.
• הרשאות הקבצים תואמות לעקרון המינימום.
• בחומת האש פתוחים רק הפורטים הנדרשים.
• יומני השגיאות נצפו במשך לפחות 15 דקות לאחר ההשקה.

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

סיכום

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

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

שאלות נפוצות

כמה אתרים ניתן לארח עם בלוקים של Nginx?

טכנית, ניתן לארח עם Nginx מספר רב של אתרים על אותו שרת; הגבול תלוי בדרך כלל ב-CPU, RAM, דיסק, תעבורה, עומס על בסיס הנתונים ויכולת PHP-FPM. באתרים סטטיים עם תעבורה נמוכה, ניתן לארח עשרות אתרים, בעוד שבפרויקטים עם תעבורה גבוהה כמו WordPress או חנויות מקוונות, עדיף לארח פחות אתרים.

האם נדרשת תעודת SSL נפרדת עבור כל אתר?

כן, כל דומיין או תת דומיין המפורסם דרך HTTPS צריך להיות כלול בכיסוי של תעודת SSL. ניתן להשתמש בתעודות נפרדות או בתעודות SAN או wildcard. החשוב הוא שהקבצים הנכונים של התעודה ישויכו לדומיין הנכון בבלוק ה-443 של Nginx.

האם ניתן לפרסם תתי דומיינים עם בלוק שרת של Nginx?

כן. ניתן להגדיר server_name נפרד עבור תתי דומיינים כמו blog.site.com או panel.site.com ולחבר אותם לתיקיית root שונה או ליישום אחורי שונה. בצד ה-DNS, יש ליצור רשומת A או CNAME עבור תת הדומיין המתאים.

מה ההבדל בין sites-available ל-sites-enabled?

sites-available הוא המקום בו מאוחסנות קבצי תצורה זמינים; sites-enabled מכיל את התצורות הפעילות. בדרך כלל, בתוך sites-enabled, נוצר קישור סימבולי לקובץ ב-sites-available. שיטה זו הופכת את הפעלת אתרים וכיבוי שלהם ליותר מאורגנים.

מה לעשות אם אתר שגוי נפתח?

הסיבות הנפוצות ביותר הן שה-DNS מפנה ל-IP שגוי, ערך server_name שגוי, בלוק ברירת המחדל של Nginx תופס את הבקשה או שיש בלוק SSL שגוי בפורט 443. קודם יש לבדוק את רשומות ה-DNS, לאחר מכן את הפלט של nginx -t, את הקישורים הפעילים ב-sites-enabled ואת קובץ ה-access_log המתאים.