Nginx विरुद्ध Caddy विरुद्ध Traefik: कोणता proxy निवडावा?

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

Nginx, Caddy आणि Traefik हे reverse proxy म्हणून समान काम करतात: port 443 वर ऐकतात, प्रत्येक request मधील hostname वाचतात आणि ती तुमच्या VPS वरील योग्य सेवेकडे पाठवतात. या तिन्हीपैकी कोणतेही साधन एका public IP address मागे चार self-hosted apps चालवू शकते. ही सर्व साधने पुरेशी वेगवान आहेत; त्यामुळे तुमचे apps हाच तुलनेने धीमा भाग ठरतील. प्रत्येक साधन TLS (transport layer security) certificate कसे मिळवते आणि प्रत्येक अतिरिक्त app साठी किती 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 कडून प्रमाणपत्र मागते. ही विनंती अपयशी ठरल्यास ते ZeroSSL कडे fallback करते. Caddy port 80 वरून HTTP ते HTTPS redirect देते आणि प्रमाणपत्राचे renewal स्वतः करते. यासाठी दुसरे साधन किंवा तपासण्यासाठी स्वतंत्र timer आवश्यक नसतो. Package install मध्ये प्रमाणपत्रे caddy user च्या data directory मध्ये, /var/lib/caddy/.local/share/caddy येथे साठवली जातात. त्यामुळे हा path backups मध्ये समाविष्ट करा किंवा rebuild नंतर नवीन प्रमाणपत्र मिळवण्याची प्रक्रिया स्वीकारा. सार्वजनिक नसलेल्या hostname साठी Caddy स्वतःच्या local 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 अजून कार्यरत आहे हे सिद्ध करते. चरण-दर-चरण सूचना Nginx सह Ubuntu 24.04 वरील Certbot मध्ये आहेत. Subdomain ची यादी देण्यापेक्षा अधिक subdomain साठी DNS-01 challenge द्वारे wildcard certificate मिळवायचे असल्यास हेच साधन वापरता येते.

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

तिन्ही साधनांसाठी एक गोष्ट समान आहे. HTTP-01 challenge साठी internet वरून port 80 पर्यंत पोहोचता आले पाहिजे, कारण certificate authority त्याच्याशी परत संपर्क करते. फक्त 443 उघडा ठेवल्यास प्रमाणपत्र मिळत नाही आणि ही त्रुटी 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 करा आणि प्रमाणपत्र जोडा.

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

प्रत्येक reload पूर्वी nginx -t ने syntax is ok आणि test is successful छापणे ही तपासणी चालवायची असते. दुसऱ्या अॅपसाठी hostname आणि port बदलून हाच block वापरा. proxy_set_header या ओळी केवळ सजावटीसाठी नाहीत: proxy_pass एखादा address नावाने दाखवते तेव्हा nginx default म्हणून Host: 127.0.0.1:8080 upstream कडे पाठवतो. त्यामुळे Host header वरून absolute URLs तयार करणारे अॅप तुमच्या वापरकर्त्यांना localhost कडे पाठवेल. या चार headers पैकी प्रत्येकाचा उपयोग काय आहे आणि proxy_pass च्या शेवटी trailing slash दिल्याने अॅपला मिळणारा path शांतपणे कसा बदलतो, हे nginx server block च्या या walkthrough मध्ये directive नुसार स्पष्ट केले आहे.

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 कुठून आली याबाबत client तुमच्या backend ला चुकीची माहिती देऊ शकत नाही. दोन site addresses वरून certificates, port 80 redirect आणि renewal आपोआप ठरतात. या file मध्ये त्यासाठी वेगळे काहीही लिहावे लागत नाही.

Traefik

Traefik कोणतेही routing करण्यापूर्वी static configuration आवश्यक असते. August 2026 पर्यंतचा 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: ओळ अजिबात आवश्यक नाही. हाच याचा मुख्य फायदा आहे: केवळ 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 लागतात.

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

Line count मुळे Nginx अधिक सोपा वाटतो. मात्र प्रत्येक block साठी symlink, एक nginx -t, reload आणि certbot run आवश्यक असतो. Caddy edit साठी एक reload पुरतो. Traefik edit साठी कोणतीही 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 ठेवा. तो 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 request दिसते. map आवश्यक आहे, कारण hardcoded Connection: upgrade प्रत्येक request सोबत पाठवले जाईल. यात close असायला हव्यात अशा साध्या request चाही समावेश होईल.

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

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 असल्यास, तुम्हाला लिहावी आणि debug करावी लागणाऱ्या configuration च्या प्रमाणात हा प्रत्यक्ष फरक पडतो.

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 lines उपयुक्त ठरतात.

• 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 define करून traefik.http.routers.app.tls.options=mtls@file वापरून router ला त्याकडे निर्देशित करावे लागते. प्रत्येक गोष्ट labels मध्ये ठेवण्याच्या पद्धतीला ही गरज प्रथमच निर्माण झाल्यावर अपवाद करावा लागतो.
• मोठे 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 वाढवा. Caddy आणि Traefik default ने body limit ठेवत नाहीत. त्यामुळे request तुमच्या app पर्यंत पोहोचते आणि मर्यादा तुमच्या app ची स्वतःची configuration ठरवते.
• Response caching. Nginx मध्ये proxy_cache उपलब्ध आहे आणि ते परिपक्व आहे. Caddy साठी plugin compile करून समाविष्ट करावा लागतो. Traefik च्या open source build मध्ये HTTP cache अजिबात नाही. प्रत्येक proxy caching करतो असे गृहीत धरणाऱ्या लोकांना हे अनपेक्षित वाटते.
• Raw TCP किंवा UDP, उदाहरणार्थ database port किंवा game server साठी. Nginx मध्ये stream module उपलब्ध आहे. Traefik मध्ये स्वतंत्र entrypoints वर TCP आणि UDP routers उपलब्ध आहेत. Caddy साठी आणखी एक plugin आवश्यक आहे. त्यामुळे आणखी एक custom build करावा लागतो.
• Proxy च्या मागे आधीपासून web server असणे. सेवा classic PHP application असल्यास Ubuntu 24.04 वरील LAMP stack मध्ये Apache आधीच समाविष्ट असतो. त्याच्या पुढे proxy लावल्यास headers set करणारी दोन ठिकाणे आणि URL rewrite करणारी दोन ठिकाणे निर्माण होतात. TLS termination कोण करेल ते ठरवा. त्यानंतर दुसऱ्या सेवेला loopback वर plain HTTP वर bind करून ठेवा.

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

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

VPS नसलेल्या मशीनवरून याची चाचणी करा. कारण त्याच मशीनवर चालवलेली चाचणी नेहमी यशस्वी होते:

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

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

तुम्ही कोणता proxy निवडावा?

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

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

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

तुम्ही कोणताही पर्याय निवडला तरी एक नियम लागू राहतो. 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 आवश्यक नसते का?

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

मी एकाच VPS वर Nginx आणि Traefik चालवू शकतो का?

एकाच 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 ने loopback port वरील जुन्या proxy कडे forwarding करू द्या.

Nginx च्या मागे 60 सेकंदांनंतर माझे websockets का disconnect होतात?

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