Reverse proxy 80 və 443 portlarında bütün veb trafiki qəbul edir və hər sorğunu serverdəki uyğun tətbiqə ötürür. Caddy yaxşı seçimdir, çünki HTTPS sertifikatlarını özü alır və yeniləyir: hər sayt üçün reverse_proxy localhost:3000 kimi bir sətir kifayətdir.
Bu bələdçi Caddy-ni Ubuntu 24.04 və ya Debian 12-yə quraşdırır və konfiqurasiyanı addım-addım qurur.
Niyə önə proxy qoymalı
- Vahid giriş nöqtəsi. Bir serverdə bir neçə tətbiq, hər biri öz domenində və ya yolunda.
- HTTPS bir yerdə. Tətbiqlər localhost-da adi HTTP ilə danışır, TLS-i Caddy idarə edir.
- Təhlükəsizlik. Tətbiqlər heç vaxt public portlarda dinləmir. Proxy-də başlıqlar, sorğu limitləri və ya parol əlavə edə bilərsiniz.
- Çeviklik. Tətbiqi başqa porta və ya serverə köçürün və bir sətri dəyişin.
1. İlkin şərtlər
- İlk addımları tamamlanmış server.
- Hər domen üçün serverə yönəlmiş DNS qeydləri (IPv4 üçün A, IPv6 üçün AAAA).
- Açıq 80 və 443 portları:
sudo ufw allow 80,443/tcp
sudo ufw allow 443/udp # HTTP/3
İstifadə edirsinizsə, eyni portları bulud firewall-ınızda da açın.
2. Caddy-ni quraşdırın
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | \
sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | \
sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install -y caddy
systemctl status caddy
Paket Caddy-ni systemd xidməti kimi işə salır, konfiqurasiya /etc/caddy/Caddyfile faylındadır.
3. Ən kiçik faydalı Caddyfile
Tutaq ki, tətbiq localhost:3000 ünvanında dinləyir. Faylın məzmununu bununla əvəz edin:
app.example.com {
reverse_proxy localhost:3000
}
Yoxlayın və yenidən yükləyin:
sudo caddy fmt --overwrite /etc/caddy/Caddyfile
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy
İlk sorğuda Caddy sertifikat alır, HTTP-ni HTTPS-ə yönləndirir və tətbiqi təqdim edir. Vəssalam.
4. Bir serverdə bir neçə tətbiq
Hər sayt üçün bir blok əlavə edin:
app.example.com {
reverse_proxy localhost:3000
}
api.example.com {
reverse_proxy localhost:8080
}
status.example.com {
reverse_proxy localhost:3001
}
Və ya bir domeni yollar üzrə bölün:
example.com {
handle_path /api/* {
reverse_proxy localhost:8080
}
handle {
root * /var/www/site
file_server
}
}
handle_path ötürməzdən əvvəl /api prefiksini kəsir; backend prefiksi gözləyirsə, handle istifadə edin.
5. Snippet ilə faydalı standart ayarlar
Snippet-lər təkrarlanan ayarları bir yerdə saxlayır:
(common) {
encode zstd gzip
header {
Strict-Transport-Security "max-age=31536000; includeSubDomains"
X-Content-Type-Options "nosniff"
Referrer-Policy "strict-origin-when-cross-origin"
-Server
}
log {
output file /var/log/caddy/access.log {
roll_size 50MiB
roll_keep 5
}
}
}
app.example.com {
import common
reverse_proxy localhost:3000
}
Log qovluğunu bir dəfə yaradın: sudo mkdir -p /var/log/caddy && sudo chown caddy:caddy /var/log/caddy.
6. İdarəetmə alətini parolla qoruyun
Parol hash-i yaradın:
caddy hash-password
Onu sayt blokunda istifadə edin:
admin.example.com {
basic_auth {
alice <paste-hash-here>
}
reverse_proxy localhost:9000
}
Caddy-nin köhnə versiyalarında bu direktiv basicauth kimi yazılır. Həssas olan hər şey üçün girişi ünvana görə də məhdudlaşdırın:
admin.example.com {
@outside not remote_ip 198.51.100.0/24
respond @outside 403
reverse_proxy localhost:9000
}
Bu diapazon nümunədir. Oraya ofisinizin və ya VPN-inizin diapazonunu yazın; WireGuard bələdçisi ilə bu, VPN alt şəbəkəniz ola bilər.
7. Docker konteynerlərinə proxy
Caddy host-da işləyirsə, konteynerləri localhost-a bağlayın ki, public olmasınlar:
services:
app:
image: ghcr.io/example/app:1.0
ports:
- "127.0.0.1:3000:3000"
Caddy Docker-də işləyirsə, onu eyni Compose layihəsinə yerləşdirin və servis adlarına proxy edin (reverse_proxy app:3000). Docker Compose bələdçisi tam stack-i göstərir.
8. Bir neçə backend arasında yük balanslaşdırma
Caddy sorğuları eyni serverdə və ya şəxsi şəbəkə üzərindən digər serverlərdə olan bir neçə tətbiq nüsxəsi arasında paylaya bilər:
app.example.com {
reverse_proxy 10.0.0.11:3000 10.0.0.12:3000 {
lb_policy least_conn
health_uri /healthz
health_interval 10s
}
}
Ünvanlar şəxsi diapazondan nümunələrdir. Balanslaşdırmanı serverlərinizdən kənarda istəyirsinizsə, idarə olunan yük balanslaşdırıcısı eyni işi health check-lərlə görür və public IP-si olmayan serverlərə də çata bilir.
9. WebSocket-lər və real müştəri IP-ləri
WebSocket-lər reverse_proxy vasitəsilə əlavə ayar olmadan işləyir. Caddy backend-ə X-Forwarded-For, X-Forwarded-Proto və X-Forwarded-Host başlıqlarını göndərir; tətbiqinizi onlara yalnız 127.0.0.1 ünvanından etibar edəcək şəkildə konfiqurasiya edin.
Caddy özü başqa proxy və ya yük balanslaşdırıcısının arxasındadırsa, ona hansı ünvanlara etibar edəcəyini bildirin:
{
servers {
trusted_proxies static 10.0.0.0/24
}
}
Bu qlobal blok Caddyfile-ın ən yuxarısına yazılır.
10. Loglar və problemlərin həlli
journalctl -u caddy --since "10 min ago"
sudo tail -f /var/log/caddy/access.log
curl -I https://app.example.com
Tez-tez rast gəlinən problemlər:
| Problem | Həll |
|---|---|
| Sertifikat verilmir | DNS bu serverə yönəlməlidir; 80/443 portları UFW-də və bulud firewall-ında açıq olmalıdır |
502 Bad Gateway |
Backend işləmir və ya başqa portda dinləyir: ss -tlnp |
| Yönləndirmə dövrəsi | Tətbiq də HTTPS-ə yönləndirir; bunu Caddy-yə həvalə edin və X-Forwarded-Proto başlığına etibar edin |
| Dəyişikliklər nəzərə alınmır | systemctl reload caddy işlədin və caddy validate çıxışını yoxlayın |
Sertifikat verən mərkəzlər təkrarlanan uğursuz cəhdləri məhdudlaşdırır, ona görə də dəfələrlə yenidən cəhd etməzdən əvvəl DNS-i düzəldin.
Yönləndirmələr və əsas domen
Əksər saytlar bir adla cavab verməli, digərlərini isə yönləndirməlidir. www-ni əsas domenə yönləndirin:
www.example.com {
redir https://example.com{uri} permanent
}
example.com {
reverse_proxy localhost:3000
}
Caddy hər iki ad üçün sertifikat alır. Əsas ünvan kimi www üstünlük verirsinizsə, onların yerini dəyişin.
Sorğu limitləri və sorğu ölçüsü
Caddy nüvəsini kiçik saxlayır, ona görə də sorğu limitləri üçün plugin lazımdır. Əksər kiçik saytlar üçün access log üzərində Fail2ban və ya tətbiqdəki limit kifayətdir. Sorğu gövdəsinin ölçüsünü məhdudlaşdırmaq isə daxili imkandır:
app.example.com {
request_body {
max_size 20MB
}
reverse_proxy localhost:3000
}
Bu, həddən artıq böyük yükləmələri tətbiqinizə çatmazdan əvvəl dayandırır.
Tətbiqin yanında statik fayllar
Resursları birbaşa diskdən təqdim etmək onları tətbiqdən keçirməkdən daha sürətlidir:
app.example.com {
handle /static/* {
root * /var/www/app
file_server
header Cache-Control "public, max-age=604800"
}
handle {
reverse_proxy localhost:3000
}
}
11. Sertifikatlar harada saxlanılır
Caddy sertifikatları və açarları /var/lib/caddy/.local/share/caddy altında saxlayır. Bərpadan sonra hər şeyi yenidən almamaq üçün bu yolu ehtiyat nüsxələrə daxil edin; bununla belə, qovluq olmasa, Caddy sadəcə yeni sertifikatlar alacaq.
Növbəti addımlar
Önündə Caddy olduqda bir serverdə çoxlu tətbiq yerləşdirə bilərsiniz. Tipik növbəti addımlar WordPress, Docker stack və ya self-hosting bölməsindən öz serverinizdə işləyən alətdir. Təhlükəsizlik əsaslarını və ehtiyat nüsxələri unutmayın.
Tez-tez verilən suallar
Caddy HTTPS sertifikatlarını həqiqətən avtomatik alırmı?
Bəli. Caddyfile-dakı sayt ünvanı serverə yönəlmiş public domen olduqda və 80 və 443 portları əlçatan olduqda Caddy sertifikatları açıq ACME mərkəzindən özü alır və yeniləyir.
Caddy production üçün kifayət qədər sürətlidirmi?
Bəli. Tipik veb tətbiqlərdə reverse proxy nadir hallarda darboğaz olur, Caddy isə HTTP/2 və HTTP/3-ü hazır şəkildə dəstəkləyir.
Caddy Docker-dəki tətbiqlərə proxy edə bilərmi?
Bəli. Caddy-ni eyni Compose şəbəkəsində işlədin və servis adlarından istifadə edin, ya da konteynerləri 127.0.0.1-ə bağlayıb localhost portlarına proxy edin.
Caddy, yoxsa Nginx?
Caddy daha az konfiqurasiya tələb edir və sertifikatları özü idarə edir. Nginx-in isə nümunələr və modullardan ibarət daha geniş ekosistemi var. Hər ikisi etibarlı seçimdir.
Caddy niyə sertifikat ala bilmir?
Adətən DNS hələ serverə yönəlmir və ya 80 və ya 443 portu firewall tərəfindən bağlanıb. Hər ikisini yoxlayın, sonra journalctl -u caddy çıxışına baxın.