یونا پشت میز آموزش Caddy در آکادمی ویونیکس، کنار نمایشگر پیکربندی و سرور خصوصی؛ تصویر آموزشی ساخته‌شده.

WIUNIX ACADEMY

راه‌اندازی Caddy و HTTPS خودکار، قدم‌به‌قدم

نسخهٔ لینوکس خودت را انتخاب کن؛ Caddy را نصب کن، برنامه را پشت reverse proxy قرار بده و HTTPS را با دستورهای قابل کپی و بررسی نتیجهٔ هر مرحله راه بینداز.

متوسط18 دقیقه مطالعهبه‌روزرسانی
محیطت را انتخاب کن

آموزش متناسب با محیط تو

کجا اجرا می‌کنی؟

سیستم‌عامل و نسخه را انتخاب کن تا مراحل، دستورها و راه‌حل‌ها برای همان محیط نمایش داده شوند.

Debian 12بررسی‌شده با مستندات رسمی ·

از اینجا شروع کن

در پایان چه چیزی خواهی داشت؟

در پایان، دامنهٔ واقعی تو با HTTPS و گواهی خودکار به Caddy وصل می‌شود و درخواست‌ها به برنامه‌ای روی آدرس داخلی سرور می‌رسند. مسیر بررسی تنظیمات، بارگذاری بدون توقف و تشخیص خطا را هم خواهی داشت.

01بازدیدکنندهدامنهٔ واقعی با HTTPS
02Caddyگواهی و ورودی عمومی
03برنامهٔ تو127.0.0.1:8080 · خصوصی
سیستم‌عامل‌ها و نسخه‌های پوشش‌داده‌شده

مسیر نصب بسته برای Ubuntu نسخه‌های ۲۶٫۱۰، ۲۶٫۰۴، ۲۴٫۰۴ و ۲۲٫۰۴ و Debian نسخه‌های ۱۳ و ۱۲ مشترک است. در Fedora 44، مخزن و راه‌اندازی اولیهٔ سرویس فرق دارد. تنظیمات مشترک یک‌بار نوشته شده‌اند و فقط بخش‌های متفاوت تغییر می‌کنند. این آموزش برای سرور لینوکسی با systemd است؛ Windows، macOS، WSL و کانتینر بدون systemd را پوشش نمی‌دهد.

قبل از شروع

  • سرور لینوکسی مطابق یکی از محیط‌های موجود، همراه systemd و دسترسی sudo.
  • دامنه‌ای که تنظیمات DNS آن در اختیار تو باشد، دسترسی اینترنت و امکان مدیریت مسیر پورت‌های TCP 80 و 443.
  • اگر سرور از قبل سایت دارد، نسخهٔ پشتیبان تنظیمات و یک اتصال مدیریتی جداگانه.
01

قدم بعدی

سرور و دامنه را آماده کن

ابتدا روی سرور آزمایشی یا سروری کار کن که تنظیمات وب‌سرورش را می‌شناسی. روش این آموزش بر پایهٔ نصب بسته و مدیریت سرویس با systemd است؛ صرف داشتن ترمینال لینوکس، برای یکسان بودن مراحل کافی نیست.

دستورهای زیر فقط محیط را بررسی می‌کنند. مقدارهای ID و VERSION_ID باید با انتخاب بالای صفحه هماهنگ باشند. خروجی ps هم باید نشان بدهد پردازش شمارهٔ یک systemd است.

یک زیردامنهٔ واقعی انتخاب کن. app.example.com در این آموزش نمونه است و باید در فایل تنظیمات و دستورهای بررسی با دامنهٔ خودت جایگزین شود. رکورد A را به IPv4 سرور بده؛ رکورد AAAA را فقط وقتی نگه دار که IPv6 آن واقعاً به همین سرور برسد.

Bash

ترمینال سرور · کاربر عادی

cat /etc/os-release
uname -m
ps -p 1 -o comm=
command -v systemctl
از کجا بدانم درست انجام شد؟

توزیع، نسخه و معماری سرور مشخص شده، systemd فعال است و دامنه‌ای داری که می‌توانی DNS آن را تنظیم کنی.

02

قدم بعدی

Caddy را از مخزن معرفی‌شده نصب کن

دستورها کلید امضای مخزن را دریافت می‌کنند، آن را در فایل جداگانه قرار می‌دهند و منبع بستهٔ پایدار Caddy را اضافه می‌کنند. Python فقط برای برنامهٔ نمونهٔ مرحلهٔ بعد نصب می‌شود.

قبل از تأیید عملیات apt، فهرست تغییرات را بخوان. بستهٔ Debian و Ubuntu سرویس Caddy را خودکار راه می‌اندازد. اگر Nginx یا سرویس دیگری پورت 80 یا 443 را گرفته باشد، ممکن است بسته نصب شود ولی سرویس اجرا نشود؛ ابتدا مشخص کن کدام سرویس باید ورودی وب را مدیریت کند.

نسخه‌ای را که caddy version نشان می‌دهد در یادداشت استقرار ثبت کن. چون مخزن پایدار به‌روز می‌شود، شمارهٔ patch ثابت وعده نمی‌دهیم. برای ارتقای بعدی، یادداشت انتشار همان نسخه را بررسی کن.

Bash

ترمینال سرور · نیازمند دسترسی sudo

sudo apt update
sudo apt install debian-keyring debian-archive-keyring apt-transport-https curl gnupg python3
curl -1sLf https://dl.cloudsmith.io/public/caddy/stable/gpg.key -o /tmp/caddy-stable.asc
sudo gpg --dearmor --yes -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg /tmp/caddy-stable.asc
curl -1sLf https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy
caddy version
از کجا بدانم درست انجام شد؟

نصب بسته بدون خطا تمام می‌شود و caddy version شمارهٔ نسخه را نشان می‌دهد. سالم بودن سرویس و مسیر عمومی را در مراحل بعد بررسی می‌کنی.

03

قدم بعدی

یک برنامهٔ نمونه روی آدرس داخلی اجرا کن

در ترمینال دوم، پوشهٔ خالی جداگانه بساز و وب‌سرور سادهٔ Python را فقط روی loopback اجرا کن. ورودی عمومی را Caddy مدیریت می‌کند؛ پورت برنامهٔ پشت آن نباید روی همهٔ رابط‌های شبکه باز شود.

این ترمینال را باز نگه دار. وب‌سرور توسعهٔ Python فقط برای دیدن نتیجهٔ آموزش است. برای استفادهٔ واقعی باید برنامهٔ خودت را با مدیریت سرویس مناسب جایگزین کنی.

Bash

ترمینال دوم سرور · کاربر عادی · باز بماند

mkdir -p ~/academy-caddy-demo
cd ~/academy-caddy-demo
printf '%s\n' 'WIUNIX Academy: backend is reachable' > index.html
python3 -m http.server 8080 --bind 127.0.0.1
از کجا بدانم درست انجام شد؟

Python روی 127.0.0.1:8080 گوش می‌دهد. در ترمینال اول، اجرای curl http://127.0.0.1:8080/ پیام WIUNIX Academy را برمی‌گرداند.

04

قدم بعدی

فایل reverse proxy را بنویس

ابتدا با sudo cp -a /etc/caddy/Caddyfile /etc/caddy/Caddyfile.academy-before یک نسخه از فایل موجود نگه دار. اگر سایت‌های دیگری در فایل هستند، بخش تازه را به آن‌ها اضافه کن و تنظیماتشان را حذف نکن.

فایل را با sudoedit /etc/caddy/Caddyfile باز کن. محتوای زیر را داخل فایل بگذار و app.example.com را با دامنهٔ واقعی عوض کن. این بلوک، محتوای فایل است؛ دستور قابل اجرا در ترمینال نیست.

نام دامنه، مسیر HTTPS خودکار را فعال می‌کند و reverse_proxy درخواست‌ها را به برنامهٔ داخلی می‌فرستد. log هم ثبت درخواست را فعال می‌کند. در این نصب، لاگ سرویس را در journald بررسی می‌کنیم. چون لاگ می‌تواند نشانی کاربر و مسیر درخواست داشته باشد، نگهداری آن و پارامترهای حساس URL را آگاهانه مدیریت کن.

Caddyfile · /etc/caddy/Caddyfile

محتوای فایل · ویرایش با sudoedit /etc/caddy/Caddyfile

app.example.com {
    reverse_proxy 127.0.0.1:8080
    log
}
از کجا بدانم درست انجام شد؟

دامنهٔ واقعی و آدرس داخلی برنامه در فایل قرار دارند، example.com باقی نمانده و سایت‌های قبلی حفظ شده‌اند.

05

قدم بعدی

تنظیمات را بررسی و بارگذاری کن

قبل از اعمال تغییر، همان فایل را با caddy validate بررسی کن. این بررسی از مرتب بودن ظاهر فایل فراتر می‌رود و می‌تواند خطاهای آماده‌سازی تنظیمات را پیدا کند.

عملگر && باعث می‌شود reload فقط پس از موفق بودن بررسی اجرا شود. بعد، وضعیت سرویس و پیام‌های تازه را بخوان. اگر بررسی خطا داد، ابتدا همان خطا را اصلاح کن؛ راه‌اندازی مجدد پی‌درپی، تنظیمات اشتباه را درست نمی‌کند.

Bash

ترمینال اول سرور · برای بررسی، بارگذاری و لاگ از sudo استفاده می‌شود

sudo caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile && sudo systemctl reload caddy
systemctl is-active caddy
sudo journalctl -u caddy --since '5 minutes ago' --no-pager
خروجی نمونه
Valid configuration
active
از کجا بدانم درست انجام شد؟

تنظیمات معتبرند، وضعیت سرویس active است و خطای حل‌نشده‌ای دربارهٔ فایل یا اشغال بودن پورت نمی‌بینی. خروجی پایین نمونه است؛ زمان‌ها و پیام‌های اضافی ممکن است فرق کنند.

06

قدم بعدی

HTTPS را از یک دستگاه دیگر بررسی کن

صدور گواهی به DNS درست و دسترسی به مسیر تأیید دامنه نیاز دارد. برای روش سادهٔ این آموزش، TCP 80 و 443 باید در فایروال سرور، تنظیمات ارائه‌دهنده و مسیر NAT به Caddy برسند. دسترسی SSH را حفظ کن و پورت 8080 را عمومی نکن. بررسی UDP 443 و HTTP/3 موضوع این مرحله نیست.

از مدیر فایروال موجود استفاده کن. برای دیدن وضعیت UFW، دستور sudo ufw status verbose و برای firewalld، دستور sudo firewall-cmd --list-all کاربرد دارند. فقط سیاست فعال و درست را تغییر بده؛ برای عبور از خطا، فایروال را خاموش یا قوانین را پاک نکن.

روی دستگاهی دیگر، دامنه را در دستورهای زیر جایگزین کن. استفاده نکردن از -k مهم است؛ باید اعتبار گواهی واقعاً بررسی شود. هدایت HTTP و پاسخ صحیح برنامه روی HTTPS، دو بخش متفاوت مسیر را تأیید می‌کنند.

Bash

دستگاهی دیگر با اینترنت · دامنهٔ نمونه را عوض کن

curl -I http://app.example.com/
curl -v https://app.example.com/
خروجی نمونه
HTTP/1.1 308 Permanent Redirect
Location: https://app.example.com/

WIUNIX Academy: backend is reachable
از کجا بدانم درست انجام شد؟

HTTP به HTTPS همان دامنه هدایت می‌شود، گواهی معتبر است و متن برنامهٔ نمونه برمی‌گردد. مرورگر هم بدون هشدار گواهی صفحه را باز می‌کند. جزئیات header و نسخهٔ پروتکل ممکن است متفاوت باشند.

خطاهای رایج را از لایهٔ درست پیدا کن

به‌ترتیب DNS، اتصال عمومی، گواهی، reverse proxy و برنامه را بررسی کن. فعال بودن یک پردازش به‌تنهایی نشان نمی‌دهد کاربر بیرون شبکه می‌تواند سایت را باز کند.

پورت 80 یا 443 در اختیار سرویس دیگری است

با دیدن پردازش صاحب پورت، مشخص کن ورودی وب باید دست کدام سرویس باشد. قبل از تغییر، سایت‌های موجود را حفظ کن.

Bash
sudo ss -lntp
گواهی صادر نمی‌شود

A و AAAA را از بیرون سرور، همراه فایروال میزبان، ارائه‌دهنده و NAT بررسی کن. موفق بودن IPv4، سالم بودن IPv6 را ثابت نمی‌کند. خطاهای journal و محدودیت CAA را هم ببین؛ درخواست اجباری پی‌درپی ممکن است به محدودیت مرجع صدور برسد.

HTTPS باز می‌شود ولی خطای 502 می‌بینی

مسیر کاربر تا Caddy برقرار است، اما برنامهٔ پشت آن پاسخ مناسب نمی‌دهد. باز بودن ترمینال Python، پورت loopback و پاسخ مستقیم برنامه را بررسی کن.

Bash
curl -v http://127.0.0.1:8080/
sudo journalctl -u caddy -n 50 --no-pager
داخل سرور کار می‌کند ولی از اینترنت باز نمی‌شود

اتصال محلی، مسیر ورودی را تأیید نمی‌کند. از شبکه‌ای دیگر DNS، فایروال‌ها و NAT را بررسی کن. اگر CDN در مسیر است، دسترسی به origin را از مسیر CDN جدا بررسی کن.

برای نگهداری و بازیابی آماده باش

قبل از استفادهٔ واقعی، Python را با برنامهٔ تحت مدیریت سرویس جایگزین کن؛ ابتدا loopback و سپس مسیر عمومی را دوباره بررسی کن. محدود بودن به loopback به معنی داشتن احراز هویت برنامه نیست.

پوشهٔ دادهٔ سرویس، مالکیت فایل‌ها، کلید حساب و وضعیت تمدید گواهی را در پشتیبان‌گیری محافظت‌شده پوشش بده. Caddyfile به‌تنهایی نسخهٔ پشتیبان کامل نیست. مسیر دقیق را از unit نصب‌شده و مستندات سرویس بردار و وضعیت را بی‌برنامه بین کاربران جابه‌جا نکن.

تمدید خودکار ادامه‌دار است؛ DNS و مسیر تأیید باید درست بمانند. انقضای گواهی و خطاهای سرویس را پایش کن و برای تغییر فایل، از بررسی و سپس reload استفاده کن. پایان این آموزش به تمدید اجباری دستی نیاز ندارد.

اگر CDN یا proxy دیگری قبل از Caddy داری، trusted_proxies را فقط با محدوده‌های تأییدشده تنظیم کن. به header ارسالی دلخواه کاربر اعتماد نکن. اضافه کردن health check برای چند backend هم به endpoint آمادگی واقعی و تصمیم روشن دربارهٔ خرابی نیاز دارد.

  • مسیر موردنیاز تمدید گواهی را قابل دسترس نگه دار.
  • از تنظیمات و دادهٔ سرویس پشتیبان محافظت‌شده بگیر.
  • ارتقای بسته را قبل از محیط اصلی بررسی کن.
  • پاسخ HTTPS عمومی را همراه وضعیت پردازش پایش کن.

به تنظیمات قبلی برگرد

اگر تغییر تازه مشکل ایجاد کرد، فایل ذخیره‌شده را برگردان، اعتبارش را بررسی کن و فقط بعد از موفقیت، reload انجام بده. این کار تنظیمات را برمی‌گرداند؛ دادهٔ برنامه را بازیابی نمی‌کند.

Python را با Ctrl+C در ترمینال دوم متوقف کن. دستورهای زیر گواهی، مخزن یا دادهٔ کاربر را حذف نمی‌کنند. اگر دیگر به سرویس تازه نیاز نداری، بعد از اطمینان از اینکه سایت دیگری ندارد، توقفش را جداگانه بررسی کن.

Bash

ترمینال سرور · ابتدا مطمئن شو فایل ذخیره‌شده همان نسخهٔ درست است

sudo cp -a /etc/caddy/Caddyfile.academy-before /etc/caddy/Caddyfile
sudo caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile && sudo systemctl reload caddy
از کجا بدانم درست انجام شد؟

تنظیمات معتبر قبلی دوباره فعال‌اند، برنامهٔ نمونه متوقف شده و تغییرهای عمدی DNS یا فایروال هم بررسی شده‌اند.

حالا چه چیزی ساخته‌ای؟

اکنون مرز مشخصی بین ورودی عمومی HTTPS و برنامهٔ خصوصی داری؛ می‌دانی تغییر را چطور بررسی و بارگذاری کنی و خطای گواهی را از خطای برنامه تشخیص بدهی.

قدم بعدی را متناسب با برنامه انتخاب کن: مدیریت سرویس، پایش محافظت‌شده، پشتیبان‌گیری قابل بازیابی و تنظیم درست proxyهای مورد اعتماد. چند backend و بررسی سلامت آن‌ها یک مرحلهٔ طراحی جداگانه است.

پشتوانهٔ این آموزش

منابع رسمی

وضعیت بررسی هر محیط بالای صفحه مشخص است؛ بررسی مستندات به معنی اجرای عملی همهٔ نسخه‌ها نیست.

همهٔ آموزش‌های آکادمی ↗