FAQ

שאלות נפוצות

מדריכים קצרים מעשיים להגדרת שירות, גישה ופעולות נפוצות של לקוחות.

> יצירת מפתח SSH ציבורי במסוף

צור מפתח SSH ציבורי לגישה ושתף רק את החלק הציבורי.
faq/generate-public-ssh-key-he

השתמש רק במפתח הציבורי

SSH משתמש בזוג מפתחות. בהגדרות השירות הדבק רק את המפתח הציבורי, בדרך כלל קובץ .pub. המפתח הפרטי נשאר במכשיר שלך.

שלבים במסוף

  1. פתח Terminal, Windows Terminal או PowerShell.
  2. הרץ: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. אשר את מיקום ברירת המחדל או בחר נתיב בטוח.
  4. הצג את המפתח הציבורי עם: cat ~/.ssh/id_ed25519.pub.
  5. ב Windows PowerShell השתמש ב: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. העתק את כל שורת ssh-ed25519 לשדה SSH public key.

בדוק לפני ההדבקה

אל תעתיק את המפתח הפרטי. אם הגדרת passphrase, שמור אותו בבטחה לשימוש עתידי.

> יצירת מפתח SSH ב Windows בממשק גרפי

השתמש ב PuTTYgen ב Windows והעתק רק את המפתח הציבורי.
faq/create-ssh-key-windows-gui-he

צריך רק את החלק הציבורי

PuTTYgen יוצר מפתח ציבורי ומפתח פרטי. הוסף ל Cli>_ רק את המפתח הציבורי ושמור את הפרטי מקומית.

שלבים ב Windows

  1. פתח את PuTTYgen.
  2. בחר EdDSA / Ed25519 כאשר זמין.
  3. השתמש ב RSA 4096 רק כאפשרות גיבוי.
  4. לחץ Generate והזז את העכבר עד שהמפתח נוצר.
  5. שמור את המפתח הפרטי במחשב שלך.
  6. העתק את טקסט המפתח הציבורי לשדה SSH public key.

אל תשתף נתונים סודיים

אל תשלח קבצי .ppk, מפתחות פרטיים, passphrase, סיסמאות או token לתמיכה או לטפסים.

> חיבור הדומיין שלך

ודאו סמכות registrar או nameservers, hostname מדויק, apex או subdomain, תמיכת CNAME או A/AAAA או ALIAS או ANAME וללא רשומות מתנגשות.
faq/hibur-hadomain-shelkha

הדומיין צריך להצביע ליעד השירות

לפני בדיקה סופית הדומיין צריך להצביע ליעד שמוצג בשירות. השיטה תלויה אם מדובר ב-apex כמו example.com או subdomain כמו app.example.com ובתמיכת ספק ה-DNS.

בדיקת DNS

  1. בחרו hostname מדויק לשימוש.
  2. ודאו שה-registrar או authoritative nameservers הם המקום הנכון לעריכה.
  3. הסירו רשומות מתנגשות לאותו hostname.
  4. השתמשו ב-CNAME, A/AAAA, ALIAS או ANAME רק כאשר הספק וסוג השם תומכים בכך.

בדקו את השם המלא

בדקו את ה-hostname המלא שבו מבקרים ישתמשו, לא רק את הדומיין הכללי. apex ו-subdomain דורשים לעיתים סוג רשומה ואימות שונים.

> העברת אזור DNS

שירותים משתמשים בדרך כלל ב-A/AAAA, CNAME, MX, TXT ו-CAA; דוא״ל משתמש ב-SPF, DKIM selector ו-DMARC על _dmarc.
faq/haavarat-ezor-dns

לכל סוג רשומה יש תפקיד

A ו-AAAA מצביעות לכתובות, CNAME מפנה subdomain ל-hostname אחר, MX לדואר, TXT לאימות ול-SPF/DKIM/DMARC, ו-CAA מגביל רשויות תעודה.

מניעת התנגשויות

  1. העתיקו במדויק את סוג הרשומה והיעד מדף השירות.
  2. אל תשתמשו ב-CNAME יחד עם רשומות אחרות על אותו hostname.
  3. שימו DKIM תחת selector שספק הדואר נתן ו-DMARC תחת _dmarc.
  4. שנו CAA בזהירות כי ערך שגוי עלול לחסום הנפקת תעודה.

שנו רשומה אחת בבירור

בעת תיקון, תעדו את הערך הישן, הערך החדש וזמן השינוי. זה מקל להבין תוצאות DNS מעורבות בזמן שה-cache פג.

> הרשמה לחשבון והתחברות

צרו חשבון לקוח אחד להזמנות, חיוב וניהול שירותים, עם כתובת דוא״ל שהצוות יוכל לשמור לאורך זמן.
faq/account-registration-and-login

חשבון אחד לניהול השירותים

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

הכנה לפני הזמנה ראשונה

  1. הירשמו עם כתובת דוא״ל פעילה.
  2. אשרו את הודעת הדוא״ל אם נדרש אישור.
  3. השלימו פרטי חיוב לפני הזמנה בתשלום.
  4. הפעילו אימות דו-שלבי כאשר הוא זמין.

שמרו בעלות על החשבון

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

> קרדיט מראש ועלות שירות יומית

קרדיט מראש מציג יתרה, זמן ריצה משוער, עלות יומית, מועד טעינה מחדש וסיכון השעיה או מחיקה גלוי.
faq/prepaid-credit-how-it-works

הקרדיט נצרך בזמן שהשירות פעיל

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

ניהול יתרה לפני השעיה

  1. הוסיפו קרדיט מאזור הלקוח.
  2. בדקו מחיר ועלות יומית לפני אישור הזמנה או שינוי.
  3. עקבו אחרי התראת יתרה נמוכה, זמן ריצה ומועד מחיקה גלוי.
  4. טענו קרדיט לפני שהוא נגמר כדי למנוע השעיה ומחיקה מאוחרת יותר.

אל תחכו ליום האחרון

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

> תקופות חיוב וצריכת קרדיט

הערכה חודשית משתמשת ב-31 ימים ושנתית ב-372 ימים; הקרדיט נצרך יומית אחרי שהשינוי אושר, שולם אם צריך, ויושם.
faq/billing-periods-and-credit-burn

חודש ושנה הם כלי השוואה

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

בדיקת עלות לפני אישור

  1. השוו הערכת 31 ימים או 372 ימים לצריכה היומית.
  2. בדקו אם שינוי משאבים מעלה או מוריד עלות יומית.
  3. אשרו ושלמו כשנדרש, ואז המתינו ליישום.
  4. שמרו חשבוניות, אישורי הזמנה והיסטוריית קרדיט לצורכי הנהלת חשבונות.

מתי הצריכה משתנה

בחירה שלא אושרה עדיין אינה משנה חיוב. הצריכה משתנה כאשר ההזמנה או השינוי אושרו, שולמו כשנדרש ויושמו על השירות.

> סטטוס הזמנה ואישור תשלום

הזמנה עשויה להמתין לאישור מספק התשלום לפני הפעלת השירות, לכן אין ליצור הזמנה כפולה מוקדם מדי.
faq/order-status-and-payment-confirmation

הזמנה ממתינה אינה בהכרח כישלון

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

מעקב אחרי התשלום

  1. חזרו מדף ספק התשלום אל Cli>_ אחרי השלמת התשלום.
  2. בדקו את מצב ההזמנה בחשבון.
  3. אם ההזמנה עדיין ממתינה, המתינו לאישור הספק.
  4. אם הסטטוס לא משתנה, פנו לתמיכה עם מספר ההזמנה ואסמכתת ספק התשלום אם יש.

הימנעו מהזמנה כפולה

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

> מידע נדרש להגדרת שירות

הכינו שם שירות, דומיין, תוכנית DNS, אחסון, משאבים, דוא״ל מנהל ומפתח SSH ציבורי, בלי סודות.
faq/service-setup-information-needed

ערכים ציבוריים מונעים עיכובים

רוב השירותים דורשים בחירות לקוח כמו שם שירות, דומיין, מוכנות DNS, גודל אחסון, CPU או RAM, דוא״ל גישה או ניהול ומפתח SSH ציבורי. אין להזין סיסמאות, מפתחות פרטיים או tokens בשדות הגדרה.

רשימת הכנה להזמנה

  1. קראו את טופס המוצר לפני התשלום.
  2. הכינו דומיין, משימות DNS ומפתח SSH ציבורי מראש.
  3. בחרו שמות שירות ברורים לצוות.
  4. אל תכניסו סודות לשדות שמבקשים ערכים ציבוריים.

רק מפתח ציבורי

כאשר נדרש SSH, שלחו רק מפתח ציבורי, בדרך כלל ערך שמתחיל ב-ssh-ed25519 או ssh-rsa. המפתח הפרטי נשאר במכשיר שלכם ואינו דרוש להפעלה.

> שינוי משאבי שירות אחרי הזמנה

שנו CPU, RAM, אחסון או תקופות שמירה רק אחרי בדיקת מחיר חדש, צריכה יומית וסיכון restart או downtime.
faq/change-service-resources-after-order

משנים את השירות הקיים

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

שינוי מבוקר

  1. פתחו את השירות הקיים ובדקו CPU, RAM, אחסון ושמירות.
  2. בחרו את השינוי ובדקו מחיר חדש וצריכה יומית.
  3. אשרו ושלמו אם נדרש, ואז המתינו ליישום.
  4. בצעו export לנתונים חשובים לפני שינוי שעלול לגרום downtime.

תזמנו שינוי בזהירות

בצעו שינויים שעלולים לגרום restart בזמן מתאים למשתמשים. אם האפליקציה רגישה להשבתה, הכינו export או תוכנית חזרה לפני אישור.

> ביטול שירות ושמירת נתונים

ביטול שירות שכבר סופק משעה אותו תחילה, מציג מועד מחיקה גלוי וניתן להגדרה, ואז מוחק סופית לפי מחזור החיים.
faq/cancel-service-and-data-retention

ביטול אינו גיבוי אוטומטי

ביטול שירות מסופק משעה אותו תחילה ומציג מועד מחיקה גלוי וניתן להגדרה. לאחר תקופת מחזור החיים מתבצע purge קבוע. הזמנות ממתינות לא משולמות שלא סופקו עשויות להסתיים בלי אותו מחזור נתוני ריצה. גיבויים ו-Offsite Archive נשמרים לפי כללים נפרדים.

לפני מחיקה קבועה

  1. צרו export משלכם לפני ביטול או חוסר קרדיט ממושך.
  2. קראו את הודעת ההשעיה ואת מועד המחיקה הגלוי.
  3. זכרו ש-backup retention ו-Offsite Archive retention נפרדים ממחיקת השירות.
  4. פנו לתמיכה לפני המועד אם אינכם בטוחים.

בדקו את התאריך המוצג

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

> גיבויים ובקשות שחזור

שמירת גיבויים תלויה באפשרויות המוצר; שחזור עלול לדרוס נתונים חדשים יותר, לכן שלחו הקשר ברור בלי סודות.
faq/backups-and-restore-requests

גיבוי מיועד להתאוששות תפעולית

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

בקשת שחזור יעילה

  1. בדקו את אפשרות שמירת הגיבויים במוצר או בשירות.
  2. שמרו exports נפרדים לנתונים קריטיים.
  3. שלחו שם שירות, מספר הזמנה, זמן שחזור משוער ושגיאה גלויה או הקשר.
  4. אל תשלחו סיסמאות, מפתחות פרטיים, tokens או נתונים סודיים.

ציינו נקודת שחזור

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

> למה מיועד Offsite Archive

Offsite Archive שומר עותקי ארכיון מרוחקים במרכז נתונים אחר והוא נפרד מגיבויים קצרים וממחיקת שירות.
faq/offsite-archive-purpose

ארכיון מרוחק ולא אחסון חי

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

שמירה ועלות

  1. בחרו מספר ימי שמירה לפי דרישת התאוששות או ציות.
  2. חשבו MB-days כנפח MB שמור כפול מספר ימי השמירה.
  3. בדקו עלות כאשר הנתונים גדלים או השמירה מתארכת.
  4. אל תשתמשו בו כתחליף לגיבויים קצרים או למועד מחיקת השירות.

השתמשו בו כשכבה נוספת

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

> בחירת CPU, RAM וגודל דיסק ל-VPS

בחרו גודל VPS לפי עומס העבודה, מסד הנתונים, cache, logs וצמיחה צפויה, ושימו לב ל-OOM או out of memory.
faq/vps-cpu-ram-and-disk-sizing

הגודל צריך להתאים לסימפטומים

מסדי נתונים, קונטיינרים, חיפוש ואפליקציות Java צריכים בדרך כלל יותר RAM ודיסק מאתר סטטי קטן. הודעות OOM, out of memory או process killed מצביעות לעיתים על RAM נמוך מדי.

מתי להגדיל משאבים

  1. התחילו בגודל הקטן ביותר שעומד בדרישות האפליקציה.
  2. הגדילו RAM כשמופיעים OOM, swap כבד או process killed.
  3. הגדילו CPU לעומס חישובי מתמשך או builds.
  4. הגדילו דיסק לפני שמערכת הקבצים מתמלאת.

נטרו לפני הגדלה

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

> אפשרויות IP ציבורי ל-VPS

IP ציבורי ייעודי מתאים כאשר ספק חיצוני או firewall דורשים allowlist קבוע, גישה ישירה או מקור outbound יציב.
faq/vps-public-ip-options

מתי IP ייעודי עוזר

IP ציבורי ייעודי שימושי כאשר שותף, ספק או firewall דורשים כתובת קבועה ל-inbound, ל-outbound source או לשני הכיוונים. עדיף להשתמש ב-DNS names כשאפשר ולפתוח רק פורטים נדרשים.

בדיקות לפני בקשה

  1. שאלו את הצד החיצוני אם דרוש inbound, outbound source או שניהם.
  2. ציינו רק את הפורטים הנחוצים ב-firewall.
  3. השתמשו ב-DNS names במקום מספרי IP כאשר אפשר.
  4. שתפו את דרישת ה-allowlist עם התמיכה לפני שינוי תכנון הגישה.

DNS ו-SSH ישיר או משותף

עם IP ציבורי ייעודי אפשר להשתמש בשם DNS שמצביע לכתובת הזו, ולעיתים להתחבר ישירות ל-SSH בכתובת השירות אם הפורט פתוח. בלי IP ייעודי, SSH משותף משתמש במארח ציבורי ובפורט גבוה שמוקצה לשירות, למשל ssh -p @.

> גישת SSH משותפת ל-VPS

ב-SSH משותף משתמשים בשם המשתמש, המארח והפורט הגבוה שמוצגים בשירות: ssh -p <port> <username>@<public-host>.
faq/shared-ssh-access-for-vps

הפורט הגבוה הוא חלק מפרטי ההתחברות

אזור הלקוח מציג SSH username, מארח ציבורי שבדרך כלל הוא שם DNS תחת vps.cliopen.cloud, ופורט מוקצה. ב-SSH משותף אל תניחו שפורט 22 פתוח; השתמשו בדיוק בפורט הגבוה שמופיע בשירות. אם לשירות יש IP ציבורי ייעודי, ייתכן שיהיה זמין גם נתיב SSH ישיר נוסף דרך ה-IP הזה או שם ה-DNS שלו.

פקודת התחברות

  1. העתיקו SSH username, public host ו-port מדף השירות.
  2. התחברו עם ssh -p <port> <username>@<public-host>.
  3. השתמשו במפתח הפרטי רק מקומית ואל תדביקו אותו בצ׳אט או בטיקט.
  4. בכשל התחברות שלחו שם שירות, מארח, פורט, שם משתמש ושגיאה גלויה.

שמרו את המפתח הפרטי מקומית

המפתח הפרטי צריך להישאר רק במכשיר שלכם. אל תשלחו אותו בטיקט או בצ׳אט; שתפו עם התמיכה רק את פרטי החיבור הגלויים ואת השגיאה.

> רשימת מוכנות לדומיין מותאם

ודאו סמכות registrar או nameservers, hostname מדויק, apex או subdomain, תמיכת CNAME או A/AAAA או ALIAS או ANAME וללא רשומות מתנגשות.
faq/custom-domain-readiness-checklist

הדומיין צריך להצביע ליעד השירות

לפני בדיקה סופית הדומיין צריך להצביע ליעד שמוצג בשירות. השיטה תלויה אם מדובר ב-apex כמו example.com או subdomain כמו app.example.com ובתמיכת ספק ה-DNS.

בדיקת DNS

  1. בחרו hostname מדויק לשימוש.
  2. ודאו שה-registrar או authoritative nameservers הם המקום הנכון לעריכה.
  3. הסירו רשומות מתנגשות לאותו hostname.
  4. השתמשו ב-CNAME, A/AAAA, ALIAS או ANAME רק כאשר הספק וסוג השם תומכים בכך.

בדקו את השם המלא

בדקו את ה-hostname המלא שבו מבקרים ישתמשו, לא רק את הדומיין הכללי. apex ו-subdomain דורשים לעיתים סוג רשומה ואימות שונים.

> סוגי רשומות DNS לשירותים

שירותים משתמשים בדרך כלל ב-A/AAAA, CNAME, MX, TXT ו-CAA; דוא״ל משתמש ב-SPF, DKIM selector ו-DMARC על _dmarc.
faq/dns-record-types-for-services

לכל סוג רשומה יש תפקיד

A ו-AAAA מצביעות לכתובות, CNAME מפנה subdomain ל-hostname אחר, MX לדואר, TXT לאימות ול-SPF/DKIM/DMARC, ו-CAA מגביל רשויות תעודה.

מניעת התנגשויות

  1. העתיקו במדויק את סוג הרשומה והיעד מדף השירות.
  2. אל תשתמשו ב-CNAME יחד עם רשומות אחרות על אותו hostname.
  3. שימו DKIM תחת selector שספק הדואר נתן ו-DMARC תחת _dmarc.
  4. שנו CAA בזהירות כי ערך שגוי עלול לחסום הנפקת תעודה.

שנו רשומה אחת בבירור

בעת תיקון, תעדו את הערך הישן, הערך החדש וזמן השינוי. זה מקל להבין תוצאות DNS מעורבות בזמן שה-cache פג.

> הפצת DNS ו-TTL

אין הבטחה קבועה לזמן הפצת DNS, כי TTL ו-cache מאפשרים לתשובות ישנות וחדשות להתקיים במקביל.
faq/dns-propagation-and-ttl

cache מסביר תוצאות שונות

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

שינוי DNS מסודר

  1. הנמיכו TTL לפני שינוי מתוכנן אם הספק מאפשר.
  2. בצעו את השינוי פעם אחת והימנעו מעריכות חוזרות בזמן ההמתנה.
  3. בדקו מכמה resolvers או רשתות כאשר התוצאות שונות.
  4. שלחו לתמיכה hostname, תשובה ישנה, תשובה צפויה, TTL וזמן שינוי.

אל תרדפו אחרי cache

עריכות חוזרות בזמן המתנה עלולות להאריך אבחון. המתינו ל-TTL הצפוי ואז בדקו מ-resolver אמין או מרשת אחרת.

> תכנון אחסון Nextcloud

תכננו אחסון עבור קבצי משתמשים, תיקיות משותפות, אשפה, גרסאות, previews, thumbnails וצמיחה צפויה.
faq/nextcloud-storage-planning

השימוש גדול מגודל הקבצים בלבד

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

מרווח צמיחה לאחסון

  1. העריכו את גודל הקבצים הנוכחי לפני ההזמנה.
  2. הוסיפו מרווח לאשפה, גרסאות, previews ו-thumbnails.
  3. בדקו שימוש עם הצוות לפני יבוא גדול.
  4. הגדילו אחסון לפני שמשתמשים מגיעים למגבלה.

השאירו מקום עבודה

סנכרון, previews והיסטוריית גרסאות צריכים מקום זמני וקבוע. אל תתכננו להשתמש ב-100% מהאחסון שהוקצה.

> העברת repositories ל-Gitea

תכננו מעבר ל-Gitea סביב Git LFS, submodules, protected branches/tags, deploy keys, tokens, webhooks ו-CI/CD.
faq/gitea-repository-migration

מעבר הוא יותר מהעתקת history

לפני המעבר מיפו בעלים, צוותים, Git LFS, submodules, protected branches, protected tags, remote URLs, webhooks, CI/CD, deploy keys ו-tokens ישנים. אל תחשפו ערכי tokens; סובבו או צרו אותם מחדש אחרי המעבר.

בדיקות לאחר המעבר

  1. בצעו export או mirror מהספק הישן.
  2. ודאו branches, tags וקבצי Git LFS.
  3. עדכנו remote URLs, webhooks, CI/CD ו-deploy keys.
  4. בדקו clone, push, Git LFS, submodules ו-CI לפני ביטול הגישה הישנה.

בדקו לפני סגירת המקור

לאחר המעבר, בדקו clone, push, CI וחשבונות צוות לפני ביטול הגישה לספק הישן או מחיקת המקור.

> בסיס דומיין שליחה ב-Listmonk

Listmonk צריך sender domain או subdomain, זהות From, רשומות SPF, DKIM, DMARC ובדיקות לפני קמפיין.
faq/listmonk-sender-domain-basics

זהות ורשומות משפרות מסירה

ניוזלטרים נמסרים טוב יותר כאשר זהות From ברורה ורשומות DNS נכונות. SPF מתפרסם במקום שספק הדואר דורש, DKIM עם selector, ו-DMARC תחת _dmarc.

לפני קמפיין ראשון

  1. בחרו דומיין או subdomain לשליחה.
  2. פרסמו רשומות אימות, SPF, DKIM ו-DMARC לפי ספק הדואר.
  3. שלחו הודעות בדיקה ובדקו bounce, Return-Path וקישורים.
  4. שמרו unsubscribe, List-Unsubscribe וזהות שולח מדויקים בלי לשתף סודות.

התחילו בשליחה ניסיונית

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

> הגדרות Runtime ב-Classic Hosting

Classic Hosting תומך במצב אוטומטי וידני עבור PHP, Node.js, Java, Python, .NET, Go, Ruby, Nginx, Apache ו-FrankenPHP.
faq/classic-hosting-runtime-settings

בחירה בין auto ל-manual

מצב auto מזהה ובונה פרויקטי PHP, Node.js, Java, Python, .NET, Go ו-Ruby. מצב manual מתאים לשליטה ב-Nginx, Apache או FrankenPHP. PHP selector חל רק כאשר ה-Runtime הנבחר תומך בו.

משאבי הרצה

  1. בחרו auto או manual לפי האפליקציה וה-framework.
  2. בחרו PHP 8.2, 8.3 או 8.4 רק כאשר יש תמיכה.
  3. הגדירו CPU, RAM, אחסון, backup retention ו-Offsite Archive retention.
  4. בדקו uploads, cache, logs ושגיאות גלויות אחרי הפריסה.

התאימו runtime לאפליקציה

בחרו auto כאשר רוצים זיהוי ובנייה, ובחרו manual כאשר השרת או גרסת PHP ידועים מראש. בדקו logs לאחר הפריסה הראשונה.

> מידע בטוח לשיתוף עם התמיכה

שתפו מספרי הזמנות, שמות שירותים, דומיינים, זמנים, שגיאות גלויות והגדרות hosting, אבל לא סודות.
faq/support-safe-information-to-share

הקשר גלוי מספיק לרוב

מידע בטוח כולל מספר הזמנה, שם שירות גלוי, דומיין, public host או port, Runtime, גרסת PHP, CPU, RAM, אחסון, backup retention, Offsite Archive retention, uploads, cache, logs, זמן הבעיה, screenshot מוסתר ושגיאה גלויה.

מה לא לשלוח

  1. אל תשלחו סיסמאות, מפתחות פרטיים, tokens או seed phrases.
  2. אל תשלחו logs מלאים עם סודות או database exports.
  3. הסתירו פרטים אישיים ו-sessions לפני screenshots.
  4. הימנעו משיתוף קבצי הגדרה לא מוסתרים או שמות וכתובות של תשתית פרטית.

הסתירו מה שלא נחוץ

לפני שליחת screenshot או log, הסתירו sessions, tokens ודוא״ל אישי. שתפו רק מידע שעוזר לזהות את השירות והשגיאה.