Nginx बनाम Caddy बनाम Traefik: कौन सा प्रॉक्सी चुनें?

Nginx बनाम Caddy बनाम Traefik: संक्षिप्त उत्तर

Nginx, Caddy और Traefik तीनों एक reverse proxy के रूप में समान कार्य करते हैं: port 443 पर listen करना, प्रत्येक request में hostname को पढ़ना और उसे आपके VPS पर सही service तक पहुँचाना। इन तीनों में से कोई भी एक public IP address के पीछे चार self-hosted apps को व्यवस्थित कर सकता है, और ये सभी इतने तेज हैं कि आपकी apps ही performance में bottleneck बनेंगी। अंतर केवल इस बात में है कि प्रत्येक tool TLS (transport layer security) certificate कैसे प्राप्त करता है और प्रत्येक अतिरिक्त app को configure करने में कितनी मेहनत लगती है। एक और अंतर तब सामने आता है जब आपको ऐसी किसी चीज की आवश्यकता होती है जिसे सामान्य tutorials में छोड़ दिया जाता है।

यदि आप चाहते हैं कि HTTPS का प्रबंधन स्वतः हो जाए और आपकी services सामान्य web apps हैं, तो Caddy चुनें। यदि सब कुछ Docker Compose में चलता है और आप हर कुछ हफ्तों में एक नई service जोड़ते हैं, तो Traefik चुनें। यदि आप पहले से ही Nginx का उपयोग कर रहे हैं, या आपको response caching, client certificates, raw TCP forwarding, या किसी ऐसे बड़े existing configuration की आवश्यकता है जिसे आप फिर से नहीं लिखना चाहते, तो Nginx चुनें।

प्रत्येक को TLS certificate कैसे मिलता है?

यह आधार अधिकांश लोगों के लिए निर्णय लेने का मुख्य बिंदु है, इसलिए यहीं से शुरुआत करें। अंत में तीनों ही एक ही authority से एक ही certificate प्राप्त करते हैं। लेकिन वहां तक पहुँचने के लिए किया जाने वाला कार्य अलग-अलग है।

Caddy certificate के लिए अनुरोध करता है क्योंकि आपने एक hostname दिया है। app.example.com को site address के रूप में लिखें और Caddy ACME (automatic certificate management environment) के माध्यम से Let's Encrypt से certificate का अनुरोध करता है। यदि वह विफल रहता है, तो यह ZeroSSL पर वापस आ जाता है, port 80 पर HTTP-to-HTTPS redirect को serve करता है, और स्वयं ही renew करता है। इसके लिए किसी दूसरे टूल या जाँच करने के लिए किसी timer की आवश्यकता नहीं होती है। Certificates, caddy user की data directory में रहते हैं, जो package install होने पर /var/lib/caddy/.local/share/caddy होती है, इसलिए उस path को अपने backups में शामिल करें या rebuild के बाद नए issuance को स्वीकार करें। यदि hostname public नहीं है, तो tls internal इसके बजाय Caddy की अपनी local certificate authority के साथ sign करता है। यह आपको वही परिणाम देता है जो Ubuntu पर self-signed certificate बनाना से मिलता है, जिसमें renewal आपके लिए प्रबंधित होता है।

Nginx में कोई ACME client नहीं होता है। Certbot certificate प्राप्त करता है, और इसका --nginx plugin आपके server block को rewrite करके 443 listener और redirect जोड़ देता है। Renewal एक systemd timer से चलता है जिसे package install करता है, इसलिए इसमें दो गतिशील हिस्से और जाँचने के लिए दो चीजें होती हैं: systemctl list-timers | grep certbot दिखाता है कि timer मौजूद है, और sudo certbot renew --dry-run साबित करता है कि renewal path अभी भी काम कर रहा है। चरण-दर-चरण प्रक्रिया Nginx के साथ Ubuntu 24.04 पर Certbot में दी गई है, और जब आपके पास सूचीबद्ध करने की इच्छा से अधिक subdomains हों, तो वही टूल DNS-01 challenge के माध्यम से wildcard certificate को भी कवर करता है।

Traefik का अपना ACME client होता है। आप static configuration में एक certificate resolver configure करते हैं, और फिर प्रत्येक router उसका उपयोग कर सकता है। सारा state, जिसमें account key और certificates शामिल हैं, एक ही acme.json file में रहता है। यदि उस file को उसके owner के अलावा कोई और पढ़ सकता है, तो 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 को inherit कर लेगा, जो कि अधिकांश लोगों के लिए इस त्रुटि का कारण बनता है।

तीनों के लिए एक बात समान है। HTTP-01 challenge के लिए internet से port 80 तक पहुँच होना आवश्यक है, क्योंकि certificate authority वापस उसी से connect करती है। यदि केवल 443 open है, तो issuance इस तरह विफल हो जाएगा जैसे कि यह कोई 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

इसके बाद प्रत्येक एप्लिकेशन अपनी राउटिंग को अपनी 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 के साथ कई ऐप्स को रूट करना में उपलब्ध है।

प्रत्येक अतिरिक्त app के लिए 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 non-blank lines होती हैं, और आपको हर hostname के लिए इसे फिर से लिखना पड़ता है। Caddy site block में 3 lines होती हैं। Traefik को पहली request serve करने से पहले 17 lines की static configuration चाहिए होती है, और उसके बाद प्रति app 5 labels की आवश्यकता होती है।

व्यापार के लाभ-हानि को समझें, न कि केवल विजेता को। Traefik की लागत पहले app से पहले सबसे अधिक होती है और उसके बाद प्रत्येक app के लिए सबसे कम, और ये दोनों totals लगभग तीसरी site पर बराबर हो जाते हैं। उससे कम sites होने पर, static configuration एक अनावश्यक overhead है। उससे अधिक होने पर, labels बेहतर साबित होते हैं क्योंकि routing उस service के पास ही रहती है जिसे वह route करती है। service को delete करने पर उसका route भी हट जाता है, जो कि एक central config file की सबसे बड़ी कमी है: उन apps के लिए stale server blocks का बने रहना जो महीनों पहले बंद हो चुके हैं।

line count Nginx के पक्ष में दिखती है, लेकिन यह पूरी सच्चाई नहीं है। इन blocks में से प्रत्येक के लिए एक symlink, एक nginx -t, एक reload और एक certbot run की आवश्यकता होती है, जबकि Caddy edit के लिए केवल एक reload और Traefik edit के लिए किसी command की आवश्यकता नहीं होती। तीनों ही live connections को गिराए बिना reload हो जाते हैं। मुख्य अंतर उन अलग-अलग steps की संख्या है जिन्हें आपको रात के एक बजे याद रखना पड़ता है।

आपके containers के बारे में किसे जानकारी है?

Traefik Docker socket को monitor करता है और containers के start या stop होने पर उनके labels से routers बनाता है। यहाँ मौजूद अन्य कोई भी tool ऐसा नहीं करता है। Nginx और Caddy दोनों को ही नए container के आने पर configuration edit करने और reload करने की आवश्यकता होती है, साथ ही उन्हें एक ऐसे address की जरूरत होती है जिसे वे access कर सकें: या तो loopback पर published कोई port, या proxy से जुड़ा हुआ कोई shared Docker network।

इस feature की एक कीमत है, और इसे स्पष्ट रूप से बताना आवश्यक है। Traefik /var/run/docker.sock को read करता है। जो कोई भी उस socket से बात कर सकता है, वह host filesystem को mount करके container start कर सकता है, जो host पर root access के बराबर है। इसे read-only mount करने से जोखिम कम हो जाता है, लेकिन पूरी तरह खत्म नहीं होता। यदि यह आपके threat model के लिए महत्वपूर्ण है, तो बीच में एक socket proxy लगाएँ जो केवल उन container list endpoints को expose करे जिनकी Traefik को आवश्यकता है।

Caddy एक community plugin के माध्यम से label-आधारित discovery कर सकता है, लेकिन Caddy plugins को compile करना पड़ता है, इसलिए आपको xcaddy के साथ एक custom binary या custom image बनानी होगी और फिर उस build और उसके updates की जिम्मेदारी आपकी होगी। तीन या चार services के लिए, Caddyfile को edit करना कम मेहनत का काम है।

Websockets और streaming: क्या खराब होता है और क्यों

Nginx को अतिरिक्त सहायता की आवश्यकता होती है। एक WebSocket कनेक्शन HTTP request के रूप में शुरू होता है जिसमें Upgrade: websocket होता है, और जब तक आप निर्देश न दें, nginx hop-by-hop headers को upstream तक नहीं भेजता है।

# /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 प्रिंट करता है जबकि आपका backend log एक सामान्य GET दिखाता है। map का अस्तित्व इसलिए है क्योंकि एक hardcoded Connection: upgrade हर request पर भेजा जाएगा, जिसमें वे plain requests भी शामिल हैं जिन्हें close कहना चाहिए।

Nginx की दो और default सेटिंग्स समस्या पैदा करती हैं। proxy_read_timeout 60 सेकंड है और यह upgrade के बाद tunnel पर लागू होता है, इसलिए एक मिनट तक बिना traffic वाला websocket proxy द्वारा बंद कर दिया जाता है। और server-sent events देर से या टुकड़ों में आते हैं जब तक कि आप उस location पर proxy_buffering off; सेट न कर दें, क्योंकि nginx response को अपने buffer में रखता है जबकि आपका पेज उसके लिए प्रतीक्षा करता है।

Caddy upgrade को निष्पादित करता है और कनेक्शन को बिना किसी निर्देश के two-way tunnel में बदल देता है। यह तुरंत डेटा भेजता है जब response text/event-stream होता है या उसकी लंबाई ज्ञात नहीं होती है, इसलिए streaming बिना किसी बदलाव के काम करती है। Traefik upgrades को पास करता है और responses को buffer नहीं करता है जब तक कि आप स्वयं उसका buffering middleware न जोड़ें। यदि आपकी 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 अपनी अतिरिक्त लाइनों की सार्थकता सिद्ध करता है।

• 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 को उसकी ओर निर्देशित करना होगा। जब आपको इसकी पहली बार आवश्यकता होती है, तो everything-in-labels मॉडल में एक अपवाद आ जाता है।
• Large uploads. Nginx डिफ़ॉल्ट रूप से request bodies को 1 MB पर सीमित करता है। बड़ा upload होने पर 413 Request Entity Too Large error मिलता है, और error log में client intended to send too large body दिखाई देता है। इसके लिए client_max_body_size को बढ़ाएं। Caddy और Traefik डिफ़ॉल्ट रूप से कोई body limit सेट नहीं करते हैं, इसलिए request सीधे आपके app तक पहुँचती है और आपके app की अपनी limit ही निर्णय लेती है।
• 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. यदि service एक classic PHP application है, तो Ubuntu 24.04 पर LAMP stack में पहले से ही Apache शामिल होता है, और इसके आगे proxy लगाने से आपको दो स्थान मिलते हैं जहाँ headers सेट किए जा सकते हैं और दो स्थान जहाँ URL को rewrite किया जा सकता है। तय करें कि TLS termination कहाँ करना है, फिर दूसरे को loopback पर bound plain HTTP पर रखें।

इस विकल्प के बाद आने वाली firewall की समस्या

Reverse proxy का मुख्य उद्देश्य केवल 80 और 443 ports को खुला रखना है। Docker चुपचाप इसे बदल देता है। -p 8080:80 के साथ port publish करने पर nat table में एक DNAT rule लिख जाता है। यह rule ufw द्वारा प्रबंधित INPUT rules से पहले evaluate होता है, इसलिए ufw deny 8080 इसे block नहीं कर पाता। परिणाम यह होता है कि आपका app उस proxy के साथ सार्वजनिक internet पर खुला रहता है जिसे आपने बहुत सावधानी से configure किया था। Published ports को 127.0.0.1:8080:80 के साथ loopback पर bind करें, या ports: का उपयोग पूरी तरह बंद कर दें और proxy को Docker network के माध्यम से container तक पहुँचने दें, जैसा कि ऊपर दिए गए Traefik उदाहरण में किया गया है। इसका तंत्र और समाधान Docker published ports ufw को क्यों bypass करते हैं में दिया गया है।

इसे उस machine से test करें जो VPS नहीं है, क्योंकि स्वयं server पर किया गया check हमेशा सफल ही रहेगा:

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

Connection refused या timeout ही वह परिणाम है जो आपको चाहिए। यदि HTTP response मिलता है, तो इसका अर्थ है कि app आपके proxy से गुजरे बिना ही पहुँच योग्य है, और आपने ऊपर जो कुछ भी configure किया है वह केवल दिखावा है।

आपको कौन सा प्रॉक्सी चुनना चाहिए?

ज्यादातर static sites, और साथ में एक या दो apps: Caddy. Automatic HTTPS आपके सबसे बड़े आवर्ती काम को खत्म कर देता है। इसका configuration इतना छोटा होता है कि एक स्क्रीन पर ही पढ़ा जा सकता है, और एक static site को उसी site block के अंदर केवल एक root लाइन और एक file_server लाइन की आवश्यकता होती है। इसकी कीमत यह है कि जब कुछ अजीब समस्या आती है, तो इंटरनेट पर कॉपी-पेस्ट करने के लिए समाधानों का दायरा छोटा होता है।

एक docker-compose homelab जिसमें आप लगातार नई चीजें जोड़ते हैं: Traefik. तीसरी service के बाद, central file को edit करने की तुलना में labels का उपयोग करना कम मेहनत वाला होता है, और एक service को delete करने पर उसका route भी अपने आप हट जाता है। पहली बार setup करने के लिए एक दोपहर का समय रखें, क्योंकि entrypoints, routers, services और middlewares पूरी तरह से नई शब्दावली हैं। label में कोई typo होने पर Traefik आमतौर पर 404 error दिखाता है, न कि service start होने में विफलता, इसलिए यह मान लेने से पहले कि app खराब है, parse error के लिए docker logs traefik को जरूर पढ़ें।

एक मौजूदा Nginx config, या ऊपर दी गई सूची की कोई भी आवश्यकता: Nginx. इसमें response caching और client certificates के लिए पहले से ही समाधान मौजूद हैं, और लगभग हर third-party guide इसी को आधार मानकर लिखी जाती है। इसकी कीमत यह है कि certificates और websocket support को आपको खुद configure करना पड़ता है, ये चीजें पहले से तैयार नहीं मिलतीं।

आप चाहे जिसे भी चुनें, एक नियम हमेशा लागू होता है। public interface पर केवल एक process listen करती है, और बाकी सब loopback या private Docker network पर listen करती हैं।

FAQ

एक VPS पर कुछ Docker apps के लिए कौन सा reverse proxy सबसे अच्छा है?

तीन या चार ऐसी services के लिए जिन्हें आप कभी-कभार जोड़ते हैं, Traefik सबसे बेहतर है, क्योंकि प्रत्येक app में उसकी अपनी routing labels होती हैं और किसी central file को edit करने की आवश्यकता नहीं होती। यदि services स्थिर हैं और आप मुख्य रूप से HTTPS की समस्याओं से छुटकारा पाना चाहते हैं, तो Caddy को सीखना आसान है और इसमें गड़बड़ी की संभावना कम है। Nginx तब चुनें जब आप इसे पहले से जानते हों, या जब आपको किसी ऐसी सुविधा की आवश्यकता हो जो अन्य दो में नहीं है, जैसे response caching या plain TCP listener।

क्या Caddy को वास्तव में किसी certificate configuration की आवश्यकता नहीं है?

सामान्य मामलों में, हाँ। एक public hostname को site address के रूप में लिखना ही पूरी configuration है: Caddy ACME के माध्यम से certificate का अनुरोध करता है, port 80 से redirect प्रदान करता है, और expiry से पहले उसे renew कर देता है। इसके लिए दो शर्तें पूरी होनी चाहिए। HTTP-01 challenge के लिए port 80 का internet से reachable होना आवश्यक है, और hostname का DNS A या AAAA record पहले से ही VPS पर point करना चाहिए, क्योंकि certificate authority नाम को resolve करती है और वापस उसी से connect करती है।

क्या मैं एक ही VPS पर Nginx और Traefik चला सकता हूँ?

एक ही ports पर नहीं। जो भी बाद में start होगा वह bind होने में विफल हो जाएगा, और Nginx bind() to 0.0.0.0:443 failed (98: Address already in use) error देगा, जबकि Traefik भी इसी तरह का bind error लॉग करेगा और बंद हो जाएगा। एक proxy को 80 और 443 पर चलाएं, और बाकी सब कुछ उसके पीछे रखें। यदि आप migrate कर रहे हैं, तो hostnames को एक-एक करके move करें: front proxy को तब तक पुराने proxy पर loopback port के माध्यम से forward करने दें जब तक कि आखिरी site move न हो जाए।

Nginx के पीछे मेरे websockets 60 seconds के बाद क्यों बंद हो जाते हैं?

proxy_read_timeout का default मान 60 seconds है और यह upgrade पूरा होने के बाद tunnel पर लागू होता है, इसलिए एक मिनट तक traffic न होने पर connection को आपके app के बजाय proxy द्वारा बंद कर दिया जाता है। इसे उस location पर proxy_read_timeout 3600s; के साथ बढ़ाएं, या application को हर 30 seconds में एक ping frame भेजने के लिए कहें। Caddy और Traefik एक मिनट के timer पर idle upgraded connections को बंद नहीं करते हैं, यही कारण है कि वही app उनके पीछे स्थिर रह सकता है और Nginx के पीछे अस्थिर हो जाता है।