Nginx vs Caddy vs Traefik: ఏ రివర్స్ ప్రాక్సీ ఎంచుకోవాలి?

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

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

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

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

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

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

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

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

ప్రతి అప్లికేషన్ తన సొంత కాన్ఫిగరేషన్ ఫైల్‌లో, లేబుల్స్ ద్వారా తన రూటింగ్‌ను కలిగి ఉంటుంది:

    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 ఆధారంగా రౌటర్లను నిర్మిస్తుంది. ఇక్కడ మరే ఇతర సాధనం ఇలా చేయదు. Nginx మరియు Caddy రెండింటికీ కొత్త కంటైనర్ వచ్చినప్పుడు కాన్ఫిగరేషన్ మార్పు మరియు reload అవసరం. అలాగే, అవి చేరుకోగల ఒక చిరునామా కూడా అవసరం: అది loopback పై ప్రచురించబడిన port కావచ్చు, లేదా proxy అనుసంధానించబడిన ఒక shared Docker network కావచ్చు.

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

Caddy ఒక కమ్యూనిటీ ప్లగిన్ ద్వారా label ఆధారిత డిస్కవరీని చేయగలదు, కానీ Caddy ప్లగిన్లు బైనరీలో కంపైల్ చేయబడతాయి. కాబట్టి మీరు ఒక custom binary ని లేదా xcaddy తో కూడిన custom image ని నిర్మించాలి, ఆ తర్వాత ఆ బిల్డ్ మరియు దాని అప్‌డేట్‌ల బాధ్యత మీదే అవుతుంది. మూడు లేదా నాలుగు సేవల కోసం అయితే, 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; సెట్ చేసే వరకు, server-sent events ఆలస్యంగా లేదా విడతలుగా వస్తాయి, ఎందుకంటే మీ పేజీ స్పందన కోసం వేచి ఉన్నప్పుడు 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 కోసం server block లో ssl_client_certificate /etc/ssl/ca.pem; మరియు ssl_verify_client on; అవసరం. Caddy కోసం tls లోపల ఒక client_auth block ఉండాలి. Traefik labels ద్వారా దీన్ని నేరుగా పేర్కొనలేము: మీరు file provider లో ఒక TLS option ను నిర్వచించి, traefik.http.routers.app.tls.options=mtls@file ద్వారా router ను దానికి మళ్లించాలి. ప్రతిదీ labels లోనే ఉంచే పద్ధతికి, ఇలాంటి అవసరం వచ్చినప్పుడు మినహాయింపు ఇవ్వాల్సి వస్తుంది.
• పెద్ద ఫైల్ అప్‌లోడ్‌లు. Nginx డిఫాల్ట్‌గా request body పరిమితిని 1 MB కి ఉంచుతుంది. అంతకంటే పెద్ద అప్‌లోడ్ చేస్తే 413 Request Entity Too Large వస్తుంది, మరియు error log లో client intended to send too large body అని కనిపిస్తుంది. దీని కోసం client_max_body_size ను పెంచాలి. Caddy మరియు Traefik డిఫాల్ట్‌గా ఎటువంటి body పరిమితిని విధించవు, కాబట్టి request మీ అప్లికేషన్‌కు చేరుతుంది మరియు మీ అప్లికేషన్ యొక్క పరిమితి నిర్ణయాత్మకం అవుతుంది.
• Response caching. Nginx లో proxy_cache ఉంది, ఇది చాలా పరిణతి చెందిన ఫీచర్. Caddy కి దీని కోసం ఒక plugin ను compile చేయాల్సి ఉంటుంది. Traefik యొక్క open source build లో HTTP cache అసలు ఉండదు, ఇది ప్రతి proxy కి cache ఉంటుందని భావించే వారికి ఆశ్చర్యం కలిగిస్తుంది.
• Raw TCP లేదా UDP, database port లేదా game server కోసం. Nginx లో stream module ఉంది. Traefik లో TCP మరియు UDP routers వాటి స్వంత entrypoints పై పనిచేస్తాయి. Caddy కి దీని కోసం మరొక plugin అవసరం, అంటే మరొక custom build చేయాలి.
• Proxy వెనుక ఇప్పటికే ఉన్న web server. ఒకవేళ సేవ ఒక classic PHP అప్లికేషన్ అయితే, Ubuntu 24.04 పై LAMP stack లో ఇప్పటికే Apache ఉంటుంది. దీని ముందు మరొక proxy ని ఉంచితే, headers సెట్ చేయడానికి మరియు URL ను rewrite చేయడానికి రెండు వేర్వేరు చోట్లు ఉంటాయి. ఏది 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 రెస్పాన్స్ వస్తే, మీ ప్రాక్సీ ద్వారా వెళ్లకుండానే ఆ అప్లికేషన్ అందుబాటులో ఉందని అర్థం; అప్పుడు మీరు పైన కాన్ఫిగర్ చేసినవన్నీ కేవలం అలంకారప్రాయమే అవుతాయి.

మీరు ఏ ప్రాక్సీని ఎంచుకోవాలి?

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

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

ఇప్పటికే ఉన్న Nginx కాన్ఫిగరేషన్ లేదా పైన పేర్కొన్న వాటిలో ఏదైనా ప్రత్యేక అవసరం ఉంటే: Nginx. రెస్పాన్స్ క్యాచింగ్ (response caching) మరియు క్లయింట్ సర్టిఫికెట్ల కోసం దీనికి ఇప్పటికే పరిష్కారాలు ఉన్నాయి. దాదాపు ప్రతి థర్డ్-పార్టీ గైడ్ Nginx నే ప్రామాణికంగా తీసుకుంటుంది. అయితే, సర్టిఫికెట్లు మరియు వెబ్‌సాకెట్ సపోర్ట్ వంటివి మీరు సొంతంగా కాన్ఫిగర్ చేసుకోవాల్సి ఉంటుంది, ఇవి ఆటోమేటిక్‌గా రావు.

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

FAQ

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

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

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

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

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

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

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

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