Nginx، Caddy یا Traefik: کون سا proxy منتخب کریں؟

Nginx بمقابلہ Caddy بمقابلہ Traefik: مختصر جواب

Nginx، Caddy اور Traefik سبھی reverse proxy کے طور پر ایک ہی کام کرتے ہیں: port 443 پر listening کرتے ہیں، ہر request میں hostname پڑھتے ہیں، اور اسے آپ کے VPS پر درست service تک پہنچا دیتے ہیں۔ ان تینوں میں سے کوئی بھی ایک public IP address کے پیچھے چار self-hosted apps چلا سکتا ہے، اور یہ سب اتنے تیز ہیں کہ سست رفتار کا اصل سبب آپ کی apps ہوں گی۔ فرق اس بات میں ہے کہ ہر ایک TLS (transport layer security) certificate کیسے حاصل کرتا ہے، اور ہر اضافی app کے لیے کتنی configuration درکار ہوتی ہے۔ دوسرا فرق بعد میں سامنے آتا ہے، جب آپ کو ایسی ضرورت پیش آتی ہے جسے عام tutorials نظرانداز کرتے ہیں۔

اگر آپ چاہتے ہیں کہ HTTPS خودکار طور پر manage ہو اور آپ کی services عام web apps ہوں، تو Caddy منتخب کریں۔ اگر سب کچھ Docker Compose میں چلتا ہے اور آپ ہر چند ہفتوں بعد نئی service شامل کرتے ہیں، تو Traefik منتخب کریں۔ اگر آپ پہلے ہی Nginx چلا رہے ہیں، یا آپ کو response caching، client certificates، raw TCP forwarding، یا بڑی موجودہ config درکار ہے جسے آپ دوبارہ لکھنا نہیں چاہتے، تو 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 سے HTTPS redirect فراہم کرتا ہے، اور خود certificate renew کرتا ہے۔ کسی دوسرے tool یا جانچنے کے لیے timer کی ضرورت نہیں ہوتی۔ Certificates caddy user کی data directory میں محفوظ ہوتے ہیں۔ Package installation میں یہ directory /var/lib/caddy/.local/share/caddy ہوتی ہے، اس لیے اس path کو اپنے backups میں شامل کریں، یا rebuild کے بعد نیا certificate جاری ہونے کو قبول کریں۔ ایسے hostname کے لیے جو public نہ ہو، Caddy اپنی مقامی certificate authority سے tls internal پر دستخط کرتا ہے۔ اس کا نتیجہ Ubuntu پر self-signed certificate بنانے جیسا ہی ہوتا ہے، لیکن renewal آپ کے لیے خودکار طور پر ہو جاتی ہے۔

Nginx میں ACME client شامل نہیں ہوتا۔ Certbot certificate حاصل کرتا ہے، اور اس کا --nginx plugin آپ کے server block میں تبدیلی کر کے 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 سے زیادہ ہوں، تو یہی tool DNS-01 challenge کے ذریعے wildcard certificate کے لیے بھی استعمال ہوتا ہے۔

Traefik اپنا ACME client ساتھ رکھتا ہے۔ Static configuration میں ایک certificate resolver configure کریں، پھر ہر router اسے استعمال کر سکتا ہے۔ تمام state، جس میں account key اور certificates بھی شامل ہیں، ایک ہی acme.json file میں محفوظ ہوتی ہے۔ اگر یہ file owner کے علاوہ کسی اور کے لیے readable ہو تو 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 ملتا ہے، اور زیادہ تر لوگ اسی طرح اس شرط پر پورا اترتے ہیں۔

تینوں کے بارے میں ایک بات یکساں ہے۔ HTTP-01 challenge کے لیے port 80 کا internet سے reachable ہونا ضروری ہے، کیونکہ certificate authority اسی port سے واپس connect کرتی ہے۔ صرف 443 کھولنے سے issuance ناکام ہو جاتی ہے، اور خرابی DNS fault جیسی دکھائی دیتی ہے۔

تین configurations میں وہی دو ایپس route کرنے کا کام

کام یہ ہے: app.example.com کو 127.0.0.1:8080 پر موجود service تک، اور files.example.com کو 127.0.0.1:8081 پر موجود service تک بھیجنا ہے، دونوں HTTPS کے ذریعے۔ ہر proxy میں مکمل configuration یہاں دی گئی ہے، تاکہ verbosity کا فرق صرف بیان کرنے کے بجائے واضح طور پر نظر آئے۔

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 test کریں، 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 دکھانا وہ check ہے جو ہر reload سے پہلے چلانا چاہیے۔ دوسری app کے لیے یہی block استعمال کریں، صرف hostname اور port تبدیل کریں۔ proxy_set_header والی سطریں محض ظاہری نہیں ہیں: جب proxy_pass کسی address کو نامزد کرتا ہے تو nginx بطور default Host: 127.0.0.1:8080 upstream بھیجتا ہے۔ اس لیے جو app Host header سے absolute URLs بناتی ہے، وہ آپ کے users کو 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 set کرتا ہے، اور بطور default client کے بھیجے ہوئے ان headers میں موجود values کو نظرانداز کرتا ہے۔ اس لیے request آپ کے backend کو اپنے origin کے بارے میں غلط معلومات نہیں دے سکتی۔ Certificates، port 80 redirect اور renewal، سب دو site addresses سے خودکار طور پر متعین ہوتے ہیں۔ File میں کسی اور چیز کو ان کے لیے configure کرنے کی ضرورت نہیں ہے۔

Traefik

Traefik کو routing شروع کرنے سے پہلے static configuration درکار ہوتی ہے۔ Compose service کے طور پر، اور August 2026 تک موجودہ image tag کے ساتھ:

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 اپنے compose file میں labels کے ذریعے رکھتی ہے:

    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 تک پہنچتا ہے۔ App کو ports: والی کسی line کی ضرورت نہیں، اور یہی اصل فائدہ ہے: صرف Traefik publish ہوتا ہے۔ 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 non-blank lines ہوتی ہیں، اور ہر hostname کے لیے اسے دوبارہ لکھنا پڑتا ہے۔ Caddy site block میں 3 lines ہوتی ہیں۔ Traefik ایک بھی request serve کرنے سے پہلے static configuration کی 17 lines چاہتا ہے، پھر ہر ایپ کے لیے 5 labels درکار ہوتے ہیں۔

صرف فاتح کو نہ دیکھیں؛ اس تبادلے کو سمجھیں۔ پہلی ایپ شامل کرنے سے پہلے Traefik کی لاگت سب سے زیادہ ہے، لیکن اس کے بعد ہر ایپ کے لیے لاگت سب سے کم رہتی ہے، اور دونوں مجموعے تقریباً تیسری site پر برابر ہو جاتے ہیں۔ اس سے کم sites پر static configuration غیر ضروری اضافی کام ہے۔ اس سے زیادہ sites پر labels آگے نکل جاتے ہیں اور فرق بڑھتا رہتا ہے، کیونکہ routing اسی service کے قریب رہتی ہے جس کے لیے وہ مقرر ہے۔ Service حذف کریں تو اس کا route بھی ساتھ حذف ہو جاتا ہے۔ یہی وہ کام ہے جس میں مرکزی config file کمزور ہوتی ہے: ایسی 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 بناتا ہے۔ یہاں کوئی اور سافٹ ویئر یہ کام نہیں کرتا۔ نیا container ظاہر ہونے پر Nginx اور Caddy دونوں میں configuration edit اور reload ضروری ہے۔ انہیں ایسا address بھی درکار ہوتا ہے جس تک وہ پہنچ سکیں: یا تو loopback پر published port، یا مشترکہ Docker network جس سے proxy منسلک ہو۔

اس سہولت کی ایک قیمت ہے، اور اسے واضح طور پر بیان کرنا ضروری ہے۔ Traefik /var/run/docker.sock پڑھتا ہے۔ جو بھی اس socket سے بات کر سکتا ہے، وہ ایسا container start کر سکتا ہے جس میں host filesystem mount ہو۔ اس سے اسے host پر root access مل جاتا ہے۔ اسے read-only mode میں mount کرنے سے خطرہ کم ہوتا ہے، لیکن ختم نہیں ہوتا۔ اگر آپ کے threat model میں یہ اہم ہے تو درمیان میں socket proxy رکھیں۔ یہ proxy صرف وہ container-list endpoints expose کرے جن کی Traefik کو ضرورت ہے۔

Caddy community plugin کے ذریعے label-based discovery کر سکتا ہے، لیکن Caddy plugins binary میں compile ہوتے ہیں۔ اس لیے آپ کو xcaddy کے ساتھ custom binary یا custom image بنانی ہوگی، اور پھر اس build اور اس کی updates کی ذمہ داری بھی آپ کی ہوگی۔ تین یا چار services کے لیے Caddyfile میں edit کرنا کم محنت کا کام ہے۔

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 کے اندر یہ تینوں lines موجود ہونی چاہییں:

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

اگر یہ lines شامل نہ ہوں تو browser console میں WebSocket connection to 'wss://app.example.com/ws' failed دکھائی دیتا ہے، جبکہ backend log میں عام GET نظر آتا ہے۔ map اس لیے موجود ہے کہ hardcoded Connection: upgrade ہر request کے ساتھ بھیجا جائے گا، حتیٰ کہ ان عام requests کے ساتھ بھی جن میں close ہونا چاہیے۔

Nginx کی دو مزید default settings بھی مسئلہ پیدا کرتی ہیں۔ proxy_read_timeout کی مدت 60 seconds ہے، اور upgrade کے بعد tunnel پر لاگو ہوتی ہے۔ اس لیے ایک minute تک network traffic نہ رکھنے والا WebSocket proxy کے ذریعے بند ہو جاتا ہے۔ Server-sent events بھی دیر سے یا وقفے وقفے سے موصول ہوتے ہیں، جب تک آپ اس location پر proxy_buffering off; set نہ کریں، کیونکہ آپ کے page کے response کا انتظار کرتے وقت nginx اسے اپنے buffer میں روکے رکھتا ہے۔

Caddy بغیر کسی directive کے upgrade انجام دیتا ہے اور connection کو دو طرفہ tunnel میں تبدیل کر دیتا ہے۔ جب response text/event-stream ہو یا اس کی length معلوم نہ ہو، تو یہ فوراً flush بھی کر دیتا ہے۔ اس لیے streaming میں کسی تبدیلی کی ضرورت نہیں پڑتی۔ Traefik بھی upgrades کو آگے بھیج دیتا ہے اور responses کو buffer نہیں کرتا، جب تک آپ خود اس کا buffering middleware شامل نہ کریں۔ اگر آپ کی 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 مؤثر ثابت ہوتی ہے۔

• 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 میں رکھنے والے model میں استثنا پیدا ہو جاتا ہے۔
• بڑی uploads۔ Nginx بطور default request bodies کو 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 کی اپنی limit کرتی ہے۔
• Response caching۔ Nginx میں proxy_cache موجود ہے اور یہ پختہ implementation ہے۔ Caddy کے لیے plugin کو build میں شامل کرنا پڑتا ہے۔ 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۔ اگر service ایک classic PHP application ہے تو Ubuntu 24.04 پر LAMP stack میں Apache پہلے ہی شامل ہے، اور اس کے سامنے proxy رکھنے سے دو ایسی جگہیں بن جاتی ہیں جہاں headers set ہو سکتے ہیں اور دو ایسی جگہیں جہاں URL rewrite ہو سکتا ہے۔ طے کریں کہ TLS termination کون کرے گا، پھر دوسرے server کو loopback پر plain HTTP کے ساتھ bind رکھیں۔

اس انتخاب کے بعد پیدا ہونے والا firewall کا مسئلہ

Reverse proxy کا مقصد یہ ہے کہ صرف 80 اور 443 کھلے ہوں۔ Docker خاموشی سے اس اصول کو ختم کر دیتا ہے۔ -p 8080:80 کے ذریعے port publish کرنے سے nat table میں DNAT rule شامل ہو جاتا ہے۔ یہ rule ان INPUT rules سے پہلے evaluate ہوتا ہے جنہیں ufw manage کرتا ہے۔ اس لیے ufw deny 8080 اسے block نہیں کرتا، اور آپ کی app اس proxy کے ساتھ public internet پر دستیاب ہو جاتی ہے جسے آپ نے احتیاط سے configure کیا تھا۔ Published ports کو 127.0.0.1:8080:80 کے ذریعے loopback پر bind کریں، یا ports: کو مکمل طور پر ہٹا دیں اور proxy کو Docker network کے ذریعے container تک پہنچنے دیں۔ اوپر Traefik کی مثال یہی طریقہ استعمال کرتی ہے۔ اس mechanism اور fix کی وضاحت Docker کے published ports ufw کو bypass کیوں کرتے ہیں میں موجود ہے۔

اسے ایسی machine سے test کریں جو VPS نہ ہو، کیونکہ خود اسی box پر چلایا گیا check ہمیشہ کامیاب ہوتا ہے:

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

Connection refused یا timeout وہ نتیجہ ہے جو آپ چاہتے ہیں۔ HTTP response کا مطلب ہے کہ app آپ کے proxy سے گزرے بغیر reachable ہے، اور اوپر کی گئی تمام configuration بے فائدہ ہے۔

کون سا proxy منتخب کرنا چاہیے؟

زیادہ تر static sites، اور ساتھ ایک یا دو ایپس: Caddy۔ خودکار HTTPS آپ کے سب سے بڑے بار بار ہونے والے انتظامی کام کو ختم کر دیتا ہے۔ configuration اتنی مختصر رہتی ہے کہ ایک ہی screen پر پڑھی جا سکتی ہے، اور static site اسی site block کے اندر ایک root line اور ایک file_server line پر مشتمل ہوتی ہے۔ اس کی قیمت یہ ہے کہ کچھ غیر معمولی خرابی آنے پر copy-paste کے لیے دستیاب جوابات کم ہوتے ہیں۔

ایسا docker-compose homelab جس میں آپ مسلسل نئی سروسز شامل کرتے رہتے ہیں: Traefik۔ تیسری service کے بعد labels میں تبدیلی کرنا مرکزی file میں ترمیم کرنے سے کم محنت طلب ہوتا ہے، اور حذف کی گئی service اپنا route بھی ساتھ لے جاتی ہے۔ پہلی setup کے لیے ایک دوپہر مختص کریں، کیونکہ entrypoints، routers، services اور middlewares سب نئی اصطلاحات ہیں۔ label میں typo عموماً start ہونے میں ناکامی کے بجائے 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 کرے، اور باقی تمام processes loopback یا private Docker network پر listen کریں۔

FAQ

چند Docker ایپس کے لیے ایک VPS پر کون سا reverse proxy بہتر ہے؟

تین یا چار ایسی services کے لیے جنہیں آپ وقتاً فوقتاً شامل کرتے ہیں، Traefik اپنا انتخاب درست ثابت کرتا ہے، کیونکہ ہر ایپ اپنی routing labels رکھتی ہے اور مرکزی file میں ترمیم کی ضرورت نہیں ہوتی۔ اگر services مستحکم ہیں اور آپ بنیادی طور پر HTTPS کی انتظامی ذمہ داری ختم کرنا چاہتے ہیں تو Caddy سیکھنے میں آسان اور خراب ہونے کے امکانات میں کم ہے۔ Nginx کا انتخاب اس وقت کریں جب آپ اسے پہلے سے جانتے ہوں، یا جب آپ کو ایسی feature درکار ہو جو باقی دونوں میں موجود نہ ہو، مثلاً response caching یا plain TCP listener۔

کیا Caddy کو واقعی certificate configuration کی ضرورت نہیں ہوتی؟

عام صورت میں، ہاں۔ کسی public hostname کو site address کے طور پر درج کرنا ہی مکمل configuration ہے: Caddy ACME کے ذریعے certificate طلب کرتا ہے، port 80 سے redirect فراہم کرتا ہے، اور expiry سے پہلے certificate renew کرتا ہے۔ تاہم دو باتیں پھر بھی ضروری ہیں۔ HTTP-01 challenge کے لیے port 80 کا internet سے قابل رسائی ہونا ضروری ہے، اور hostname کا DNS A یا AAAA record پہلے ہی VPS کی طرف اشارہ کر رہا ہو، کیونکہ certificate authority نام resolve کر کے اس سے دوبارہ connect کرتی ہے۔

کیا میں اسی VPS پر Nginx اور Traefik چلا سکتا ہوں؟

ایک ہی ports پر نہیں۔ جو بھی دوسرے نمبر پر start ہوگا، وہ bind کرنے میں ناکام ہو جائے گا، اور nginx bind() to 0.0.0.0:443 failed (98: Address already in use) دکھائے گا، جبکہ Traefik اسی نوعیت کی bind error log کر کے exit ہو جائے گا۔ ایک proxy کو 80 اور 443 پر چلائیں، اور باقی تمام چیزیں اس کے پیچھے رکھیں۔ اگر آپ migration کر رہے ہیں تو hostnames کو ایک ایک کر کے منتقل کریں: جب تک آخری site منتقل نہ ہو جائے، front proxy کو loopback port پر موجود پرانے proxy تک forward کرتے رہیں۔

Nginx کے پیچھے میرے websockets 60 seconds کے بعد کیوں disconnect ہو جاتے ہیں؟

proxy_read_timeout کی default value 60 seconds ہے، اور upgrade مکمل ہونے کے بعد یہ tunnel پر لاگو ہوتی ہے۔ اس لیے ایک منٹ تک network traffic نہ ہونے والی connection کو آپ کی app کے بجائے proxy بند کر دیتا ہے۔ اس location پر proxy_read_timeout 3600s; کے ذریعے timeout بڑھائیں، یا application کو ہر 30 seconds بعد ping frame بھیجنے دیں۔ Caddy اور Traefik ایک منٹ کے timer پر idle upgraded connections بند نہیں کرتے، اسی لیے وہی app ان کے پیچھے مستحکم، مگر Nginx کے پیچھے غیر مستحکم دکھائی دے سکتی ہے۔