חזרה לבלוג
אוגוסט 19, 2026מדריכים

איך להתקין שרת ווב Caddy עם HTTPS אוטומטי

התקינו Caddy על Ubuntu מהמאגר הרשמי, כתבו Caddyfile לאתרים סטטיים ולפרוקסי הפוך, הבינו תעודות אוטומטיות, systemd, יומנים וטעויות נפוצות במעבר מ-Nginx.

איך להתקין שרת ווב Caddy עם HTTPS אוטומטי

Caddy הוא שרת ווב שמשיג ומחדש תעודות TLS כברירת מחדל. ל-VPS קטן שמארח דומיין או שניים זה מסיר מחלקה שלמה של טיימרי Certbot וקבצי קטעי Nginx. שפת ההגדרה (Caddyfile) קצרה. פרוקסי הפוך, gzip ו-HTTP/2 הם תכונות רגילות, לא סוף שבוע של מודולים נוספים.

Nginx עדיין הבחירה הנכונה לחלק מהצוותים: כבר יש לכם קונפיגורציות שנבחנו בקרב, או שצריך מודול מאוד ספציפי. המדריך הזה למקרה הנפוץ האחר — רוצים HTTPS שעובד על VPS טרי של Hiddence בלי לשנן קטעי include. נתקין Caddy ממאגר apt הרשמי, נסביר איך הוא מדבר עם Let's Encrypt, נגיש אתר סטטי, נעשה פרוקסי לאפליקציה מקומית, נארח כמה דומיינים, נסתכל ביומנים, ונכסה את קרבות פורט 80 הרגילים עם Apache או Nginx ישן.

מתי Caddy מתאים

HTTPS אוטומטי הוא הכותרת, אבל הרווח היומי הוא פחות חלקים נעים. Caddy מאזין על 80 ו-443, מפנה HTTP ל-HTTPS, ושומר תעודות בספריית הנתונים שלו. עדיין צריך דומיין שמצביע ל-VPS. עדיין צריך לא לשבור ACME (חומת אש 80/tcp, אין תהליך אחר שגונב :80). תעודות תו כלליות צריכות מודול ספק DNS — זה נתיב ארוך יותר מתעודת מארח יחיד.

  • HTTP→HTTPS אוטומטי וחידוש תעודות
  • Caddyfile קריא במקום בלוקי שרת ארוכים
  • פרוקסי הפוך מוכשר ל-Node, Python, PHP-FPM עם הגדרה נוספת, או backends של Docker
  • HTTP/2 ובררות מחדל TLS מודרניות בלי גיליון צפנים
  • יחידת systemd מחבילה רשמית

דרישות

דומיין חייב להיפתר ל-VPS הזה לפני ש-Caddy יכול להוכיח ACME HTTP-01. אם DNS עדיין מתפשט ההנפקה תיכשל ותנסה שוב; זה נראה כמו «Caddy שבור» כשזה רק DNS. עצרו Apache או Nginx קודם אם הם מחזיקים 80/443.

  • Ubuntu 22.04 או 24.04
  • רשומת A של דומיין לכתובת ה-IP של ה-VPS (ו-AAAA אם משתמשים ב-IPv6)
  • פורטים 80 ו-443 פנויים ומותרים בחומת האש
  • Root או sudo

שלב 1: התקינו Caddy מהמאגר הרשמי

אל תתקינו Caddy ישן אקראי מ-universe ברירת המחדל של Ubuntu אם רוצים התנהגות TLS ו-ACME עדכנית. פרויקט Caddy מתעד מקור apt. אחרי התקנה קיים משתמש caddy והשירות מופעל.

bash
ssh root@YOUR_VPS_IP
apt update && apt -y install debian-keyring debian-archive-keyring apt-transport-https curl gpg

curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | tee /etc/apt/sources.list.d/caddy-stable.list

apt update
apt -y install caddy

caddy version
systemctl status caddy --no-pager

שלב 2: Caddyfile ראשון — אתר סטטי

קובץ Caddyfile ברירת המחדל הוא /etc/caddy/Caddyfile. החליפו אותו בדומיין שלכם. Caddy ינסה להשיג תעודה ברגע שההגדרה נטענת אם שם המארח אינו localhost. שימו קבצי אתר בתיקייה שמשתמש caddy יכול לקרוא (לעיתים קרובות הרשאות בסגנון www-data, אבל החבילה משתמשת במשתמש caddy).

bash
mkdir -p /var/www/example
echo '<h1>It works</h1>' > /var/www/example/index.html
chown -R caddy:caddy /var/www/example

cat >/etc/caddy/Caddyfile <<'EOF'
example.com {
    root * /var/www/example
    file_server
    encode gzip
}
EOF

caddy validate --config /etc/caddy/Caddyfile
systemctl reload caddy

# Watch issuance:
journalctl -u caddy -f

שלב 3: פרוקסי הפוך לאפליקציה מקומית

אם Gunicorn, Node או Docker מאזינים על 127.0.0.1:8000, Caddy צריך להיות התהליך הציבורי היחיד. ההנחיה reverse_proxy מעבירה כותרות Host ו-X-Forwarded-* באופן סביר לרוב האפליקציות. אם האפליקציה מייצרת כתובות HTTP מוחלטות, הגדירו דגלי פרוקסי מהימן / HTTPS באפליקציה (Django SECURE_PROXY_SSL_HEADER, Express trust proxy וכן הלאה).

bash
app.example.com {
    encode gzip
    reverse_proxy 127.0.0.1:8000
}

# Several hosts in one file are normal:
# blog.example.com {
#     root * /var/www/blog
#     file_server
# }

שלב 4: חומת אש ו-systemd

אפשרו 80 ו-443. יחידת Caddy היא caddy.service; reload מספיק אחרי עריכות Caddyfile אם התהליך בריא. אם משנים משתני סביבה לתוסף DNS, הפעלה מחדש מלאה ברורה יותר. תעודות חיות תחת /var/lib/caddy/.local/share/caddy/ כברירת מחדל — כללו את הנתיב בגיבויים אם אכפת לכם ממגבלות קצב בהתקנה מחדש.

bash
ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

systemctl enable --now caddy
systemctl reload caddy

# Backup cert storage (path may vary slightly by version):
ls -la /var/lib/caddy/

שלב 5: יומנים, דחיסה וכותרות

יומני גישה עוזרים כשבוט דופק נתיב או כשמנפים 404. אפשר לרשום לכל אתר. הוסיפו כותרות אבטחה אם מארחים אפליקציית דפדפן; אל תעתיקו חבילת כותרות ענקית בלי להבין HSTS (אחרי שמגדירים max-age ארוך דפדפנים זוכרים).

bash
example.com {
    root * /var/www/example
    file_server
    encode gzip
    log {
        output file /var/log/caddy/example.log
    }
    header {
        X-Content-Type-Options nosniff
        Referrer-Policy no-referrer-when-downgrade
        -Server
    }
}

mkdir -p /var/log/caddy
chown caddy:caddy /var/log/caddy
systemctl reload caddy

שלב 6: PHP ותוספות אחרות

Caddy יכול לדבר עם PHP-FPM בהנחיית php_fastcgi. זה מספיק להרבה אירוח WordPress או Laravel, אבל עדיין צריך php-fpm מותקן ונתיב שקע שתואם. אם כבר יש קונפיגורציית PHP מושלמת של Nginx, מעבר בערב אחד אופציונלי — Caddy זורח יותר בפרוקסי הפוך + סטטי + TLS אוטומטי.

bash
example.com {
    root * /var/www/example
    php_fastcgi unix//run/php/php8.3-fpm.sock
    file_server
}

# Confirm FPM is running:
systemctl status php8.3-fpm

מעבר מ-Nginx בלי הפתעות השבתה

עצרו Nginx לפני הפעלת Caddy או שהם יילחמו על 80/443. הנמיכו TTL של DNS יום לפני אם גם מעבירים כתובות IP. בדקו עם curl --resolve כדי לפגוע ב-VPS החדש לפני החלפת רשומת A. שמרו קונפיגורציות Nginx ב-git לשבוע למקרה שצריך לחזור.

  • systemctl stop nginx && systemctl disable nginx
  • התקינו Caddy, אמתו Caddyfile, הפעילו Caddy
  • curl -I --resolve example.com:443:NEW_IP https://example.com
  • רק אז שנו DNS אם ה-IP חדש
  • הנפקה מחדש אוטומטית; אל תריצו גם Certbot נגד אותו שם מארח

פתרון בעיות

כשלי ACME כמעט תמיד DNS, חומת אש או שירות אחר על פורט 80. שורות יומן של Caddy מזכירות tls.obtain. אם האתר עובד ב-HTTP אבל לא ב-HTTPS, ההנפקה מעולם לא הושלמה. אם רואים יותר מדי תעודות פגעתם במגבלות קצב של Let's Encrypt — השתמשו ב-CA של staging בזמן בדיקה, לא ייצור.

  • validate נכשל: תחביר Caddyfile, סוגר חסר
  • permission denied על root: chown caddy לתיקיית האתר
  • bind: address already in use — ss -tulpn | grep -E ':80|:443'
  • פג תוקף תעודה: dig +short לדומיין מה-VPS, ufw allow 80
  • 502 reverse_proxy: backend למטה, או פרוקסי שגוי ל-localhost מרשת קונטיינר

הערות אבטחה

ברירות המחדל של TLS ב-Caddy שמרניות. העבודה שלכם היא אבטחת אפליקציה ו-SSH. אל תפעילו את API הניהול של Caddy בממשק ציבורי. נקודת הניהול המוגדרת כברירת מחדל מקומית; השאירו כך. אם משתמשים ב-Caddyfile מהאינטרנט קראו כל matcher — קטע שעושה reverse_proxy ל-/* אל IP פנימי יכול להפוך לפרוקסי פתוח.

  • אל תחשפו את API הניהול
  • שמרו על החבילה מעודכנת
  • HSTS רק אחרי שאתם בטוחים ש-HTTPS עובד לכל שמות המארח
  • הפרידו שמות מארח לבדיקה ולייצור כדי להגן על מגבלות קצב ACME

טיפים

  • caddy fmt --overwrite /etc/caddy/Caddyfile שומר על הקובץ קריא
  • השתמשו בקטעי import כשיש הרבה אתרים דומים
  • ל-Docker תמונת caddy:alpine עם Caddyfile מעוגן נפוצה
  • תעודות תו כלליות צריכות מודול DNS ואסימון API — הגנו על האסימון
  • קראו journalctl -u caddy לפני שמשכתבים את כל הקובץ

Caddy על VPS הוא: חבילה רשמית, Caddyfile קצר, פורטים 80/443 פתוחים, DNS שכבר מצביע לשרת, ו-systemd reload אחרי עריכות. השתמשו בו כשרת קבצים סטטי או כפרוקסי הפוך מול Gunicorn, Node או Docker. HTTPS אוטומטי עובד כש-ACME יכול לענות על פורט 80; אם ההנפקה נכשלת תקנו DNS והתנגשויות פורטים לפני שמאשימים את Caddy. גבו את /var/lib/caddy אם מתקינים מחדש לעיתים קרובות.