स्वचालित HTTPS के साथ Caddy वेब सर्वर कैसे इंस्टॉल करें

Caddy वेब सर्वर है जो डिफ़ॉल्ट रूप से TLS प्रमाणपत्र प्राप्त और नवीनीकृत करता है। एक-दो डोमेन होस्ट करने वाले छोटे VPS के लिए यह Certbot टाइमर और Nginx स्निपेट फ़ाइलों का पूरा वर्ग हटा देता है। कॉन्फ़िगरेशन भाषा (Caddyfile) छोटी है। रिवर्स प्रॉक्सी, gzip, और HTTP/2 सामान्य सुविधाएँ हैं, अतिरिक्त मॉड्यूल का सप्ताहांत नहीं।

कुछ दुकानों के लिए Nginx अभी सही चुनाव है: युद्ध-परीक्षित कॉन्फ़िग पहले से हैं, या बहुत विशिष्ट मॉड्यूल चाहिए। यह गाइड दूसरे आम मामले के लिए है — include स्निपेट याद किए बिना ताज़ा Hiddence VPS पर काम करने वाला HTTPS चाहिए। हम आधिकारिक apt रेपो से Caddy इंस्टॉल करेंगे, समझाएँगे कि यह Let's Encrypt से कैसे बात करता है, स्थिर साइट सर्व करेंगे, स्थानीय ऐप प्रॉक्सी करेंगे, कई डोमेन होस्ट करेंगे, लॉग देखेंगे, और Apache या पुराने Nginx के साथ आम पोर्ट-80 झगड़े कवर करेंगे।

Caddy कब अच्छा फिट है

स्वचालित HTTPS शीर्षक है, लेकिन रोज़ की जीत कम चलने वाले हिस्से हैं। Caddy 80 और 443 पर सुनता है, HTTP को HTTPS पर रीडायरेक्ट करता है, और प्रमाणपत्र अपने डेटा निर्देशिका में रखता है। अभी भी VPS की ओर इंगित डोमेन चाहिए। अभी भी ACME नहीं तोड़ना चाहिए (फ़ायरवॉल 80/tcp, :80 चुराने वाली दूसरी प्रक्रिया नहीं)। वाइल्डकार्ड प्रमाणपत्र को DNS प्रदाता मॉड्यूल चाहिए — यह एकल-होस्ट प्रमाणपत्र से लंबा पथ है।

• स्वचालित HTTP→HTTPS और प्रमाणपत्र नवीनीकरण
• लंबे सर्वर ब्लॉक की जगह पठनीय Caddyfile
• Node, Python, अतिरिक्त कॉन्फ़िग से PHP-FPM, या Docker बैकएंड के लिए सक्षम रिवर्स प्रॉक्सी
• साइफ़र स्प्रेडशीट के बिना HTTP/2 और आधुनिक TLS डिफ़ॉल्ट
• आधिकारिक पैकेज से systemd यूनिट

आवश्यकताएँ

Caddy ACME HTTP-01 साबित करने से पहले डोमेन इस VPS पर resolve होना चाहिए। DNS अभी फैल रहा हो तो Caddy जारी करना विफल होगा और फिर कोशिश करेगा; यह ‘Caddy टूटा’ दिखता है जबकि केवल DNS है। 80/443 उनके पास हो तो पहले Apache या Nginx रोकें।

• Ubuntu 22.04 या 24.04
• VPS IP पर डोमेन A रिकॉर्ड (IPv6 इस्तेमाल करें तो AAAA भी)
• पोर्ट 80 और 443 खाली और फ़ायरवॉल में अनुमति प्राप्त
• Root या sudo

चरण 1: आधिकारिक रिपॉजिटरी से Caddy इंस्टॉल करें

वर्तमान TLS और ACME व्यवहार चाहिए तो डिफ़ॉल्ट Ubuntu universe से यादृच्छिक पुराना Caddy इंस्टॉल न करें। Caddy प्रोजेक्ट apt स्रोत दस्तावेज़ करता है। इंस्टॉल के बाद caddy उपयोगकर्ता मौजूद होता है और सेवा सक्षम होती है।

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 है। अपने डोमेन से बदलें। होस्टनाम localhost न हो तो कॉन्फ़िग लोड होते ही Caddy प्रमाणपत्र लेने की कोशिश करेगा। साइट फ़ाइलें caddy उपयोगकर्ता द्वारा पठनीय निर्देशिका में रखें (अक्सर www-data-शैली अनुमति, लेकिन पैकेज उपयोगकर्ता caddy इस्तेमाल करता है)।

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 URL जनरेट करे तो ऐप में विश्वसनीय प्रॉक्सी / HTTPS फ़्लैग सेट करें (Django SECURE_PROXY_SSL_HEADER, Express trust proxy, इत्यादि)।

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 है; प्रक्रिया स्वस्थ हो तो Caddyfile संपादन के बाद reload काफ़ी है। DNS प्लगइन के लिए पर्यावरण चर बदलें तो पूरा रीस्टार्ट साफ है। प्रमाणपत्र डिफ़ॉल्ट रूप से /var/lib/caddy/.local/share/caddy/ के नीचे रहते हैं — रीइंस्टॉल के दौरान दर सीमा की चिंता हो तो वह पथ बैकअप में शामिल करें।

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 सेट करने पर ब्राउज़र याद रखते हैं)।

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_fastcgi निर्देश से PHP-FPM से बात कर सकता है। कई WordPress या Laravel होस्ट के लिए काफ़ी है, लेकिन अभी भी php-fpm इंस्टॉल होना चाहिए और सॉकेट पथ मेल खाना चाहिए। पहले से परिपूर्ण Nginx PHP कॉन्फ़िग हो तो एक शाम में माइग्रेट करना वैकल्पिक है — Caddy रिवर्स प्रॉक्सी + स्थिर + स्वचालित TLS पर अधिक चमकता है।

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 से माइग्रेट करना

Caddy शुरू करने से पहले Nginx रोकें वरना वे 80/443 के लिए लड़ेंगे। IP भी स्थानांतरित कर रहे हों तो एक दिन पहले DNS TTL घटाएँ। A रिकॉर्ड बदलने से पहले नए VPS पर मारने के लिए curl --resolve से जाँचें। रोल बैक चाहिए तो Nginx कॉन्फ़िग एक सप्ताह git में रखें।

• systemctl stop nginx && systemctl disable nginx
• Caddy इंस्टॉल करें, Caddyfile सत्यापित करें, Caddy शुरू करें
• curl -I --resolve example.com:443:NEW_IP https://example.com
• IP नया हो तभी DNS बदलें
• पुनर्जारी स्वचालित है; उसी होस्टनाम के विरुद्ध Certbot भी न चलाएँ

समस्या निवारण

ACME विफलताएँ लगभग हमेशा DNS, फ़ायरवॉल, या पोर्ट 80 पर दूसरी सेवा हैं। Caddy लॉग पंक्तियाँ tls.obtain का उल्लेख करती हैं। साइट HTTP पर काम करे HTTPS पर नहीं तो जारी करना कभी पूरा नहीं हुआ। बहुत प्रमाणपत्र दिखें तो Let's Encrypt दर सीमा लगी — परीक्षण करते समय उत्पादन नहीं स्टेजिंग CA इस्तेमाल करें।

• validate विफल: Caddyfile सिंटैक्स, गायब ब्रेस
• root पर permission denied: साइट निर्देशिका के लिए chown caddy
• bind: address already in use — ss -tulpn | grep -E ':80|:443'
• प्रमाणपत्र टाइमआउट: VPS से डोमेन का dig +short, ufw allow 80
• 502 reverse_proxy: बैकएंड डाउन, या कंटेनर नेटवर्क से localhost पर गलत प्रॉक्सी

सुरक्षा नोट

Caddy के TLS डिफ़ॉल्ट रूढ़िवादी हैं। आपका काम एप्लिकेशन सुरक्षा और SSH है। सार्वजनिक इंटरफ़ेस पर Caddy एडमिन API चालू न करें। डिफ़ॉल्ट एडमिन एंडपॉइंट स्थानीय है; वैसा ही छोड़ें। इंटरनेट से Caddyfile इस्तेमाल करें तो हर मैचर पढ़ें — /* को आंतरिक IP पर reverse_proxy करने वाला स्निपेट खुला प्रॉक्सी बन सकता है।

• एडमिन API उजागर न करें
• पैकेज अपडेट रखें
• HSTS केवल तब जब सभी होस्टनाम के लिए HTTPS काम करे
• ACME दर सीमा बचाने के लिए परीक्षण और उत्पादन होस्टनाम अलग करें

सुझाव

• caddy fmt --overwrite /etc/caddy/Caddyfile फ़ाइल पठनीय रखता है
• कई समान साइटें हों तो import स्निपेट इस्तेमाल करें
• Docker के लिए माउंटेड Caddyfile वाली caddy:alpine इमेज आम है
• वाइल्डकार्ड प्रमाणपत्र को DNS मॉड्यूल और API टोकन चाहिए — उस टोकन की रक्षा करें
• पूरी फ़ाइल फिर लिखने से पहले journalctl -u caddy पढ़ें

VPS पर Caddy है: आधिकारिक पैकेज, छोटा Caddyfile, खुले पोर्ट 80/443, पहले से सर्वर की ओर इंगित DNS, और संपादन के बाद systemd reload। स्थिर फ़ाइल सर्वर या Gunicorn, Node, या Docker के आगे रिवर्स प्रॉक्सी के रूप में इस्तेमाल करें। स्वचालित HTTPS तब काम करता है जब ACME पोर्ट 80 पर उत्तर दे सके; जारी करना विफल हो तो Caddy को दोष देने से पहले DNS और पोर्ट संघर्ष ठीक करें। अक्सर रीइंस्टॉल करें तो /var/lib/caddy बैकअप करें।