Nginx, Caddy, Traefik: మీ సర్వర్ కోసం ఏది ఉత్తమం?

Nginx vs Caddy vs Traefik: క్లుప్త సమాధానం

Nginx, Caddy మరియు Traefik అన్నీ reverse proxy గా ఒకే పనిని చేస్తాయి: port 443 పై వినడం, ప్రతి అభ్యర్థనలోని hostname ను చదవడం మరియు దానిని మీ VPS లోని సరైన సేవకు పంపడం. ఈ మూడింటిలో ఏది వాడినా నాలుగు self-hosted అప్లికేషన్లను ఒకే public IP అడ్రస్ వెనుక ఉంచవచ్చు. ఇవన్నీ చాలా వేగంగా పనిచేస్తాయి, కాబట్టి మీ అప్లికేషన్లే నెమ్మదిగా ఉండే అవకాశం ఉంది. వీటి మధ్య ప్రధాన వ్యత్యాసం ఏమిటంటే, ప్రతి ఒక్కటి TLS (transport layer security) సర్టిఫికేట్‌ను ఎలా పొందుతుంది మరియు ప్రతి అదనపు అప్లికేషన్ కోసం ఎంత కాన్ఫిగరేషన్ అవసరమవుతుంది అనేది. మరొక వ్యత్యాసం ఏమిటంటే, సాధారణ ట్యుటోరియల్స్‌లో లేని ప్రత్యేక అవసరాలు వచ్చినప్పుడు వీటి పనితీరు మారుతుంది.

మీకు HTTPS ఆటోమేటిక్‌గా జరగాలి మరియు మీ సేవలు సాధారణ web apps అయితే Caddy ని ఎంచుకోండి. అన్నీ Docker Compose లో నడుస్తుంటే మరియు మీరు ప్రతి కొన్ని వారాలకు ఒక కొత్త సేవను జోడిస్తుంటే Traefik ని ఎంచుకోండి. మీరు ఇప్పటికే Nginx వాడుతుంటే, లేదా మీకు response caching, client certificates, raw TCP forwarding అవసరమైతే, లేదా ఇప్పటికే ఉన్న పెద్ద కాన్ఫిగరేషన్‌ను తిరిగి రాయకూడదు అనుకుంటే Nginx ని ఎంచుకోండి.

ప్రతి ఒక్కటి TLS సర్టిఫికేట్‌ను ఎలా పొందుతాయి?

చాలామందికి ఈ అంశమే నిర్ణయాత్మకమైనది, కాబట్టి ఇక్కడి నుంచే ప్రారంభించండి. ఈ మూడూ కూడా ఒకే సర్టిఫికేషన్ అథారిటీ నుండి ఒకే రకమైన సర్టిఫికేట్‌ను పొందుతాయి. కానీ, ఆ సర్టిఫికేట్ పొందడానికి చేసే పని విధానం వేరుగా ఉంటుంది.

Caddy మీరు ఒక hostname ను పేర్కొన్నందున సర్టిఫికేట్ కోసం అభ్యర్థిస్తుంది. app.example.com ను సైట్ అడ్రస్‌గా రాస్తే, Caddy ACME (automatic certificate management environment) ద్వారా Let's Encrypt నుండి సర్టిఫికేట్‌ను అభ్యర్థిస్తుంది. ఒకవేళ అది విఫలమైతే ZeroSSL కి మారుతుంది, పోర్ట్ 80 పై HTTP నుండి HTTPS కి రీడైరెక్ట్‌ను అందిస్తుంది మరియు స్వయంచాలకంగా రెన్యూవల్ చేస్తుంది. దీని కోసం రెండవ సాధనం లేదా తనిఖీ చేయడానికి టైమర్ అవసరం లేదు. సర్టిఫికేట్లు caddy యూజర్ యొక్క డేటా డైరెక్టరీలో ఉంటాయి, ప్యాకేజీ ఇన్‌స్టాలేషన్‌లో ఇది /var/lib/caddy/.local/share/caddy వద్ద ఉంటుంది, కాబట్టి ఆ పాత్‌ను మీ బ్యాకప్‌లలో చేర్చండి లేదా రీబిల్డ్ తర్వాత కొత్తగా ఇష్యూ చేయడాన్ని అంగీకరించండి. పబ్లిక్ కాని hostname కోసం, tls internal Caddy యొక్క స్వంత లోకల్ సర్టిఫికేట్ అథారిటీతో సైన్ చేస్తుంది. ఇది Ubuntu పై self-signed సర్టిఫికేట్ సృష్టించడం ద్వారా పొందే ఫలితాన్నే ఇస్తుంది, కానీ రెన్యూవల్ బాధ్యత Caddy చూసుకుంటుంది.

Nginx లో ACME క్లయింట్ ఉండదు. Certbot సర్టిఫికేట్‌ను పొందుతుంది, మరియు దాని --nginx ప్లగిన్ మీ సర్వర్ బ్లాక్‌ను రీరైట్ చేసి 443 లిజనర్‌ను మరియు రీడైరెక్ట్‌ను జోడిస్తుంది. ప్యాకేజీ ఇన్‌స్టాల్ చేసే systemd టైమర్ ద్వారా రెన్యూవల్ జరుగుతుంది, కాబట్టి ఇక్కడ రెండు భాగాలు ఉంటాయి మరియు రెండింటినీ సరిచూసుకోవాలి: systemctl list-timers | grep certbot టైమర్ ఉందో లేదో చూపిస్తుంది, మరియు sudo certbot renew --dry-run రెన్యూవల్ పాత్ పనిచేస్తుందో లేదో నిర్ధారిస్తుంది. దీనికి సంబంధించిన దశల వారీ సమాచారం Ubuntu 24.04 లో Nginx తో Certbot లో ఉంది, మరియు మీరు లిస్ట్ చేయాలనుకున్న దానికంటే ఎక్కువ సబ్‌డొమైన్‌లు ఉన్నప్పుడు DNS-01 ఛాలెంజ్ ద్వారా వైల్డ్‌కార్డ్ సర్టిఫికేట్ పొందడానికి కూడా ఇదే సాధనం ఉపయోగపడుతుంది.

Traefik తన స్వంత ACME క్లయింట్‌ను కలిగి ఉంటుంది. మీరు స్టాటిక్ కాన్ఫిగరేషన్‌లో ఒక సర్టిఫికేట్ రిజాల్వర్‌ను కాన్ఫిగర్ చేస్తే, ప్రతి రూటర్ దానిని ఉపయోగించుకోవచ్చు. అకౌంట్ కీ మరియు సర్టిఫికేట్‌లతో సహా మొత్తం స్టేట్, ఒకే acme.json ఫైల్‌లో ఉంటుంది. ఆ ఫైల్‌ను దాని యజమాని తప్ప మరెవరైనా చదవగలిగితే Traefik దానిని ఉపయోగించడానికి నిరాకరిస్తుంది, మరియు రిజాల్వర్‌ను డ్రాప్ చేసే ముందు మీకు ఈ విధంగా తెలియజేస్తుంది:

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

ఒక డైరెక్టరీని మౌంట్ చేసి, Traefik నేరుగా ఆ ఫైల్‌ను సృష్టించేలా చేయండి. మీరు ముందుగా touch తో దానిని సృష్టిస్తే, అది మీ umask ను పొందుతుంది, చాలామంది ఈ సమస్యను ఎదుర్కోవడానికి ఇదే కారణం.

ఈ మూడింటికి ఒక విషయం వర్తిస్తుంది. HTTP-01 ఛాలెంజ్ కోసం ఇంటర్నెట్ నుండి పోర్ట్ 80 అందుబాటులో ఉండాలి, ఎందుకంటే సర్టిఫికేట్ అథారిటీ తిరిగి దానికే కనెక్ట్ అవుతుంది. కేవలం 443 ని మాత్రమే ఓపెన్ చేస్తే, జారీ ప్రక్రియ విఫలమవుతుంది మరియు అది DNS లోపంలా కనిపిస్తుంది.

మూడు రకాల కాన్ఫిగరేషన్లలో ఒకే రెండు-యాప్ రూటింగ్ పని

పని: app.example.com ఒక సర్వీసుకి 127.0.0.1:8080 ద్వారా, files.example.com మరొక సర్వీసుకి 127.0.0.1:8081 ద్వారా వెళ్లాలి, రెండూ HTTPS ద్వారానే జరగాలి. ప్రతి ప్రాక్సీలో పూర్తి అమరిక ఇక్కడ ఉంది, దీనివల్ల మాటలతో చెప్పేదానికంటే ఆచరణలో ఉండే వ్యత్యాసం స్పష్టంగా కనిపిస్తుంది.

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

ఆ తర్వాత దానిని లింక్ చేయండి, పరీక్షించండి, రీలోడ్ చేయండి మరియు సర్టిఫికేట్‌ను జోడించండి.

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 ద్వారా syntax is ok మరియు test is successful ప్రింట్ చేయడం అనేది ప్రతి రీలోడ్‌కు ముందు చేయాల్సిన తనిఖీ. రెండవ యాప్ కూడా ఇదే బ్లాక్, కానీ హోస్ట్‌నేమ్ మరియు పోర్ట్ మారుతాయి. proxy_set_header లైన్లు కేవలం అలంకరణ కోసం కావు: proxy_pass ఒక అడ్రస్‌ను పేర్కొన్నప్పుడు, Nginx డిఫాల్ట్‌గా Host: 127.0.0.1:8080 ను అప్‌స్ట్రీమ్‌కు పంపుతుంది. కాబట్టి Host హెడర్ నుండి అబ్సల్యూట్ URLలను నిర్మించే యాప్, మీ వినియోగదారులను localhost కి పంపుతుంది. ఆ నాలుగు హెడర్లు దేనికి ఉపయోగపడతాయి, మరియు proxy_pass చివరన ఉండే స్లాష్ (trailing slash) మీ యాప్‌కు అందే పాత్‌ను ఎలా మారుస్తుందో, Nginx సర్వర్ బ్లాక్ యొక్క ఈ వివరణలో ప్రతి డైరెక్టివ్ వారీగా చర్చించబడింది.

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

ఇది మొత్తం ఫైల్. reverse_proxy స్వయంగా X-Forwarded-For, X-Forwarded-Proto మరియు X-Forwarded-Host లను సెట్ చేస్తుంది. డిఫాల్ట్‌గా ఇది క్లయింట్ పంపిన హెడర్లను పట్టించుకోదు, కాబట్టి ఒక అభ్యర్థన తన మూలం గురించి బ్యాకెండ్‌ను తప్పుదోవ పట్టించలేదు. సర్టిఫికేట్లు, పోర్ట్ 80 రీడైరెక్ట్ మరియు రెన్యూవల్ అన్నీ ఆ రెండు సైట్ అడ్రసుల నుండే అమలవుతాయి. ఫైల్‌లో వేరే ఏమీ వాటి కోసం అడగాల్సిన అవసరం లేదు.

Traefik

ఏదైనా రూట్ చేసే ముందు Traefik కు స్టాటిక్ కాన్ఫిగరేషన్ అవసరం. Compose సర్వీసుగా, ఆగస్టు 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

ప్రతి అప్లికేషన్ తన సొంత రూటింగ్‌ను, లేబుల్స్ ద్వారా, తన సొంత 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 అనేది కంటైనర్ లోపల ఉండే పోర్ట్, పబ్లిష్ చేసిన పోర్ట్ కాదు. ఎందుకంటే Traefik షేర్డ్ Docker నెట్‌వర్క్ ద్వారా కంటైనర్‌ను చేరుకుంటుంది. యాప్‌కు ports: లైన్ అసలు అవసరం లేదు, అదే దీని అసలైన ప్రయోజనం: Traefik మాత్రమే పబ్లిష్ చేయబడుతుంది. షేర్డ్ నెట్‌వర్క్ మరియు రీడైరెక్ట్ మిడిల్‌వేర్‌తో సహా పూర్తి బిల్డ్, Traefik మరియు Docker Compose తో బహుళ యాప్‌ల రూటింగ్ లో ఉంది.

ప్రతి అదనపు అప్లికేషన్ కోసం ఎంత కాన్ఫిగరేషన్ అవసరమవుతుంది?

[
  {
    "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
  }
]

పైన పేర్కొన్న బ్లాక్‌ల ఆధారంగా లెక్కించబడింది. Nginx సర్వర్ బ్లాక్ 11 ఖాళీ లేని లైన్లను కలిగి ఉంటుంది, మరియు ప్రతి hostname కోసం మీరు దీన్ని మళ్ళీ రాయాల్సి ఉంటుంది. Caddy సైట్ బ్లాక్ 3 లైన్లను కలిగి ఉంటుంది. Traefik మొదటి అభ్యర్థనను స్వీకరించడానికి ముందు 17 లైన్ల స్టాటిక్ కాన్ఫిగరేషన్ అవసరమవుతుంది, ఆపై ప్రతి అప్లికేషన్‌కు 5 లేబుల్స్ అవసరమవుతాయి.

లాభనష్టాలను గమనించండి, విజేతను మాత్రమే కాదు. మొదటి అప్లికేషన్‌కు ముందు Traefik ఖర్చు ఎక్కువగా ఉంటుంది, కానీ ఆ తర్వాత ప్రతి అప్లికేషన్‌కు అయ్యే ఖర్చు తక్కువ. సుమారు మూడవ సైట్ వద్ద ఈ రెండు మొత్తాలు సమానమవుతాయి. అంతకంటే తక్కువ సైట్లు ఉన్నప్పుడు, స్టాటిక్ కాన్ఫిగరేషన్ అనేది మీకు అవసరం లేని అదనపు భారం. అంతకంటే ఎక్కువ సైట్లు ఉన్నప్పుడు, లేబుల్స్ పద్ధతి మెరుగ్గా ఉంటుంది, ఎందుకంటే రూటింగ్ అనేది అది ఏ సేవకు దారి చూపుతుందో ఆ సేవ పక్కనే ఉంటుంది. ఒక సేవను తొలగిస్తే దాని రూట్ కూడా తొలగిపోతుంది; కేంద్ర కాన్ఫిగరేషన్ ఫైల్‌లో ఇది సాధ్యం కాదు, ఎందుకంటే నెలల క్రితమే నిలిపివేసిన అప్లికేషన్ల పాత సర్వర్ బ్లాక్‌లు అలాగే ఉండిపోతాయి.

లైన్ల సంఖ్య Nginx కు అనుకూలంగా అనిపించవచ్చు. కానీ ఆ ప్రతి బ్లాక్‌కు ఒక symlink, ఒక nginx -t, ఒక reload మరియు ఒక certbot రన్ అవసరం. అదే Caddy ఎడిటింగ్‌కు ఒక reload సరిపోతుంది, Traefik ఎడిటింగ్‌కు ఎటువంటి కమాండ్ అవసరం లేదు. ఈ మూడూ కూడా లైవ్ కనెక్షన్‌లను తొలగించకుండానే reload అవుతాయి. అసలైన తేడా ఏమిటంటే, అర్ధరాత్రి సమయంలో మీరు గుర్తుంచుకోవాల్సిన విడివిడి దశల సంఖ్య.

మీ కంటైనర్ల గురించి ఏది తెలుసుకుంటుంది?

Traefik, Docker socket ను నిరంతరం గమనిస్తూ, కంటైనర్లు ప్రారంభమైనప్పుడు లేదా ఆగిపోయినప్పుడు వాటి labels ఆధారంగా routers ను నిర్మిస్తుంది. ఇక్కడ ఉన్న ఇతర సాధనాలు ఏవీ ఇలా చేయవు. కొత్త కంటైనర్ వచ్చినప్పుడు Nginx మరియు Caddy రెండింటికీ configuration మార్పులు చేసి, reload చేయాల్సి ఉంటుంది. అంతేకాకుండా, అవి చేరుకోగల ఒక చిరునామా కూడా అవసరం: అది loopback పై ప్రచురించబడిన port కావచ్చు, లేదా proxy కి అనుసంధానించబడిన shared Docker network కావచ్చు.

ఈ ఫీచర్‌కు ఒక వెల చెల్లించాల్సి ఉంటుంది, అది స్పష్టంగా చెప్పుకోవాలి. Traefik, /var/run/docker.sock ను చదువుతుంది. ఆ socket తో కమ్యూనికేట్ చేయగల ఎవరైనా, host filesystem ను లోపలికి mount చేసి కంటైనర్‌ను ప్రారంభించగలరు, అంటే అది host పై root యాక్సెస్‌తో సమానం. దీన్ని read-only గా mount చేయడం వల్ల ప్రమాదం తగ్గుతుంది కానీ పూర్తిగా తొలగిపోదు. మీ threat model లో ఇది ముఖ్యమైనది అయితే, Traefik కు అవసరమైన కంటైనర్ జాబితా endpoints ను మాత్రమే అనుమతించే ఒక socket proxy ని మధ్యలో ఉంచండి.

Caddy ఒక community plugin ద్వారా label ఆధారిత discovery ని చేయగలదు, కానీ Caddy plugins ను binary లోకి compile చేయాలి. కాబట్టి మీరు ఒక custom binary ని లేదా xcaddy తో కూడిన custom image ని తయారు చేసుకోవాలి, ఆ తర్వాత ఆ build మరియు దాని updates బాధ్యత మీదే ఉంటుంది. మూడు లేదా నాలుగు సేవల కోసం అయితే, Caddyfile ను ఎడిట్ చేయడం తక్కువ శ్రమతో కూడుకున్న పని.

Websockets మరియు స్ట్రీమింగ్: ఏమి విఫలమవుతాయి, ఎందుకు?

Nginx కు ప్రత్యేకమైన కాన్ఫిగరేషన్ అవసరం. ఒక WebSocket కనెక్షన్ Upgrade: websocket తో కూడిన HTTP అభ్యర్థనగా ప్రారంభమవుతుంది, అయితే మీరు ప్రత్యేకంగా సూచించకపోతే Nginx hop-by-hop హెడర్లను అప్‌స్ట్రీమ్‌కు పంపదు.

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

ఆ తర్వాత, location బ్లాక్ లోపల, ఈ మూడు లైన్లు తప్పనిసరిగా ఉండాలి:

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

వీటిని వదిలేస్తే, బ్రౌజర్ కన్సోల్‌లో WebSocket connection to 'wss://app.example.com/ws' failed అని కనిపిస్తుంది, అదే సమయంలో మీ బ్యాకెండ్ లాగ్‌లో సాధారణ GET అభ్యర్థన మాత్రమే కనిపిస్తుంది. map ఎందుకు అవసరమంటే, హార్డ్‌కోడ్ చేసిన Connection: upgrade ప్రతి అభ్యర్థనపై పంపబడుతుంది, ఇందులో close అని ఉండాల్సిన సాధారణ అభ్యర్థనలు కూడా ఉంటాయి.

Nginx లోని మరో రెండు డిఫాల్ట్ సెట్టింగ్‌లు సమస్యలను కలిగిస్తాయి. proxy_read_timeout 60 సెకన్లుగా ఉంటుంది మరియు ఇది అప్‌గ్రేడ్ తర్వాత టన్నెల్‌కు వర్తిస్తుంది, కాబట్టి ఒక నిమిషం పాటు ట్రాఫిక్ లేని WebSocket కనెక్షన్‌ను ప్రాక్సీ మూసివేస్తుంది. అలాగే, మీరు ఆ లొకేషన్‌లో proxy_buffering off; సెట్ చేసే వరకు, సర్వర్-పంపిన ఈవెంట్‌లు (SSE) ఆలస్యంగా లేదా విడతలుగా వస్తాయి, ఎందుకంటే మీ పేజీ వేచి ఉన్నప్పుడు Nginx ప్రతిస్పందనను తన బఫర్‌లో ఉంచుకుంటుంది.

Caddy ఎటువంటి అదనపు డైరెక్టివ్‌లు లేకుండానే అప్‌గ్రేడ్‌ను పూర్తి చేసి, కనెక్షన్‌ను టూ-వే టన్నెల్‌గా మారుస్తుంది. ప్రతిస్పందన text/event-stream గా ఉన్నప్పుడు లేదా దాని నిడివి తెలియని పక్షంలో ఇది వెంటనే డేటాను పంపుతుంది (flush), కాబట్టి స్ట్రీమింగ్ ఎటువంటి మార్పులు లేకుండా పనిచేస్తుంది. Traefik అప్‌గ్రేడ్‌లను అనుమతిస్తుంది మరియు మీరు స్వయంగా దాని buffering మిడిల్‌వేర్‌ను జోడించకపోతే ప్రతిస్పందనలను బఫర్ చేయదు. మీ సేవల్లో చాట్, వెబ్ టెర్మినల్, లాగ్ టైల్స్ లేదా లైవ్ డాష్‌బోర్డ్‌లు ఉంటే, మీరు ఎంత కాన్ఫిగరేషన్ రాయాలి మరియు డీబగ్ చేయాలి అనే విషయంలో ఇది చాలా తేడాను చూపిస్తుంది.

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

అసాధారణమైన అవసరాలు ఏర్పడినప్పుడు ఏమి జరుగుతుంది?

ఇక్కడే Nginx తన అదనపు సామర్థ్యాలను నిరూపించుకుంటుంది.

• Client certificates, వీటినే mTLS (mutual TLS) అని కూడా అంటారు. ఇందులో క్లయింట్ కూడా ఒక సర్టిఫికేట్‌ను సమర్పించాల్సి ఉంటుంది. Nginx కోసం సర్వర్ బ్లాక్‌లో ssl_client_certificate /etc/ssl/ca.pem; మరియు ssl_verify_client on; అవసరం. Caddy కోసం tls లోపల ఒక client_auth బ్లాక్ అవసరం. Traefik లేబుల్స్ ద్వారా దీన్ని పూర్తిగా అమలు చేయడం సాధ్యం కాదు: మీరు ఫైల్ ప్రొవైడర్‌లో ఒక TLS ఆప్షన్‌ను నిర్వచించి, traefik.http.routers.app.tls.options=mtls@file ద్వారా రూటర్‌ను దానికి పాయింట్ చేయాలి. లేబుల్స్ ద్వారానే అన్నీ నిర్వహించే పద్ధతికి, ఇలాంటి అవసరాలు వచ్చినప్పుడు మినహాయింపు ఇవ్వాల్సి వస్తుంది.
• పెద్ద ఫైల్ అప్‌లోడ్‌లు. Nginx డిఫాల్ట్‌గా రిక్వెస్ట్ బాడీని 1 MB కి పరిమితం చేస్తుంది. అంతకంటే పెద్ద అప్‌లోడ్ చేస్తే 413 Request Entity Too Large ఎర్రర్ వస్తుంది, మరియు ఎర్రర్ లాగ్‌లో client intended to send too large body అని కనిపిస్తుంది. దీని కోసం client_max_body_size ని పెంచాలి. Caddy మరియు Traefik డిఫాల్ట్‌గా ఎటువంటి బాడీ పరిమితిని విధించవు, కాబట్టి రిక్వెస్ట్ నేరుగా మీ అప్లికేషన్‌కు చేరుతుంది మరియు మీ అప్లికేషన్ యొక్క పరిమితిని బట్టి అది నిర్ణయించబడుతుంది.
• రెస్పాన్స్ క్యాషింగ్ (Response caching). Nginx లో proxy_cache ఉంది, ఇది చాలా పరిణతి చెందిన ఫీచర్. Caddy కి దీని కోసం ఒక ప్లగిన్ కంపైల్ చేయాల్సి ఉంటుంది. Traefik యొక్క ఓపెన్ సోర్స్ బిల్డ్‌లో HTTP క్యాష్ అసలు ఉండదు, ప్రతి ప్రాక్సీ క్యాషింగ్ చేస్తుందని భావించే వారికి ఇది ఆశ్చర్యం కలిగించవచ్చు.
• Raw TCP లేదా UDP, డేటాబేస్ పోర్ట్ లేదా గేమ్ సర్వర్ కోసం. Nginx లో stream మాడ్యూల్ ఉంది. Traefik లో వాటి స్వంత ఎంట్రీ పాయింట్లపై TCP మరియు UDP రూటర్లు ఉంటాయి. Caddy కి మరొక ప్లగిన్ అవసరం, అంటే మరొక కస్టమ్ బిల్డ్ అవసరమవుతుంది.
• ప్రాక్సీ వెనుక ఇప్పటికే ఉన్న వెబ్ సర్వర్. ఒకవేళ సేవ ఒక క్లాసిక్ PHP అప్లికేషన్ అయితే, Ubuntu 24.04 పై LAMP stack ఇప్పటికే Apache ని కలిగి ఉంటుంది. ప్రాక్సీని ముందు ఉంచడం వల్ల హెడర్లను సెట్ చేసేవి రెండు, URL ని రీరైట్ చేసేవి రెండు అవుతాయి. TLS termination ఎక్కడ జరగాలో నిర్ణయించుకుని, మరొక దాన్ని loopback కి కట్టుబడి ఉన్న plain HTTP పై ఉంచండి.

ఈ ఎంపికను అనుసరించే ఫైర్‌వాల్ ఉచ్చు

రివర్స్ ప్రాక్సీ యొక్క ముఖ్య ఉద్దేశ్యం కేవలం 80 మరియు 443 పోర్టులను మాత్రమే తెరిచి ఉంచడం. కానీ Docker నిశ్శబ్దంగా ఆ భద్రతను దెబ్బతీస్తుంది. -p 8080:80 తో ఒక పోర్టును పబ్లిష్ చేసినప్పుడు, అది nat టేబుల్‌లోకి ఒక DNAT రూల్‌ను రాస్తుంది. ఈ రూల్ ufw నిర్వహించే INPUT రూల్స్ కంటే ముందే అమలు చేయబడుతుంది. కాబట్టి, ufw deny 8080 ఆ కనెక్షన్‌ను అడ్డుకోలేదు. ఫలితంగా, మీరు ఎంతో జాగ్రత్తగా కాన్ఫిగర్ చేసిన ప్రాక్సీ పక్కనే, మీ అప్లికేషన్ పబ్లిక్ ఇంటర్నెట్‌లో బహిర్గతమవుతుంది. పబ్లిష్ చేసిన పోర్టులను 127.0.0.1:8080:80 తో లూప్‌బ్యాక్ (loopback) కి బైండ్ చేయండి, లేదా ports: ని పూర్తిగా వదిలేసి, పైన పేర్కొన్న Traefik ఉదాహరణలో లాగా Docker నెట్‌వర్క్ ద్వారా ప్రాక్సీని కంటైనర్‌కు చేరుకునేలా చేయండి. దీనికి సంబంధించిన విధానం మరియు పరిష్కారం Docker పబ్లిష్ చేసిన పోర్టులు ufw ని ఎందుకు దాటవేస్తాయి లో ఉంది.

దీనిని మీ VPS కాని మరొక మెషీన్ నుండి పరీక్షించండి, ఎందుకంటే సర్వర్ లోపల నుండి చేసే తనిఖీ ఎల్లప్పుడూ విజయవంతమవుతుంది:

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

Connection refused లేదా టైమ్-అవుట్ రావడం మీరు ఆశించే ఫలితం. ఒకవేళ HTTP రెస్పాన్స్ వస్తే, మీ ప్రాక్సీ ద్వారా వెళ్లకుండానే ఆ అప్లికేషన్ అందుబాటులో ఉందని అర్థం. అప్పుడు మీరు పైన కాన్ఫిగర్ చేసినవన్నీ కేవలం అలంకారప్రాయమే అవుతాయి.

ఏ proxyని ఎంచుకోవాలి?

ఎక్కువగా static సైట్లు, ఒకటి రెండు అప్లికేషన్లు ఉంటే: Caddy. Automatic HTTPS ఉండటం వల్ల తరచుగా చేసే పని తగ్గుతుంది. దీని configuration ఒకే స్క్రీన్‌లో చదివేంత చిన్నదిగా ఉంటుంది. ఒక static సైట్ కోసం అదే site block లో ఒక root లైన్ మరియు ఒక file_server లైన్ సరిపోతాయి. ఏదైనా సమస్య వచ్చినప్పుడు ఇంటర్నెట్‌లో దొరికే పరిష్కారాలు (copy-paste answers) తక్కువగా ఉండటం దీని లోపం.

నిరంతరం కొత్తవి జోడించే docker-compose homelab అయితే: Traefik. మూడవ సర్వీస్ దాటిన తర్వాత, ఒకే ఫైల్‌ను ఎడిట్ చేయడం కంటే labels వాడటం సులభం. ఒక సర్వీస్‌ను తొలగిస్తే, దాని route కూడా ఆటోమేటిక్‌గా తొలగిపోతుంది. మొదటిసారి సెటప్ చేయడానికి ఒక మధ్యాహ్నం సమయం కేటాయించండి, ఎందుకంటే entrypoints, routers, services మరియు middlewares అనేవి కొత్త పదజాలం. label లో చిన్న తప్పు ఉన్నా Traefik సాధారణంగా 404 error చూపిస్తుంది, అప్లికేషన్ స్టార్ట్ అవ్వలేదని కాదు. కాబట్టి అప్లికేషన్ పాడైందని అనుకునే ముందు, parse error కోసం docker logs traefikని తనిఖీ చేయండి.

ఇప్పటికే ఉన్న Nginx config, లేదా పైన పేర్కొన్న వాటిలో ఏదైనా అవసరం ఉంటే: Nginx. దీనిలో response caching మరియు client certificates కోసం ఇప్పటికే పరిష్కారాలు ఉన్నాయి. దాదాపు ప్రతి థర్డ్-పార్టీ గైడ్ Nginx గురించే ఉంటుంది. దీనిలో లోపం ఏమిటంటే, certificates మరియు websocket support వంటివి మీరు మాన్యువల్‌గా కాన్ఫిగర్ చేసుకోవాలి.

మీరు ఏది ఎంచుకున్నా ఒక నియమం వర్తిస్తుంది. పబ్లిక్ ఇంటర్‌ఫేస్‌పై కేవలం ఒక ప్రాసెస్ మాత్రమే వినాలి (listen), మిగిలినవన్నీ loopback లేదా ప్రైవేట్ Docker నెట్‌వర్క్‌పై మాత్రమే ఉండాలి.

FAQ

ఒకే VPSపై కొన్ని Docker అప్లికేషన్ల కోసం ఏ reverse proxy ఉత్తమమైనది?

మీరు అప్పుడప్పుడు జోడించే మూడు లేదా నాలుగు సేవల కోసం Traefik చాలా అనుకూలంగా ఉంటుంది, ఎందుకంటే ప్రతి అప్లికేషన్ దాని స్వంత routing labels ను కలిగి ఉంటుంది మరియు కేంద్ర ఫైల్‌లో ఎటువంటి మార్పులు చేయాల్సిన అవసరం ఉండదు. సేవలు స్థిరంగా ఉండి, HTTPS నిర్వహణ తలనొప్పి లేకుండా ఉండాలనుకుంటే, Caddy నేర్చుకోవడం సులభం మరియు తక్కువ సమస్యలను కలిగిస్తుంది. మీకు ఇప్పటికే Nginx తెలిసినా, లేదా response caching లేదా plain TCP listener వంటి ఇతర రెండింటిలో లేని ఫీచర్లు అవసరమైనప్పుడు Nginx ను ఎంచుకోండి.

Caddy కి నిజంగా certificate కాన్ఫిగరేషన్ అవసరం లేదా?

సాధారణ సందర్భాల్లో, అవును. ఒక public hostname ను site address గా పేర్కొనడమే పూర్తి కాన్ఫిగరేషన్: Caddy ACME ద్వారా certificate ను అభ్యర్థిస్తుంది, port 80 నుండి redirect ను అందిస్తుంది మరియు గడువు ముగిసేలోపు దాన్ని renew చేస్తుంది. అయితే రెండు విషయాలు నిజం కావాలి. HTTP-01 challenge కోసం port 80 ఇంటర్నెట్ నుండి అందుబాటులో ఉండాలి, మరియు hostname యొక్క DNS A లేదా AAAA record ఇప్పటికే VPS కి పాయింట్ అయి ఉండాలి, ఎందుకంటే certificate authority ఆ పేరును resolve చేసి తిరిగి కనెక్ట్ అవుతుంది.

నేను ఒకే VPSపై Nginx మరియు Traefik రెండింటినీ నడపవచ్చా?

ఒకే ports పై సాధ్యం కాదు. ఏది ముందుగా ప్రారంభమైతే అది port ను ఆక్రమిస్తుంది, రెండోది bind అవ్వడంలో విఫలమవుతుంది; అప్పుడు Nginx bind() to 0.0.0.0:443 failed (98: Address already in use) అని చూపిస్తుంది, Traefik కూడా ఇలాంటి bind error నే ఇచ్చి ఆగిపోతుంది. ఏదైనా ఒక proxy ని 80 మరియు 443 ports పై నడపండి, మిగిలిన వాటన్నింటినీ దాని వెనుక ఉంచండి. మీరు మైగ్రేట్ అవుతున్నట్లయితే, hostnames ను ఒక్కొక్కటిగా మార్చండి: చివరి సైట్ మారే వరకు front proxy ద్వారా పాత proxy కి loopback port పై ట్రాఫిక్ పంపండి.

Nginx వెనుక ఉన్న నా websockets 60 సెకన్ల తర్వాత ఎందుకు ఆగిపోతున్నాయి?

proxy_read_timeout డిఫాల్ట్‌గా 60 సెకన్లకు సెట్ చేయబడి ఉంటుంది మరియు upgrade పూర్తయిన తర్వాత ఇది tunnel కి వర్తిస్తుంది. కాబట్టి ఒక నిమిషం పాటు ఎటువంటి ట్రాఫిక్ లేని connection ను మీ అప్లికేషన్ కాకుండా proxy మూసివేస్తుంది. ఆ location లో proxy_read_timeout 3600s; తో దీన్ని పెంచండి, లేదా అప్లికేషన్ ప్రతి 30 సెకన్లకు ఒక ping frame పంపేలా చూడండి. Caddy మరియు Traefik ఒక నిమిషం టైమర్‌తో idle upgraded connections ను మూసివేయవు, అందుకే అదే అప్లికేషన్ వాటి వెనుక స్థిరంగా ఉండి, Nginx వెనుక అస్థిరంగా కనిపిస్తుంది.