Nginx dhidi ya Caddy dhidi ya Traefik: ipi bora?

Nginx dhidi ya Caddy dhidi ya Traefik: jibu fupi

Nginx, Caddy na Traefik zote hufanya kazi sawa kama reverse proxy: husikiliza kwenye port 443, husoma hostname katika kila ombi, na kuliwasilisha kwa huduma sahihi kwenye VPS yako. Yoyote kati ya hizo tatu itaweka programu nne zilizojiendesha (self-hosted) nyuma ya anwani moja ya IP ya umma, na zote zina kasi ya kutosha kiasi kwamba programu zako ndizo zitakuwa sehemu ya polepole. Kinachotofautiana ni jinsi kila moja inavyopata cheti cha TLS (transport layer security) na gharama ya usanidi kwa kila programu ya ziada. Tofauti nyingine hujitokeza baadaye, siku utakapohitaji kitu ambacho mafunzo ya kawaida hayakielezei.

Chagua Caddy ikiwa unataka HTTPS ishughulikiwe kwa ajili yako na huduma zako ni programu za kawaida za wavuti. Chagua Traefik ikiwa kila kitu kinaendeshwa kwenye Docker Compose na unaongeza huduma mpya kila baada ya wiki chache. Chagua Nginx ikiwa tayari unaitumia, au ikiwa unahitaji response caching, client certificates, raw TCP forwarding, au usanidi mkubwa uliopo ambao ungependelea usiuandike upya.

Kila moja hupataje cheti cha TLS?

Mhimili huu ndio huamua kwa watu wengi, kwa hivyo anza hapa. Zote tatu huishia kuwa na cheti kilekile kutoka kwa mamlaka ileile. Kazi unayofanya ili kufika hapo si sawa.

Caddy huomba cheti kwa sababu umetaja hostname. Andika app.example.com kama anwani ya tovuti na Caddy huomba cheti kupitia ACME (automatic certificate management environment) kutoka Let's Encrypt, ikishindwa hutumia ZeroSSL, hutoa redirect ya HTTP kwenda HTTPS kwenye port 80, na hujihuisha yenyewe. Hakuna zana ya pili wala kipima muda cha kukagua. Vyeti hukaa kwenye saraka ya data ya mtumiaji wa caddy, /var/lib/caddy/.local/share/caddy wakati wa usakinishaji wa kifurushi, kwa hivyo ongeza njia hiyo kwenye backups zako au ukubali utoaji mpya baada ya ujenzi upya. Kwa hostname isiyo ya umma, tls internal hutia saini kwa kutumia mamlaka ya cheti cha ndani ya Caddy badala yake. Hiyo hukupa kitu kilekile kama kuunda cheti kilichotiwa saini na wewe mwenyewe kwenye Ubuntu, huku uhuishaji ukishughulikiwa kwa ajili yako.

Nginx haina mteja wa ACME. Certbot hupata cheti, na plugin yake ya --nginx huandika upya server block yako ili kuongeza msikilizaji wa 443 na redirect. Uhuishaji huendeshwa kutoka kwa systemd timer ambayo kifurushi husakinisha, kwa hivyo kuna sehemu mbili zinazohamia na vitu viwili vya kuthibitisha: systemctl list-timers | grep certbot huonyesha kuwa timer ipo, na sudo certbot renew --dry-run huthibitisha kuwa njia ya uhuishaji bado inafanya kazi. Hatua kwa hatua iko kwenye Certbot kwenye Ubuntu 24.04 na Nginx, na zana hiyo hiyo inashughulikia cheti cha wildcard kupitia changamoto ya DNS-01 unapokuwa na subdomain nyingi kuliko unazotaka kuorodhesha.

Traefik hubeba mteja wake wa ACME. Unasanidi resolver moja ya cheti katika usanidi tuli, na kila router inaweza kuitumia. Hali yote, ufunguo wa akaunti na vyeti vikiwemo, hukaa kwenye faili moja ya acme.json. Traefik hukataa kutumia faili hiyo ikiwa inaweza kusomwa na mtu yeyote isipokuwa mmiliki wake, na hukuambia hivyo kabla ya kuacha resolver:

The ACME resolver "le" is skipped from the resolvers list because: unable to get ACME account: permissions 660 for /letsencrypt/acme.json are too open, please use 600

Mount saraka na uiruhusu Traefik iunde faili yenyewe. Iunde kwanza kwa touch na itarithi umask yako, ambayo ndiyo njia ambayo watu wengi hukutana na mstari huo.

Jambo moja ni kweli kwa zote tatu. Changamoto ya HTTP-01 inahitaji port 80 iweze kufikiwa kutoka kwenye Internet, kwa sababu mamlaka ya cheti huunganisha nyuma kwake. Fungua 443 pekee na utoaji utashindwa kwa njia inayoonekana kama kosa la DNS.

Kazi ileile ya routing ya programu mbili katika usanidi tatu

Kazi yenyewe: app.example.com inaelekea kwenye huduma iliyo kwenye 127.0.0.1:8080, files.example.com inaelekea kwenye huduma iliyo kwenye 127.0.0.1:8081, zote zikipitia HTTPS. Hapa kuna kila kitu katika kila proxy, ili tofauti ya ukubwa wa usanidi ionekane badala ya kusimuliwa tu.

Nginx

# /etc/nginx/sites-available/app.example.com
server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Kisha iunganishe, ifanyie majaribio, i-reload, na uongeze cheti.

sudo ln -s /etc/nginx/sites-available/app.example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
sudo certbot --nginx -d app.example.com

nginx -t inayochapisha syntax is ok na test is successful ndiyo ukaguzi wa kufanya kabla ya kila reload. Programu ya pili ni kizuizi kilekile chenye hostname na port iliyobadilishwa. Mistari ya proxy_set_header si mapambo: wakati proxy_pass inapotaja anwani, nginx hutuma Host: 127.0.0.1:8080 kwenda upstream kwa chaguo-msingi, kwa hivyo programu inayounda URL kamili kutoka kwa Host header itawapeleka watumiaji wako kwenye localhost. Kazi ya kila moja ya headers hizo nne, na kwa nini slash ya mwisho kwenye proxy_pass hubadilisha kimya kimya njia inayopokelewa na programu yako, imefafanuliwa kwa kila directive katika mwongozo huu wa nginx server block.

Caddy

app.example.com {
	reverse_proxy 127.0.0.1:8080
}

files.example.com {
	reverse_proxy 127.0.0.1:8081
}

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

Hiyo ndiyo faili nzima. reverse_proxy hujiwekea X-Forwarded-For, X-Forwarded-Proto na X-Forwarded-Host yenyewe, na kwa chaguo-msingi hupuuza chochote ambacho mteja alituma kwenye headers hizo, kwa hivyo ombi haliwezi kudanganya backend yako kuhusu mahali lilipotoka. Vyeti, redirect ya port 80 na ufanyaji upya (renewal) vyote hufuata kutoka kwa anwani mbili za tovuti. Hakuna kitu kingine kwenye faili kinachoviomba.

Traefik

Traefik inahitaji usanidi tuli (static configuration) kabla ya kuelekeza chochote. Kama huduma ya Compose, ikiwa na image tag ya sasa kufikia Agosti 2026:

services:
  traefik:
    image: traefik:v3.7
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.le.acme.email=you@example.com"
      - "--certificatesresolvers.le.acme.storage=/letsencrypt/acme.json"
      - "--certificatesresolvers.le.acme.httpchallenge.entrypoint=web"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./letsencrypt:/letsencrypt

Kila programu hubeba routing yake yenyewe, kwenye labels, katika faili yake ya compose:

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.app.rule=Host(`app.example.com`)"
      - "traefik.http.routers.app.entrypoints=websecure"
      - "traefik.http.routers.app.tls.certresolver=le"
      - "traefik.http.services.app.loadbalancer.server.port=8080"

loadbalancer.server.port ni port iliyo ndani ya container, si port iliyochapishwa (published), kwa sababu Traefik hufikia container kupitia mtandao wa Docker ulioshirikiwa. Programu haihitaji mstari wa ports: hata kidogo, na hiyo ndiyo faida halisi: ni Traefik pekee iliyochapishwa. Ujenzi kamili, ikijumuisha mtandao ulioshirikiwa na redirect middleware, uko katika routing ya programu nyingi kwa kutumia Traefik na Docker Compose.

Kila programu ya ziada inagharimu usanidi kiasi gani?

[
  {
    "tool": "Nginx",
    "proxy_setup_lines": 0,
    "lines_per_app": 11
  },
  {
    "tool": "Caddy",
    "proxy_setup_lines": 0,
    "lines_per_app": 3
  },
  {
    "tool": "Traefik",
    "proxy_setup_lines": 17,
    "lines_per_app": 5
  }
]

Imehesabiwa kutoka kwa vizuizi vilivyo hapo juu. Kizuizi cha seva ya Nginx kina mistari 11 isiyo tupu, na unaiandika tena kwa kila hostname. Kizuizi cha tovuti cha Caddy kina mistari 3. Traefik inahitaji mistari 17 ya usanidi tuli kabla ya kuhudumia ombi lolote, kisha lebo 5 kwa kila programu.

Tathmini uwiano, si mshindi. Traefik inagharimu zaidi kabla ya programu ya kwanza na kidogo zaidi kwa kila programu inayofuata, na jumla zote mbili hukutana karibu na tovuti ya tatu. Chini ya hapo, usanidi tuli ni mzigo usio wa lazima. Zaidi ya hapo, lebo huchukua nafasi ya mbele na kuendelea kuongoza, kwa sababu uelekezaji (routing) upo karibu na huduma inayoelekezwa. Futa huduma na uelekezaji wake utafutika, jambo ambalo faili kuu ya usanidi hushindwa kufanya: vizuizi vya seva vilivyopitwa na wakati kwa programu ambazo ziliacha kuwepo miezi iliyopita.

Idadi ya mistari pia huipendelea Nginx. Kila kizuizi kati ya hivyo kinahitaji symlink, nginx -t, reload na uendeshaji wa certbot, wakati marekebisho ya Caddy yanahitaji reload moja na marekebisho ya Traefik hayahitaji amri yoyote. Zote tatu hufanya reload bila kukata miunganisho inayotumika. Tofauti ni idadi ya hatua tofauti unazopaswa kukumbuka saa tisa usiku.

Ni nani anayefahamu kuhusu container zako?

Traefik hufuatilia Docker socket na kujenga routers kutoka kwa labels za container kadiri container zinavyoanza na kusimama. Hakuna kingine hapa kinachofanya hivyo. Nginx na Caddy vyote vinahitaji marekebisho ya configuration na reload wakati container mpya inapoonekana, na vinahitaji anwani inayoweza kufikika: aidha port iliyochapishwa kwenye loopback, au Docker network iliyoshirikiwa ambayo proxy imeunganishwa nayo.

Kipengele hicho kina gharama, na ni vyema kusema wazi. Traefik husoma /var/run/docker.sock. Mtu yeyote anayeweza kuwasiliana na socket hiyo anaweza kuanzisha container yenye host filesystem iliyopachikwa ndani yake, jambo ambalo ni root kwenye host. Kuipachika kwa hali ya read-only hupunguza hatari bila kuiondoa kabisa. Ikiwa hilo ni muhimu kwa threat model yako, weka socket proxy katikati ambayo hufichua tu endpoints za orodha ya container ambazo Traefik inahitaji.

Caddy inaweza kufanya ugunduzi wa msingi wa labels kupitia plugin ya jamii, lakini plugins za Caddy huunganishwa wakati wa compilation, kwa hivyo unajenga binary maalum au image maalum ukitumia xcaddy na kisha unawajibika kwa build hiyo na masasisho yake. Kwa huduma tatu au nne, kuhariri Caddyfile ni kazi ndogo zaidi.

Websockets na utiririshaji: nini kinaharibika, na kwa nini

Nginx ndiyo inayohitaji msaada. Muunganisho wa WebSocket huanza kama ombi la HTTP lenye Upgrade: websocket, na nginx haipitishi hop-by-hop headers kwenda upstream isipokuwa kama utaiagiza kufanya hivyo.

# /etc/nginx/conf.d/upgrade-map.conf
map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

Kisha, ndani ya block ya location, kuna mistari mitatu ambayo lazima yote iwepo:

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

Ukiiondoa, console ya kivinjari itaonyesha WebSocket connection to 'wss://app.example.com/ws' failed wakati log ya backend yako ikionyesha GET ya kawaida. map ipo kwa sababu Connection: upgrade iliyowekwa kwa kudumu ingetumwa kwenye kila ombi, ikiwemo yale ya kawaida ambayo yanapaswa kusema close.

Default nyingine mbili za Nginx huleta shida. proxy_read_timeout ni sekunde 60 na inahusu tunnel baada ya upgrade, kwa hivyo websocket isiyo na traffic kwa dakika moja hufungwa na proxy. Na server-sent events hufika kwa kuchelewa au kwa vipindi hadi utakapoweka proxy_buffering off; kwenye location hiyo, kwa sababu nginx hushikilia majibu kwenye buffer yake wakati ukurasa wako unasubiri.

Caddy hufanya upgrade na kubadilisha muunganisho kuwa tunnel ya njia mbili bila maelekezo yoyote ya ziada. Pia hutoa data mara moja wakati jibu ni text/event-stream au halina urefu unaojulikana, kwa hivyo utiririshaji hufanya kazi bila kubadilishwa. Traefik hupitisha upgrades na haifanyi buffering ya majibu isipokuwa kama utaongeza middleware yake ya buffering mwenyewe. Ikiwa huduma zako zinajumuisha chat, terminal ya wavuti, log tails au dashibodi za moja kwa moja, hiyo ni tofauti kubwa katika kiasi cha usanidi utakachoandika na kutatua.

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 80;
    server_name app.example.com;
    client_max_body_size 64m;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_read_timeout 3600s;
        proxy_buffering off;
    }
}

Nini hutokea unapohitaji kitu kisicho cha kawaida?

Hapa ndipo Nginx inapothibitisha thamani ya usanidi wake wa ziada.

• Vyeti vya mteja (Client certificates), vinavyojulikana pia kama mTLS (mutual TLS), ambapo mteja lazima awasilishe cheti pia. Nginx inahitaji ssl_client_certificate /etc/ssl/ca.pem; na ssl_verify_client on; katika server block. Caddy inahitaji block ya client_auth ndani ya tls. Lebo za Traefik haziwezi kuelezea hili kabisa: unafafanua chaguo la TLS katika file provider na kuelekeza router kwalo kwa kutumia traefik.http.routers.app.tls.options=mtls@file. Mfumo wa kuweka kila kitu kwenye lebo hupata ubaguzi mara ya kwanza unapohitaji hili.
• Upakiaji mkubwa wa faili (Large uploads). Nginx huzuia miili ya maombi (request bodies) kwa 1 MB kwa chaguomsingi. Upakiaji mkubwa zaidi hurejesha 413 Request Entity Too Large, na logi ya makosa husema client intended to send too large body. Ongeza client_max_body_size. Caddy na Traefik hazina kikomo cha mwili kwa chaguomsingi, kwa hivyo ombi hufika kwenye programu yako na kikomo cha programu yako ndicho huamua.
• Caching ya majibu (Response caching). Nginx ina proxy_cache, na ni thabiti. Caddy inahitaji plugin iliyokusanywa (compiled in). Toleo la chanzo huria la Traefik halina HTTP cache kabisa, jambo ambalo huwashangaza watu wanaodhani kila proxy hufanya caching.
• Raw TCP au UDP, kwa ajili ya port ya database au seva ya mchezo. Nginx ina moduli ya stream. Traefik ina routers za TCP na UDP kwenye entrypoints zake. Caddy inahitaji plugin nyingine, kwa hivyo inahitaji toleo jingine maalum (custom build).
• Seva ya wavuti iliyo nyuma ya proxy. Ikiwa huduma ni programu ya kawaida ya PHP, basi LAMP stack kwenye Ubuntu 24.04 tayari inajumuisha Apache, na kuweka proxy mbele yake kunakupa sehemu mbili zinazoweka headers na mbili zinazoweza kubadilisha URL. Amua ni ipi itakayomalizia TLS (terminate TLS), kisha iache nyingine kwenye HTTP ya kawaida iliyofungwa kwenye loopback.

Mtego wa firewall unaofuata chaguo hili

Lengo la reverse proxy ni kuhakikisha kuwa port 80 na 443 pekee ndizo zilizo wazi. Docker hupindua hali hiyo kimyakimya. Kuchapisha port kwa kutumia -p 8080:80 huandika sheria ya DNAT kwenye jedwali la nat, na sheria hiyo hutathminiwa kabla ya sheria za INPUT zinazosimamiwa na ufw, kwa hivyo ufw deny 8080 haizuii muunganisho huo na programu yako inakuwa wazi kwenye Internet kando ya proxy uliyoisanidi kwa uangalifu. Funga (bind) port zilizochapishwa kwenye loopback kwa kutumia 127.0.0.1:8080:80, au acha kabisa kutumia ports: na uiruhusu proxy ifikie container kupitia Docker network, jambo ambalo ndilo mfano wa Traefik hapo juu unafanya. Utaratibu huu na suluhisho lake viko kwenye kwa nini port zilizochapishwa na Docker hupita ufw.

Jaribu hili kutoka kwa mashine ambayo siyo ile VPS, kwa sababu ukaguzi unaofanywa ndani ya seva hiyo hiyo utafaulu kila wakati:

curl --max-time 5 http://your.server.address:8080

Connection refused au timeout ndiyo matokeo unayotaka. Jibu la HTTP linamaanisha kuwa programu hiyo inafikika bila kupitia proxy yako, na kila kitu ulichosanidi hapo juu ni mapambo tu.

Ni proxy ipi unapaswa kuchagua?

Tovuti nyingi za static, pamoja na programu moja au mbili: Caddy. HTTPS ya kiotomatiki huondoa kazi kubwa zaidi ya mara kwa mara uliyo nayo. Usanidi hubaki mfupi kiasi cha kusomeka kwenye skrini moja, na tovuti ya static ni mstari wa root na mstari wa file_server ndani ya block moja ya tovuti. Gharama yake ni kuwa na idadi ndogo ya majibu ya kunakili na kubandika (copy-paste) wakati kitu kisicho cha kawaida kinapoharibika.

Homelab ya docker-compose unayoendelea kuiongezea huduma: Traefik. Baada ya huduma ya tatu, labels huchukua kazi kidogo kuliko kuhariri faili kuu, na huduma ikifutwa huondoa njia yake (route) yenyewe. Tenga mchana mzima kwa ajili ya usanidi wa kwanza, kwa sababu entrypoints, routers, services na middlewares ni msamiati mpya. Kosa la kuandika (typo) kwenye label kwa kawaida huonekana kama 404 kutoka kwa Traefik badala ya kushindwa kuanza, kwa hivyo soma docker logs traefik ili kuona kosa la uchanganuzi (parse error) kabla ya kudhani kuwa programu imevunjika.

Usanidi wa Nginx uliopo, au hitaji lolote kutoka kwenye orodha hapo juu: Nginx. Tayari ina jibu kwa ajili ya caching ya majibu na vyeti vya mteja (client certificates), na karibu kila mwongozo wa watu wengine huichukulia kama msingi. Gharama yake ni kwamba vyeti na usaidizi wa websocket ni vitu unavyosanidi badala ya vitu unavyopata moja kwa moja.

Kanuni moja inatumika bila kujali unachochagua. Mchakato mmoja tu ndio husikiliza kwenye interface ya umma, na kila kitu kingine husikiliza kwenye loopback au kwenye mtandao wa kibinafsi wa Docker.

FAQ

Ni reverse proxy ipi iliyo bora kwa programu chache za Docker kwenye VPS moja?

Kwa huduma tatu au nne unazoongeza mara kwa mara, Traefik inafaa zaidi kwa sababu kila programu hubeba lebo zake za routing na haihitaji kuhariri faili kuu ya usanidi. Ikiwa huduma ni thabiti na unataka tu HTTPS isikuletee shida, Caddy ni rahisi kujifunza na haiharibiki haraka. Chagua Nginx ikiwa tayari unaijua, au unapohitaji kipengele ambacho vingine havina, kama vile response caching au TCP listener ya kawaida.

Je, Caddy haihitaji usanidi wowote wa cheti?

Kwa matumizi ya kawaida, ndiyo. Kutaja hostname ya umma kama anwani ya tovuti ndio usanidi mzima: Caddy huomba cheti kupitia ACME, hutoa redirect kutoka port 80, na kusasisha cheti kabla ya muda wake kuisha. Mambo mawili lazima yawe kweli. Port 80 lazima iweze kufikiwa kutoka Internet kwa ajili ya HTTP-01 challenge, na DNS A au AAAA record ya hostname lazima ielekeze kwenye VPS, kwa sababu mamlaka ya vyeti hutatua jina hilo na kuunganisha nyuma kwenye seva hiyo.

Je, ninaweza kuendesha Nginx na Traefik kwenye VPS moja?

Huwezi kutumia port zilezile. Yoyote itakayoanza ya pili itashindwa kufunga port, na Nginx itatoa bind() to 0.0.0.0:443 failed (98: Address already in use) wakati Traefik itatoa hitilafu kama hiyo ya bind na kusimama. Endesha proxy moja kwenye 80 na 443, na uweke huduma nyingine zote nyuma yake. Ikiwa unahama, hamisha hostname moja baada ya nyingine: ruhusu proxy ya mbele ipeleke maombi kwenye proxy ya zamani kupitia port ya loopback hadi tovuti ya mwisho itakapohamia.

Kwa nini websockets zangu hukatika baada ya sekunde 60 zikiwa nyuma ya Nginx?

proxy_read_timeout ina muda chaguo-msingi wa sekunde 60 na inatumika kwenye tunnel pindi upgrade inapokamilika, kwa hivyo muunganisho usio na trafiki kwa dakika moja hufungwa na proxy badala ya programu yako. Ongeza muda huo kwenye location husika kwa kutumia proxy_read_timeout 3600s;, au fanya programu itume ping frame kila baada ya sekunde 30. Caddy na Traefik hazifungi miunganisho iliyoboreshwa (upgraded connections) kwa kipima muda cha dakika moja, ndiyo maana programu hiyo hiyo inaweza kuonekana thabiti nyuma yao na isiyo thabiti nyuma ya Nginx.