স্বয়ংক্রিয় 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

ধাপ ১: অফিসিয়াল রিপোজিটরি থেকে 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

ধাপ ২: প্রথম 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

ধাপ ৩: স্থানীয় অ্যাপ্লিকেশন রিভার্স প্রক্সি করুন

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
# }

ধাপ ৪: ফায়ারওয়াল ও 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/

ধাপ ৫: লগ, কম্প্রেশন ও হেডার

বট কোনো পথে আঘাত করলে বা 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

ধাপ ৬: 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 ব্যাকআপ করুন।