Nginx, Caddy की Traefik: कोणता reverse proxy निवडावा?

Nginx विरुद्ध Caddy विरुद्ध Traefik: थोडक्यात उत्तर

Nginx, Caddy आणि Traefik हे reverse proxy म्हणून एकच काम करतात: port 443 वर listening करतात, प्रत्येक request मधील hostname वाचतात आणि ती योग्य सेवेकडे तुमच्या VPS वर पाठवतात. या तिन्हीपैकी कोणतेही एक public IP address मागे चार self-hosted अॅप्स चालवू शकते. तिन्ही proxy इतके वेगवान आहेत की प्रत्यक्षात तुमचे अॅप्सच धीमे घटक ठरतील. फरक मुख्यतः प्रत्येक proxy TLS (transport layer security) certificate कसे मिळवतो आणि प्रत्येक अतिरिक्त अॅप जोडण्यासाठी किती configuration आवश्यक असते यात आहे. दुसरा फरक नंतर जाणवतो, जेव्हा नेहमीच्या tutorials मध्ये वगळलेली एखादी गोष्ट आवश्यक ठरते.

HTTPS आपोआप हाताळले जावे आणि तुमच्या सेवा सामान्य web apps असतील, तर Caddy निवडा. सर्वकाही Docker Compose मध्ये चालत असेल आणि तुम्ही दर काही आठवड्यांनी नवीन service जोडत असाल, तर Traefik निवडा. तुम्ही आधीपासून Nginx चालवत असाल, किंवा response caching, client certificates, raw TCP forwarding किंवा मोठी विद्यमान config आवश्यक असेल आणि ती पुन्हा लिहायची नसेल, तर Nginx निवडा.

प्रत्येकाला TLS प्रमाणपत्र कसे मिळते?

बहुतेक लोकांसाठी हा निकष निर्णायक ठरतो, त्यामुळे येथून सुरुवात करा. तिन्ही साधने शेवटी एकाच प्राधिकरणाकडून मिळालेले तेच प्रमाणपत्र वापरतात. ते मिळवण्यासाठी करावी लागणारी प्रक्रिया मात्र वेगळी आहे.

तुम्ही hostname दिल्यामुळे Caddy प्रमाणपत्राची विनंती करते. app.example.com ही site address म्हणून लिहा. त्यानंतर Caddy ACME (automatic certificate management environment) द्वारे Let's Encrypt कडून प्रमाणपत्राची विनंती करते. ती विनंती अयशस्वी झाल्यास Caddy ZeroSSL कडे fallback करते, port 80 वर HTTP ते HTTPS redirect देते आणि प्रमाणपत्राचे renewal स्वतः करते. यासाठी दुसरे साधन किंवा तपासण्यासाठी timer आवश्यक नाही. Package install मध्ये प्रमाणपत्रे caddy user च्या data directory मध्ये, /var/lib/caddy/.local/share/caddy येथे साठवली जातात. त्यामुळे हा path backups मध्ये समाविष्ट करा किंवा पुन्हा build केल्यानंतर नवीन प्रमाणपत्र मिळवण्याची प्रक्रिया स्वीकारा. सार्वजनिक नसलेल्या hostname साठी Caddy स्वतःच्या स्थानिक certificate authority ने tls internal वर स्वाक्षरी करते. त्यामुळे Ubuntu वर self-signed certificate तयार करण्यासारखाच परिणाम मिळतो आणि renewal तुमच्यासाठी स्वयंचलितपणे हाताळले जाते.

Nginx मध्ये ACME client नसतो. Certbot प्रमाणपत्र मिळवते आणि त्याचा --nginx plugin तुमचा server block बदलून 443 listener आणि redirect जोडतो. Package install करणाऱ्या systemd timer मधून renewal चालते. त्यामुळे दोन स्वतंत्र घटक आणि पडताळण्यासाठी दोन गोष्टी असतात: systemctl list-timers | grep certbot वापरल्यावर timer अस्तित्वात आहे हे दिसते, आणि sudo certbot renew --dry-run वापरल्यावर renewal path अजून कार्यरत आहे हे सिद्ध होते. याची step-by-step प्रक्रिया Nginx सह Ubuntu 24.04 वरील Certbot मध्ये दिली आहे. तुमच्याकडे सूचीमध्ये समाविष्ट करण्यापेक्षा अधिक subdomains असतील, तर त्याच साधनाद्वारे DNS-01 challenge द्वारे wildcard certificate देखील मिळवता येते.

Traefik मध्ये स्वतःचा ACME client असतो. Static configuration मध्ये एक certificate resolver configure करा. त्यानंतर प्रत्येक router तो वापरू शकतो. Account key आणि certificates यांसह सर्व state एकाच acme.json file मध्ये साठवली जाते. त्या file ला owner व्यतिरिक्त अन्य कोणालाही read करण्याची परवानगी असल्यास Traefik ती वापरण्यास नकार देते आणि 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

एक directory mount करा आणि Traefik ला file स्वतः तयार करू द्या. touch वापरून ती आधी तयार करा. त्यामुळे तुमचा umask लागू होतो आणि बहुतेकांना हा permission error याच कारणामुळे दिसतो.

तिन्ही साधनांसाठी एक गोष्ट समान आहे. HTTP-01 challenge साठी port 80 इंटरनेटवरून reachable असणे आवश्यक आहे, कारण certificate authority त्या port शी पुन्हा connect करते. फक्त 443 उघडा ठेवला, तर issuance अयशस्वी होते आणि समस्या DNS मध्ये असल्यासारखी दिसते.

तीन कॉन्फिगरेशनमध्ये समान दोन-अॅप routing काम

काम: app.example.com हे 127.0.0.1:8080 वरील सेवेकडे आणि files.example.com हे 127.0.0.1:8081 वरील सेवेकडे जाते. दोन्हींसाठी HTTPS वापरले आहे. verbosity मधील फरक स्पष्टपणे दिसावा म्हणून प्रत्येक proxy मधील संपूर्ण कॉन्फिगरेशन येथे दिले आहे.

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

त्यानंतर त्याची link तयार करा, configuration तपासा, reload करा आणि certificate जोडा.

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 छापणे ही प्रत्येक reload पूर्वी करायची तपासणी आहे. दुसऱ्या अॅपसाठी hostname आणि port बदलून हाच block वापरा. proxy_set_header ओळी केवळ सजावटीसाठी नाहीत: proxy_pass मध्ये एखादा address असल्यास nginx default ने Host: 127.0.0.1:8080 upstream कडे पाठवतो. त्यामुळे Host header वरून absolute URLs तयार करणारे अॅप तुमच्या वापरकर्त्यांना 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

हीच संपूर्ण file आहे. reverse_proxy स्वतः X-Forwarded-For, X-Forwarded-Proto आणि X-Forwarded-Host सेट करते. तसेच default ने client ने त्या headers मध्ये पाठवलेली मूल्ये दुर्लक्षित करते. त्यामुळे request आपल्या backend ला ती कुठून आली याबद्दल चुकीची माहिती देऊ शकत नाही. दोन site addresses वरून certificates, port 80 redirect आणि renewal हे सर्व आपोआप ठरते. त्यासाठी file मध्ये अन्य काही मागण्याची गरज नाही.

Traefik

Traefik कोणतेही routing करण्यापूर्वी static configuration आवश्यक असते. August 2026 पर्यंत current असलेल्या image tag सह Compose service म्हणून:

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

त्यानंतर प्रत्येक application स्वतःचे routing labels मध्ये, स्वतःच्या compose file मध्ये ठेवते:

    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 हा container मधील port आहे, published port नाही, कारण Traefik shared Docker network द्वारे container पर्यंत पोहोचतो. अॅपला ports: line ची अजिबात गरज नाही. हाच याचा मुख्य लाभ आहे: फक्त Traefik published असतो. Shared network आणि redirect middleware सहित संपूर्ण build Traefik आणि Docker Compose सह अनेक अॅप्सचे routing मध्ये दिले आहे.

प्रत्येक अतिरिक्त अॅपसाठी किती configuration लागते?

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

वरील blocks वरून ही मोजणी केली आहे. Nginx server block मध्ये 11 रिकाम्या नसलेल्या lines आहेत आणि प्रत्येक hostname साठी तो पुन्हा लिहावा लागतो. Caddy site block मध्ये 3 lines आहेत. एकही request स्वीकारण्यापूर्वी Traefik ला 17 lines ची static configuration लागते. त्यानंतर प्रत्येक अॅपसाठी 5 labels लागतात.

फक्त कोणता पर्याय विजेता आहे हे पाहू नका; या पर्यायांमधील तडजोड समजून घ्या. पहिल्या अॅपपूर्वी Traefik साठी सर्वाधिक configuration लागते. मात्र त्यानंतर प्रत्येक अॅपसाठी त्याची किंमत सर्वात कमी असते. दोन्ही एकूण आकडे साधारण तिसऱ्या site वर समान होतात. त्यापेक्षा कमी site असतील, तर static configuration अनावश्यक overhead ठरते. त्यापेक्षा जास्त site असतील, तर labels पुढे जातात आणि हा फरक वाढत राहतो, कारण routing संबंधित service च्या जवळच ठेवलेले असते. एखादी service delete केली, तर तिचा route देखील delete होतो. Central config file ची हीच कमतरता आहे: अनेक महिन्यांपूर्वी बंद झालेल्या अॅप्ससाठी stale server blocks तिथे राहू शकतात.

Line count मुळे Nginx अधिक सोयीस्कर असल्याचा भास होतो. प्रत्येक block साठी symlink, एक nginx -t, reload आणि certbot run करावा लागतो. Caddy मध्ये बदल केल्यानंतर एक reload पुरतो. Traefik मध्ये बदल केल्यानंतर कोणतीही command चालवावी लागत नाही. तिन्ही पर्याय live connections बंद न करता reload करता येतात. फरक एवढाच आहे की रात्री एक वाजता लक्षात ठेवाव्या लागणाऱ्या स्वतंत्र steps ची संख्या किती आहे.

तुमच्या कंटेनरची माहिती कोणाला असते?

कंटेनर सुरू किंवा बंद होताना Traefik Docker socket वर लक्ष ठेवतो आणि कंटेनर labels वरून routers तयार करतो. येथे इतर कोणतेही साधन हे करत नाही. नवीन कंटेनर दिसल्यावर Nginx आणि Caddy दोघांनाही configuration संपादित करून reload करावे लागते. तसेच त्यांना पोहोचता येईल असा address आवश्यक असतो: loopback वर प्रकाशित केलेला port किंवा proxy जोडलेले shared Docker network.

या सुविधेची एक किंमत आहे आणि ती स्पष्टपणे सांगणे आवश्यक आहे. Traefik /var/run/docker.sock वाचतो. त्या socket शी संवाद साधू शकणारी कोणतीही व्यक्ती host filesystem कंटेनरमध्ये mount करून कंटेनर सुरू करू शकते. त्यामुळे host वर root प्रवेश मिळतो. तो read only स्वरूपात mount केल्याने धोका कमी होतो, पण पूर्णपणे नाहीसा होत नाही. तुमच्या threat model मध्ये हा धोका महत्त्वाचा असल्यास, मध्ये socket proxy ठेवा. त्या proxy ने Traefik ला आवश्यक असलेले container list endpointsच उपलब्ध करून द्यावेत.

Caddy community plugin द्वारे label based discovery करू शकतो. मात्र Caddy plugins binary मध्ये compile केलेले असतात. त्यामुळे xcaddy सह custom binary किंवा custom image तयार करावी लागते. त्यानंतर त्या build ची आणि त्यातील updates ची जबाबदारी तुमची असते. तीन किंवा चार services साठी Caddyfile संपादित करणे कमी कष्टाचे ठरते.

WebSocket आणि streaming: काय बिघडते आणि का

Nginx ला अतिरिक्त configuration आवश्यक असते. WebSocket connection ची सुरुवात Upgrade: websocket असलेल्या HTTP request ने होते. तुम्ही स्पष्टपणे सांगितले नाही, तर nginx hop-by-hop headers upstream कडे पाठवत नाही.

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

त्यानंतर location block मध्ये खालील तीन ओळी असणे आवश्यक आहे:

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

या ओळी वगळल्यास browser console मध्ये WebSocket connection to 'wss://app.example.com/ws' failed दिसते, तर backend log मध्ये साधी GET दिसते. map आवश्यक आहे, कारण hardcoded Connection: upgrade प्रत्येक request सोबत पाठवले जाईल. यामध्ये साध्या request चाही समावेश होईल, ज्यांनी close सांगणे अपेक्षित आहे.

Nginx ची आणखी दोन default settings अडचण निर्माण करतात. proxy_read_timeout ही 60 seconds असते. Upgrade नंतरच्या tunnel वरही ती लागू होते. त्यामुळे एका मिनिटभर network traffic नसलेले WebSocket connection proxy बंद करते. तसेच location वर proxy_buffering off; सेट करेपर्यंत server-sent events उशिरा किंवा एकत्रित bursts मध्ये येतात. याचे कारण nginx response आपल्या buffer मध्ये ठेवते आणि page त्याची प्रतीक्षा करत राहते.

Caddy कोणत्याही directives शिवाय upgrade पूर्ण करते आणि connection चे two-way tunnel मध्ये रूपांतर करते. Response text/event-stream असेल किंवा त्याची लांबी ज्ञात नसेल, तर Caddy तो लगेच flush करते. त्यामुळे streaming साठी अतिरिक्त configuration आवश्यक नसते. Traefik upgrades पुढे पाठवते आणि तुम्ही स्वतःचे buffering middleware जोडले नाही, तर responses buffer करत नाही. तुमच्या services मध्ये chat, web terminal, log tails किंवा live dashboards असतील, तर तुम्हाला किती configuration लिहावी आणि debug करावी लागेल यात हा प्रत्यक्ष फरक आहे.

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 मधील अतिरिक्त configuration directives उपयुक्त ठरतात.

• Client certificates, ज्यांना mTLS (mutual TLS) असेही म्हणतात. यात client ने certificate सादर करणे आवश्यक असते. 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 मधून configure करण्याच्या पद्धतीला ही आवश्यकता प्रथमच अपवाद ठरते.
• मोठे uploads. Nginx मध्ये request body ची कमाल मर्यादा default ने 1 MB असते. त्यापेक्षा मोठे upload केल्यास 413 Request Entity Too Large मिळते आणि error log मध्ये client intended to send too large body नोंदवले जाते. client_max_body_size ची value वाढवा. Caddy आणि Traefik मध्ये default ने body limit नसते. त्यामुळे request तुमच्या app पर्यंत पोहोचते आणि मर्यादा तुमच्या app मधील configuration ठरवते.
• 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 मध्ये स्वतंत्र entrypoints वर TCP आणि UDP routers उपलब्ध आहेत. Caddy साठी आणखी एक plugin आवश्यक आहे. त्यामुळे पुन्हा custom build करावा लागतो.
• Proxy च्या मागे आधीपासून web server असल्यास. सेवा पारंपरिक PHP application असल्यास Ubuntu 24.04 वरील LAMP stack मध्ये Apache आधीच समाविष्ट असतो. Proxy त्याच्या पुढे ठेवल्यास headers सेट करणारी दोन ठिकाणे आणि URL rewrite करणारी दोन ठिकाणे तयार होतात. TLS termination कोण करणार हे ठरवा. त्यानंतर दुसऱ्या सेवेला loopback वर bind करून plain HTTP वर चालू ठेवा.

या निवडीमुळे उद्भवणारा firewall trap

reverse proxy चा उद्देश फक्त 80 आणि 443 उघडे ठेवणे हा आहे. Docker हे नियंत्रण नकळत मोडून काढतो. -p 8080:80 वापरून port publish केल्यास nat table मध्ये DNAT rule लिहिला जातो. हा rule ufw व्यवस्थापित करत असलेल्या INPUT rules च्या आधी तपासला जातो. त्यामुळे ufw deny 8080 तो block करू शकत नाही. परिणामी, तुम्ही काळजीपूर्वक configure केलेल्या proxy च्या शेजारी तुमचे app थेट public internet वर उपलब्ध होते. Published ports loopback ला bind करण्यासाठी 127.0.0.1:8080:80 वापरा. किंवा ports: पूर्णपणे काढून टाका आणि proxy ला Docker network द्वारे container पर्यंत पोहोचू द्या. वरील Traefik उदाहरणात हीच पद्धत वापरली आहे. ही यंत्रणा आणि तिचे निराकरण Docker published ports ufw ला का bypass करतात येथे दिले आहे.

ही चाचणी VPS व्यतिरिक्त दुसऱ्या मशीनवरून करा. कारण स्वतः VPS वर चालवलेली तपासणी नेहमी यशस्वी होते:

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

तुम्हाला Connection refused किंवा timeout मिळणे अपेक्षित आहे. HTTP response मिळाल्यास ते app तुमच्या proxy मार्गे न जाता थेट reachable आहे. अशा वेळी तुम्ही वर configure केलेल्या सर्व गोष्टी केवळ दिखावा ठरतात.

कोणता proxy निवडावा?

मुख्यतः static sites आणि एक-दोन अॅप्स: Caddy. Automatic HTTPS मुळे वारंवार करावे लागणारे सर्वात मोठे काम दूर होते. Configuration एका स्क्रीनवर वाचता येईल इतकी लहान राहते. Static site साठी त्याच site block मध्ये root line आणि file_server line एवढेच आवश्यक असते. मात्र काही अनपेक्षित बिघाड झाल्यास copy-paste करता येतील अशा उत्तरांचा उपलब्ध संच लहान असतो.

तुम्ही सतत वाढवत असलेला docker-compose homelab: Traefik. तिसऱ्या सेवेपुढे गेल्यावर केंद्रीय file संपादित करण्यापेक्षा labels वापरणे कमी कष्टाचे ठरते. एखादी service हटवल्यावर तिचा route देखील आपोआप हटतो. पहिल्या setup साठी एक दुपार राखून ठेवा, कारण entrypoints, routers, services आणि middlewares ही सर्व नवीन संज्ञा असतात. Label मधील typo बहुतेक वेळा Traefik कडून 404 म्हणून दिसतो, startup failure म्हणून नाही. त्यामुळे अॅप बिघडले आहे असे गृहीत धरण्यापूर्वी parse error साठी docker logs traefik वाचा.

आधीपासून असलेले Nginx configuration किंवा वरील यादीतील कोणतीही आवश्यकता: Nginx. Response caching आणि client certificates साठी त्यात आधीपासून उपाय उपलब्ध आहेत. जवळपास प्रत्येक third-party guide त्याचा आधार घेतो. मात्र certificates आणि websocket support यांची configuration तुम्हालाच करावी लागते.

तुम्ही कोणताही proxy निवडला तरी एक नियम लागू राहतो. Public interface वर नेमकी एकच process listen करते. इतर सर्व process loopback किंवा private Docker network वर listen करतात.

FAQ

काही Docker अॅप्स एका VPS वर चालवण्यासाठी कोणता reverse proxy सर्वोत्तम आहे?

तुम्ही अधूनमधून जोडणार असलेल्या तीन किंवा चार सेवांसाठी Traefik उपयुक्त ठरतो, कारण प्रत्येक अॅपमध्ये त्याचे routing labels असतात आणि मध्यवर्ती फाइलमध्ये बदल करण्याची गरज नसते. सेवा स्थिर असतील आणि HTTPS ची जबाबदारी स्वतःकडे ठेवायची नसेल, तर Caddy शिकायला सोपे आणि बिघडण्याची शक्यता कमी असते. Nginx आधीपासून परिचित असल्यास ते निवडा. तसेच इतर दोन्हीमध्ये नसलेले response caching किंवा plain TCP listener यांसारखे वैशिष्ट्य आवश्यक असल्यासही Nginx निवडा.

Caddy ला खरोखर certificate configuration ची गरज नसते का?

सामान्य परिस्थितीत, होय. Site address म्हणून public hostname देणे हीच संपूर्ण configuration असते. Caddy ACME द्वारे certificate मागवतो, port 80 वरून redirect देतो आणि certificate expire होण्यापूर्वी त्याचे renewal करतो. तरीही दोन अटी पूर्ण असणे आवश्यक आहे. HTTP-01 challenge साठी port 80 इंटरनेटवरून reachable असला पाहिजे. तसेच hostname चा DNS A किंवा AAAA record VPS कडे निर्देश करणारा असला पाहिजे. Certificate authority नाव resolve करून VPS शी पुन्हा connect करते.

Nginx आणि Traefik एकाच VPS वर चालवता येतात का?

एकाच ports वर नाही. जो दुसरा सुरू होईल तो bind करू शकणार नाही. Nginx bind() to 0.0.0.0:443 failed (98: Address already in use) दाखवतो, तर Traefik समान bind error log करून बंद होतो. एक proxy 80 आणि 443 वर चालवा आणि इतर सर्व सेवा त्यामागे ठेवा. Migration करत असल्यास hostnames एकावेळी एक हलवा. शेवटची site हलवेपर्यंत front proxy ने जुन्या proxy कडे loopback port वर forwarding करू द्या.

Nginx मागे माझे websockets 60 seconds नंतर बंद का होतात?

proxy_read_timeout चे default मूल्य 60 seconds आहे. Upgrade पूर्ण झाल्यानंतर ते tunnel वर लागू होते. त्यामुळे एका minute पर्यंत कोणताही traffic नसलेले connection तुमच्या अॅपऐवजी proxy बंद करते. त्या location साठी proxy_read_timeout 3600s; ने timeout वाढवा. किंवा application ने प्रत्येक 30 seconds ने ping frame पाठवावा. Caddy आणि Traefik idle upgraded connections एक minute च्या timer वर बंद करत नाहीत. त्यामुळे तेच अॅप त्यांच्या मागे stable दिसू शकते, पण Nginx मागे unstable दिसते.